Hallo zusammen, ich stehe vor der Aufgabe, ein solides, einfaches und robustes Interface zu schaffen. Es sollen zwei Boards miteinander kommunizieren, die einen Systemtakt von 30MHz haben. Die Daten sollen innerhalb von einem Takt übertragen werden und ich habe 134 Bits (125 in, 9 out) zu übertragen. Neben dieser Echtzeit Übertragung von einem Takt zum anderen habe ich noch ein Registerinterface, auf das ich nun aufsetzen wollte. Mein zur Verfügung stehender Steckverbinder hat 30 Pins. Nun habe ich mir gedacht, dass ich meine 134 Bits in sinnvolle 16 Bit Blöcke unterteile, also so, wie sie auch logisch zusammen gehören. Das ist gleichzeitig meine Registerbreite. Dann unterteile ich in IN und OUT Register, die also read-only und write-only sind. Allen Registern ordne ich eine Adresse zu, so dass ich nicht erst unterscheiden muss, ob ich lese oder schreibe. Wird auf eine read-only Adresse zugegriffen, werden die Daten einfach in den Master geschrieben (Master: Register <= Bus, Slave: Bus <= Register). Wird auf eine write-only Adresse zugegriffen, werden die Daten einfach in den Slave geschrieben (Master: Bus <= Register, Slave: Register <= Bus). Damit mit jedem 30MHz Takt die Register aktuell sind, muss ich die Übertragung mit einer höheren Taktfrequenz betreiben. Also meinetwegen bei 10 Zugriffen (160 Bits) um die 10fache Systemfrequenz, nämlich 300MHz. Das Register Interface funktioniert dann im "Register mode" mit Systemtakt, weil hier keine Echtzeitanwendung dahinter steht. Meine 134 Bits werden aber im "real time mode" mit 300MHz übertragen und so stehen sie beim nächsten Systemtakt zur Verfügung. Die Register sind dann mit jedem 30 MHz Takt auf beiden Seiten identisch. Durch die feste Zuordnung von write und read Registern erspare ich mir ein RNW Signal und auch das OEN Signal fällt weg. Haben die Überlegungen noch irgendwelche Schwächen, oder kann man das so umsetzen? Vor allem die feste Zuordnung von read und write - hat das Schwächen? Ich erarbeite das erste mal etwas eigenes, konnte mich bisher immer auf Datenblätter und Timingdiagramme verlassen, weil das Interface quasi schon vorgegeben war. Vielen Dank! Ralf
Welchen Steckverbinder hast du? Wie wgroß ist die Distanz zwischen den Boards? Gibt es andere Besondere Randbedingungen (EMV, ExSchutz ect.)? Wie wird die Übertragung gesichert? Ist es tragisch wenn eine Übertragung schief geht?
Vorweg gesagt: 300MHz auf der Platine sind sportlich. Und 300MHz am FPGA-Pin etwas für Ausgeschlafene... Ralf schrieb: > Also meinetwegen bei 10 Zugriffen (160 Bits) um die 10fache > Systemfrequenz, nämlich 300MHz. Warum überträgst du nur 16 Bits, wenn du auch 24 oder gar 29 übertragen könntest? Willst du lieber bequem rechnen können, oder ein einfach(er)es Platinenlayout?
Hallo, ich denke die Frage zielt darauf ab, ob der Interface Takt von 300MHz übertragen werden kann?! Ich denke das ist machbar, das Layout wird dann entsprechend der Frequenz des Interfaces angefertigt. Der Steckverbinder ist ein High-Speed Steckverbinder von Samtec, auf dem noch 30 Pins zur Verfügung stehen. Alle anderen sind durch VDD, GND usw. belegt. Der Abstand zwischen beiden FPGAs wird nicht mehr als 10-15cm betragen. Es soll also nicht über mehrere Meter übertragen werden. Das Interface sollte schon so robust sein, dass eine fehlerhafte Übertragung eher unwahrscheinlich ist. Daher mein primitiver Ansatz mit möglichst wenigen Steuerleitungen, die zappeln müssen. Es muss aber keine ausfallsichere Übertragung sein. Die Sache ist für einen Laboraufbau gedacht... wenn also mal was schief geht, kann man entsprechend reagieren. Es muss also nicht in einer Millionen Stückzahl gefertigt werden :) Vielen Dank! Ralf
Lothar Miller schrieb: > Vorweg gesagt: 300MHz auf der Platine sind sportlich. Und 300MHz am > FPGA-Pin etwas für Ausgeschlafene... Das ist mir bekannt und bewusst. Es war eher als Bsp. zu sehen. Wie breit ich die Register dann mache und wie viel Zugriffe dann daraus resultieren, muss ich genau ausrechnen. Ziel sollte es aber sein, die Frequenz niedrig zu halten. > Warum überträgst du nur 16 Bits, wenn du auch 24 oder gar 29 übertragen > könntest? Willst du lieber bequem rechnen können, oder ein einfach(er)es > Platinenlayout? Aber an sich spricht nichts dagegen, wenn alle Steuersignale, Adressen etc. vorhanden sind, alle noch verbleibenden Pins für die Übertragung zu nutzen. Ist ja dann nur eine Sache des mappings im master und slave. Ich wollte erstmal prinzipiell die Vorgehensweise des Interfaces diskutieren, bevor ich mit konkreten Zahlen rechne. Vielen Dank! Ralf
>Neben dieser Echtzeit Übertragung von einem Takt zum anderen
Gibt es jeden Takt bis in alle Unendlichkeit Daten oder gibt es Pakete,
die eine entsprechende Paketlücke aufweisen? Was sind das überhaupt für
Daten?
Ralf schrieb: > Ich wollte erstmal prinzipiell die Vorgehensweise des Interfaces > diskutieren, bevor ich mit konkreten Zahlen rechne. Warum nimmst du nicht die Serdes-IO, die zwischenzeitlich jedes FPGA an Bord hat? Da sind Übertragungsraten in deiner Dimension (125*30MHz) leicht machbar, wenn du mehrere Kanäle parallel schaltest.
>Es sollen zwei Boards miteinander kommunizieren
Wie werden diese Boards denn miteinander verbunden?
Flachbandkabel o.Ä.?
Hallo, Joe schrieb: > Gibt es jeden Takt bis in alle Unendlichkeit Daten oder gibt es Pakete, > die eine entsprechende Paketlücke aufweisen? Was sind das überhaupt für > Daten? Im Normalbetrieb, wenn also nicht gerade im Registerinterface rumkonfiguriert wird, gibt es Daten bis in die Unendlichkeit. Die Übertragung kann aufgrund von diversen Steuersignalen (ca. 15) für externe Peripherie nicht auf Pausen ausgelegt werden, weil diese taktgenau ausgewertet werden müssen. Lothar Miller schrieb: > Warum nimmst du nicht die Serdes-IO, die zwischenzeitlich jedes FPGA an > Bord hat? Da sind Übertragungsraten in deiner Dimension (125*30MHz) > leicht machbar, wenn du mehrere Kanäle parallel schaltest. Ich würde das Interface gerne ohne FPGA spezifische Bestandteile in VHDL umsetzen, so dass es dann auf jeder Plattform Xilinx, Altera, ASIC etc. implementierbar ist. Es soll zwar kein IP entstehen, aber eine Wiederverwendbarkeit sehe ich schon als wichtig an. Einzig die PLL zum Erzeugen des Interface Taktes könnte austauschbar sein und wird vorerst von Altera stammen (heisst die da auch DCM wie bei Xilinx?). Joe schrieb: > Wie werden diese Boards denn miteinander verbunden? Die Boards werden ohne Kabel mit den board-to-board Samtec Steckverbindern kommunizieren. Vielen Dank! Ralf
Grundsärtlich lässt sich das bauen, mit einem aktuellen FPGA kriegst Du ja auch einen 200 MHZ DDR3 RAM ans laufen und da rennt der Datentakt auf 800 MBit. Bei 400Mhz - gfs als DDR - bekommst Du zwischen den FPGAs sicher 4-5 cm Distanz hin, wenn Du ein gutes matching beteibst. Die Leiterbahnlängen laufen dann mit ca. 8-10 cm. Wichtig ist eine gute Führung mit sauberer Impedanz. Wenn Du das receiver-FPGA auf den Sender eintrainieren lässt, ist das kein Problem. Ist halt Aufwand.
Bastian schrieb: > Grundsärtlich lässt sich das bauen, mit einem aktuellen FPGA kriegst Du > ja auch einen 200 MHZ DDR3 RAM ans laufen und da rennt der Datentakt auf > 800 MBit. Aber nicht mit LVCMOS, Und das hier beschränkt es darauf: Ralf schrieb: > Ich würde das Interface gerne ohne FPGA spezifische Bestandteile in VHDL > umsetzen, so dass es dann auf jeder Plattform Xilinx, Altera, ASIC etc. > implementierbar ist. > Einzig die PLL zum Erzeugen des Interface Taktes könnte austauschbar sein
Ralf schrieb: > Ich würde das Interface gerne ohne FPGA spezifische Bestandteile in VHDL > umsetzen, Naja, das geht ja schon mal überhaupt nicht, denn du willst es ja letztendlich auf eine FPGA umsetzen. Und das Timing wird zusammen mit den Constraints hier den Knackpunkt darstellen. > so dass es dann auf jeder Plattform Xilinx, Altera, ASIC etc. > implementierbar ist. Auf jeder dieser Plattform sind Serdes und DDR-FFs Standard. Du wirst auch bei gleichem VHDL-Code sowieso mindestens das Constraints File herstellerabhängig haben. Warum nicht einfach eine Ebene mehr, und das IO-Interface auch technologiespezifisch? Denn gerade da an der Schnisstelle zur Aussenwelt kann und muss man das eingekaufte Silizium am sinnvollsten einsetzen.
Guten Morgen, ich bin meine Anforderungen nochmal durchgegangen. Wenn ich mit voller Datenbreite arbeiten kann, komme ich mit 7 Takten aus. Das sind etwas mehr als 200MHz. Aber ich sehe schon, ich werde mich auf eine Plattform festlegen müssen. War vielleicht etwas naiv der Ansatz... Ich habe schon mal ein Serielles Interface verbaut. Das hat aber mit LVDS gearbeitet. Das war ein Spartan 3 und lief problemlos auf 160MHz. Aber ob LVDS bei meiner aktuellen Problemstellung in Frage kommt, muss ich abklären. Mal abgesehen von den Frequenzen, den Übertragungswegen usw. - wäre das Interface denn vom Protokoll mit den read und write only Registern robust genug? Oder übersehe ich da noch etwas und es gibt vielleicht Probleme bei der Einsynchronisierung in den Systemtakt oder so? Vielen Dank für die Hilfe! Ralf
Ralf schrieb: > wäre das Interface denn vom Protokoll mit den read und write only > Registern robust genug? Was bedeutet für dich "robust"? In deiner gesamten Betrachtung im ersten Post steht nichts zur Qualität. Dort wird nur frischfrommfröhlichfrei Physik mit Struktur (Pinanzahl mit "Register-Mode") vermischt und neue Namen für alte Begriffe definiert. Du solltest deine Informationen mal von der Hardware trennen und sagen: Ich muss 125Bits*30MHz = 3,75 GBit/s netto übertragen. Welches Medium kann das? Ralf schrieb: > Oder übersehe ich da noch etwas und es gibt vielleicht > Probleme bei der Einsynchronisierung in den Systemtakt oder so? Bei dieser Datenrate darfst du nichts mehr einsynchronisieren (wollen/müssen)! Die Daten müssen synchron kommen!
Hallo, Lothar Miller schrieb: > Bei dieser Datenrate darfst du nichts mehr einsynchronisieren > (wollen/müssen)! Die Daten müssen synchron kommen! Das war vielleicht etwas unglücklich ausgedrückt. Beide Chips arbeiten mit 30MHz. Das Interface (wie es immer auch aussehen mag) muss ja dann mit einer höheren Frequenz arbeiten, wenn ich nicht gerade einen 134bit breiten Bus habe. Der Übergang von 30MHz - IF MHz - 30MHz könnte in meinen Augen ein Problem sein, auch wenn die Takte an sich synchron sind. Lothar Miller schrieb: > Du solltest deine Informationen mal von der Hardware trennen und sagen: > Ich muss 125Bits*30MHz = 3,75 GBit/s netto übertragen. > Welches Medium kann das? Dieser Ansatz schockt mich gerade etwas - ist zwar genau das, was ich die ganze Zeit erzähle, aber so auf den Punkt gebracht machen mir ca. 4GBit/s schon etwas Angst. Vielen Dank! Ralf
Ralf schrieb: > aber so auf den Punkt gebracht machen mir ca. 4GBit/s schon etwas Angst. Tja, das wars, was mir an deiner Umschreibung aufgefallen ist: du versuchst einen Nebenschauplatz (mit Protokollen und pipapo) aufzumachen, um dich selber von dieser recht ansehnlichen Datenrate abzulenken...
>und lief problemlos auf 160MHz.
Dann wird es ca 268Mbps wahrsch. auch schaffen
Der erste LVDS-Standard hat schon 622Mbps.
Ich würde die beiden Teilaufgaben Datenübertragung und Registerugriff trennen. Dann kann den Registerzugriff mit den langsamen 30 MHz ohne spezielle FPGA Eigenschaften machen. Weiter gehe Ich gehe davon aus, dass deine Samtec Verbinder eine gtrennte Masseschiene haben, d.h. dass die verfügbaren 30 Pins nicht auch noch mit GND belegt werden müssen. Mit
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.