Hallo,

Ich stehe davor demnächst ein größeres FPGA Projekt zu beginnen.
Mit groß meine ich jetzt für meine Verhältnisse groß. D.h. externe
Komponenten wie mehrere ADCs, SDRAM, FX2,...
Das ist jetzt nicht so extrem groß, aber größer als alles was ich bisher
gemacht habe.

Daher meine Frage: Gibt es Richtlinien für größere Projekte?
Ich meine jetzt nicht unbedingt wie man das Projekt strukturiert
bekommt. Vorher werde ich sicher genau definieren, was die FPGA am Ende
machen soll und nicht drauf los designen.
Das ich im Projekt den Überblick verliere ist auch nicht meine
Befürchtung. Mit Instantiierungen sollte das ganze übersichtlich machbar
sein.

Meine Frage ist ehr:
Was ändert sich, wenn das Design größer wird?
Beispiel Zustandsmaschine: Es ist klar, dass die nicht beliebig viele
Zustände haben kann, aber was ist maximal möglich/sinnvoll?
Gibt es andere Dinge über die man sich da Gedanken machen muss?
Was sind die schlimmsten Fehler mit denen man sich ein Design langsam
machen kann?

Oder ist das ganze gar nicht so wild wie ich es mir vorstelle und es ist
nicht mehr oder weniger zu beachten als bei einem "ordentlichen"
kleineren design?

Viele Grüße,
Christian

>Ich stehe davor demnächst ein größeres FPGA Projekt zu beginnen.

Benutzt Du eine fertige Platine für den FPGA, oder machst Du sie selbst?
Beim selber machen kann man natürlich einiges falsch oder zumindest
ungünstig machen. Leider.

Die Platine mache ich selbst. Damit habe ich aber auch ein wenig mehr
Erfahrung (Betonung auf wenig). Sicher wird sich im nachhinein
herausstellen, dass ich den einen oder anderen Fehler gemacht habe. Für
das Projekt eine Platine zu machen ist für mich aber auf jeden Fall der
nächste Schritt. Für fast jeden Teil der Schaltung habe ich etliche
Prototypen gebaut und getestet, die natürlich nur die Teilfunktion
erfüllen. Ich wüsste keinen sinnvollen Schritt, den ich noch vor dem
erstellen der großen Platine machen könnte.

Was für typische Fehler wüsstest du denn?

>Was für typische Fehler wüsstest du denn?

Ich habe bisher noch keine Platine mit einem FPGA selbst gemacht, kommt
aber wahrscheinlich in den nächsten Monaten.

Ich gehe eigentlich fest davon aus, dass mein erster Prototyp nicht
funktionieren wird: Vertauschte Leitungen, insbesondere die zur
Konfiguration des FPGA. Probleme durch Signallaufzeiten, Reflexionen...

Da können Dir Andere sicher mehr sagen, vielleicht der derzeit so
schweigsame Herr Brunner.

Mein großer Vorteil ist, dass ich nicht unter Zeitdruck stehe. D.h. ich
kann alles 10 mal Kontrollieren.

Reflektionen sind nicht meine größte Sorge. Bei Frequenzen von 50 bzw
133 MHz und Leitungslängen von wenigen cm rechne ich nicht mit großen
Schwierigkeiten. Aber das kann man ja in IBIS mal testen.

@  Stefan Salewski (Gast)

>Ich gehe eigentlich fest davon aus, dass mein erster Prototyp nicht
>funktionieren wird: Vertauschte Leitungen, insbesondere die zur
>Konfiguration des FPGA. Probleme durch Signallaufzeiten, Reflexionen...

Warum sooo pessimistisch? Aller Wahrcheinlichkeit werden Fehler drauf
sein, ja. Aber meist läuft der Prototyp, wenn auch mit kleineren oder
grösseren Korrekturen.

>Da können Dir Andere sicher mehr sagen, vielleicht der derzeit so
>schweigsame Herr Brunner.

Die Wissenden reden nicht.
Die Redenden wissen nicht.

  Laotse

@ Christian H. (cavorca)

>Reflektionen sind nicht meine größte Sorge. Bei Frequenzen von 50 bzw
>133 MHz und Leitungslängen von wenigen cm rechne ich nicht mit großen
>Schwierigkeiten. Aber das kann man ja in IBIS mal testen.

Lass das mal nicht MC Murphy hören . . . .

133 MHz SDRAM hat so Pi mal Dauem 1ns Anstiegszeit. -> 20cm Laufzeit ->
ab 3cm Reflexionen etc.

Siehe Wellenwiderstand

Was sollte man beachten? Hmmm Grübel

Hardware:

- Solide Spannungsversorgung
- Prüfen, ob eine Einschaltreihenfolge der verschiedenen Spannungen
nötig ist
- Prüfen, ob beim Einschalten ein hoher Strompuls benötigt wird
- Prüfen, elche verschiedenen IO-Spannungen benötigt werden
- Bei schnellen Signalen, den Wellenwiderstand beim Layout beachten
- Ein paar frei Pins auf in Stecker legen, zum Testen
- JTAG/Programmieranschluss auf einen Stecker legen (keine Einzelpins!)

Software:

