Forum: FPGA, VHDL & Co. Speichergrenze spartan6


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Detlef (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Detlef (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von bitwurschtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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.

von bitwurschtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christian R. (supachris)


Bewertung
0 lesenswert
nicht lesenswert
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.

von bitwurschtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von freduardo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Christian R. (supachris)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Frickler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
>
> Die Chip Revision kann/muss man im ucf angeben.
>

Hast du dazu mehr infos?

von freduardo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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'

von Christian R. (supachris)


Bewertung
0 lesenswert
nicht lesenswert
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
von Frickler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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. ;)

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.