Dlaczego nie wdrożyć 1 Gb / s, gdy wszystko, czego potrzebuję, to 20 Mb / s?


27

tło

Współpracuję z klientem przy dużym projekcie, który wymaga zaprojektowania niestandardowego układu sieciowego w celu rozwiązania wymagań dotyczących transferu danych w ramach projektu. Sieć ma przesyłać małe pakiety kilka cali z jednej płytki drukowanej na drugą za pomocą jednego skrętki komputerowej. Będziemy projektować i określać protokół sieciowy, a inna firma będzie odpowiedzialna za wdrożenie krzemu.

Szacuję, że szybkość przesyłania danych między węzłami wynosząca 20 Mb / s z łatwością poradzi sobie z ilością danych, które należy wysłać, z dużą ilością miejsca na wypadek, gdyby ilość danych wzrosła w przyszłości.

Problem

Klient pyta mnie, dlaczego określam tylko 20 Mb / s. Dlaczego nie coś takiego jak 1 Gbps? Czy nie byłoby lepiej? Intuicyjnie uważam, że znaczne zwiększenie szybkości przesyłania danych powyżej tego, co byłoby potrzebne, jest złym pomysłem. Początkowo myślałem, że okablowanie będzie musiało być ekranowane (czego nie chcę), ale patrząc na kategorie kabli Ethernet, widzę, że Gigabit Ethernet może działać na kablu Cat 6, który nie musi być ekranowany.

Inne ograniczenia

  • Projekt jest rozpaczliwie ograniczony przestrzenią i czy nie mamy miejsca na takie rzeczy jak magnetyka, chyba że jest to bardzo mały element (maks. 0603).
  • Kable muszą być możliwie cienkie i elastyczne.
  • Urządzenie będzie działać z zasilania wtyczki, więc nie ma szczególnego zapotrzebowania na niskie zużycie energii.

Pytanie

Jakie są problemy, jeśli chodzi o konstrukcję krzemu, okablowanie i cokolwiek innego, z czym można się zmierzyć przy prędkości 1 Gb / s, co nie byłoby tak złe przy prędkości 20 Mb / s? Czy powinienem pójść za sugestią mojego klienta dotyczącą wdrożenia sieci z prędkością 1 Gb / s, czy też powinienem nalegać na wdrożenie tylko tego, co jest wymagane?

Jesteśmy pod ścisłą NDA, więc nie mogę podać zbyt wielu szczegółów na temat naszych wymagań. Ale proszę zostawić komentarz, jeśli konieczne jest wyjaśnienie.


3
Jeśli aplikacja potrzebuje przepustowości 20 Mb / s, prawdopodobnie wystarczający byłby starszy o 100 Mb / s standard, biorąc pod uwagę wszystkie koszty ogólne. Pytanie dotyczy więc kosztów wdrożenia, dostępności przyszłych części. Czy sprawdziłeś odpowiednie koszty? Co masz na myśli mówiąc „pod względem konstrukcji silikonowej”? Czy planujesz zaprojektować własny krzem?
Ale..chenski

9
1 Gb / s może być przesadą ... 100 Mb / s może być bardziej odpowiednim następnym krokiem w szybkości .... jeśli klient jest zainteresowany zabezpieczeniem urządzenia na przyszłość, może zapoznaj się z wykorzystaniem kompresji danych ...... klient, ile przepustowości danych uzyskuje się przy 20 Mb / s ... pokaż mu wideo HD na YouTube i wyjaśnij, że przepustowość wynosi tylko 8
Mb

12
Dlaczego potrzebujesz protokołu „sieciowego” dla połączenia punkt-punkt?
Photon

20
Projektowanie „protokołu sieciowego” od zera nie wydaje się szczególnie mądrym pomysłem. Może to być dość kosztowne w przypadku projektowania, wdrażania warstwy fizycznej, sprawdzania poprawności warstwy fizycznej, a następnie warstwy protokołu, całego powiązanego oprogramowania i jej sprawdzania itp. Itp. Czy słyszałeś o HSIC, rodzaju USB ponad 1.2VLVCMOS?
Ale..chenski

20
Proszę, połączcie demo ze 100M ethernetowymi układami scalonymi bez magnesów, aby zaprezentować je użytkownikowi i sobie, co można zrobić za pomocą standardowych części z półki. Nie rób niestandardowego krzemu, niestandardowych protokołów, bez zrozumienia, dlaczego standardowe protokoły tego nie zrobią.
Neil_UK