- Design sinnvoll in Module gliedern, eher ein bisschen mehr als zu
wenig
- Ein SOLIDES Konzept erstellen und durchdenken
- Taktkonzep , sehr wichtig. Mit so wenig wie möglich verschiedenen
Takten arbeiten
-  Voll synchrones Design, keine asynchronen Tricks, Siehe auch
Taktung FPGA/CPLD
- Taktverteilung für IO solide planen. Takte kann man nicht einfach mal
auf ein beliebiges IO Pin geben und zu nem IC routen. Das geht in den
meisten Fällen NICHT, Siehe SDRAM-Timing
- Pinbelegung sinnvoll strukturieren, dabei auf einfaches Layout achten
und die verschieden IO-Bänke mit möglicherweise verschiedenen
IO-Spannungen beachten; IO Pins kann man immer noch ein wenig per
Software tauschen, bei Takten geht das meistens NICHT
- IO-Treiber so langsam und schwach wie möglich einstellen, um Probleme
mit Reflexionen und EMV zu minimieren
- Wenn asynchrone Takte/Signale vorhanden sind, diese sehr solide und
vorsichtig behandeln (Asynchrone FIFOs, doppeltes Abtasten vor der
Nutzung in State-Machines etc.)
- Ausgangssignale möglichst über FlipFlops treiben, das macht das
IO-timig schneller, selbes für Eingangssignale

Simulation

- Verhaltensimulation reicht im allgemeinen aus. Post Place & Route
Simulation ist aufwändig und langsam. In einem soliden synchronen Design
reicht eine automatische Timinganalyse

Und noch viele Dinge mehr, die mir spontan nicht einfallen

MFG
Falk

Ein schnell gemachter Fehler ist eine zu mickrige Speisung. Altera zB
hat als Fussnote fuer den Stromverbrauch 15% Auslastung der Gatter. Dh
wenn's langsam voll wird, kann der Strom der siebenfache sein. Wer hat
die Speisung denn schon siebenfach ueberdimensioniert ....

Da du keinen Zeitdruck hast, empfehle ich, das FPGA-Design VOR dem
endgültigen Routing der Platine komplett zu erstellen und zu simulieren.
Auch immer mal eine Timing-Simulation laufen lassen, gerade bei vollen
FPGA mit einigen schnellen Pfaden kommt´s da gerne mal zu Setup- und
Hold-zeit-Verletzungen. Ansonsten auf jeden Fall vorher das gesamte
Konzept aufstellen, und alles simulieren. Ohne Simulation wird das nur
Harakiri im Blindflug. Ich kenn da einen Kollegen....5 Bit
Logic-analyser an 5 Testpins und dann los....naja.

Falk Brunner wrote:
> Lass das mal nicht MC Murphy hören . . . .
>
> 133 MHz SDRAM hat so Pi mal Dauem 1ns Anstiegszeit. -> 20cm Laufzeit ->
> ab 3cm Reflexionen etc.
Ich hoffe unter 3 cm bleiben zu können. Ich hoffe auch durch die kurzen
Leitungen die timing Probleme weitgehend umschiffen zu können.

> Siehe Wellenwiderstand
>
> Was sollte man beachten? Hmmm *Grübel*
>
> Hardware:
OK
Wie sieht es eigentlich mit der Taktverteilung aus? Also insb. die
Versorgung der 4 ADCs. Es heißt ja, dass man keinesfalls einen vom FPGA
generierten Takt für high speed ADCs nehmen soll. Aber gilt das auch,
wenn man den Ausgang eines DCMs auf einen Pin legt?
In den App-notes steht ja, dass die dinger den Takt aufarbeiten.
Also was ist besser: Quarzoszillator direkt an alle ADCs und den FPGA
(sofern der Oszillator so viele Eingänge Treiben kann) oder nur in den
FPGA und von da aus über einen DCM an die ADCs?

> Software:
Das einzige was bei mir Asynchron sein wird sind externe
Trigger-Signale. Aber die kann ich ja synchron abtasten.
Takte werde ich 2 oder 3 verwenden. Nur einer wäre mir viel lieber, aber
das geht nicht. Die Daten kommen mit 50MHz.


> Simulation
>
> - Verhaltensimulation reicht im allgemeinen aus. Post Place & Route
> Simulation ist aufwändig und langsam. In einem soliden synchronen Design
> reicht eine automatische Timinganalyse

OK.

3363 wrote:
> Ein schnell gemachter Fehler ist eine zu mickrige Speisung. Altera zB
> hat als Fussnote fuer den Stromverbrauch 15% Auslastung der Gatter. Dh
> wenn's langsam voll wird, kann der Strom der siebenfache sein. Wer hat
> die Speisung denn schon siebenfach ueberdimensioniert ....
Ich werde dann die Maximalwerte aller ICs zu addieren. Dann sollte ja
nichts schief gehen.
Für die Versorgung +-5V werde ich auch erst mal ein externes Netzteil
verwenden. Sowas zu bauen ist ja ein Thema für sich.



Christian R. wrote:
> Da du keinen Zeitdruck hast, empfehle ich, das FPGA-Design VOR dem
> endgültigen Routing der Platine komplett zu erstellen und zu simulieren.
> Auch immer mal eine Timing-Simulation laufen lassen, gerade bei vollen
> FPGA mit einigen schnellen Pfaden kommt´s da gerne mal zu Setup- und
> Hold-zeit-Verletzungen. Ansonsten auf jeden Fall vorher das gesamte
> Konzept aufstellen, und alles simulieren. Ohne Simulation wird das nur
> Harakiri im Blindflug. Ich kenn da einen Kollegen....5 Bit
> Logic-analyser an 5 Testpins und dann los....naja.

Das erfordert natürlich viel Disziplin. Aber es ist schon der richtige
Weg. Geplant hatte ich es Anfangs so, jetzt bin ich mir auch wieder
sicher, dass ich es so mache.


