Ich möchte im Spartan 3 einen recht breiten bus aus 64 Bit Daten in 8 Bit serialisieren. Dazu benutze ich ein FIFO, in dem ich die 64 Bit speichere und dann jeweils ein Element lese und die Daten in 8 bit Stücken schreibe. Das klappt auch soweit gut allerdings hat das einen massiven Verbrauch von RAM Blöcken zur Folge. Nach dem Mapping braucht das für nur 8 Elemente schon 7 RAM Blöcke. Das ist etwas suboptimal, da ich die auch noch für anderes brauche. Eine RAM Zelle hat ja 18kb und die wären dann eben quasi ungenutzt. Kann es sein, dass die Datenbreite an der Stelle dazu führt, dass so viele Zellen benutzt werden. Was wäre ein Ausweg?
Timo Z. schrieb: > 64 Bit Daten in 8 Bit serialisieren Das kann der Xilinx FIFO IP auch. Timo Z. schrieb: > Dazu benutze ich ein FIFO Ja. Aber wenn das die einzige Funktion des FIFO ist, dann muss der nicht sehr tief sein. Timo Z. schrieb: > massiven Verbrauch von RAM Blöcken Wie viele? Timo Z. schrieb: > für nur 8 Elemente schon 7 RAM Blöcke Was sind "Elemente"? Ein 18k BRAM kann als Dualport mit je 36 Bit betrieben werden. Für 64 Bit nach 8 Bit benötigst du also mindestens zwei 18k BRAMs. ------ Gute wäre dein Code mit dem du das FIFO bedienst. Das kann man nämlich alles wunderbar simulieren.
FPGA NOTFALLSEELSORGE schrieb im Beitrag #7107829: > Das kann der Xilinx FIFO IP auch. Den will ich aber nicht nutzen weil die IP Sachen das wenig portabel machen FPGA NOTFALLSEELSORGE schrieb im Beitrag #7107829: > Wie viele? 7 Stück habe ich geschrieben. FPGA NOTFALLSEELSORGE schrieb im Beitrag #7107829: > Was sind "Elemente"? Die FIFO Tiefe
Timo Z. schrieb: > Den will ich aber nicht nutzen weil die IP Sachen das wenig portabel > machen Also hast du den FIFO selber geschrieben? Zeig den doch mal her. Ich würde mir die Lösung so vorstellen: Du nimmst zwei BRAMs. Dann schreibst du für einen Takt jeweils 32 Bit/BRAM. Und du liest dann 8 Takte lang jeweils 8 Bits. Und zwar die ersten 4 Takte lang von dem einen BRAM und die nächsten 4 Takte lang von dem anderen BRAM.
Andererseits, wenn der FIFO wirklich nur die Funktion hat das von 64 Bit nach 8 Bit zu wandeln, dann würde ich gar kein BRAM verwenden. Dann baut man eine Gearbox. Also quaso ein Array aus FFs an das man immer hinten 64 Bits ranhängt und vorne 8 Bit wegnimmt.
Ganz schlechte Idee. Das packt einem schnell mal den gesamten FPGA je nach Tiefe voll weil das alles in LUTs gemacht wird.
FPGA NOTFALLSEELSORGE schrieb im Beitrag #7107883: > Also hast du den FIFO selber geschrieben? Ja habe ich. FPGA NOTFALLSEELSORGE schrieb im Beitrag #7107883: > Zeig den doch mal her. Nein mache ich nicht weil das ziemliche Arbeit war und ich damit Geld verdienen will.
FPGA Freak schrieb im Beitrag #7107929: > Ganz schlechte Idee. Was genau? Die Gearbox? FPGA Freak schrieb im Beitrag #7107929: > weil das alles in LUTs gemacht wird Was meinst du mit "das"? Hier geht es um 64 Bit nach 8 Bit, das ist eher überschaubar wenig. Selbst wenn das am Ende LUTs werden ist selbst ein kleines FPGA noch lange nicht voll. Und wenn man es richtig macht werden es ein paar FFs.
FPGA NOTFALLSEELSORGE schrieb im Beitrag #7107829: >> massiven Verbrauch von RAM Blöcken > > Wie viele? Das sind absolut nicht viele. Nur hat der Spartan 3 nur 20 gehabt, glaube ich. Wer baut denn heute noch mit so einer Krücke?
Dann sind es eben anteilig viele. Und außerdem unnötig viele. Für die paar Hände voll Bits muss man keine BRAMs verschwenden. Andererseits ... Wenn man die übrig hat, wieso nicht?
VHDL-Polizei schrieb im Beitrag #7108887: > Wer baut denn heute noch mit so einer Krücke? Immer das nehmen was für die Anwendung reicht und verfügbar ist. Manchmal reicht ein spartan 3 eben.
Beitrag #7109176 wurde von einem Moderator gelöscht.
Beitrag #7109210 wurde von einem Moderator gelöscht.
Timo Z. schrieb: > Ich möchte im Spartan 3 einen recht breiten bus aus 64 Bit Daten in 8 > Bit serialisieren. Dazu benutze ich ein FIFO, in dem ich die 64 Bit > speichere und dann jeweils ein Element lese und die Daten in 8 bit > Stücken schreibe. Lerne die Grundlagen der Digitaltechnik. Für Serializierung nimmt man kein FIFO sondern ein Shifter, respektive Serializer. wie man das in VHDL beschreibt steht in der XAPP465. Viele die die Grundlagen nie gelernt haben, machen dabei Fehler mit dem Reset und das Ganze wird zu groß. https://docs.xilinx.com/v/u/en-US/xapp465 Allerdings ist Deine Problembeschreibung widersprüchlich, eigentlich willste nicht serialialisieren sondern Dwords auf Bytes multiplexen. https://startingelectronics.org/software/VHDL-CPLD-course/tut4-multiplexers/
Timo Z. schrieb: > Nach dem Mapping braucht das für nur 8 Elemente schon 7 RAM Blöcke. Mich wundert hier eher, dass da nicht 8 BlockRAMS verwendet werden. Was ist das eine mal anders? > einen recht breiten bus aus 64 Bit Daten "einen" bedeutet ind Zahlen "1"? Dann wundert mich, dass du für einen (in Zahlen 1) 64-Bit breiten Bus mehr als ein (in Zahlen 1) BlockRAM zum Puffern brauchst. > Was wäre ein Ausweg? Kommt auf die nötige Fifo-Tiefe an. Wenn du nur 1 64-bit Wort empfängst und es dann schaffst, das in 8 8-Bit Häppchen zu verschicken, vor das nächste 64-Bit Wort kommt, dann brauchst du gar keinen Fifo. Wenn die 64-Bit Worte schneller kommen, dann wäre interessant, wie viele Bytes/Worte da gepuffert werden müssen. Bei entsprechend geringer Puffertiefe würde dann auch Distributed RAM ausreichen. Bei Puffertiefe = 1 reichen sogar 64 Flipflops. Учиться, учиться, снова учиться schrieb: > Allerdings ist Deine Problembeschreibung widersprüchlich, eigentlich > willste nicht serialialisieren sondern Dwords auf Bytes multiplexen. Ich sehe hier im Geiste trotzdem einfach 8 Stück 8-Bit-Schieberegister... ;-)
:
Bearbeitet durch Moderator
Ist das nicht eine klassische Aufgabe für ein Dual-Port Ram? Auf der einen Seite sind es eben Daten[63:0] mit Adresse[2:0] und auf der anderen Seite sind es Daten[7:0] mit Adresse[5:0]. Da kannst du den Coregenerator von Xilinx nehmen. Der packt das dann fertig zusammen. Schreib- uns Lesekollisionen sind dann auch schon kein Problem mehr. Und um das RAM packst du einen kleinen Automaten rum, der die Adressen durchzählt und ausgibt. Mehr ist das doch nicht. Da brauchst du auch keinen besonderen Schutz (weil du deinen Code nicht zeigen wolltest), wenn du das verkaufen willst. Das ist eine Standard-Anwendung! Gruß, Jens
Jens W. schrieb: > Da kannst du den Coregenerator von Xilinx nehmen. Will er nicht. Aber das was er will, also Datenbreite ändern bei gleicher Datenrate rein und raus ist das typische Verhalten einer Gearbox. Hier ist der Lesetakt (oder die Read Enables) 8 mal so hoch (oder 8 mal so häufig) wie der Schreibtakt (oder die Schreib Enables). Er kann also in jedem 8. Takt den 64 Bit Vektor in FFs übernehmen und gleichzeitig jeden Takt ein 8-Bit Häppchen davon ausgeben.
Gustl B. schrieb: > Er kann also in jedem 8. Takt den 64 Bit Vektor in FFs übernehmen und > gleichzeitig jeden Takt ein 8-Bit Häppchen davon ausgeben. und auch hier beschreibt der TE wieder nicht, mit welcher Datenrate er das tun will. Daran bemisst sich, wie man das machen muss. Gfs mit Registern.
Register sind FFs. Und was hat das mit der Datenrate zu tun? Gearbox bleibt Gearbox.
FPGA Notfallseelsorge schrieb im Beitrag #7116084: > Register sind FFs. Nein, nicht unbedingt. Slices bestehen aus LUT und FF. Die LUT's kann man aber auch als 16bit Shift-register (SRL16) konfigurieren. (siehe erwähnte XAPP465)
Das braucht ein SLICEM. Und das ist schon von sich aus keine einfache Taktfreie LUT, sondern kann als getakteter Speicher verwendet werden. Ist also quasi eine LUT mit Zusatzfunktion.
Die Begriffe sind tatsächlich schwierig. LUT ist eigentlich nur eine Anwendung von Speicher. Speicher gibt es mit Takt und ohne Takt. Ein Bit und mehrere Bits. Eine Reihe an Bits kann man als LUT verwenden wenn das adressierbar gebaut ist. Ohne Adresse dann als SR.
FPGA NOTFALLSEELSORGE schrieb im Beitrag #7120124: > Die Begriffe sind tatsächlich schwierig. Eigentlich nicht, sind nur recht viele Primitive dafür das sie als primitiv gelten ;-). Dafür hat man sie schön mit Logigtabelle etc. im passenden Library guide auf knapp 500 Seiten aufgelistet: https://www.xilinx.com/content/dam/xilinx/support/documents/sw_manuals/xilinx14_7/spartan3_hdl.pdf Einfach raussuchen was gebraucht.
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.