Odpowiedzi:


24

Kilka powodów:

Moc

Większa prędkość oznacza więcej mocy. Potrzebujesz nie tylko szybszych obwodów analogowych, które zużyją więcej energii, ale cała otaczająca je elektronika musi być szybsza. Twoje systemy cyfrowe, zatrzaski, zarządzanie zegarem itp. Jeśli uzyskasz 1 Gb / s za pomocą wielopoziomowej sygnalizacji, potrzebujesz teraz lepszych przetworników ADC i DAC. Może być konieczne rozpoczęcie bardziej skomplikowanego filtrowania. Możesz zacząć wymagać FEC, który również musi nadążyć.

Rozmiar wiórów

Szybszy oznacza więcej. Potrzebujesz lepszej stabilności zegara, co oznacza większe obwody. Potrzebujesz lepszego czasu, co oznacza bardziej złożony system odzyskiwania zegara. Konieczne może być przejście na używanie DSP w celu wyrównywania kanałów. Potencjalnie potrzebny FEC potrzebuje obszaru chipowego.

Wrażliwość na środowisko

Jeśli zmienisz z kilkudziesięciu megabaud na wszystko, co jest potrzebne do gigabit, staniesz się znacznie bardziej wrażliwy na środowisko. Małe niedopasowania, które mogą być niezauważalne przy kilkudziesięciu MHz, stają się rezonansowymi odcinkami przy wyższych częstotliwościach. Refleksje mogą zacząć powodować przerywane działanie. Kabel z nacięciem z powodu nadużywania przez lata (nie znam środowiska aplikacji dla twojego produktu) może być odpowiedni dla niższych prędkości, ale może powodować niską wydajność, gdy idziesz wyżej.

Wysiłek projektowy

Myślę, że ze wszystkich dodatkowych kwestii, które omówiłem powyżej, wynika, że ​​czas i wysiłek związany z zaprojektowaniem szybszego łącza komunikacyjnego jest znaczący. Już samo to powinno wystarczyć.

EMI

Większa prędkość oznacza, że ​​spełnienie wymagań EMI może być trudniejsze.


5
@Rocketmagnet: Warto również zauważyć, że rzeczywisty gigabit E 802.3aseBase-T przez Cat5e wysyła sygnały w obu kierunkach jednocześnie przez 4 pary przewodów, a także przy użyciu kodowania wielopoziomowego, aby utrzymać częstotliwości na tym samym poziomie 125 MHz jako 100Base-T . Każdy odbiornik musi więc odjąć to, co wysyła własny nadajnik, aby otrzymać tylko sygnał wysyłany przez drugi koniec.
Peter Cordes

2
@PeterCordes - To bardzo interesujące, przyjrzę się temu. Ale to brzmi jak znacznie bardziej złożona niż podstawowy LVDS.
Rocketmagnet

2
@Rocketmagnet: tak, GigE brzmi jak bardzo zły wybór. Jest powód, dla którego transceiver GigE zużywają więcej energii niż 100M.
Peter Cordes

24

Sygnały TTL (single-ended, niezakończone) mogą z łatwością obsłużyć 20 Mb / s lub więcej - na przykład SPI. Jeśli masz tylko kilka cali, kabel wstążkowy i złącza IDC (lub pewnego rodzaju płyta montażowa) poprowadzą cię od deski do deski.

1 Gb / s przenosi Cię w sferę radzenia sobie ze śladami, złączami i kablami o kontrolowanej impedancji. Odbiorniki będą musiały stosować techniki PLL / DLL w celu utrzymania synchronizacji i oddzielnego zegara / danych, podczas gdy przy niższej prędkości wystarczająca będzie normalna logika synchroniczna. Przepełnienie 50 × i dodatkowe problemy głowy po prostu nie są tego warte, jeśli jesteś pewien, że 20 Mb / s wystarczy w dającej się przewidzieć przyszłości.


Kiedyś zaprojektowałem (25 lat temu) niestandardowy protokół magistrali szeregowej do sterowania kartą i kartą w szafie telekomunikacyjnej. Coś w rodzaju skrzyżowania I 2 C i SPI - sygnały jednokierunkowe, takie jak SPI, ale adresy urządzeń osadzonych, takie jak I 2 C.


Zakładając, że już zamierzamy używać śladów, kabli i złączy kontrolowanych impedancją, czy są jakieś inne problemy?
Rocketmagnet