Ich plane einen Spartan 3(E) Speedgrade 4 einzusetzen. (Bestellungen bei
Digikey sind ja viel billiger geworten :-) ) Sind da Taktraten von 133
MHZ realistisch? Oder vielleicht auch ein bisschen mehr?
Hat die Sache Chancen auf einer 2 Layer Platine zu funktionieren? 4
Layer sind so teuer. Bevor ich in den Sauren Apfel beiße frage ich mal
lieber...

Autsch... Du machst Dir so viel Mühe mit der Simulation, Aufbau der
Platine und co und dann möchstest Du nur 2 Layerplatine mache? :-o
Das finde ich, ehrlich gesagt, sehr gewagt. Es mag funktionieren, doch
habe ich da meine Zweifel.

Zu anderen Sachen: für die Clocks würde ich einen Clockmultiplexer
nehmen. Also zunächst mal aus dem FPGA raus -> Clock Mux -> ADCs und
zurück zum FPGA. Die Vorteile liegen auf der Hand -- Du kannst die Phase
drehen, wie Du lustig bist. Die Clock, die z.B. beim ADC ankommt ist
vollkommen synchron zu der Clock, die dann am FPGA zurückkommt. Damit
vermeidest Du diverse Probleme mit der Phase.

Was soll das Ganze werden?


Grüße,
Kest

Kest wrote:

> Platine und co und dann möchstest Du nur 2 Layerplatine mache? :-o
Ich würde lieber, wenn es aber nicht viele Aussichten auf Erfolg hat
nehme ich 4 Layer
>
> Zu anderen Sachen: für die Clocks würde ich einen Clockmultiplexer
> nehmen. Also zunächst mal aus dem FPGA raus -> Clock Mux -> ADCs und
> zurück zum FPGA. Die Vorteile liegen auf der Hand -- Du kannst die Phase
> drehen, wie Du lustig bist. Die Clock, die z.B. beim ADC ankommt ist
> vollkommen synchron zu der Clock, die dann am FPGA zurückkommt. Damit
> vermeidest Du diverse Probleme mit der Phase.
>
Kann man das gleiche aber nicht auch mit DCMs erreichen?
Ich meine Takt an die ADCs von da aus an den FPGA in einen DCM. In dem
kann ich doch auch beliebig die Phase verschieben.

> Was soll das Ganze werden?
Ein kleines USB-Oszilloskop mit Logic Analyzer.
Klar davon gibts sicher Fertige mehr als genug, ich will aber basteln
;-)

4 Layers... hast du das pinout vom FPGA schon gemacht?

Nimm lieber ein ordentlich schnelles Speedgrade, wochenlang zu
optimieren ist viel schlimmer als ein paar euro mehr ausgeben.
Falls du mehr baust und das timing stimmt dann kannst du dann ja
immernoch einen billigeren nehmen.

ijuz wrote:
> 4 Layers... hast du das pinout vom FPGA schon gemacht?
>
Nein. Glaubst du 4 sind auch zu wenig? Ich bin bisher davon ausgegangen,
dass ich die Leitungen weitgehend entflechtet bekomme. Ist das
unrealistisch?

> Nimm lieber ein ordentlich schnelles Speedgrade, wochenlang zu
> optimieren ist viel schlimmer als ein paar euro mehr ausgeben.
> Falls du mehr baust und das timing stimmt dann kannst du dann ja
> immernoch einen billigeren nehmen.
Und wo kauft man sowas? Bei Digikey finde ich Spartan 3E im passenden
Gehäuse nur im Speedgrade 4.
Höchstwahrscheinlich bleibt es ein Einzelexemplar.

Hm....also 133MHz mit dem Spartan 3e, und dann noch Speedgrade 4. Ohje.
Also ich verwende in einem Projekt einen 3e500 mit Grade 5, und der ist
zu 28% voll, etwa die Hälfte davon an 80MHz und das schafft der gerade
so. Da sind aber recht viele Multiplexer im High-Speed-Pfad. Lässt sich
leider nicht anders machen. ich bin da eher skeptisch, dass die die
133Mhz für den SDRAm schafft. Wozu eigentlich? Bei 50MHz Sampling-Rate?
Müssen die alle permanent in den Speicher schreiben? Kannst du das nicht
erst mal in je einen FIFO pro ADC schreiben und dann in ein SRAM oder
gleich an den USB-Chip?

Ahso, ADC-Takt sollte natürlich jitter-arm sein, sonst bekommst du
digitales Rauschen ins Signal. DCM ist keine gute Idee. Wir machen das
so: Quarz-Oszillator (jauch) in den FPGA an einen GCK Eingang, und für
die ADCs wieder ausgeben, ohne FFs oder sonstiges dazwischen, also nur
über die Clock-Buffer. Jitter liegt dann bei 28ps bei 80MHz. Noch besser
wäre, den Takt vom Oszillator (eventuell Clock-Treiber dahinter) direkt
an die ADCs und an den Spartan parallel.

Simulier das mit dem SDRAM mal durch, ich bezweifle, dass der Spartan
das schafft. Erst recht der 4er und wenn noch viel logik im Chip ist.
Ahja, und viel Spaß mit dem FX2-Timing. Aber das hatten wir ja in einem
anderen Thread schon mal ;)

Mit einer 2-Lagen-Platine brauchste da gar nicht anzufangen, wie willst
du da auf die Impedanzen für die Leitungen des SDRAM kommen? 4 Lagen
sind Minimum.

