Hey Leute, welche Größe im Datenblatt für ein Fpga (Spartan 6) muss ich mir anschauen, um zu wissen wie viele Register und Wires (Verilog) ich insgesamt haben kann. Bzw. Wie viel Speicher mein Fpga hat und wie viel Speicher ein Register im Vergleich zum Gesamtspeicher verbrauchen würde.
Detlef schrieb: > um zu wissen wie viele Register und Wires (Verilog) ich insgesamt > haben kann. Die Wires sind sowieso nur eine rein logische Ressource, die nicht in einem Datenblatt abgebildet werden kann. Du kannst z.B. eine Schaltung mit 6 Eingängen und 1 Ausgang und vielen Wires und aller Logik einfach in 1 einzige 6er-LUT abbilden. Den Registerverbrauch kannst du bestenfalls überschlägig ermitteln, denn die Toolchain kann da auch ohne Weiteres Register verdoppeln oder zusammenfassen oder wegoptimieren. Oder sie packt ein einfaches 64 Bit Fifo Schieberegister, das ja 64 Flipflops hat, einfach in eine LUT. Oder sie packt einen Zustandsautomaten in einen RAM-Block, oder, oder... > Wie viel Speicher mein Fpga hat und wie viel Speicher ein Register im > Vergleich zum Gesamtspeicher verbrauchen würde. Dir fehlt ganz offensichtlich der Überblick, was in einem FPGA wo hinkommt und was du womit machen kannst. Dort musst du dringend ansetzen. Für deine Schaltungsbeschreibung bestehend aus Logik hast du grundsätzlich LUTs und Flipflops und die Verdrahtung dazwischen zur Verfügung. Damit lassen sich auch Werte speichern. Im Besonderen können die LUTs als kleine Speicherblöcke verwendet werden. Wenn die Datenmengen groß werden, dann gibt es RAM-Blöcke, die meist als Dual-Port-RAM ausgeführt sind. > welche Größe im Datenblatt für ein Fpga (Spartan 6) muss ich mir > anschauen Ich schaue mir die erste(n) Seite(n) an, dort wo die jeweiligen FPGA-Ressourcen aufgelistet sind: LUT, Flipflops, CLB, RAM, Taktnetze, Taktmanager, IO... So, und jetzt wieder zu deiner Frage: was ist denn dein eigentliches Problem? Warum fragst du da nach Vergleichswerten und Äquivalenzen?
Detlef schrieb: > welche Größe im Datenblatt für ein Fpga (Spartan 6) muss ich mir > anschauen, um zu wissen wie viele Register und Wires (Verilog) ich > insgesamt haben kann. Bzw. Wie viel Speicher mein Fpga hat und wie viel > Speicher ein Register im Vergleich zum Gesamtspeicher verbrauchen würde. https://www.xilinx.com/support/documentation/data_sheets/ds160.pdf https://www.xilinx.com/support/documentation/user_guides/ug363.pdf https://www.xilinx.com/support/documentation/user_guides/ug384.pdf
Lothar M. schrieb: > So, und jetzt wieder zu deiner Frage: was ist denn dein eigentliches > Problem? Warum fragst du da nach Vergleichswerten und Äquivalenzen? Erst mal vielen Dank für dein Antwort. Ich habe einen Fifo Buffer in meinem Code und ich frage mich eben wie gross der maximal sein darf. Hast du vielleicht eine gute Quelle, wo ich mich vielleicht nochmal besser reinlesen kann bzgl FPGAs und der richtigen Dimensionierung von FPGAs.
Detlef schrieb: > Ich habe einen Fifo Buffer in meinem Code und ich frage mich eben wie > gross der maximal sein darf. spiel mal mit dem Core-Generator in der ISE rum, damit kannst du fifo's für den jeweiligen FPGA nach Vorgaben wie Speicherbreite/-tiefe etc. generieren und der CoreGenerator sagt dir wieviel Resourcen (BRAM etc) im FPGA dafür benutzt werden. https://www.xilinx.com/support/documentation/ip_documentation/fifo_generator/v9_3/pg057-fifo-generator.pdf
RAM-Resourcen sind ein wenig weich, weil die sich teilweise die HW mit anderen resourcen teilen und auch RAMs dazu herangezogen werden (können) um Logik unterzubringen. Vor allem kann ein Teil des RAM-Bedarfs besser in Zellen verfrachtet werden. Die Sache beim Spartan 6 besonders tricky, weil der einige RAM-INIT-Defizite hat, welche je nach Anwendung mit Zellen ergänzt oder ersetzt werden müssen. Von daher ist das mit Vorsicht zu genießen und auf Sicherheit zu designen. Und: Spartan 6 ist ein wenig ein toter Chip, weil die Software dafür schon 5 Jahre nicht mehr weiterentwickelt wurde.
Detlef schrieb: > Hast du vielleicht eine gute Quelle, wo ich mich vielleicht nochmal > besser reinlesen kann bzgl FPGAs und der richtigen Dimensionierung von > FPGAs. Die einzig vernünftige Quelle ist so oder so das Synthese-Werkzeug. Installiere es, lass' die Synthese laufen und guck', was dabei rauskommt. Es nutzt dir nachher gar nix, wenn dein Design theoretisch in den Käfer passen würde, wenn's das Synthesetool aus irgendwelchen Gründen nicht hinkriegt.
Markus F. schrieb: > Es nutzt dir nachher gar nix, wenn dein Design theoretisch in den > Käfer passen würde, wenn's das Synthesetool aus irgendwelchen Gründen > nicht hinkriegt. Doch, die Info was der Chip nach Datenblatt kann nützt ne ganze Menge, beispielsweise kann er die Entscheidung nach dem passenden Synthesetool und Entwurfsmedologie erleichtern. Grad bei Speicherblöcken decken die verilog/VHDL Hochsprachen-beschreibungsmöglichkeiten nur einen Teil des realisierbaren an. Beispielsweise dataports mit unterschiedlicher Breite. Wenns halt das synthesetool nicht mit array-Beschreibung gebacken kriegt - dann instanziiert man halt die Blockram-Blöcke händisch. Oder man nutzt den Coregenerator, der dann auch für das Synthesetool passenden wrapper mitbastelt.
Jürgen S. schrieb: > Die Sache beim Spartan 6 besonders tricky, weil der einige > RAM-INIT-Defizite hat, welche je nach Anwendung mit Zellen ergänzt oder > ersetzt werden müssen. Von daher ist das mit Vorsicht zu genießen und > auf Sicherheit zu designen. > Naja, würde mal sagen: It's not a bug, it's a feature. Tut jetzt nicht so weh, ein ROM als RAMB16 zu implementieren. > Und: Spartan 6 ist ein wenig ein toter Chip, weil die Software dafür > schon 5 Jahre nicht mehr weiterentwickelt wurde. Das würde in dem Kontext als positiv sehen. Betr. Software heisst das bei Xilinx nämlich: Man kann endlich mit den Bugs leben. Der Chip ist deswegen noch lange nicht tot, eher gut bewährt, und es wird ihn darum auch noch lange geben.
Aufgrund der massiven Bugs am BRAM und der vielen Beschränkungen z.B. beim Clocking ist der S6 echt übel. Wenn man damit leben kann, OK. Aber für neue Designs setzen wir den nicht mehr ein. Die Artixe sind da viel besser. Xilinx hat zwar inzwischen eine Spartan 6 only ISE Variante für Windows 10 rausgebracht, aber auch das ist halt nur halbgar.
Christian R. schrieb: > Aufgrund der massiven Bugs am BRAM und der vielen Beschränkungen z.B. > beim Clocking ist der S6 echt übel. Echt? Also ich fand der S6 macht egenüber seinen Vorgängern S3 und S2 vieles besser.BUFGMUX sharing und Quadrantenbegrenzungen beim Clocking gehörten auch der Vergangenheit an etc.. Hardcore-Speichercontroller, mittel granulare IO-delays, das macht einem das Leben schon deutlich einfacher. U Und das die Entwicklungssoftware nicht ständig geupdatet qwerden muss sehe ich eher als Vor- statt als Nachteil. Ebenso das die tools auif Windows 7 und Linux laufen und man den bitteren Kelch "Kachel 0.8" und andere Mühsal an sich vorüber ziehen lassen kann.
Christian R. schrieb: > Aufgrund der massiven Bugs am BRAM und der vielen Beschränkungen z.B. > beim Clocking ist der S6 echt übel. Wenn man damit leben kann, OK. Mir sind diese Dinge bis jetzt auch noch nicht auf die Füße gefallen.... Duke
Duke Scarring schrieb: > Mir sind diese Dinge bis jetzt auch noch nicht auf die Füße gefallen.... weil die Firma mit dem grossen X sie geschickt kaschiert. Das Resultat der ominösen Adressleitungsgeschichte ist z.B. dass man kein zusammenhängendes großes RAM vernünftig betreiben kann, weil weite Teile des Decoders ausgelagert werden müssen, was die Geschichte enorm verlangsamt bis hin zur Nichtnutzbarkeit.
Ich hatte beim Spartan 6 folgendes "Phänomen" während eines Projekts: Ein FIFO mit dem Fifo-IP-Core erzeugt und ins Prjekt eingebaut zur Synchronisierung zw. zwei Taktdomänen und ggf. Datenpufferung. wr_clk und rd_clk waren zwei unabhängige Takte mit unterschiedlicher Frequenz. Es wurde gelesen, solange Daten im Fifo vorhanden waren, also empty auf '0' war. Wenn das Fifo leer war, und wieder etwas reingeschrieben wurde, ist das empty auf '1' gegangen, nur waren die reingeschriebenen Daten noch nicht am DOUT angekommen. Wenn also auf steigende Flanke der rd_clk empty "NICHT LEER" angezeigt hat, war noch nicht das neue Datenwort am DOUT, sondern das alte/vorhergehende... Simulation hat dieses Verhalten (diesen Fehler imho) selbstverständlich nicht abgebildet... Hat recht lange gedauert, bis wir rausgefunden haben, wo die falschen Daten herkamen und wie das zu beheben war (Lösung war letztendlich, nicht auf empty, sondern auf almost_empty zu hören. Dies ging aber auch nur, weil es sich um einen Datenstrom handelte und der eine Takt bzw. wenige Takte Verzögerung nicht die Funktionalität einschränkten). Interessanterweise schien dieser Bug nur bei ganz bestimmten Frequenzen und Frequenzverhältnissen von wr_clk zu rd_clk aufzutreten. Die Frequenzen waren auch nicht besonders hoch, sondern im humanen Bereich von um die 100-150 MHz. @Detlef: Die Aussagen über die verfügbaren Ressourcen im FPGA sind meiner Meinung nach eher theoretischer Natur. Sobald man mit seinem Design über 90%-95% einer bestimmten Ressource verbraucht, wird es für die Place&Route Werkzeuge sehr schwierig die Schaltung in die Ressourcen des FPGA unterzubringen und dabei noch das geforderte Timing zu erreichen. Ich will gar nicht davon anfangen, dass die Durchlaufzeiten für Synthese, Place&Route "plötzlich" explodieren. Ich hatte mal getestet, was passiert, wenn ich im einem vorhandenen Design mehr BRAMs verwende. Ich kam dann auf 93% Ausnutzung der BRAMs, nur wurden dann plötzlich 2 Timing Constraints nicht mehr eereicht. Nachdem ich die Constraints versuchsweise entschärft habe so dass sie erreicht werden konnten, ist die Zeit für Synthese+Implementierung von 5-6Min auf etwas über eine Stunde angestiegen.
Hier mal ein paar Zahlen aus dem letzten Synthesereport:
[pre}
...
---- Other Options
infer_ramb8 : No
...
INFO:Xst:3226 - The RAM <Mram_ram> will be implemented as a BLOCK RAM,
absorbing the following register(s): <memARead> <memBRead>
-----------------------------------------------------------------------
| ram_type | Block |
|
-----------------------------------------------------------------------
| Port A
|
| aspect ratio | 65536-word x 32-bit |
|
| mode | write-first |
|
| clkA | connected to signal <clk> | rise
|
| weA | connected to signal <memAWriteEnbl> | high
|
| addrA | connected to signal <memAAddr> |
|
| diA | connected to signal <memAWrite> |
|
| doA | connected to signal <memARead> |
|
-----------------------------------------------------------------------
| optimization | speed |
|
-----------------------------------------------------------------------
| Port B
|
| aspect ratio | 65536-word x 32-bit |
|
| mode | write-first |
|
| clkB | connected to signal <clk> | rise
|
| weB | connected to signal <GND> | high
|
| addrB | connected to signal <GND> |
|
| diB | connected to signal <GND> |
|
| doB | connected to signal <memBRead> |
|
-----------------------------------------------------------------------
| optimization | speed |
|
-----------------------------------------------------------------------
...
Number of RAMB16BWERs: 235 out of 268 87%
Number of RAMB8BWERs: 0 out of 536 0%
[/pre]
Wo finde ich jetzt, wie groß der Decoder ist?
Und von welchen Geschwindigkeiten reden wir hier?
Obiges Design läuft bei 50 MHz, die Serdes an den IOs mit 200 MHz und
Ethernet mit 125 MHz.
Duke
Duke Scarring schrieb: > Wo finde ich jetzt, wie groß der Decoder ist? Bei der gesteigerten Nutzung von Slices, bzw der reduzierten Möglichkeit, diese mit der Ansteuerlogik, die vor der Adresslogik sitzt, zusammenzufassen. Ein Xilinx FAE hat da mal in einem Forum was zu rausgegeben. Der Artikel ist dann aber von ihm selber später wieder wegmodiert worden. War wohl zu heiss, die Info! Die eierlegende Wollmilchsau Spartan 6, besonders die 45er-Version, sollte wohl weiter als all-inclusive Superchip gehandelt werden. > Und von welchen Geschwindigkeiten reden wir hier? Spartan 6 Designs habe Ich mit 300MHz partiell verwendet. Die RAMs können angeblich noch schneller. Angeblich. Wenn nix angeschlossen ist, wahrscheinlich. Man kennt ja die Thematik > Obiges Design läuft bei 50 MHz, Also im SPAR(tan) Modus. Da wundert es mich nicht, daß Du keine Einschränkungen bemerkst. Ach ja: Übrigens soll es so sein (ungesichterte Info) dass in späteren Chargen einige der Bugs behoben worden sein sollten und die SW da weniger drumherum baut. Wie die SW es merkt, welcher Chip angesprochen wird, blieb in der Diskussion offen.
freduardo schrieb: > Wenn das Fifo leer war, und wieder etwas reingeschrieben wurde, > ist das empty auf '1' gegangen, nur waren die reingeschriebenen Daten > noch nicht am DOUT angekommen. Wenn empty auf 1 gegangen ist, dann ist das FIFO doch offiziell "leer". Warum möchtest Du dann etwas daraus lesen können?
Weltbester FPGA-Pongo schrieb im Beitrag #5335969: > Wie die SW es merkt, welcher Chip angesprochen wird, blieb in der > Diskussion offen. Die Chip Revision kann/muss man im ucf angeben. Uns ist der blöde Bug mit der nicht korrekten Initialisierung der BRAMs auf die Füße gefallen. Das war zu der Zeit als Xilinx das noch nicht so richtig zugegeben hatte. Mit dem Clocking hatten wir einige Probleme beim Ansteuern der SERDES, das stand zwar zumindest im UG, ist aber stellenweise sehr einschränkend. Zum Glück gab es dann endlich die 7er, die sind einfach besser designed. Der Spartan 6 ist ja nur ein extrem abgespeckter Virtex 5. Sollte für alles herhalten, aber wie das mit eierlegenden Willmilchschweinen halt so ist. Klar, besser als der S3 war er schon, aber das sollte man ja schon erwarten. Übrigens läuft Vivado mittlerweile sehr gut und keiner zwingt einem Kachel Windows zu nutzen, das gibts ja auch für 7 und Linux. Ich bin froh, dass unsere IT endlich auf W10 umgestellt hat, endlich Linux Subsystem, funktionierendes USB 3.0 unabhängig vom Host Controller Hersteller und und und. Mit etwas Gefummel geht das allermeiste von ISE auch unter Windows 10.
Christian R. schrieb: > > Die Chip Revision kann/muss man im ucf angeben. > Hast du dazu mehr infos?
Weltbester FPGA-Pongo schrieb im Beitrag #5335994: > freduardo schrieb: >> Wenn das Fifo leer war, und wieder etwas reingeschrieben wurde, >> ist das empty auf '1' gegangen, nur waren die reingeschriebenen Daten >> noch nicht am DOUT angekommen. > > Wenn empty auf 1 gegangen ist, dann ist das FIFO doch offiziell "leer". > Warum möchtest Du dann etwas daraus lesen können? Sorry, war ein Zahlendreher... Ich wollte natürlich lesen, wenn das FIFO nicht leer war, also empty auf '0'
Das mit der Revision finde ich gerade nicht, aber den blöden Würgaround zum BRAM init hab ich noch gefunden: https://www.xilinx.com/support/answers/39999.html Eventuell erinnere ich mich auch falsch, und die Chip Rev Angabe war beim Spartan 3e oder Virtex 4. Edit: Bei nem alten Virtex 4 Design hab ich gefunden: CONFIG STEPPING = 2; Ob das auch beim Spartan 6 klappt, bin ich mir jetzt nicht mehr sicher, wir haben den aufgrund der Bugs dann direkt durch den Artix ersetzt sobald der verfügbar war.
:
Bearbeitet durch User
Christian R. schrieb: > Das mit der Revision finde ich gerade nicht, aber den blöden Würgaround > zum BRAM init hab ich noch gefunden: > https://www.xilinx.com/support/answers/39999.html > Eventuell erinnere ich mich auch falsch, und die Chip Rev Angabe war > beim Spartan 3e oder Virtex 4. > > Edit: Bei nem alten Virtex 4 Design hab ich gefunden: > CONFIG STEPPING = 2; > Ob das auch beim Spartan 6 klappt, bin ich mir jetzt nicht mehr sicher, > wir haben den aufgrund der Bugs dann direkt durch den Artix ersetzt > sobald der verfügbar war. Danke Dir! Mal fix probiert mit einem S6, aber leider sagt ISE... "WARNING:Pack:1375 - STEPPING Levels are not supported for this device." Einen Versuch war es wert. ;)
freduardo schrieb: > Ich hatte beim Spartan 6 folgendes "Phänomen" während eines Projekts: Bei FIFOs in divergenten Domänen ist der Zeitpunkt der Flanke und des Resets interessant. Da gibt es ganz grundsätzlich das Problem, dass sich Takte zwischen Reset, Schreib- und Leseprozeduren, die scheinbar voll sequenziell laufen, überholen können und damit gleich instanziierte FIFOs nach lokalem Signalzustand mit unterschiedlichen Zuständen gesetzt werden können. Daher sind bei asynchronen, nicht deterministischen Domänen immer +/-1 Takte zusätzlich in Betracht zu ziehen. Was die interpretation der Signale angeht, muss genau geschaut werden, in welche Domäne die jeweils synchron sind. Jedes der Signale - auch das "empty" - kann nur nur einer domain vollkommen synchron und korrekt sein.
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.