Wir haben ein ARM-Plattform mit einem FPGA, die mit einer IO-Funktion und Überwachung erweitert werden soll, die aber nicht mehr in den FPGA passt (bei Weitem nicht!). Deshalb soll in das Gehäuse nachträglich eine weitere Platine eingesetzt werden, die einen weiteren FPGA, wahrscheinlich MAX10 oder etwas Ähnliches enthalten wird. Dieser FPGA braucht sehr viele Daten vom ARM und dem Haupt-FPGA, die in Blockrams gespeichert sind und die ich gerne "rüberstreamen" würde. Die Hauptplatine hat aber nur noch 4 Lötaugen frei, die an FPGA-Pins angeschlossen sind. Die sind als Testpins ausgeführt, um einen Tastkopf draufhalten zu können. Die Funktion kann ich im FPGA aber einstellen. Die Frage ist jetzt, wie ich das verbinden kann und welche Bandbreiten ich erwarten kann. Der Abstand der Platinen wird etwa 5cm sein. Folgende Ideen: A) bidirektionaler 3-fach serieller Bus, full duplex - 4 Leitungen single ended - 3 BIT-Bus mit Takt-Leitung - auf allen 3 Leitungen ein serielles 11-Bit Protokoll - Steuercodes, internes proprietäres Format - es wird per Protokoll umgeschaltet und der Slave FPGA sendet - Bandbreite ca 60% Senden, 30%, Empfangen, 10% Overhead - Effizienz 8/11 * 90% = 70%, davon 30% Daten = 27% * 3 =80% - Geschätzt 100 MHz Leitung -> 80Mbps - Auslastung wegen Gleichverteilung von Schreiben und Lesen bei 70% - 50Mbps Nutzdaten hoch - 100Mbps Daten+Addressen runter B) Alternativ, statische Richtungen: - eine Leitung uplink, 2 Leitungen downlink, + Takt - Keine Umschaltverluste, dafür statischer und weniger gut ausgelastet, weil immer eine Leitung für Daten brach liegt. - 60 Mbps Addressen - 60 Mbps entweder hoch oder runter - > 30MHz C) 2 Serielle Verbindungen mit LVDS, dafür schneller - 2 Leitungen LVDS uplink - 2 Leitungen LVDS downlink - senden synchron, Empfangen asynchron mit Rekonstruktion, Taktrate bekannt, aber anders Quarz. - Geschätzte Geschwindigkeit 200 MHz (????) - 100 Mbps downlink Addressen - 100 Mbps downlink Daten Schreiben - 200 Mpbs uplink Daten Lesen, die aber nicht ausgelastet sind, weil nur 1:2 gelesen wird -> 100 M * 0,5 = 50M Aufgrund der Datenverhältnisse, dass man doppelt so viel schreiben muss, wie man statistisch liest, ist der dynamische Bus A) der Bessere. LVDS wäre wahrscheinlich technisch stabiler, aber ich muss dann auch mindestens doppelt so viel Rate haben, wie bei B). Wie schnell kriegt man das single ended hin? Und wie schnell geht es über LVDS? Wie verbindet man das praktisch am Besten? Serielle / Parallele Terminierung? - Wo? Verkabelung? hier gab es das schon einmal, aber auch ohne verwertbares Ergebnis: Beitrag "2 Spartans verbinden, welcher IO Standard"
Eine Idee habe ich noch: Kann man LVDS auch umschalten? Der FPGA hat noch SERDES, aber das wäre ein größerer Umbau wegen PLLs wie es aussieht und mit denen kenne ich mich auch nicht genug aus.
Das FPGA-Manual nimmt einem keine Entscheidung ab, was Protokoll anbelangt und macht auch keine Vorgbane für die Leitungsführung. Höchstens das mit der LVDS-Umschaltung kann ich recherchieren. Ich lese mich gerade in die Serializer ein (Cyclone IV), dort steht nicht einmal etwas von Randbedingungen für die Leitungsführung. Wird wohl in einem Extra-Datenblatt sein. Die Transceiver wären ja ganz nett, da wenigstens 600Mbps, nur brauchen die sicher eine noch qualitativ höhere Leitungsführung und deshalb werde ich die kaum per Luftverdrahtung aufs Nachbar-FPGA bekommen. Und obendrein muss dann auch einiges an zusätzlichen Resourcen verbraucht werden, die wahrscheinlich nicht vorhanden sind. Ich brauche also eine Einschätzung, was man da zu erwarten hat. Ich habe bisher selbst geroutete Platinen gebaut, auf denen Datenbusse um 100MHz aufs FPGA gingen. Das war in einem Cyclone noch gut zu machen. Aber natürlich befand sich die CPU in relativer Nähe zum FPGA und wenn nicht, war es dennoch das gleiche PCB.
Tobias N. schrieb: > Ich brauche also eine Einschätzung, was man da zu erwarten hat. Typischerweise das Redesign der Hauptplatine (mal aus der wirtschaftlichen Perspektive gesehen). Ansonsten sind alle 'guten Ideen' ad absurdum, wenn nicht gerade zufaellig die richtigen LVDS-Pins frei sind und es zufaellig mit der Impedanz und manuellen Leiterlaengenkorrektur gerade so hinhaut.
Der TO hat doch gar keine Mindestanforderungen genannt. Also ist fast alles gut genug. Tja was tatsächlich geht hängt sehr davon ab wie die Schaltung und das Layout der beiden Platinen aussieht. 5 cm zwischen den Platinen wird egal wenn die Platinen groß sind und die FPGAs trotzdem weit auseinander sitzen. Ich würde da ein USB3 Kabel ranlöten, also beide Superspeed Paare verwenden. Und natürlich auch die Masse schön mit verbinden. Und dann einfach testen wie schnell du dein LVDS machen kannst bis es Fehler gibt.
Tobias N. schrieb: > Dieser FPGA braucht sehr viele Daten vom ARM > und dem Haupt-FPGA, die in Blockrams gespeichert sind und die ich gerne > "rüberstreamen" würde. Kannst du uns hier noch grobe Zahlen nennen? - Menge Daten pro Zeit - Latenz von Anfrage zur Antwort - Anzahl Anfragen pro Sekunde - Grosse zusammenhängende Datenblöcke oder kurze häppchen dafür sehr oft Das hat erheblichen Einfluss, was tauglich sein kann oder nicht. Was mir an allen deinen Vorschlagen auffällt: Musst du wirklich für jede einzelne Anfrage die Adresse mitschicken oder reicht da auch eine Startadresse und dann als Antwort ein Block Daten mit Variabler/Fixer Länge? Tobias N. schrieb: > A) bidirektionaler 3-fach serieller Bus, full duplex > B) Alternativ, statische Richtungen: Du führst den Takt in Richtung Slave, der kann dann alles einfach Empfangen (so lange die Leitungen ungefähr gleich lang sind aber das kanns du ja auf dem Zusatz PCB sonst Kompensieren). Und wie geschiet das Rückwärts zum Master hin? Muss der Slave dann so schnell reagieren, dass seine Antwort dann genüg früh wieder beim Master ankommt? Kann schon gehen, macht deine Timing Anforderungen einfach strenger. Du kannst dir auch bei Single-endet Gedanken über Clock-Recovery machen. > C) 2 Serielle Verbindungen mit LVDS, dafür schneller LVDS geht wohl sogar noch schneller aber wie Martin geschrieben hat, wohl kaum ohne ein Redesign auf differenzielle Paare. Clock-Data-Recovery mit 8/10 bit Codierung geht super. Andere Ideen: - Vielleicht reicht ja am Ende doch SPI mit 20 bis 50 MHz :-) - Single-ended, statische Richtung mit Data/Strobe Codierung (z. B. bei Firewire oder SpaceWire)
Ich würde es einfach testen, da sehr kabel- und störungsabhängig. LVDS hat in jedem Fall den Vorteil der größeren Störsicherheit gegenüber Signalen von Außen. Siehe EEE 1596.3 Es kommt auch drauf an, ob eine Leitungscode benutzt wird, der Takt rekonstruiert wird und was noch an overhead hinein muss. Wenn es mit den gematchten Leitungen nicht passt, dann eben händisch mit Spannungsteiler und serieller Terminierung, wobei dann 2 halb so schnelle serielle Datenströme sicher schneller sind.
Uwe Bonnes schrieb: > "Junge, keine Gewalt, nimm ein groesseres FPGA" Die bestehenden Systeme sollen damit auch ausgestattet werden, was bedeuten würden, die Elektronik wegzuwerfen. Aus Gründen der funktionalen Sicherheit soll es auch in einen anderen Baustein, weil dieser eben überwachen soll. Martin S. schrieb: > Redesign der Hauptplatine (mal aus der > wirtschaftlichen Perspektive gesehen). ... > zufaellig die richtigen LVDS-Pins frei sind Es sind in der Tat zwei benachbarte Pins ausgeführt und das sollten LVDS-fähige IOs sein. Könnte nur mit der benötigten Bankspannung klemmen. Werde ich checken. Gustl B. schrieb: > 5 cm zwischen den Platinen wird > egal wenn die Platinen groß sind und die FPGAs trotzdem weit auseinander > sitzen. Die Testpunkte sitzen soweit aussen, dass es am Ende tatsächlich 5cm werden. Maximal vielleicht 8, durch gekrümmte Kabel. > Ich würde da ein USB3 Kabel ranlöten, also beide Superspeed Paare > verwenden. Und natürlich auch die Masse schön mit verbinden. "Schön Masse verbinden" heißt konkret was? Abschirmung? Oder zwischenliegende Leitungen?
Christoph Z. schrieb: > Kannst du uns hier noch grobe Zahlen nennen? Das Protokoll ist noch nicht ganz klar. Sicher kann man da funktionell etwas einsparen, aber zunächst geht es um die Bandbreite an sich. Geplant ist ein mehr oder weniger dichtes Streamen von Daten, um eine möglichst hohe Überwachungsrate zu erhalten. > Du kannst dir auch bei Single-endet Gedanken über Clock-Recovery machen. > Clock-Data-Recovery mit 8/10 bit Codierung geht super. Literatur-Tipp?
Tobias N. schrieb: > Es sind in der Tat zwei benachbarte Pins ausgeführt und das sollten > LVDS-fähige IOs sein. Könnte nur mit der benötigten Bankspannung > klemmen. Werde ich checken. Das wäre erstmal wichtig. Tobias N. schrieb: > "Schön Masse verbinden" heißt konkret was? Abschirmung? Oder > zwischenliegende Leitungen? Die Massen der beiden Platinen sollen möglichst niederohmig verbunden werden. Im USB Kabel sind dazu Masseleitungen dabei. Meist eine je Superspeed Paar und dann noch eine von der normalen Stromversorgungs Masse. Alle möglichst nahe an den anderen Anschlüssen mit Masse verbinden. Gut wäre es wenn du dazu Fotos machen könntest und da auch schreibst welcher der Testpunkte welcher FPGA Pin bei welchem FPGA (genaue Modellnummer) ist. Aber selbst wenn deine Pins nicht zu LVDS Paaren gehören kannst du die gegenphasig betreiben (dann Spannung statt Strom). Ob du da viel gewinnst weiß ich aber nicht. Tobias N. schrieb: > Das Protokoll ist noch nicht ganz klar. Sicher kann man da funktionell > etwas einsparen, aber zunächst geht es um die Bandbreite an sich. > Geplant ist ein mehr oder weniger dichtes Streamen von Daten, um eine > möglichst hohe Überwachungsrate zu erhalten. Nun, das Problem ist, dass deine Takte der beiden FPGAs auseinanderlaufen werden. Du musst also entweder a) einen Takt mitliefern, das geht 1) über eine eigene Leitung - Nachteil, kostet eine Leitung 2) über eine eingebettete Clock im Datensignal mit z. B. 8B/10B Kodierung - Nachteil: Ist aufwändiger und du kannst je 10 Bits auf der Leitung nur 8 Bit Nutzdaten übertragen. Vorteil: Du verlierst keine Leitung und du kannst das auch bei hoher Bitrate machen. b) etwas asynchrones fahren. Du könntest am Anfang nur für einen Test zweimal UART über die LVDS machen. Einen in jede Richtung. Wenn du am Empfänger SerDes verwendest für die Überabtastung, dann solltest du da auch > 100 MBit/s hinbekommen. Nachteil: Das kann keine sehr hohen Datenraten und du nutzt ebenfalls nur 8 von 10 Bits. Also zu bevorzugen wäre wirklich 8B/10B Kodierung und dann eine hohe Bitrate. Also mit einem SerDes ausgeben und ebenfalls mit einem SerDes empfangen. Fotos wären gut und die genau Bezeichnung vom FPGA und den Pins am FPGA.
Tobias N. schrieb: > Aus Gründen der > funktionalen Sicherheit soll es auch in einen anderen Baustein, weil > dieser eben überwachen soll. Das macht mich jetzt doch etwas stutzig. Dem gegenueber soll also stehen: - 'fliegende' Verkabelung - Zusaetzliche Logik, die verifiziert werden muss - Custom-Protokoll fuer Datentransfer Und das dann alles zum TueV? Ich will hier niemandem auf die Fuesse treten, aber das klingt fuer mich nach grober Stolperfalle. Wenn es dennoch mit einem externen Baustein laufen soll: Bloss so simpel wie moeglich halten. Normalerweise muss man keine Daten streamen, sondern nur ein CRC-Vergleichsprotokoll fahren. Dann reicht ein einfaches SPI-Interface. Fuer eine kritische Anwendung (in der ich haften muesste) wurde so etwas aehnliches fuer einen Programmablauf implementiert. Der bereits zertifizierte externe Controller ueberprueft nur noch ca. 20 Checksummen/s per SPI (i2c ist tabu) und stimuliert einen Watchdog-Schaltkreis. Was dann bleibt, ist, an den kritischen Stellen die 'Checkpoints' fuer die CRC-Bildung einzufuegen. Das ist mehr Analyse (Wahrscheinlichkeiten) als Entwicklung.
Martin S. schrieb: > Tobias N. schrieb: >> Aus Gründen der >> funktionalen Sicherheit soll es auch in einen anderen Baustein, weil >> dieser eben überwachen soll. > > Das macht mich jetzt doch etwas stutzig. Datt Mopped kommt so aber nech übern TÜV ;)
Martin S. schrieb: > Tobias N. schrieb: >> Aus Gründen der >> funktionalen Sicherheit soll es auch in einen anderen Baustein, weil >> dieser eben überwachen soll. > > Das macht mich jetzt doch etwas stutzig. Meine Frage wäre, WAS da alles überwacht und abgesichert werden soll und ob mit dem Begriff "funktionale Sicherheit" auch wirklich das gemeint ist, was man offiziell darunter versteht. Tobias N. schrieb: >> Du kannst dir auch bei Single-endet Gedanken über Clock-Recovery machen. >> Clock-Data-Recovery mit 8/10 bit Codierung geht super. > Literatur-Tipp? Das gibt es als Core im Megawizzard, bei den Transceivern. Man muss aber nicht 8/10 betreiben (wegen "Dateneffizienz"-Argument oben). Kommt letzlich auf den FPGA an, ob man das manuell baut oder einen fertigen Transportlayer verwendet. Für die höherwertigen Xilinx Bausteine gibt es u.a. das Aurora mit B64B66 Codierung. Was die Verbindungen und - qualität angeht, würde ich das mal ansehen: https://www.xilinx.com/publications/archives/books/serialio.pdf Hohe Raten erfordern in jedem Fall LVDS über SER-IOs - und ein PCB-Design dafür, bzw man muss im Empfänger einiges tun. Wenn das nachgerüstet werden muss, wird man irgendwo bei 50...100 MHz landen. Das hängt aber auch davon ab, wie der Signaldatenstrom aussieht: Für meine Chip to Chip Verbindungen habe ich anfänglich S/PDIF mit höheren Tatkraten gefahren. Mit den verfügbaren Standard-Bausteinen waren da 192 kHz/64 Bit drin, über COAX, bei 48 Bit Nutzdaten. S/PDIF ist "BMC" und der Empfänger rekonstruiert sich den Takt selber. Klappte über etliche Meter (industriell auch durch EMI-verseuchte Maschinen!) und ist super billig. Wenn du keine besonderen EMI-Probleme hast, geht auch erheblich mehr. Konkretes Beispiel: 150 MHz Video, 20cm über Flachband von Platine zu Platine mit komplettem 33-Bit Bus mit einem Spartan 6, single ended - allerdings mit per ISE-constraints justierten IO-Delays auf der Sendeseite (ca 100ps Koheränz) und einem Video-Receiver-Chip, der seine Eingänge trainiert. Bei nur 4 Leitungen würde ich keinen Takt verschwenden, sondern alle 4 als einzelne, SER-Ströme fahren und gfs Leitungs-Code, Daten-Redundanz und Scrambling einbauen. Bei individuellen Leitungen braucht man kein Eintrainieren. Das Maximum, was ich über eine Leitung ohne Transceiver über ein paar Zentimeter zu einem Folge-FPGA geschafft habe, waren 320Mbps: Kapazitiv gekoppelt, intern terminiert, B4B7 Code mit 2 NRZ-Ausgleichs-Bits und einem FEC-Protokoll. Der Takt ist dann da mit drin und Fehler wirden korrigiert. Ist aber eine statistische Sache, wie weit man von den Problemfällen wegbleiben will. Liegen die Ausgänge noch eng beieinander, kommt noch ein SSO-Problem. Momentan fahre ich ein 8-Bus-System mit knapp 8x150 Mbps netto (192kHz x 256 ch). Ohne Codierung und Fehlerkorrektur ist es die Hälfte; bei 4 Kanälen vlt. 4x75.
:
Bearbeitet durch User
Gustl B. schrieb: > Ob du da viel > gewinnst weiß ich aber nicht. Wahrscheinlich nicht, weil ihm der headroom der Signale verloren geht. Gleichtaktunterdrückung funktioniert auch nur, wenn die Signale wirklich synchron laufen.
Gustl B. schrieb: > Nun, das Problem ist, dass deine Takte der beiden FPGAs > auseinanderlaufen werden. Du musst also entweder > a) einen Takt mitliefern, das geht Das Allereinfachste wäre sicher, dass beide FPGAs aus demselben Takt gespeist werden. Dafür müssen ja Pins an beiden Submoduln vorhanden sein.
Angehängte Dateien:
-
serializer_8b10b.gif
59 KB
Gustl B. schrieb: > Also zu bevorzugen wäre wirklich 8B/10B Kodierung und dann eine hohe > Bitrate. Also mit einem SerDes ausgeben und ebenfalls mit einem SerDes > empfangen. Ich konnte den 8b10b-core von open cores laden und simulieren. Scheint zu stimmen. Er wurde um einen Serialisierung in der Testbench erweitert mit der ich das probieren möchte. Die Frage wäre jetzt, wie ich aus dem 1-Bit Input zu einem Takt komme? In der Testbench habe ich probehalber einfach den Sendetakt genutzt. Aber das Ziel wäre, ohne einen extra Takt zu arbeiten und nur das Signal zu versenden. Wie macht man das? Abtasten und asynchron wie bei einer UART? Oder gibt es da einen Trick? Mein Problem ist, dass ich das zwar asynchron machen könnte, aber für die gewünschte Taktfrequenz von 100 MHz einen wenigstens um Faktor 2 größeren Takt bräuchte. Mit SERDES wäre es wieder eine Extra-Leitung. Außerdem habe ich versucht, eines der files zu synthetisieren. Es kommt
1 | SYNCRST: process (RESET, XLRESET, SBYTECLK) |
2 | begin |
3 | if SBYTECLK'event and SBYTECLK = '1' then |
4 | XLRESET <= RESET ; |
5 | elsif SBYTECLK'event and SBYTECLK = '0' then |
6 | LRESET <= XLRESET ; |
7 | end if ; |
8 | end process SYNCRST ; |
Xilinx meckert, dass das nicht zulässig sei.
Der Code bräuchte DDR-Register. Ich weiß nicht wie das bei xilinx ist. Bei Actel musste man ein DDR IO instantieren und dann intern mit doppelten Takt anfahren, wenn ich mich richtig erinnere.
Jayden Bubblegum Blue schrieb: > er Code bräuchte DDR-Register. Damit wäre aber nur das interne Taktproblem gelöst, daß nicht deswegen überabgetastet werden muss. Beim klassischen Einlesen asynchroner Daten muss aber intern in jedem Fall ein Takt her, der schneller ist, dass das zweifache der Daten (Grundfrequenz), sonst geht irgendwann eine Flanke flöten. Da der aussendende Takt aber ungefähr bekannt ist, muss man nur den Jitter in Betracht ziehen. Bei 100 MHz Daten reichen 2x125 MHz dicke.
Uwe B. schrieb: > PonyLink Ist ziemlich aufgebläht mit AXIS und allem, hat aber Decoder / Encoder schon verbaut. Immerhin "100 MBit/s at 166 MHz". Fast 1/3 von meinem :-)
Jürgen S. schrieb: > Damit wäre aber nur das interne Taktproblem gelöst, daß nicht deswegen > überabgetastet werden muss. Wollte nur darauf hinweisen,warum die Synthese meckert :-)
Tobias N. schrieb: > Aber das Ziel wäre, ohne einen extra Takt zu arbeiten und nur das Signal > zu versenden. Wie macht man das? Das Stichwort heißt "clock and data recovery (CDR)", "clock recovery" bzw. Taktrückgewinnung: https://de.wikipedia.org/wiki/Taktr%C3%BCckgewinnung Üblicherweise füttert man mit dem 'gemischten' Signal eine PLL, die mit den Flanken nachgeführt wird. Duke
Tobias N. schrieb: > Aber das Ziel wäre, ohne einen extra Takt zu arbeiten und nur das Signal > zu versenden. Wie macht man das? > Abtasten und asynchron wie bei einer UART? Oder gibt es da einen Trick? Ich habe mich damals an dieser Präsentation orientiert: Digital Phase Follower -- Deserializer in Low-Cost FPGA https://ppt-online.org/8875
Auf Folie 3 steht was von PLL, ich habe das mal versucht zu simulieren, also den seriellen enkodierten Datenstrom in eine PLL gefüttert. Aber die lockt nicht. Geht das überhaupt das Clock Recovery nur mit PLL? Ich tendiere zu ja wenn die seriellen Daten genug Flanken haben. Manchmal lockt die PLL. Kann man irgendwie die Trägheit einstellen oder so?
:
Bearbeitet durch User
Gustl B. schrieb: > Geht das überhaupt das Clock Recovery nur mit PLL? Ich tendiere zu ja > wenn die seriellen Daten genug Flanken haben. Prinzipiell ja, aber es muss alles passen: 1. man braucht den richtigen Phasenkomparator, 2. das Schleifenfilter sollte passen, 3. der VCO sollte schon ungefähr mit der nominellen Bitrate laufen und sich auch nicht zu arg verstimmen lassen 4. im Datensignal müssen genügend Flanken drin sein. Dafür sorgt z.B. die 8B10B-Kodierung. Ein üblicher Phasenkomperator benötigt immer die Flanken von beiden Signalen (Referenz und VCO). Hier braucht man einen, der die fehlende Eingangsflanke ignoriert. Sonst wird bei fehlenden Flanken versucht die Frequenz zu senken, da ja die 'Frequenzen' nicht gleich sind. Der Phasenkomparator muß ähnlich arbeiten wie beim FM-Empfänger im Auto: Da will man auch nicht, das der Sender wegläuft, nur weil das Signal schwach wird. Duke
Christoph Z. schrieb: > Tobias N. schrieb: >> Aber das Ziel wäre, ohne einen extra Takt zu arbeiten und nur das Signal >> zu versenden. Wie macht man das? >> Abtasten und asynchron wie bei einer UART? Oder gibt es da einen Trick? > > Ich habe mich damals an dieser Präsentation orientiert: > Digital Phase Follower -- Deserializer in Low-Cost FPGA > https://ppt-online.org/8875 Eine Multiphase-CDR ist eine gute Wahl, wenn der Takt limitiert ist. Die Aufbereitung ist aber relativ aufwendig. Insbesondere muss man beachten, dass der Skew der verschiedenen Taktphase möglichst gleich am Ziel ankommt. Alternativ existieren auch CDR-Konzepte über IDELAY-Regelschleifen. Nicht unbedingt einfacher. Auch eine tolle Idee über einen NCO. z.B. "NCO based CDR implementation in FPGA - Xilinx XOHW20-203". Ein offenes Git-Projekt dazu ist mir noch nicht bekannt. Eine schnelle, gute All-Digital-CDR zu bauen, benötigt grob den gleichen Aufwand wie die Protokollschicht der Übertragungstrecke. Bitte auch nicht den Aligner vergessen, denn ein Shift um ein bis mehrere Bits ist nicht ungewöhnlich.
Klakx -. schrieb: > Alternativ existieren auch CDR-Konzepte über IDELAY-Regelschleifen. > Nicht unbedingt einfacher. Finde ich schon einfacher. Mit einem doppelten Takt detektiert man immer eine Flanke (wenn vorhanden) und nimmt dann das Signal des anderen cycles, befindet sich also ziemlich in der Mitte des Bits. Man muss das Delay nur rotieren, das man sicher ist, immer etwas schneller als der richtige Takt zu sein und im Fall des Überlaufens eben 2-3 delays zurückspringen. Damit rennt die Taktflanke des Lesetaktes immer "gegen die Wand und prallt ab". Wenn keine Flanke erkennbar ist, regelt man nicht weiter und liest nur (Bit eh konstant). Wichtig ist nur, dass das update der Schleife nicht so schnell passiert, dass der Takt rausspringt. Es gibt daher einen maximalen Jitter, der verträglich ist. Sind rund 15%-20% der Taktperiode. Klakx -. schrieb: > Bitte auch nicht den Aligner vergessen, denn ein Shift um ein bis > mehrere Bits ist nicht ungewöhnlich. Die im paper vorgeschlagene Lösung für denTeilchenbeschleuniger ist eine Sicherheitslösung, die für weite Strecken gedacht ist, hier aber nicht so gut taugt. Die Daten haben nur 62,5 MBit müssen im Manchester-Code vorliegen, haben also eine geringe Bandbreite / Spektrum. Das lässt sich einfach dekodieren, ist aber nur sinnvoll, wenn man wirklich nur eine Leitung hat. Im Grunde ist es so, als würde man 2 Leitungen mit jeweils dem halben Takt und der halben Rate parallel fahren. Mit 8/10 hat man aber 160% davon. Interessanterweise brauchen die Autoren für 125 einen Xilinx Kintex! Würde man die Signalverarbeitung etwas schlauer machen, z.B. mit einem IQ-Mischer, käme man auf 2 Pfade mit der halben der hier 6fachen PLL aus. Macht 187,5 MHz und geht auch in einem Artix.
Jürgen S. schrieb: > Interessanterweise brauchen die Autoren für 125 einen Xilinx Kintex! Forschungseinrichtungen haben i.d.R. die teuren FPGA Boards rumliegen bzw. Budget dafür, also machen die das halt damit. Ist bei den Stückzahlen (und bei den sonstigen Kosten) um die es da geht egal was das FPGA kostet.
Komisch schrieb: > Forschungseinrichtungen haben i.d.R. die teuren FPGA Boards rumliegen > bzw. Budget dafür, also machen die das halt damit. Ist bei den > Stückzahlen (und bei den sonstigen Kosten) um die es da geht egal was > das FPGA kostet. Das ist so und hat viel damit zu tun, daß sie diese boards vergünstigt bekommen. Damit lernen sie aber nicht unbedingt das Richtige: Zu einem soliden Design gehört, nur Bauteile zu nutzen, die auch benötigt werden und bei FPGAs heisst das, die Schaltung klein auszulegen. Wenigstens könnte man erwarten, daß mehrere Wege aufgezeigt und dann anhand von Kriterien ein plausibler ausgewählt wird. Es scheint in der Tat so, daß der Versuch der Hersteller, Studenten mit Baukästen auszustatten, damit sie schnell und richtig groß designen und damit Anforderungen an die Chipfläche zu generieren, Erfolg gehabt hat! Es wird verschwenderisch gebaut. Auch wenn die Studenten 10 Jahre im Job sind, ändert sich das nicht mehr. Aber wehe du kommst und zeigst auf, wie es mit dem nächst kleineren FPGA ginge. Dann ist der Bär los. Dann wird die Lösung verteidigt, wie die bachelor-Arbeit.
Ich finde das Kintex Board KC705 ist ein ziemlich guter Allrounder. Auf ein Artix kann man dann immer noch gehen, wenn nicht mehr das große Debugging droht. Die 7er Generation ist dabei recht ähnlich. Auch ein Virtex hat seinen Zweck. Forschungseinrichtungen überlegen sich das gut. Geschenkt gibt's die nicht. Hauptmarkt ist jedoch Datacenter für diese FPGAs. Nebenbei, auf dem Mars fährt auch ein Kintex mit. Für billig und klein kann man gleich auf lattice gehen. Besonders in solchen GT-losen FPGAs sind o.g. CDRs interessant. Es kommt immer auf die Anwendung an und ob jemand bereit es zu zahlen. Ab Ethernet mit Stack wird es auch auf dem Artix eng.
Tim schrieb: > Ab Ethernet mit Stack wird es auch auf dem Artix eng. Wieso? Ethernet habe ich schon auf dem S6 gemacht.
Jürgen S. schrieb: > Tim schrieb: >> Ab Ethernet mit Stack wird es auch auf dem Artix eng. > Wieso? Ethernet habe ich schon auf dem S6 gemacht. Ja, das geht auf nem kleinen LX9. https://www.avnet.com/shop/us/products/avnet-engineering-services/aes-s6mb-lx9-g-3074457345628965461/ Und der hat signifikant weniger Ressourcen als der kleinste Artix.
Weltbester FPGA-Pongo schrieb im Beitrag #6888043: > Komisch schrieb: >> Ja, das geht auf nem kleinen LX9. > Eine komplette TCP/IP - Schicht in einem LX9? Für einen Hard-IP-Stack mit Hardware-Packet-Filter-Logik wird's eng, aber eher wegen BlockRAM-Mangel, nicht wegen der Logik. Wer keine Performance braucht: lwip laeuft auf ner ZPU in wenigen kB. Ich nutze allerdings UDP/RTP, wegen Durchsatz und Echtzeit.
Weltbester FPGA-Pongo schrieb im Beitrag #6886604: > Zu einem soliden Design gehört, nur Bauteile zu nutzen, die auch > benötigt werden und bei FPGAs heisst das, die Schaltung klein > auszulegen. Du hast noch nie Designs für die Wissenschaft gemacht. Der Entwicklungsaufwand für ein kleines FPGA ist erstmal genauso groß, wie für ein großes FPGA. Wenn dann aber neue Ideen und Anforderungen auf dem Tisch liegen, fängst Du beim kleinen FPGA nochmal von vorn an, was die Hardware angeht. Duke
Weltbester FPGA-Pongo schrieb im Beitrag #6888043: > Komisch schrieb: >> Ja, das geht auf nem kleinen LX9. > Eine komplette TCP/IP - Schicht in einem LX9? Man braucht ja nicht unbedingt TCP, UDP reicht oft. Und wie Strubi schon schreibt, auf dem AVNET Board läuft TCP natürlich in nem Microblaze der auch externes LPDDR RAM mit dran hat.
Duke Scarring schrieb: > Weltbester FPGA-Pongo schrieb: > >> Zu einem soliden Design gehört, nur Bauteile zu nutzen, die auch >> benötigt werden und bei FPGAs heisst das, die Schaltung klein >> auszulegen. > > Du hast noch nie Designs für die Wissenschaft gemacht. > Der Entwicklungsaufwand für ein kleines FPGA ist erstmal genauso groß, > wie für ein großes FPGA. Wenn dann aber neue Ideen und Anforderungen auf > dem Tisch liegen, fängst Du beim kleinen FPGA nochmal von vorn an, was > die Hardware angeht. > Duke Das ist das eine. Das andere ist, dass Arbeitszeit um Größenordnungen teurer ist als Hardware. Da es nie um Stückzahl geht, ist das Gesamtprojekt dann immer noch viel günstiger als wenn man ewig optimiert und das FPGA nimmt was gerade so reicht.
Duke Scarring schrieb: > Weltbester FPGA-Pongo schrieb im Beitrag #6886604: >> Zu einem soliden Design gehört, nur Bauteile zu nutzen, die auch >> benötigt werden und bei FPGAs heisst das, die Schaltung klein >> auszulegen. > Du hast noch nie Designs für die Wissenschaft gemacht. Oh doch und wir haben schon in unserer DA sehr genau ausführen müssen, welche Wege zu welchen Aufwänden, Kosten und Risiken führen würden und warum wir DEN Weg gewählt haben, den wir gegangen sind, Das war Teil der Aufgabe. Dies geschah um so mehr in den Forschungsprojekten. Dort mussten nämlich VOR Projektbeginn Mittel angefordert werden und man konnte nachher schlecht aufstocken. Es ist auch nicht von Wissenschaft abhängig oder nicht, wie man baut. Es ist gerade beim FPGA ein Leichtes, bei der Simulation herauszubekommen, ob eine Methode funktioniert und wieviel Fläche sie braucht, BEVOR man Einkaufen geht. Wer sagt denn, dass das "große" board reicht und man nicht 2-3 kleine oder 5 ganz große braucht? Konkret bei FPGAs ist es zumindest im Nachgang möglich, das Design zu analysieren und zu prognostizieren, welchen minimalen FPGA es braucht. Gerade diese wissenschaftlichen Projekte wollen doch immer on top sein, also das Beste aus der Technologie herauskitzeln. Aber bei Wissenschaftsprpjekten muss es ja immer groß und teuer sein. Mann darf sich dann nur noch wundern, wenn man solche Super-Forscher ins Team holt, die dann doppelt so viele Kosten an Hardware verursachen, wie es nötig wäre.
Weltbester FPGA-Pongo schrieb im Beitrag #6901840: > Dies geschah um so mehr in den Forschungsprojekten. Dort mussten nämlich > VOR Projektbeginn Mittel angefordert werden und man konnte nachher > schlecht aufstocken. Es ist auch nicht von Wissenschaft abhängig oder > nicht, wie man baut. Es ist gerade beim FPGA ein Leichtes, bei der > Simulation herauszubekommen, ob eine Methode funktioniert und wieviel > Fläche sie braucht, BEVOR man Einkaufen geht. Wer sagt denn, dass das > "große" board reicht und man nicht 2-3 kleine oder 5 ganz große braucht? Du hast also vor Projektantrag schon das Design fertig gemacht und komplett durchsimuliert, damit im Antrag der richtige Typ mit der richtigen Größe steht?!? Ich nicht. Ich mache aus der Erfahrung eine Schätzung und schlage einen Faktor drauf, wenn mich jemand fragt. Wenn ich dann ein Jahr oder länger daran beschäftigt bin, relativieren sich die Hardwarekosten ganz schnell. > Aber bei > Wissenschaftsprpjekten muss es ja immer groß und teuer sein. Na wenn Du meinst... Duke
Duke Scarring schrieb: > Du hast also vor Projektantrag schon das Design fertig gemacht und > komplett durchsimuliert, Solchige Projekte beginnt nicht bei Null. In der Regel forscht ein Institut jahrelang an irgendwelchen Themen, bevor ein Produkt bei raus kommt, oder (wie hier) ein industrieller Einsatz. Methoden und Mathematik sind also lange vorher fertig, denn die wird man dem Kunden ja anbieten müssen. Von daher ist es sicher möglich, eine Abschätzung zu liefern, wenn es daran geht die Kosten für eine Installation zu definieren. Muss man in Projekten außerhalb des Elfenbeinturms auch.
Schön, dass wir das alles geklärt haben. Hat jemand noch eine Idee bezüglich der eigentlichen Fragestellung: Beitrag "Re: 2 FPGAs bidirektional verbinden"
Was hast du denn zwischenzeitlich ausprobiert? Ideen gab es schließlich genug.
Die entscheidende Platine ist noch nicht da und die firmware auch noch nicht drin. Gfs klappt es noch vor Weihnachten, dass ich es testen kann. Werde aber berichten.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.