Christian R. wrote:
> 133Mhz für den SDRAm schafft. Wozu eigentlich? Bei 50MHz Sampling-Rate
8 Bit * (4 ADC + 1 Logic), sind bei 16 Bit Datenbus des SDRAMS 125MHz
Dann muss es ein Bisschen mehr sein für Refreshs.
Aber Vielleicht kann ich ja einen SDRAM nehmen der einen breiteren Bus
hat? Das würde die Sache ziemlich entspannen. Oder bekomme ich dann
andere Probleme?
Vielleicht sollte ich auch lieber nur 3 Kanäle nehmen.

> Müssen die alle permanent in den Speicher schreiben? Kannst du das nicht
> erst mal in je einen FIFO pro ADC schreiben und dann in ein SRAM oder
> gleich an den USB-Chip?

In ein Fifo muss ich sowieso zuerst, da SDRAM und ADCs wegen der
Refreshs leider nicht Synchron laufen können.

Ich will nur mehr Daten zwischenspeichern als in den Spartan passen.
Außerdem will ich lernen wie man SDRAM anspricht. Das kann ich bestimmt
irgendwann mal gebrauchen.

> über die Clock-Buffer. Jitter liegt dann bei 28ps bei 80MHz. Noch besser
hui, nicht schlecht.
> wäre, den Takt vom Oszillator (eventuell Clock-Treiber dahinter) direkt
> an die ADCs und an den Spartan parallel.
>
> Simulier das mit dem SDRAM mal durch, ich bezweifle, dass der Spartan
> das schafft. Erst recht der 4er und wenn noch viel logik im Chip ist.
mach ich. Ich würde ja auch gerne einen 5er nehmen. Die sind nun mal nur
nicht so leicht zu bekommen.
> Ahja, und viel Spaß mit dem FX2-Timing. Aber das hatten wir ja in einem
> anderen Thread schon mal ;)
>
Ich weiß ehrlich nicht gesagt was daran so schwierig sein soll. Damals
habe  ich mein FX2 Modul mit einem Nexys2 verbunden. Der Spartan auf dem
Board hat Daten in das FIFO vom FX2 geschrieben, gewartet, wenn das FIFO
grade voll ist.
Das hat ohne große Komplikationen funktioniert. Klar musste ich mir
überlegen wie und bei welcher Flanke, aber das muss man doch bei jedem
Logik-Chip.
In der Übertragung gab es jedenfalls keine Fehler.
Oder hatte ich einfach nur Glück? ;-)

> Mit einer 2-Lagen-Platine brauchste da gar nicht anzufangen, wie willst
> du da auf die Impedanzen für die Leitungen des SDRAM kommen? 4 Lagen
> sind Minimum.

Die Chips sollen ja alle ganz dicht am FPGA sitzen. Meinst du die
Impedanzen sind auch bei 2-3cm langen Leitungen so wichtig?
Klar, es ist ein wichtiges Thema und man sollte es auf keinen Fall
ignorieren, aber ich will ja auch nicht die Signale über 10 cm oder noch
längere Leitungen schicken.
Aber ich habe mich schon auf den Gedanken eingestellt tief in die Tasche
greifen zu müssen.

Die Leitungen zum FX2 bei dem Aufbau mit Nexys2 sind die Leitungen
außerhalb des Nexys-Boards auch noch ein paar cm und die
Masserückleitungen sind wegen der schlechten Ansteckmöglichkeit leider
extrem ungünstig. Aber es hat funktioniert.
Und der Aufbau kann doch eigentlich nur besser laufen, wenn ich alles
auf eine Platine mache und nicht über 2 Stecker muss.

Als ich mit der Elektronikbastelei angefangen habe habe ich mir um
Leitungsimpedanzen und Signalreflektionen noch gar keine Gedanken
gemacht. Damals hatte ich einen Aufbau mit 30-40cm langen frei laufenden
Kabeln (d.h. ohne ordentliche Masseleitung in der Nähe) das dann noch
auf Breadboards mit den parasitären Kapazitäten. Es lief Tatsächlich bei
50MHz. Das hätte ich vorher nicht für möglich gehalten.
Aber sowas will ich auch nicht nochmal versuchen ;-)

125 MHz für SDRAM x 16 Bit reicht aber für 4 x 50 Mhz x 8 Bit nicht! Im
Burst-Modus (8 Daten) kommst Du gerade mal auf 40 % effektive
Transferrate
(Im Page-modus bekommst Du zwar mehr, bist aber auf eine SDRAM-Page
beschränkt). Na ja, da musst Du noch rechnen.

Nimm lieber irgendein SDRAM mit 32 Bit, oder mehrere Chips
nebeneinander. 16 Bit limitiert ganz schön. Außerdem gehen 32 Bit gut
durch 8 Bit Auflösung, wo Du auf Deine 4 Kanäle kommst.

Grüße,

Kest

Kest wrote:
> 125 MHz für SDRAM x 16 Bit reicht aber für 4 x 50 Mhz x 8 Bit nicht! Im
> Burst-Modus (8 Daten) kommst Du gerade mal auf 40 % effektive
> Transferrate
> (Im Page-modus bekommst Du zwar mehr, bist aber auf eine SDRAM-Page
> beschränkt). Na ja, da musst Du noch rechnen.
40%?
ich hätte gedacht, dass man während man Daten in den Ram schreibt die
nächste auf der nächsten Bank schon zum beschreiben vorbereiten kann.
Grade wenn man immer Pageweise die Daten reinschreibt hätte ich ehr mit
>95% gerechnet. Aber wenn das nicht stimmt muss ich wohl noch mal in ein
SDRAM Datenblatt schauen.


> Nimm lieber irgendein SDRAM mit 32 Bit, oder mehrere Chips
> nebeneinander. 16 Bit limitiert ganz schön. Außerdem gehen 32 Bit gut
> durch 8 Bit Auflösung, wo Du auf Deine 4 Kanäle kommst.
OK. Mache ich.