1
Odbiorniki będą musiały korzystać z technik PLL / DLL w celu utrzymania synchronizacji i oddzielnego zegara / danych. Przy wolniejszej prędkości wystarcza normalna logika synchroniczna.
Dave Tweed

10
Zależy to od szczegółów dotyczących technologii implementacji, których prawdopodobnie nie możesz ujawnić. Jeśli korzystasz z układów FPGA (jak sugeruje to użycie tagu), pamiętaj, że wszyscy główni dostawcy mają rozwiązania w zakresie komunikacji między układami z różnymi prędkościami. Zaleca się użycie tego dla warstwy fizycznej i zaimplementowanie na niej niestandardowego protokołu.
Dave Tweed

1
Zaprojektowanie bloku PLL nie jest trywialne, a zakup IP może łatwo przywrócić ci 50-100 tys. Dolarów
Mike

1
@Tustique Myślisz, że zaprojektowanie własnego PLL na krzemie jest trywialne?
user253751,

14

Oczywiste pytanie brzmi: „Czy 1 Gb / s oznacza 1000BASET Ethernet?” Jeśli tak myśli klient, wymóg, że „nie mamy miejsca na rzeczy takie jak magnesy”, wyklucza to od razu. Ethernet korzysta z magnetyzmu na warstwie fizycznej, a kiedy kilka lat temu zaprojektowałem interfejs, był on częścią mniej więcej 1 calowej kostki.

Mówisz, że używasz układów FPGA, ale nie mówisz, czyje. Jeśli korzystasz z Xilinx, powinieneś mieć świadomość, że obecne modele natywnie obsługują LVDS, co wydaje się idealne do Twoich celów. Wczesne systemy LVDS (telewizory hi-def) działały z prędkością 122 Mb / s, a technologia może znacznie przewyższyć Gb / s, jeśli naprawdę tego potrzebujesz. Odróżniając się i zakładając, że dwie deski nie używają dziko pływających gruntów, odporność na hałas jest doskonała.

Jeśli chodzi o konkretny wybór częstotliwości zegara, zwiększenie rezerwy, niż myślisz, że potrzebujesz, to jedna z tych decyzji, które mogą uratować twój bekon w przyszłości, więc nie wykluczę wybrania czegoś takiego jak 100 MHz, ale to zależy od ciebie. Możesz zapoznać swojego klienta z prawem Roberge'a (Jim Roberge był znanym profesorem elektrotechniki w MIT kilka dekad temu): „Ci, którzy proszą o większą przepustowość niż potrzebują, zasługują na to, co otrzymują”. To prawda, że ​​mówił o systemach serwo, ale zasada pozostaje dobra w niezwykle szerokim zakresie dyscyplin.


7
Ethernet nie potrzebuje magnesów, jeśli wykonujesz niestandardowe połączenie. Jest całkiem niezawodny, jeśli zostanie wdrożony bez izolacji.
Jack Creasey,

1
@JackCreasey, ale czy nadal można to nazwać Ethernetem ?
Mels

2
Z pewnością nie jest zgodny z IEEE 802.3. Nie połączy się ze zgodnym punktem końcowym, ale powiedziałem, że byłby niezgodny bez magnesów. Wątpię, czy przekazałby pakiet testowy sygnałów dla połączenia na płycie montażowej, ale powinien przekazać wszystko inne, w tym jitter. Nadal nazwałbym to Ethernet, ale ty możesz nie.
Jack Creasey,

2
Do Twojej wiadomości: jedyny wynik Google dla „Ci, którzy proszą o większą przepustowość niż potrzebują, zasługują na to, co otrzymują”. jest ta odpowiedź.
user253751,

11

Opisana przez Ciebie aplikacja nie ma sensu wskakiwać od razu do niestandardowego rozwiązania krzemowego. Szybkości transmisji danych, których się spodziewasz, można łatwo obsłużyć za pomocą niedrogiej technologii FPGA, a FPGA można zaprogramować do implementacji specjalnego protokołu, jeśli naprawdę uważasz, że taki protokół jest potrzebny.

Znacznie częściej powinieneś rozważyć standardową warstwę fizyczną, a następnie zbudować niestandardowy protokół. W przypadku przepustowości kanału komunikacji sieciowej wynoszącej 20 Mb / s powinieneś zaplanować pewien narzut protokołu, ponieważ kadrowanie, kodowanie błędów i synchronizacja pochłaniają część przepustowości. Może więc rozważyć wyższą przepustowość, aby uwzględnić ten narzut.

