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.
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.
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... ;-)
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.
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.
Eine eigene Frage?
Dieser Thread ist über 4 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