Viele Grüße,
Christian

@ Christian R. (supachris)

>Hm....also 133MHz mit dem Spartan 3e, und dann noch Speedgrade 4. Ohje.

???
Das schaffen sogar "alte" Spartan II.

@>Also ich verwende in einem Projekt einen 3e500 mit Grade 5, und der
ist
>zu 28% voll, etwa die Hälfte davon an 80MHz und das schafft der gerade
>so.

UND? Es ommt immer darauf an, wie lang die kominatorischen Pfade sind.
Pipelinig ist das Stichwort.

>133Mhz für den SDRAm schafft.

Problemlos.

 Wozu eigentlich? Bei 50MHz Sampling-Rate?

>erst mal in je einen FIFO pro ADC schreiben und dann in ein SRAM oder
>gleich an den USB-Chip?

Dannbraucht er ja keinen SDRAM. Der ist wesentlich grösser als die
BRAMS, und das will er wahscheinlich.

>wäre, den Takt vom Oszillator (eventuell Clock-Treiber dahinter) direkt
>an die ADCs und an den Spartan parallel.

Eben.

@ Christian H. (cavorca)

>Die Chips sollen ja alle ganz dicht am FPGA sitzen. Meinst du die
>Impedanzen sind auch bei 2-3cm langen Leitungen so wichtig?

Naja, die Impedanz allein ist es nicht. Es ist auch die Masseverteilung.
Das wird eng auf zwei Lagen. Nimm besser 4.

@ Kest (Gast)

>125 MHz für SDRAM x 16 Bit reicht aber für 4 x 50 Mhz x 8 Bit nicht! Im
>Burst-Modus (8 Daten) kommst Du gerade mal auf 40 % effektive
>Transferrate

Das halte ich für ein Gerücht!

MfG
Falk

Autor:  Christian R. (supachris) schrieb:

>Noch besser wäre, den Takt vom Oszillator (eventuell Clock-Treiber dahinter)
>direkt an die ADCs und an den Spartan parallel.

Ich wollte eigentlich das Taktsignal vom Taktgenerator direkt dem ADC
zuführen und vom Taktausgang des ADC zum Takteingang des FPGA. Ich denke
bezüglich Jitter ist das das beste. Soweit ich weiß ist alles, was
irgendwie durch den FPGA geschleust wird vom Jitter deutlich schlechter,
als das was von einem guten Taktgenerator kommt. Nachteil ist natürlich,
dass man den Takt dann nicht beliebig runterteilen kann. (Meine
Anwendung wäre: 12 bit ADC mit 100 MSPS, da sollte der Jitter nicht
wesentlich größer als 1ps rms sein -- denke ich zumindest.) Später kann
ich bei Bedarf ja statt eines einfachen Taktgenerators einen
Clock-Synthesizer wie etwa den MAX3674 verwenden.

@Falk Brunner (falk):
das ist kein Gerücht, das steht im Datenblatt: Im Burstmodus (wo nur 8
Werte gelesen werden), braucht man ca. 20 Takte. Wie der
SDRAM-Controller dann implementiert ist, ist eine andere Frage. Damit
kann man mit jedem Burst unterschiedliche Adressen anlegen und man
bekommt seine Sachen nach 20 Takten. Liest oder schreibt man aber
kontinuierlich (von mir aus 1024 Werte, es kommt natürlich auf die Größe
der Page an), dann bekommt man schon eine Auslastung von 95 %.

Grüße,

Kest

Falk Brunner wrote:
> @ Christian R. (supachris)
>
>>Hm....also 133MHz mit dem Spartan 3e, und dann noch Speedgrade 4. Ohje.
>
> ???
> Das schaffen sogar "alte" Spartan II.
>
> @>Also ich verwende in einem Projekt einen 3e500 mit Grade 5, und der
> ist
>>zu 28% voll, etwa die Hälfte davon an 80MHz und das schafft der gerade
>>so.
>
> UND? Es ommt immer darauf an, wie lang die kominatorischen Pfade sind.
> Pipelinig ist das Stichwort.

Jo, ohne kombinatorische Logik gerade durch als Datenschaufel ist das
kein Thema. Ich meinte oben irgendwas gelesen zu haben, dass er die
Maxima raussuchen und abspeichern will.

Refresh ? Vergiss den. Refreshen muss man nur wenn was drin ist. Also
zuerst sampeln und in einem Rutsch synchron reinschreiben. Nachher kann
man dann ja refreshen.

3363 wrote:
> Refresh ? Vergiss den. Refreshen muss man nur wenn was drin ist. Also
> zuerst sampeln und in einem Rutsch synchron reinschreiben. Nachher kann
> man dann ja refreshen.

Das geht nicht beliebig. Wenn man einen größeren RAM hat muss man
refreshen bevor der RAM voll ist. Auch wenn man mit maximaler Rate
reinschreibt.
Beispiel: 64MB reinschreiben mit 200MB/s dann ist das Ding nach 0,32
Sekunden voll. Refreshen muss man aber laut Datenblatt mindestens alle
64 ms. Oder kann man das in der Praxis was strecken?

Oder meinst du ganz was anderes?

Viele Grüße,
Christian

Kriegt man eigentlich aus dem MIG von Xilinx einen tauglichen
SDRAM-controller raus? Oder muss ich mir den selber schreiben?

