Hallo! Ich bekommen ein 256 bit breites Signal, das in 64 32 Bit Words unterteilt und eines nach dem anderen gesendet werden soll. Nun gibt es da zwei Herangehensweisen: 1. Ich konnte ein Shift-Register mit den 64 Words füllen und dann eines nach dem anderen heraus shiften. 2. Ich könnte einen Counter laufen lassen und dann den jeweiligen Teil aus dem Signal demuxen. Prinzipiell funktioniert ja beides. Aber was wäre auf einem Xilinx Virtex-6 schneller? Vielen Dank im Voraus! Sawtooth
Er meinte vermutlich 2048 Bit, wie du dir sicherlich schon gedacht hast ;)
Ja, natürlich. ;-) Also, hat da jemand Erfahrungswerte, was schneller ist?
Am schnellsten auf dem Virtex vermutlich die Kombination aus einem OSERDES und einer vorgeschalteten Logik (oder FIFO), die die 2048 erst mal auf die Breite des OSERDES Eingangs bringt. Geht natürlich nur, wenn du die serialisierten Daten nur extern brauchst.
Ich finde es erschreckend das Leute die wenig Ahnung von FPGAs haben einen Virtex 6 verwenden :-) Dieser Baustein ist doch so extrem teuer. Er verwendet sicherlich nicht mal 1% der LUT und FFs. Wieso nimmst Du denn keinen Spartan 6 oder ARTIX7 die sind doch viel günstiger und erledigen dies sicherlich auch. Wie hoch muss denn die Übertragungsrate sein.
@supachris: Nein, das Signal wird intern noch verarbeitet, bevor es raus geht. Aber ein FIFO dazwischen zu schalten ist eine gute Idee, da ich nicht kontinuierlich senden muss. Danke für den Denkanstoß! :-) @Sebastian: > Dieser Baustein ist doch so extrem teuer. Er verwendet sicherlich nicht > mal 1% der LUT und FFs. Mal schauen, was map so meint: Slice Logic Utilization: Number of Slice Registers: 16,060 out of 301,440 5% Number used as Flip Flops: 16,059 Number used as Latches: 1 Number used as Latch-thrus: 0 Number used as AND/OR logics: 0 Number of Slice LUTs: 17,866 out of 150,720 11% Number used as logic: 16,138 out of 150,720 10% Number using O6 output only: 13,057 Number using O5 output only: 1,443 Number using O5 and O6: 1,638 Number used as ROM: 0 Number used as Memory: 0 out of 58,400 0% Number used exclusively as route-thrus: 1,728 Number with same-slice register load: 1,609 Number with same-slice carry load: 119 Number with other load: 0 > Wieso nimmst Du denn keinen Spartan 6 oder ARTIX7 die sind doch viel > günstiger und erledigen dies sicherlich auch. Weil die kein radiation hardened Äquivalent haben. > Wie hoch muss denn die Übertragungsrate sein. 1 GBit/s. Allerdings nicht kontinuierlich.
Kann jemand noch etwas zu folgendem (vielleicht auftretendem) Problem sagen: Ich habe irgendwo im Kopf, dass es eine Limitierung gibt, wie viele Bits zugleich im FPGA schalten können. Gibt es so etwas? Würde man jetzt ein riesiges Schieberegister erstellen (ohne explizite HW-Unterstützung wie SERDES), 2048 lang, dass bei jedem Takt 2048 Bit umlädt, würde dies funktionieren?
Im FPGA ist das weniger ein Problem, eher an den Ausgangs-Pins. Da gibts einen Wert, wieviele Ausgänge gleichzeitig (pro Bank meistens) schalten dürfen. SSO heißt das im englsichen. Synchronous switching outputs. Im FPGA schalten auch im Normalbetrieb weitaus mehr als 2048 Bits gleichzeitig....
Fragender schrieb: > Würde man jetzt ein riesiges Schieberegister erstellen (ohne explizite > HW-Unterstützung wie SERDES), 2048 lang, dass bei jedem Takt 2048 Bit > umlädt, würde dies funktionieren? Problemlos, vorausgesetzt dein Power-Konzept (Stromversorgung, Abblockung etc.) ist einigermassen seriös gebaut. Falls das nicht ginge, würde es kaum Sinn machen, reisige FPGA's mit vielen BRAM und DSP-Blocks, usw. herzustellen...
Sawtooth schrieb: >> Wie hoch muss denn die Übertragungsrate sein. > 1 GBit/s. Allerdings nicht kontinuierlich. Und wieviel effektiv? Christian R. schrieb: > Synchronous switching outputs. Ich kenne das als Simultaneous Switching Outputs... ;-)
Lothar Miller schrieb: > Ich kenne das als Simultaneous Switching Outputs... ;-) Ups :) Stimmt natürlich.
@lkmiller: >>> Wie hoch muss denn die Übertragungsrate sein. >> 1 GBit/s. Allerdings nicht kontinuierlich. > Und wieviel effektiv? Das kann man nicht sagen. Die Daten werden vom FPGA immer dann herausgegeben, wenn sie angefordert werden. Das ist aber auch nicht wichtig. Wichtig ist nur, dass dies mit einer bestimmten Geschwindigkeit getan werden muss (125 MB/s). Daher auch die Frage, ob das mit einem Schieberegister oder einem Demuxer effizienter geht. :-) @Fragender: > Kann jemand noch etwas zu folgendem (vielleicht auftretendem) Problem > sagen: Ich habe irgendwo im Kopf, dass es eine Limitierung gibt, > wie viele Bits zugleich im FPGA schalten können. Gibt es so etwas? > Würde man jetzt ein riesiges Schieberegister erstellen (ohne explizite > HW-Unterstützung wie SERDES), 2048 lang, dass bei jedem Takt 2048 Bit > umlädt, würde dies funktionieren? Klar ist das möglich. Das habe ich ja oben schon als eine der beiden Möglichkeiten geschrieben. Ich habe das jetzt auch mal implementiert, da ich vermutet habe, dass hier weniger zeitraubende Logic gebraucht wird als bei einem Demuxer. Das ist auch im Prinzip richtig, allerdings geht dafür recht viel fürs Routing drauf (0.744ns logic, 7.208ns route). Bei Zeiten versuche ich das auch mal mit einem Demuxer, aber viel Hoffnung, dass es schneller ist, habe ich nicht. ;-)
>Bei Zeiten versuche ich das auch mal mit einem Demuxer, aber viel Hoffnung, >dass es schneller ist, habe ich nicht. ;-) Das hat mir Hoffen nichts zu tun. Probier einfach beides aus, schau Dir an was dabei herauskommt, und lerne daraus.
Das hört sich ja nach GBit Ethernet als Schnittstelle an. Was ist denn bitte schön radiation hardened Äquivalent
> Das hört sich ja nach GBit Ethernet als Schnittstelle an. So was ähnliches, ja. ;-) > Was ist denn bitte schön radiation hardened Äquivalent http://www.xilinx.com/applications/aerospace-and-defense/space/index.htm
Ich frag lieben nicht was Du damit vor hast es sieht sehr aufwändig aus :-) Auf jedenfall viel Erfolg
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.