Po sprawdzeniu projektu możesz udać się do dostawcy FPGA i poprosić go o wykonanie projektu twardego układu z programowania FPGA. Takie podejście zmniejsza całe ryzyko wczesnego rozwoju i obniża ogólne koszty NRE w porównaniu z „zanurzeniem się w niestandardowym krzemie tylko dlatego, że wydaje się fajny”.


To dokładnie trasa, którą zamierzamy obrać.
Rocketmagnet

11

Rzeczywiste pytanie brzmi: po co projektować protokół, gdy wszystko już istnieje.

W przypadku rozwiązań Ethenet bierzesz 10/100, a nie 1GbE, ponieważ wciąż jest nieco tańszy i znacznie łatwiejszy do rozmieszczenia. Nawiasem mówiąc, Ethernet może działać bez magnesów. Ale wymaga MAC, który może być dodatkowym układem scalonym. A może masz mikrokontroler?

20 Mb / s to coś, co pasuje do RS485 lub takiej warstwy, co jest jeszcze tańsze i prostsze. Skręcone pary są wyposażone w różnego rodzaju kable, mniej lub bardziej elastyczne, ze złączami lub po prostu wlutowane do płytki drukowanej.

Ach, najważniejsze. Łatwiej jest zepsuć 1 Gb. Ale jeśli potrzebują miejsca na dalszy wzrost, ogranicza to mniej.

Podsumowując: musisz zrozumieć wymagania systemowe.


10

Sugerowałbym, że najprostszą drogą z największym prawdopodobieństwem sukcesu i najmniejszym nakładem oprogramowania byłoby wdrożenie połączenia Ethernet 100 Mb / s. Możesz to zrealizować bez udziału magnesów, gdy odległości są małe.

Oto początek z informacjami o kontrolerze Intel 8255 PCI-Ethernet oraz uwagą dotyczącą aplikacji bez połączeń magnetycznych.
Nie sugeruję, abyś używał 8255, ale możesz uzyskać IP (10/100/1000 Mb / s) dla dowolnego układu FPGA, którego prawdopodobnie będziesz używać bardzo łatwo, i jest dobrze debugowany.

Zakładając, że masz procesor w miksie, obsługa standardowego kontrolera Ethernet jest bardzo niskim nakładem programowym na wdrożenie sieci punkt-punkt.
Wykorzystaliśmy kilka tego typu połączeń typu punkt-punkt na specjalistycznych płytach głównych firmy Intel, były łatwe do debugowania i bardzo niezawodne.


4
Chociaż protokół Ethernet może wykonać protokół, minimalna odległość 100 Base Ethernet wymaga 1 metra (to trochę mnie ugryzło kilka lat temu przy użyciu Ethernetu nad implementacją płyty montażowej). OP wspomniał, że odległość wynosi kilka cali, co raczej wyklucza ethernet na warstwie fizycznej.
Peter Smith

1
@PeterSmith, minimalna odległość NIE MA zastosowania do Ethernetu bez magnesów. To zadziała do zaledwie kilku cali.
Jack Creasey,

5

Odpowiedzi tutaj są techniczne, daję perspektywę inżynierii wymagań:

Mój pogląd na to jest prosty

  • Aby działało, potrzebujesz co najmniej 20 Mb / s, więc nie określaj 20, ale „20 lub więcej” dla aplikacji.

  • każdy szybszy sprzęt również spełnia twoje wymagania

  • jeśli szybsze HW jest tańsze / łatwiejsze do opracowania ze względu na istniejące standardy, to twoje wymagania mogą być spełnione również przez te.

  • Jeśli klient chce więcej, spróbuj dowiedzieć się, czy coś za tym stoi (być może już planuje aktualizacje i chce pozostać kompatybilny między płytami podczas wymiany)


3

Moc, integralność sygnału i synchronizacja. Pracowałem na układzie z interfejsem 25 Gb / s, co oznaczało częstotliwość taktowania 1,6 GHz i tonę mocy. Gdybyśmy mogli uruchomić przy 19,2, częstotliwość zegara wynosiłaby 1,2 GHz. Większa niż 200ps dodatkowej marży na okres zegarowy, to byłaby ogromna pomoc.

Nigdy nie projektowałem kart, ale spodziewam się, że 20 Mb / s to żaden problem. 1 Gb / s wciąż nie jest tak trudny, ale o wiele trudniejszy niż 20 Mb / s.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.