Ich stehe auch vor der Aufgabe, mir ein RAM ins Design ziehen zu müssen
und überlege, ob ich es nicht statisch machen soll: Wenn ich "nur"
125MHz hinbekomme, sei es druch das RAM oder den FPGA, kann ich ja auch
ein SRAM nehmen mit 10ns und 2 paralle schalten. Dann kriege ich meine
Daten auch weg.

Der Standardtrick ist die Zeilen und Spalten zu vertauschen. Man muss
fuer einen Refresh ja nur die Adresse anlegen, ob lesen oder schreiben
ist egal. In diesem Fall ist ein lineares Schreiben genugend. Zumindest
war das frueher so, als die dynamischen RAMs noch kleiner waren.

War das jetzt eine Antwort aif meine Frage?
Ich habe es aber in keinen Fall kapiert. :-(

> Der Standardtrick ist die Zeilen und Spalten zu vertauschen. Man muss
> fuer einen Refresh ja nur die Adresse anlegen, ob lesen oder schreiben
> ist egal.

Erstens musst du für einen Refresh die entsprechende Zeile öffnen und
wieder schließen. Ob du dazwischen liest oder schreibst ist egal.
Zweitens dauert genau deshalb der Zugriff viel länger, als wenn man eine
Zeile "offenhält" und verschiedene Zellen darin schreibt/liest.

Soll heißen: Mit dem "Vertauschen" verschlechterst du ziemlich den
Durchsatz. Wenn das kein Problem ist: optimal, denn dann werden die
Zeilen tatsächlich alle refreshed.

Mensch, genau das mit diesem "Refresh-Trick" habe ich hier vor Monaten
mal gefragt. Da wollte mir keiner Antworten.

Sollte es nicht auch so gehen:
Bank1 präparieren, sodass eine ganze Page im Burst-Mode beschrieben
wird.
Auf Bank2 ein Activate Kommando, aber nichts reinschreiben sondern
direkt wieder Precharge. Dann das gleiche mit einer anderen Bank/Spalte
bis der Writeburst zu Ende ist. Der ist ja 256 Takte lang. Da hat man
allerlei Zeit was anderes zu machen.

Was ich aber mittlerweile vielleicht für einfacher halte wäre den RAM
einfach mit einem schnelleren Takt laufen zu lassen und die Daten in
einem Fifo oder Dualportram im FPGA zwischenspeichern.

In meiner Anwendung brauche ich ja auch den Durchsatz.

Zum MIG:
So weit ich weiß kann der keinen SDRAM sondern nur DDR, DDR2 RLDDR,...

SDRAM Controller gibt es wie Sand am Meer. Ich habe allerdings damals
selber nach der Vorlage gemacht und ich muss sagen, es war auch gut so
-- da weis man, was so intern paassiert.
Mittlerweile verwende ich den von Altera aus dem SOPC-Builder und es
funktioniert wunderbar, man muss sich um nichts kümmern.
Auch von Altera gibt es SDRAM Controller (aus dem Megawizard) mit VHDL
Dateien, die kann man sogar ohne Änderung für Xilinx verwenden.


Grüße,

Kest

p.s.: such mal bei Altera nach dem SDRAM-Controller, wenn Du nichts
findest, dann kann ich den hier hochladen

> Was sind die schlimmsten Fehler mit denen man sich ein Design langsam
> machen kann?
- Mangelhafte Programmier-Kenntnisse in VHDL
- Keine/wenig Erfahrung mit dem eingesetzten FPGA
- Unterschiedlichen Leiterbahnlängen bei schnellen, parallelen
Leitungen.

Unbedingt kalkulieren:

Benötigter Speicher im FPGA. Gerade bei Fifo-lastigen Designs
unbedingt darauf achten.

Nicht zu vergessen: Beim Einsatz eines Embedded Analyzers kann man
nie genug Speicher haben.

Auch nicht zu vergessen: Lieber einen höheren Speedgrade ansetzen,
kann man nachher immer noch durch einen langsameren ersetzen.

Gruß
Willy

Weiterer Punkt:

Vernünftigen (bspw. durch Watchdog getriggerten) externen Reset
vorsehen. Würde mich nicht bei allen Herstellern auf saubere
Initialwerte der Register verlassen.

Willy wrote:
> Vernünftigen (bspw. durch Watchdog getriggerten) externen Reset
> vorsehen. Würde mich nicht bei allen Herstellern auf saubere
> Initialwerte der Register verlassen.

Spartan 3 ist das Thema, der hat nach der Konfiguration sehr wohl
verlaessliche Initalwerte, wie jedes andere SRAM basierte FPGA auch!
Ein zusaetzlicher Reset ist meistens Ueberfluessig!

Ein Supervisor fuer z.B. die I/O Spannung(en) kann durchaus Sinn machen,
dann kann man das FPGA aber auch gleich damit in den config mode
schicken.

Cheers, Roger

>Ein zusaetzlicher Reset ist meistens Ueberfluessig!

ja,ja, das sagt Xilinx, unterschlägt aber, aber es nicht nur
System-Resets gibt sondern druchaus unterschiedliche Schaltungsteile mit
unterschiedlichen Aufgaben. Hat man in einem FPGA einen watch dog, ein
BSP-bios und noch die eigentliche Applikation, dann darf da nur die APP
resettet werden und sonst nichts, wenns weiterlaufen soll. Also ohne
einen logischen Reset kommt man in der Regel nicht aus und warum soll
man den immer synchron machen ?

>>Spartan 3 ist das Thema, der hat nach der Konfiguration sehr wohl
>>verlaessliche Initalwerte, wie jedes andere SRAM basierte FPGA auch!
>>Ein zusaetzlicher Reset ist meistens Ueberfluessig!

Kann mich da jemand aufklären? Ich verwende einen Vitrex-2 und je nach
Lust und Laune läuft das geladene Programm nach dem Upload der
Konfiguration nicht richtig an, trotz einem asynchronem Reset nach dem
Programmstart. Mal läuft das Programm 40 Mal hintereinander an, mal muss
ich den 2/10 Mal zusätzlich resetten, damit das Programm startet. Bin
immer noch nicht drauf gekommen, warum es so ist.

Hells Angel wrote:
> Also ohne
> einen logischen Reset kommt man in der Regel nicht aus und warum soll
> man den immer synchron machen ?

Das mag vielleicht in der Biker Szene so sein.
Zu asynchron/synchron resets findest du genuegend Info im Netz.

Cheers, Roger

Gast (Gast):

Hast Du mal darüber nachgedacht, dass es an der Clock liegen könnte,
dass das Program nicht anläuft? Hast Du DCMs drin? Hatte auch was
ähnliches, wo DCM nicht richtig konfiguriert wurde (ab und zu) und die
Clock falsche Frequenz hatte.


Grüße,

Kest

@ Kest (Gast)

>kontinuierlich (von mir aus 1024 Werte, es kommt natürlich auf die Größe
>der Page an), dann bekommt man schon eine Auslastung von 95 %.

Das meinte ich impizit. Was anderes macht bei dieser Anwendung wenig
Sinn.

Und das mit dem Vertauschen der Adressen an einem SDRAM würde ich mir
fix verkneifen. Nehmt einen ordentlichen SDRAM-Controller mit Refresh,
pappt davor im FPGA einen FIFO und gut.

MFG
Falk

>> einen logischen Reset kommt man in der Regel nicht aus und warum soll
>> man den immer synchron machen ?

>Das mag vielleicht in der Biker Szene so sein.
>Zu asynchron/synchron resets findest du genuegend Info im Netz.

Der resettende Takt muss immer synchron zum taktenden sein, auch wenn
man den asynchronen Eingang des FF nutzen will. Dazu muss es externe
Reset eben in einen internen verwandelt werden.

>Mal läuft das Programm 40 Mal hintereinander an, mal muss
>ich den 2/10 Mal zusätzlich resetten

Das hört sich genau nach sowas an: Dein Reset startet unterschiedliche
design paritions unterschiedlich. Entweder ist nichts alles verdrahtet,
oder es gibt ein logistisches Problem, oder der REset ist nicht stabil,
weil nicht ordentlich eingetaktet oder in einer Clock domain verschluckt
oder insgesamt einfach zu kurz zum Eintakten.

Berater wrote:
> Der resettende Takt muss immer synchron zum taktenden sein, auch wenn
> man den asynchronen Eingang des FF nutzen will. Dazu muss es externe
> Reset eben in einen internen verwandelt werden.

Wieso antwortest du auf meinen Text mit diesem geblabber?

> Sollte es nicht auch so gehen:
> Bank1 präparieren, sodass eine ganze Page im Burst-Mode beschrieben
> wird.
> Auf Bank2 ein Activate Kommando, aber nichts reinschreiben sondern
> direkt wieder Precharge. Dann das gleiche mit einer anderen Bank/Spalte
> bis der Writeburst zu Ende ist. Der ist ja 256 Takte lang. Da hat man
> allerlei Zeit was anderes zu machen.

Klingt nicht schlecht. Ich bin grad nicht 100 pro sicher, dass ein
activate auf einer anderen Bank den Burst-Write nicht unterbricht, aber
ich glaub das geht.

ABER: Bedenke bei allen Tricks, um Refresh-Zyklen zu sparen, um wieviel
der Speichercontroller dadurch komplizierter wird. Insbesondere wieviel
inneren Zustand er über den Refresh-Zustand der Zeilen halten muss (sind
ja schnell mehrere K Zeilen).

@Kest:
Vielleicht wäre ein fertiger Controller auch was für mich. Aber klar hat
es auch Vorteile den selbst zu schreiben.

@Gast:
Ich programmiere zwar in Verilog, aber da sind magelhafte Kenntnisse
sicher genau so schlimm. Profi bin ich sicher nicht, aber die ganz
brutalen Anfängerfehler mache ich immerhin nicht mehr.

@Willy:
Wo bekomme ich denn einen höheren Speedgrade? Kann ich bei den
distributoren auf xilinx.com auch einzelne bestellen? Sonst hätte ich
keine Idee. Es soll ein 250E PQ208 werden.

@Roger Steiner:
Wie lege ich die Initialwerte fest? Geschieht das im "nicht
synthetisierbaren" Initial Block? (Oder wie der in VHDL auch heißen mag)


Über den Unterschied synchrone / asynchrone Resets muss ich mich noch
etwas einlesen.

@Morin:
Aus dem Datenblatt hatte ich mir damals erarbeitet dass es funktionieren
müsste. Ein writeburst wird nur von einem anderen Write, einem Read oder
einem Burst Terminate unterbrochen. Wenn ich mich richtig erinnere und
es damals nicht falsch verstanden habe. Ich hatte mir auch schon eine
kleine Platine mit SDRAM gemacht mit der ich das mal ausprobieren kann.
Habe ich aber bisher nicht gemacht.
In neueren RAM Sorten ist das alles viel besser geregelt. Da kann man
auf einer Bank lesen/schreiben und WÄHREND eines Bursts auf den anderen
Banks refresh-Kommandos ausführen. Ich will wirklich mal wissen welcher
Teufel die Leute damals geritten hat die den refresh-Teil nur einmal für
alle 4 Banks vorgesehen haben. Für so einen Ram würde ich auch den
doppelten Preis zahlen. Aber RLDDR-RAM ist mir dann doch was komplex.

Die Refresh-"Tricks" mögen den Controller aufwändiger machen aber
bedenke dass der ganze Teil davor dann synchron mit einem einzigen Takt
läuft. Das ist doch auch was wert. Man spart auch den ganzen Fifo davor.

Allerdings bin ich auch ehr von der Idee runter. In meiner Anwendung
will ich auch die Möglichkeit haben mit der halben, 1/5, 1/10,... Rate
zu Samplen. Und den RAM Takt will ich nicht unbedingt im Betireb
umschalten.




Aber nochmal eine allgemeine Frage wie komplex etwas werden kann/darf:
Gibt es eine Beschränkung wie viele Eingänge ein Multiplexer haben kann?
Gibt es eine Beschränkung auf Sinnvolle Werte die kleiner ist?
Gleiche Fragen zu den Anzahl Zuständen in einer Zustandsmaschine. Ist es
irgendwann einfach nicht mehr synthetisierbar?

Viele Grüße,
Christian

Die FPGAs gibts eigentlich alle bei Silica/AVNet. Spoerle hat auch jede
Menge. NuHorizons auch.

@ Christian H.

die Initial-/oder Default-Werte legst du bei der Deklaration fest.
z.B.

signal my_signal : std_logic := '1';

oder

process(...)
 variable my_variable : std_logic := '1';
begin
  ...
end process;

und die sind auch synthetisierbar.

Du kannst locker FSMs mit mehreren hundert Zustaenden bauen,
synthetisieren ist nicht das Problem, sondern eher Latenz und
ueberschaubarkeit des designs.

Cheers, Roger

@ Christian R.:
bei spoerle kann ich nichts finden.
Bei NuHorizons und Avnet schon. Da hat doch sicher schon mal jemand was
bestellt. Wie teuer ist das im Endeffekt? Also mit Versand und Zoll.

Die verfügbarkeiten sehen aber auch nicht so toll aus. Nuhorizons hat 2
Stück, avnet keine auf lager. Ich glaube nicht dass die extra welche
einkaufen, wenn ich einen haben will.

@Roger:
Weißt du auch wie es mit Verilog aussieht?
Vielleicht so:

initial data=0;

Ich könnte mir vorstellen das auch mehrere hundert Zustände bei
entsprechend sorgfältiger Vorbereitung noch übersichtlich sein können.
Es ist aber so, dass auch dann noch in ein Flipflop in jedem Zustand
etwas anderes reingeschireben werden kann? Da muss es dann doch einen
Multiplexer geben der genau so viele Eingänge hat wie es Zustände gibt.
Entstehen da durch die langen Latenzen?

Ich frage anders: Muss ich mir darum Gedanken machen?

Christian H. wrote:
> @ Christian R.:
> bei spoerle kann ich nichts finden.
> Bei NuHorizons und Avnet schon. Da hat doch sicher schon mal jemand was
> bestellt. Wie teuer ist das im Endeffekt? Also mit Versand und Zoll.

Die haben doch Vertretungen in Deutschland. Nix Zoll und so....Wir
bestellen immer bei Avnet/Silica in Poing bei München. Lass dir halt ein
Angebot schicken.....oder willst du die Privat kaufen? Versand kostet
bei Silica 4,50€.

Ich habe ein Gewerbe, das ich angeben kann. Das sollte denen ja reichen?

Jo klar. Privat geht halt nur nicht. Einfach Angebot anfordern, kommt
meist am gleichen Tag.

@ Roger

>die Initial-/oder Default-Werte legst du bei der Deklaration fest.
>z.B.
>signal my_signal : std_logic := '1';


Das halte ich aber bei der Synthese für ein Gerücht. Für
Simulationszwecke
stimmt das, aber für die Synthese spielt man auf diese Weise Roulette
...

Gruß,
Willy

>>z.B.
>>signal my_signal : std_logic := '1';
>
>Das halte ich aber bei der Synthese für ein Gerücht.

Das funktionier 100% mit Altera


Grüße,

Kest

Aber die Welt besteht nicht nur aus "A" und "X"

Gruß,
Willy

Willy wrote:
> @ Roger
>
>>die Initial-/oder Default-Werte legst du bei der Deklaration fest.
>>z.B.
>>signal my_signal : std_logic := '1';
>
>
> Das halte ich aber bei der Synthese für ein Gerücht. Für
> Simulationszwecke
> stimmt das, aber für die Synthese spielt man auf diese Weise Roulette
> ...
>
> Gruß,
> Willy

Bei Mentor Precision muss man es zwar extra aktivieren, aber dann werden
die init Werte auch mit synthetisiert.

Gruß
Little Chip

IEEE-1076.6 (Standard for VHDL Register Transfer Level (RTL) Synthesis)
sagt aus das ein Initialwert bei der Deklaration eines Signals oder
einer Variablen ignoriert werden. D.h. man sollte sich nicht darauf
verlassen das das bei jedem Tool und jeder Version eines Tools umgesetzt
wird.

Gruß,
 Mathi

Mag ja alles sein, aber man darf doch nicht davon ausgehen,
dass ein globaler Fpga-Reset gleichbedeutend mit einem
Power-Up-Reset ist !

Initial-Registerwerte bei
Signal-Deklarationen erleichtern mir nur Schreibarbeit bei
Testbench-Geschichten.


Gruß,
Willy

@ Christian R.:

> Weißt du auch wie es mit Verilog aussieht?</