Hallo Forum, Ich bin auf der Suche nach einem preisgünstigen FPGA (development) Board das es ermöglicht zwei Boards dieses Typs über eine highspeed (>= 1Gb/s) Verbindung zu verbinden. Hierbei würde ich Glasfaser als Medium bevorzugen. Die Idee ist es ein System aufzubauen das mehrere "Verbindungen" (zum Beispiel CAN, RS232, 10Mbit LAN) zusammenfasst (time multiplext) und über den highspeed Link zum anderen Bord schickt wo das Signal wieder auf die einzelnen "Verbindungen" aufgeteilt wird (demultiplext). Sozusagen ein transparenter Tunnel für mehrere "Kabel". Im Moment sind schon theoretische Überlegungen zu den auftretenden Verzögerungen gelaufen und prinzipielle Überlegungen wie dies in einem FPGA realisiert werden könnte durchgeführt worden. Was nun fehlt ist eine proof of concept Implementierung. Um dies halbwegs realistisch zu machen würde ich mir 1Gb/s oder mehr wünschen. Die Distanz die später einmal überbrückt werden soll ist <=5m. Aufgrund des geplanten Umfelds (EMV Störungen) würde ich Glasfaser bevorzugen. Wenn das finanziell unrealistisch ist kann für diese erste Implementierung auch eine kürzere Strecke und Kupfer genommen werden. Die finanziellen Mittel sind hier eher limitiert (Systempreise (2 Boards + nötiges Zubehör) <= 1000EUR, besser viel weniger) da Uni Projekt ohne Geldgeber. Ich habe mich bei Altera und Xilinx nach dev Boards umgeschaut aber nichts gefunden das in meinen Preisrahmen passt. Hat jemand von euch einen Vorschlag für ein Board das hier verwendet werden könnte. Gruß, Dirk
Ohne, dass ich dir jetzt ein konkretes Board nennen könnte: Aber haben die heutzutage nicht alle schon ne GBit-Ethernetschnittstelle drauf? Dann wäre deine "Kupferlösung" schonmal fertig. Und wenn es die Applikation unbedingt erforert, kann man auch einen LWL-Wandler nachschalten.
Hallo Schlumpf Vielen Dank für die Idee mit Gb Ethernet. Darüber habe ich auch schon nachgedacht. Ich war mir aber nicht sicher ob Ethernet hier wirklich anwendbar ist/die Anforderungen erfüllt. Was ich brauche ist ja ein "kontinuierlicher Bitstrom" in beide Richtungen. Dabei sollte die von meinem System erzeugte Verzögerung konstant sein (und hoffentlich minimal). Wenn ich an meine Netzwerkvorlesung zurückdenke erinnere ich mich an Kollisionen bei Ethernet die eine nicht konstante Verzögerung verursachen. Mir ist allerdings nicht klar ob dies auch bei nur zwei Teilnehmern auftritt. Zusätzlich finde ich den Ethernet frame overhead etwas drastisch. (Um die delays niedrig zu halten muss ich die Paketgröße klein halten. Damit ist der prozentuale overhead dann ja recht groß.) Übersehe ich hier etwas? Gruß, Dirk
Na ja das mit den Kollisionen kannst du bei Fullduplex vergessen. Die treten da nicht auf. hast du etwa vor, die einzelnen Protokolle zu "mischen"? Also die Bits im Zeitmultiplexverfahren hin und her zu schalten? Das halte ich auf den ersten Blick für ein recht umständliches Verfahren. Wenn du mal mit 1GBit/s rechnest und annimmst, dass du erst die Daten eines 10MBit Ethernet-Telegramm überträgst und danach die Daten für die anderen beiden Telegramme. Also diese jeweils in einen separaten 1GBit-Frame "tunnelst", dann kommst du doch sicher auf aktezptable Zeiten, oder nicht?
Schlumpf schrieb: > Na ja das mit den Kollisionen kannst du bei Fullduplex vergessen. Die > treten da nicht auf. OK. Das ist schonmal gut. > hast du etwa vor, die einzelnen Protokolle zu "mischen"? Also die Bits > im Zeitmultiplexverfahren hin und her zu schalten? Das war die Idee. OK, ich dachte an bytes nicht bits. > Das halte ich auf den ersten Blick für ein recht umständliches > Verfahren. Stimme ich dir zu. Allerdings bin ich mir nicht sicher ob ich andernfalls die delays klein genug halten kann > Wenn du mal mit 1GBit/s rechnest und annimmst, dass du erst die Daten > eines 10MBit Ethernet-Telegramm überträgst und danach die Daten für die > anderen beiden Telegramme. Also diese jeweils in einen separaten > 1GBit-Frame "tunnelst", dann kommst du doch sicher auf aktezptable > Zeiten, oder nicht? Hmm. Die maximal zulässige Länge eines ethernet frames ist 1542 bytes. Bei 10Mbit muss ich also 1.2ms (1542 * 8 / 10000000) warten bis ich den ganzen Frame bekommen habe. (Erst dann kann ich ihn weiterschicken.) Ihn auf dem Gb link zur anderen Seite zu schicken sollte dann nochmal 12ns dauern. Mit Warten aufgrund der anderen Kanäle nochmal <(n-1) * 12ns. Damit füge ich also ein delay von 1.2-1.3ms ein. Die maximale Segmentlänge bei Ethernet ist 100m. Ich habe jetzt leider mein Netzwerke Buch nicht hier und kann auch im Netz nicht finden ob dies aufgrund von Signaldämpfung oder delay ist. Falls es Aufgrund von delay ist würden die 100m etwa 0.3ns entsprechen (mit 300000km/s gerechnet). Da währen die 1.2ms also ein Problem. Man könnte dies bei Ethernet natürlich umgehen indem sich dieser FPGA-FPGA Tunnel wie ein Switch verhält. Aber ich denke das macht die Implementierung erheblich komplizierter und ich bin mir nicht sicher ob das für alle "Protokolle" funktioniert. RS232 sollte kein Problem sein. CAN weiß ich nicht. Eigentlich sollte das ganze in der Zukunft auf andere "Protokolle" erweiterbar sein. Gruß, Dirk
Nur weil das ein Ethernet-Port/Buchse ist musst du doch noch lange keine Ethernet-Frames übertragen... Das ist im Endeffekt doch nur eine Kupferleitung, da kannst do doch übertragen was du willst. Irgendwas mit Frames zur Synchronisation/Fehlererkennung wirst du aber vermutlich so oder so brauchen...
Dr. Sommer schrieb: > Nur weil das ein Ethernet-Port/Buchse ist musst du doch noch lange keine > Ethernet-Frames übertragen... Das ist im Endeffekt doch nur eine > Kupferleitung, da kannst do doch übertragen was du willst. Irgendwas mit > Frames zur Synchronisation/Fehlererkennung wirst du aber vermutlich so > oder so brauchen... Richtig, das meinte ich ja auch: Dem MAC ist es egal, was er verschickt. Das einzige, was der PHY eben "sehen" will, sind die 7 Byte Präambel und 1 Byte SFD, was danach kommt, ist dem PHY egal. Also ein Overhead von 8 Byte, was 64 ns bedeutet. @ Dirk: Die einzige deiner Rechnungen, die für mich nachvollziehbar ist, ist die, wo du die Dauer eines 1500Byte langen Frames ausrechnest. Alles andere ist meines erachtens falsch. Vermutlich meinst du µs, wo du ns geschrieben hast. Dann würde es ungefähr passen :-) Aber deine Schlussfolgerung aus der Rechnung verstehe ich auch nicht so ganz.
Ein ganz anderer Ansatz wäre, dass du einfach mit konstanter Geschwindigkeit deine Daten der einzelnen Eingangsprotokolle sampelst und diese dann über einen konstanten seriellen Datenstrom überträgst. Dadurch bekommst du aber ein paar "Probleme": 1. du musst deinen Datenstrom am Empfänger deserialisieren. Da du aber nur eine Leitung für jede Richtung hast, musst du den Takt wieder extrahieren und immer wieder nachsynchronisieren. 2. das 10MBit Ethernet kannst du nicht einfach auf der seriellen Leitung abtasten, sondern musst es durch einen PHY dekodieren und der liefert dir nicht mehr einen konstanten Datenstrom, sondern Nibble + Takt.
.. noch ne Ergänzung: Falls du jetzt mit dem Gedanken spielst, dass man ja auch die Datensignale, Takt etc des PHYs sampeln, direkt übertragen und nachher wieder auf einen PHY geben könnte, dann wird das vermutlich nicht klappen. Der PHY spuckt dir zwar genau die Daten aus, die er auf der Leitung sieht, aber von deiner Präambel auf der Leitung wird er u.U. eine unbestimmte Anzahl der Bytes wegwerfen. Und die musst du wieder auffüllen, bevor du dein Signal vom Empfänger an den nächsten Teilnehmer weiterreichst.
Schlumpf schrieb: > Dr. Sommer schrieb: >> Nur weil das ein Ethernet-Port/Buchse ist musst du doch noch lange keine >> Ethernet-Frames übertragen... Das ist im Endeffekt doch nur eine >> Kupferleitung, da kannst do doch übertragen was du willst. Irgendwas mit >> Frames zur Synchronisation/Fehlererkennung wirst du aber vermutlich so >> oder so brauchen... > > Richtig, das meinte ich ja auch: > Dem MAC ist es egal, was er verschickt. > Das einzige, was der PHY eben "sehen" will, sind die 7 Byte Präambel und > 1 Byte SFD, was danach kommt, ist dem PHY egal. > > Also ein Overhead von 8 Byte, was 64 ns bedeutet. OK. Wenn ich euch recht verstehe könnte ich die Kommunikation selbst implementieren (indem ich das ganze nur als Kabel ansehe) oder ich könnte die Definition des Ethernet physical layer weiterverwenden (und Gewinne dadurch die Synchronisation). Ich nehme jetzt mal an das die Synchronisation (auf dem PHY) im FPGA implementiert ist und nicht in Hardware. Die könnte ich also nur wiederverwenden wenn der IP Core für Ethernet modular aufgebaut ist (MAC separat vom PHY). > @ Dirk: > Die einzige deiner Rechnungen, die für mich nachvollziehbar ist, ist > die, wo du die Dauer eines 1500Byte langen Frames ausrechnest. Alles > andere ist meines erachtens falsch. OK. Eigentlich sollte ich solche Berechnungen nicht zu so später Stunde machen. Sorry für die Fehler. > Vermutlich meinst du µs, wo du ns geschrieben hast. > Dann würde es ungefähr passen :-) Korrekt. > Aber deine Schlussfolgerung aus der Rechnung verstehe ich auch nicht so > ganz. Falls die maximale Segmentlänge in Ethernet (und das ist ja eines der Protokolle die ich tunnele) durch ein maximales delay bedingt ist (bin ich mir nicht sicher) dann ist dieses maximale delay 0.3us. Wenn ich jetzt mit meinem System ein delay von 1.2ms erzeuge überschreite ich die 0.3us ja. Dirk
Dirk K. schrieb: > OK. Wenn ich euch recht verstehe könnte ich die Kommunikation selbst > implementieren (indem ich das ganze nur als Kabel ansehe) oder ich > könnte die Definition des Ethernet physical layer weiterverwenden (und > Gewinne dadurch die Synchronisation). richtig, mit der Einschränkung, dass der PHY eben die Präambel sehen will, um sich aufzusynchronisieren. Aber was danach kommt, ist dir überlassen. Dirk K. schrieb: > Ich nehme jetzt mal an das die Synchronisation (auf dem PHY) im FPGA > implementiert ist und nicht in Hardware. Die könnte ich also nur > wiederverwenden wenn der IP Core für Ethernet modular aufgebaut ist (MAC > separat vom PHY). Falsch: Der PHY synchronisiert sich auf den Datenstrom auf der Leitung auf und spuckt dann diese Daten Nibbleweise mit einem Takt aus (google mal MII) der MAC kann entweder als IP im FPGA implementiert werden, oder du schreibst ihn selber (so ein MAC für deine Zwecke ist ein paar Zeilen groß), oder er sitzt als externer Baustein zwischen FPGA und PHY Der PHY selbst lässt sich nicht als IP Core in den FPGA synthetisieren. Dirk K. schrieb: > OK. Eigentlich sollte ich solche Berechnungen nicht zu so später Stunde > machen. Sorry für die Fehler. Kein Problem.. ich bin ja noch "wach" gg Dirk K. schrieb: > Falls die maximale Segmentlänge in Ethernet (und das ist ja eines der > Protokolle die ich tunnele) durch ein maximales delay bedingt ist (bin > ich mir nicht sicher) dann ist dieses maximale delay 0.3us. Wenn ich > jetzt mit meinem System ein delay von 1.2ms erzeuge überschreite ich die > 0.3us ja. Das eine hat mit dem Anderen gar nichts zu tun.. Du kannst ein beliebig langes Delay auf der Leitung haben, das interessiert den Frame nicht. Alle Bits marschieren tapfer auf der Leitung entlang und kommen am Empfänger an. Einem Zug ist es ja auch egal, wie lange die Reise zum nächsten Bahnhof dauert. Er bleibt ein Zug. Ich glaube, dass du nochmal bissle tiefer in die Materie einsteigen musst, bevor du dich daran machst, ein "Proof of Concept" auf einer realen Hardware durchzuführen.
Schlumpf schrieb: > Falsch: Der PHY synchronisiert sich auf den Datenstrom auf der Leitung > auf und spuckt dann diese Daten Nibbleweise mit einem Takt aus (google > mal MII) GMII macht das byteweise
korrektör schrieb: > GMII macht das byteweise Ändert aber am Prinzip nichts ;-) GMII braucht er, falls er das Universalkabel mit Ethernet füttern will. MII braucht er aber so oder so, weil er ja 10MBit Ehternet übertragen will. Oder hat 10MBit wieder nen anderen PHY? Ich kenn das nur noch aus dem Museum gg
Schlumpf schrieb: > Oder hat 10MBit wieder nen anderen PHY? oder korrekt formuliert. Ein anderes MII... nicht, dass der Korrektör gleich wieder zuschlägt ;-)
Schlumpf schrieb: > nicht, dass der Korrektör gleich wieder zuschlägt ;-) der geht jetzt schlafen ;-)
Der Schlumpf auch.. aber nicht, ohne dem Korrektör noch eine gute Nacht Geschichte vom R-GMII zu erzählen, das schiebt auch nur Nibbles raus ;-) Wünsche allen eine gute Nacht
Dirk K. schrieb: > Die finanziellen Mittel sind hier eher limitiert (Systempreise (2 Boards > + nötiges Zubehör) <= 1000EUR, besser viel weniger) Dann wären vielleicht 2 Xilinx SP605 Boards was. Die sind mit jeweils knapp 400€ im Budget, dazu noch 2 SFP MM Module zu je 34€ und schon hast du deine 1GBit/s Strecke. Ich hab sowas hier am Laufen, die Ansteuerung der MGT ist zwar nicht ganz ohne, aber wenn man das einmal raus hat, dann ist es kein Problem.
@Schlumpf Danke für die Hinweise bezüglich Ethernet auf der 10Mbit Seite. Ich denke wir haben uns bisher die zu tunnelnden "Protokolle" zu stark vereinfacht in unseren Berechnungen/Überlegungen. Das müssen wir uns definitiv nochmal näher anschauen. @supachris Vielen Dank für den Vorschlag mit den SP605. Die hatte ich schon im Auge, habe aber auf eine noch billigere Lösung gehofft. Die scheint es ja aber nicht zu geben. Was sind denn "SFP MM Module"? Ich vermute es sind optical link module (SFP), bin mir aber nicht klar wofür das MM steht. Habe bei Xilinx FMC SFP Karten gefunden, aber nicht zu dem Preis von dem du sprichst. Hast du vielleicht einen Link für mich? Danke, Dirk
SFP steht für "Small form-factor pluggable" http://en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver SFP Transceiver gibt es von vielen Herstellern. Der Einsatz ist nicht nur auf Gigabit Ethernet beschränkt, im Falle des SP605 kannst du damit einen optischen Link zwischen 2 Boards aufbauen, und kansst alles realiesieren was die MGT Transceiver des FPGAs können.
Grundsätzlich stehen dir also zwei Konzepte offen: 1. du emfpängst die Protokolle, deserialsierst sie, packst sie um und verschickst sie wieder über ein schnelleres Medium. Dort werden sie wieder entpackt, neu zusammengebaut und weitergesendet. Dazu brauchst du aber FIFO Strukturen etc, dir dir auf jeden Fall eine Verszögerung erzeugen. 2. Du "kümmerst" dich nicht um die zu tunnelnden Protkolle, sondern stellst einen endlosen Träger zur Verfügung, mit dem du die ankommenden Bits einfach sampelst und verschickst. Quasi nach folgendem Prinzip: Jedes Byte repräsentiert z.B. 8 Kanäle. in diesem Kanälen stehen die aktuellen Samplewerte der zu tunnelen Datenströme. Dann würdest du bei 1GBit/s mit 125 MHz sampeln. Das sollte für viele einfache Protokolle wie CAN oder RS232 ausreichen schnell sein. Voraussetzung ist aber, dass das Protokoll es ermöglicht, dass du die Daten einfach sampeln kannst und 1:1 dann wieder rekonstruieren kannst. Mit dieser Methode bekommst du meines Erachtens die kürzeste Verzögerung hin und vorallem eine konstante Verzögerung. Allerdings wird es dann bei Protokollen wie 10MBit Ethernet schwer, da die nicht so ohne weiteres auf der Leitung samplebar sind. Außerdem kannst du zum Übertragen kein 1GBit Ethernet verwenden, da du hier keinen unendlich langen Frame erzeugen kannst.
Dirk K. schrieb: > Was sind denn "SFP MM Module"? Ich vermute es > sind optical link module (SFP), bin mir aber nicht klar wofür das MM > steht. Ja, das sind diese kleinen Optical Link Module, die direkt in das SP605 gesteckt werden können. Wurde ja schon verlinkt. MM steht einfach für Multi Mode Fasern, damit kommst du bei 1.25 GBaud/s etwa 500m weit. Single Mode geht weiter, ist aber wesentlich teurer. Diese Module, beispielsweise das HFBR5710PZ kosten reichlich 30€ netto, war glaub ich bei RS.
Die Chips alleine sind nicht ganz guenstig. Ich hab mich mal umgeschaut. Es sollten bei mir 1)die Chips durch die schemafaehige Webversion unterstuetzt werden. 2)Altium Designer die Schematischen Symbole & footprints unterstuetzen 3)Ein Haendler wie Digikey die Teile auch liefern koennen Fertige Boards gingen leider nicht, da sie die schnellen Links nur auf utopischen Steckern/Buchsen zur Verfuegung stellten. Altera faellt flach weil, die Lieferbarkeit nicht gegeben ist. Digikey hat die chips vielleicht jetzt, in drei monaten nicht mehr. Mein Alteravertreter will keinen neuen chip an Lager nehmen, da er davon fuer 10kEuro kaufen muesste. Xilinx ging leider auch nicht. Weshalb hab ich vergessen. Actel auch nicht. Nun bin ich bei Lattice. Die chips alleine sind da um die 40.. 160$, bei Altera waeren's 400$+ gewesen. Nicht dasselbe, aber fuer meine Anforderungen.
Schematic bei solch komplexen Sachen? Ist das ein schlechter Witz? Bist du sicher, im richtigen Thread gelandet zu sein? Irgendwie fehlt da der Zusammenhang...
Der Thread ging um Boards und Chips mit schnellen Links. Weshalb sollte man die nicht per Schematic verwenden koennen?
Kann man natürlich machen, aber das Gebastel stößt bei solchen komplexen Sachen schnell an die Grenzen. Ich hab selbst genug mit den Xilinx MGTs gearbeitet, das ist schon einigermaßen aufwendig, wenn man das mit Schematic Design machen müsste....gruselig. Die Spartan 6 sind mittlerweile überall in ausrechenden Mengen verfügbar, preiswert und die Boards liefern die schnellen Schnittstellen auf einem SFP raus. Und bis zum 45er kann man meines Wissens auch im kostenlosen WebPack arbeiten, Schematic geht aber auch in der Bezahl-Version (noch).
i-Troll (c) schrieb: > 1)die Chips durch die schemafaehige Webversion unterstuetzt werden. Wenn du mit Webvesrion die kostenfreie Variante meinst, trifft das nicht auf Lattice zu. Mit einer kostenlosen Lizenz unterstützt Diamond keine der FPGAs mit Highspeed SERDES (SCM,ECP2M,ECP3).
Ich hätte Bedarf für eine High-Speed Verbindung mit 24GBit/sec. Leider kenne ich mich mit 10GigE nicht aus. Gibt es da inzwischen Erfahrungen über die Reichweite mit Verkabelung (nicht optisch)? Ich hätte etwa 12m-15m zu überbrücken. (von einem Raum in den anderen). Ich beabsichtige 3x10GigE.
Von Computer zu Computer oder was ist dein Anwendungsfall? Es gibt auch Infiniband das direkt 40GBits/s kann oder auch 40Gbit Ethernet. Was spricht gegen optisch?
optisch geht nicht, wegen der Knickempfindlichkeit der Kabel. 40GB Ethernet?
OK 40GBit Ethernet scheint noch nicht am Markt zu sein. Ja dann nimm 10GBit. Wenn du da Rechner vernetzen willst kannst du die Links schön bündeln unter Linux oder Ähnlichem. Die Frage ist eher wohin mit den Daten? Das muss ja irgendwie echt schnell weg, das schreibt dir auch schnell den RAM voll.
Gustl Buheitel schrieb: > Die Frage ist eher wohin mit den > Daten? FPGA 2 FPGA, das zweite sammelt mehrere Kanäle, schaltet und überlagert die Daten. Die Reduktion erfolgt von 16x 24GBit auf 1x24GBit/2, dann wird dezimiert auf 500kB/s und geht in einen Rechner. Der zeigt dann 20 Werte pro Sekunde an, allerdings sehr wertvolle!
Hui, klingt spannend, aber helfen kann ich da leider nicht, ich muss erstmal überhaupt Ethernet mit meinem FPGA machen. Was sind das denn für 24GBit Links? Also Probleme könnte ich mir vorstellen beim Ansprechen der PHYs, das hab ich aber noch nie gemacht. Ja und dann muss man die Links irgendwie "bündeln" trunking nennt man das sonst aber in einem FPGA ohne CPU stelle ich mir das schon schwieriger vor.
Wer sagt denn das man keine CPU hat. Es gibt ja genuegend cores zur Auswahl.
Klar gibt es die, aber durch die wird man kaum 2x 10GBit durchschleifen können. Aber klar eine CPU könnte da schon helfen.
>>i-Troll (c) schrieb: >> 1)die Chips durch die schemafaehige Webversion unterstuetzt werden. > >Wenn du mit Webvesrion die kostenfreie Variante meinst, trifft das nicht >auf Lattice zu. Mit einer kostenlosen Lizenz unterstützt Diamond keine >der FPGAs mit Highspeed SERDES (SCM,ECP2M,ECP3). Es scheint so, dass das Lattice Diamond, Webwersion, das ECP2M unterstuetzt. In der Tat muss man aufpassen. Das Quartus2 unterstuetzt eine Fanilie, deren Namen ich vergass, bis zum Floorplanner, der dann streikt. Unschoen, wenn man das erst bei diesem Schritt merkt.
i-Troll (c) schrieb: > > Es scheint so, dass das Lattice Diamond, Webwersion, das ECP2M > unterstuetzt. > Nicht nach dieser Matrix: http://www.latticesemi.com/products/designsoftware/diamond/diamondsoftwarematrix.cfm Ausnahmen gibt es u.U. zusammen mit Evalbaords (z.B. Versa PCIe Board).
>Nicht nach dieser Matrix: >http://www.latticesemi.com/products/designsoftware... In der Tat. Der Preis der jaehrlichen Lizen von 99$ unterscheidet sich aber signifikant von den 1000$ fuer Quartus2..
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.