mikrocontroller.net

Forum: FPGA, VHDL & Co. Richtlinien für große FPGA Designs?


Autor: Christian H. (cavorca)
Datum:

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

Autor: Stefan Salewski (Gast)
Datum:

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

Autor: Christian H. (cavorca)
Datum:

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

Autor: Stefan Salewski (Gast)
Datum:

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

Autor: Christian H. (cavorca)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: 3363 (Gast)
Datum:

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

Autor: Christian R. (supachris)
Datum:

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

Autor: Christian H. (cavorca)
Datum:

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

Autor: Kest (Gast)
Datum:

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

Autor: Christian H. (cavorca)
Datum:

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

Autor: ijuz (Gast)
Datum:

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

Autor: Christian H. (cavorca)
Datum:

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

Autor: Christian R. (supachris)
Datum:

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

Autor: Christian H. (cavorca)
Datum:

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

Autor: Kest (Gast)
Datum:

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

Autor: Christian H. (cavorca)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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: Stefan Salewski (Gast)
Datum:

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

Autor: Kest (Gast)
Datum:

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

Autor: Christian R. (supachris)
Datum:

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

Autor: 3363 (Gast)
Datum:

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

Autor: Christian H. (cavorca)
Datum:

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

Autor: Harald Weigelt (Gast)
Datum:

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

Autor: 3363 (Gast)
Datum:

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

Autor: Harald Weigelt (Gast)
Datum:

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

Autor: Morin (Gast)
Datum:

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

Autor: Christian H. (cavorca)
Datum:

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

Autor: Kest (Gast)
Datum:

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

Autor: Gast (Gast)
Datum:

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

Autor: Willy (Gast)
Datum:

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

Autor: Willy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weiterer Punkt:

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

Autor: Roger Steiner (edge)
Datum:

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

Autor: Hells Angel (Gast)
Datum:

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

Autor: Gast (Gast)
Datum:

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

Autor: Roger Steiner (edge)
Datum:

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

Autor: Kest (Gast)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: Berater (Gast)
Datum:

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

Autor: Roger Steiner (edge)
Datum:

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

Autor: Morin (Gast)
Datum:

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

Autor: Christian H. (cavorca)
Datum:

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

Autor: Christian R. (supachris)
Datum:

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

Autor: Roger Steiner (edge)
Datum:

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

Autor: Christian H. (cavorca)
Datum:

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

Autor: Christian R. (supachris)
Datum:

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

Autor: Christian H. (cavorca)
Datum:

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

Autor: Christian R. (supachris)
Datum:

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

Autor: Willy (Gast)
Datum:

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

Autor: Kest (Gast)
Datum:

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

Autor: Willy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber die Welt besteht nicht nur aus "A" und "X"

Gruß,
Willy

Autor: Maik H. (littlechip)
Datum:

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

Autor: Mathi (Gast)
Datum:

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

Autor: Willy (Gast)
Datum:

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

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian R.:

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

leider nein.

> Ich könnte mir vorstellen das auch mehrere hundert Zustände bei
> entsprechend sorgfältiger Vorbereitung noch übersichtlich sein können.

Das ist Ansichtssache, aber wie gesagt, wenn du willst, dann kannst du 
das machen.

> 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?

Kommt auf die Art der Codierung draufan, bei one-hot z.B. brauchts zwar 
soviel Flipflops wie states, dafuer ist die decodierung recht simpel.

> Ich frage anders: Muss ich mir darum Gedanken machen?

Nein, all das nimmt dir die Synthese ab.

@ Willy

> 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

Dann musst du aber dein Kentnissstand etwas auffrischen!

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

Nein, aber es ist doch der groesste Brocken davon, schau dir nur mal die 
posts in diesem Forum an. Zuerst Xilinx dann Altera und once in a blue 
moon was anderes.

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

Bei den SRAM basierten FPGAs sind die Initialwerte implizit im 
Bitstream. Ausser fuer einen brown-out gibt es meistens keinen Anlass 
fuer einen globalen Reset.

Autor: Willy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Roger,

95% meiner REALEN Designs hätten mit deiner Reset-Strategie nichts
getaugt.

Schöne Grüße,
Willy

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Willy (Gast):
Ich möchte Dir nicht zu nahe treten, aber denkst Du nicht, dass das 
nicht am Reset lag, sondern wie Du programmiert hast? ;-)

Grüße,
Kest

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fakt ist, Willy hat nach IEEE recht.
Wenn ein Tool solche Initialwerte übernimmt, macht es mehr als es 
muss/sollte. Wenn man sich darauf verlassen will, kann man das tun, sich 
Schreibarbeit sparen und unter Umständen bei Toolwechsel auf die Nase 
fallen. Man kann aber auch dem Standard glauben und unter Umständen mehr 
schreiben als überhaupt notwendig ist.

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Willy,

du hast ein Konzeptionelles oder Verstaendnis Problem.

Cheers, Roger

Autor: Willy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach Herr Kest ist auch wieder da,

ich programmiere meine Designs nicht, ich beschreibe sie ;O)
Konntest du eigentlich in der Zwischenzeit "dein"
bmp-Package etwas verfeinern ?

Gruß,
Willy

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Willy (Gast):
nein, BMP Zeug habe ich nicht mehr angefasst -- keine Zeit gehabt.

Grüße,
Kest

Autor: Willy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Roger,

kann man denn auch Zustandsmaschinen mit einer Initial-Deklaration
in einen Quasi-Reset-Zustand bringen ?

Bsp.:

type state_type is (s_config_up, s_idle, s_running ...);
signal ls_state : state_type := s_config_up;

Kann man hier sicher gehen, dass der Automat im "s_config_up"-Zustand
losläuft ?

Gruß,
Willy

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch das funktioniert (zumindest für Altera) zuverlässig.

Mal stelle sich nur ein BlockRam vor, den man mit bestimmten Werten 
initialisiertz haben möchte :-o

Grüße,
Kest

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Willy,

> kann man denn auch Zustandsmaschinen mit einer Initial-Deklaration
> in einen Quasi-Reset-Zustand bringen ?

Ja, das geht natuerlich auch fuer selbst definierte types, wie man sie 
eben fuer state machines verwendet.

> type state_type is (s_config_up, s_idle, s_running ...);
> signal ls_state : state_type := s_config_up;
>
> Kann man hier sicher gehen, dass der Automat im "s_config_up"-Zustand
> losläuft ?

Wie du kann ich hier sagen dass alle meine REALEN designs diesen Ansatz 
erfolgreich implementieren.

Cheers, Roger

Autor: Willy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Roger,

eine kritische Situation für deine Initialwert-Strategie ist bspw.
ein Prozessor-FPGA-System, in dem der Prozessor dem FPGA einen globalen
Reset verpassen möchte. Was machst Du denn dann ?

Gruß,
Willy

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Willy,

Altera StratixII + und CycloneIII -> Remote System Upgrade.

Cheers, Roger

Autor: Willy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, aber nur für zwei B'A'usteine und mit entsprechendem 
Update-Controller-Aufwand. Schade, dass noch nicht jeder einen 
CycloneIII
auf dem Board hat.
Wie auch immer ...

Gruß,
Willy

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal zu der Aussage möglichst wenig unterschiedliche Takte im Design 
haben. Wie viele sind denn noch OK? Und warum sollte man Möglichst 
wenige haben? Übersichtlichkeit oder Ressourcen?
Um Asynchronität muss man sich bei einem neuen Takt ja nicht unbedingt 
so viele Gedanken machen. Ich meine, wenn man den Takt mit einer DCM 
verdoppelt ist es ja nicht so kompliziert, wie es ist, wenn man einmal 
100MHz und einmal 133MHz hat. Oder noch schlimmer 2 Oszillatoren die 
vollkommen unabhängig laufen.

Wenn ich jetzt Folgende Situation habe:
Die ADCs laufen mit 50MHz, die logik-Eingänge sollen aber mit 100MHz 
abgetastet werden. Dann brauche ich im Eingangsteil ja auf jeden Fall 
einen 100MHz Takt. Dann brauche ich aber auch auf jeden Fall eine 
Möglichkeit die Information weiter zu geben, bei welchen Taktflanken des 
100MHz Taktes die Ausgänge der ADCs valide sind (bei 1,3,5,... oder bei 
2,4,6,...). Also brauche ich entweder nochmal den 50MHz Takt, der auch 
an die ADCs geht oder ein Signal, das mir sagt ob bei der nächsten pos 
Flanke des 100MHz Taktes auch bei den 50MHz eine positive Flanke ist. 
Wenn ich genauer darüber nachdenke frage ich mich ob da überhaupt ein 
Unterschied ist. Oder gibt es vielleicht eine elegantere Lösung?

Andere Frage:
Bei CPLDs kann man Flip-Flops durcheinander auf positive und negative 
Flanke sensitiv sein lassen. Wenn ich mich richtig erinnere muss man 
sich bei FPGAs für eine Sorte entscheiden. Ist das richtig?

Viele Grüße,
Christian

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du solltest in eimem Design je Clock nur eine Taktsorte verwenden, weil 
am Ende dadruch am meisten Zeitresource für das Routen besteht. Wenn der 
Ausgang eines FF, das mit falling getrieben wurde, über Kombinatorik an 
den Eingang eines FFs geht, der mit risign getrieben wird, besteh nur 
die halbe Zeit (ungefähr). Das limitiert das gedamte Design.

Es gibt auch keinen Grund, beide Takte zu verwenden, es sei denn im IO 
Bereich zum Eintakten!

Bei Deinem Design verwendest du einen 100er Takt (wird schwer genug, je 
nach FPGA) und taktest damit ein FF -> das macht dann die benötigten 50 
und Du kannst schon damit 50% Phase einstellen. Ansonsten DDR-Zelle mit 
100 Takten und einen verschobenen 50er als Eingang. MAcht 25% 
Genaugikeit.

So brauchst du nur e9in Taktnetz -> weniger Strom.

Autor: Sym (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Anzahl der Taktnetze in einem FPGA ist beschränkt, abhängig vom 
FPGA. Es gibt globale Taktnetze und lokale Taktnetze, die sich über 
einen Quadranten eines FPGA beschränken.

Taktübergänge sind manchmal nicht ganz unproblematisch, man muss schon 
wissen was man tut. Stichwort Metastabilität. Wenige Taktnetze sind 
daher nur ein Vorteil.

Wo ist das Problem Daten von einem 50 MHz Signal auf 100 MHz zu 
übernehmen, wenn beide Clocks phasenstarr sind? Dein Design muss dann 
aber mit 100 MHz laufen können (bzw. du arbeitest mit Chip Enables alle 
2 Cycles).

FF auf beide Flanken zu triggern ist nur für DDR-Ausgangsregister zu 
empfehlen.

Was das PCB-Layout betrifft: FPGA mit ADCs, externer PLL usw.. 4 Lagen 
ist da das absolute Minimum.  Du willst schließlich mit deinem ADC ein 
paar gültige Bits haben und nicht nur Einstreuungen von den ganzen 
digitalen Bausteinen. Je nach sonstigen Bauteilen wären 6 Lagen durchaus 
angebracht.

P.S.: Wir basteln auch grad einen ADC Board: 250 MS/s 12bit ADC, 600 
MS/s 12 bit DAC auf 8 Lagen. Das ganze steckt auf einem 16 lagigem 
FPGA-Board.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem die ADC Daten mit 100MHz abzutasten ist meiner Meinung nach 
folgendes:
Wenn ich jeden 2. Takt etwas mache ist es - sofern ich im Design nur den 
100MHz Takt habe - vollkommen zufällig ob ich das dann jeweils zur 
fallenden oder steigenden Flanke der 50MHz mache.
Im Datasheet des ADCs steht jetzt über das Timing:
-neue Daten bei Rising Edge
-Hold Time nach Rising Edge: min 3,9ns
-Delay Time für neue Daten nach Rising Edge: max 12ns

Wenn ich bei 50MHz ADC Takt also bei der fallenden Flanke Sample kommt 
evtl nur murks raus, da die neuen Daten noch nicht unbedingt anliegen, 
die alten aber nicht mehr. Also könnte alles dazwischen sein.
Einzige Möglichkeit ist also bei der Rising Edge der 50MHz zu samplen. 
Ich sehe nicht wie ich das sicher stellen kann, wenn ich nur die 100MHz 
am Input habe.
Oder ist irgendwo in meiner Argumentation ein Fehler?

Autor: Morin (Gast)
Datum:

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

Roulette spielst du nur, wenn du Sprachfeatures benutzt, von denen du 
nicht weißt, ob sie synthetisiert werden. Siehe (hoffentlich) die 
Anleitung des jeweiligen Synthesetools.

Das gilt aber für alle Sprachfeatures, nicht nur für 
Register-Initialwerte. Insofern sehe ich hier keine besondere Situation.

Ohne einen gemeinsamen Standard, an den sich alle Tools halten (Betonung 
auf dem letzten Halbsatz), programmierst du immer nach den Regeln des 
jeweiligen Tools.

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

Deine Entscheidung. Andere verwenden sie auch für die Synthese.

Mathi:
> Wenn man sich darauf verlassen will, kann man das tun, sich
> Schreibarbeit sparen und unter Umständen bei Toolwechsel auf die Nase
> fallen.

Andersherum würde ich niemals davon ausgehen, dass bei 100%igem 
Einhalten des Standards keine Probleme bei Toolwechsel auftreten. Erst 
Recht nicht nach meiner Erfahrung mit den Xilinx-Tools.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian H. (cavorca)

>wenige haben? Übersichtlichkeit oder Ressourcen?

Probleme beim Datenüberganz zwischen den Taktnetzen (Clock domains).

>Um Asynchronität muss man sich bei einem neuen Takt ja nicht unbedingt
>so viele Gedanken machen. Ich meine, wenn man den Takt mit einer DCM
>verdoppelt ist es ja nicht so kompliziert, wie es ist, wenn man einmal

Das sind die Aussnahmen. Und auch die wollen SOLIDE gehandhabt sein.

>100MHz und einmal 133MHz hat. Oder noch schlimmer 2 Oszillatoren die
>vollkommen unabhängig laufen.

Eben.

>Die ADCs laufen mit 50MHz, die logik-Eingänge sollen aber mit 100MHz
>abgetastet werden.

Warum? Sehe ich als relativ sinnfrei an.

>Wenn ich genauer darüber nachdenke frage ich mich ob da überhaupt ein
>Unterschied ist. Oder gibt es vielleicht eine elegantere Lösung?

Du bist gerade auf dem besten Weg, dein Taktkonzept an die Wand zu 
fahren. ;-)
K.I.S.S.!!!

Lass den Kuddelmuddel! EIN 50 MHz Takt für die ADCs und das FPGA zum 
Eintakten
EIN 133 MHz Takt für den SDRAM und FPGA. Sonst nichts. Die 133 MHz kann 
man  ggf. aus den 50 MHz per DCM erzeugen. Und selbst dann braucht man 
einen asynchronen FIFO.

>Bei CPLDs kann man Flip-Flops durcheinander auf positive und negative
>Flanke sensitiv sein lassen. Wenn ich mich richtig erinnere muss man
>sich bei FPGAs für eine Sorte entscheiden. Ist das richtig?

Ja. Davon sollte man aber nur sehr überlegt Gebrauch machen.

MFG
Falk

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Bei CPLDs kann man Flip-Flops durcheinander auf positive und negative
>>Flanke sensitiv sein lassen. Wenn ich mich richtig erinnere muss man
>>sich bei FPGAs für eine Sorte entscheiden. Ist das richtig?

>Ja. Davon sollte man aber nur sehr überlegt Gebrauch machen.
>MFG Falk

Deine Aussage ist sicher richtig -- worauf sie sich nun genau bezieht 
bleibt jedoch völlig offen.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
>>Die ADCs laufen mit 50MHz, die logik-Eingänge sollen aber mit 100MHz
>>abgetastet werden.
>
> Warum? Sehe ich als relativ sinnfrei an.
Die ADCs sind bei 50MHz fast an ihrem Maximum. Es spricht aber nichts 
dagegen die Logic-Analyzer-Eingänge schneller abzutasten. Es könnte ja 
mal interessant sein sich schnellere digitale Signale anzugucken.
Du hast mich nicht etwa so Missverstanden, dass ich die ADC Eingänge am 
FPGA mit 100MHz abtasten will? Das ist klar, dass das Quatsch ist.
Ich will 4*8Bit ADC und davon unabhängig noch digitale Eingänge.

>>Wenn ich genauer darüber nachdenke frage ich mich ob da überhaupt ein
>>Unterschied ist. Oder gibt es vielleicht eine elegantere Lösung?
>
> Du bist gerade auf dem besten Weg, dein Taktkonzept an die Wand zu
> fahren. ;-)
> K.I.S.S.!!!
>
> Lass den Kuddelmuddel! EIN 50 MHz Takt für die ADCs und das FPGA zum
> Eintakten
> EIN 133 MHz Takt für den SDRAM und FPGA. Sonst nichts. Die 133 MHz kann
> man  ggf. aus den 50 MHz per DCM erzeugen.
Leider brauche ich noch mindestens einen 3. Takt für die Komunikation 
mit dem FX2. Das Fifo läuft laut Spezifikation nur bis 48MHz. Gut, ich 
kann die 50MHz einfach durch 2 Teilen, aber Fifo brauche ich da ja 
trotzdem noch eins, da der RAM ja mit 133MHz läuft. Wäre es denn 
komplizierter dieses Fifo mit einem 3. Takt zu betreiben als mit den 
50MHz? Wenn ja wüsste ich nicht warum.

> Und selbst dann braucht man
> einen asynchronen FIFO.
Warum asynchron? Macht es das nicht komplizierter? Reicht nicht auch ein 
Synchroner? Den hätte ich jetzt genommen. Hier sagen doch immer alle, 
dass man das Design Synchron halten soll ;-)
>
> Ja. Davon sollte man aber nur sehr überlegt Gebrauch machen.
>
OK

Viele Grüße,
Christian

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian H. (cavorca)

>Ich will 4*8Bit ADC und davon unabhängig noch digitale Eingänge.

Das hast du vielleicht GEDACHT, aber mit nichten GESCHRIEBEN!

>mit dem FX2. Das Fifo läuft laut Spezifikation nur bis 48MHz. Gut, ich

Welches FIFO? Ein externer Baustein? Wozu? Du hast ein FPGA, da passen 
viel schnelle FIFOs rein.

>komplizierter dieses Fifo mit einem 3. Takt zu betreiben als mit den
>50MHz? Wenn ja wüsste ich nicht warum.

Kann man manchen.

>Warum asynchron?

Wenn ich zwei verschieden Takte habe, egal ob unabhängig oder per 
PLL/DCM gekoppelt, ich einfach ZWEI Takteingänge am FIFO brauche. UNd 
die haben nun mal nur Asynchrone FIFOs.

> Macht es das nicht komplizierter?

Nicht wirklich.

> Reicht nicht auch ein
>Synchroner?

Siehe oben.

>Den hätte ich jetzt genommen. Hier sagen doch immer alle,
>dass man das Design Synchron halten soll ;-)

Was bei einer Taktgrenze schlecht geht.

MfG
Falk

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian H. hat viele Fragen:

>Warum asynchron? Macht es das nicht komplizierter? Reicht nicht auch ein
>Synchroner? Den hätte ich jetzt genommen. Hier sagen doch immer alle,
>dass man das Design Synchron halten soll

Wenn die Bemerkung von einem Beckenrandschwimmer gestattet ist:

Wenn Du etwas kommerzielles baust solltest Du vielleicht etwas mehr 
Erfahrung haben -- oder Mitarbeiter die Dir helfen.

Wenn es nicht kommerziell ist, würde ich zunächst den VHDL-Code 
schreiben, irgendwo verfügbar machen und zur Diskussion stellen.

So ist das einfach alles zu wage.

"Hier sagen doch immer alle" usw hat doch keinen Wert, wenn man nicht 
verstanden hat warum.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @ Christian H. (cavorca)
>
>>Ich will 4*8Bit ADC und davon unabhängig noch digitale Eingänge.
>
> Das hast du vielleicht GEDACHT, aber mit nichten GESCHRIEBEN!
>
Ok, das in dem Post musste man wirklich missverstehen. Geschrieben habe 
ich es ganz oben schon mal. Aber dass man bei so einem langen Thread mal 
den Überblick verliert ist ja schon fast zu erwarten ;-)
>>mit dem FX2. Das Fifo läuft laut Spezifikation nur bis 48MHz. Gut, ich
>
> Welches FIFO? Ein externer Baustein? Wozu? Du hast ein FPGA, da passen
> viel schnelle FIFOs rein.
Ich meine die Fifos im FX2.
Es soll ja etwa so aussehen:
ADC ---(50MHz)---> Fifo im FPGA ---(133MHz)---> SDRAM 
---(133MHz)--->Fifo im FPGA ---(48 oder 30 MHz)---> Fifo im FX2 
---USB---> PC

Und der Fifo im FX2 läuft nunmal nicht schneller als 48MHz.

>>komplizierter dieses Fifo mit einem 3. Takt zu betreiben als mit den
>>50MHz? Wenn ja wüsste ich nicht warum.
>
> Kann man manchen.
>
>>Warum asynchron?
>
> Wenn ich zwei verschieden Takte habe, egal ob unabhängig oder per
> PLL/DCM gekoppelt, ich einfach ZWEI Takteingänge am FIFO brauche. UNd
> die haben nun mal nur Asynchrone FIFOs.
>
Hm. Ergibt Sinn.
Ich habe mir den Fifo aus dem Xilinx Core Generator nochmal angesehen. 
Der hat 2 Takteingänge. Ob synchron oder asynchron steht gar nicht 
dabei. Wie auch immer, den sollte ich ja nehmen können für diese 
Anwendung.

> Was bei einer Taktgrenze schlecht geht.
ok. wenn er nur einen Takt hat klar. Ich dachte Synchron= 2 Takteingänge 
+ WE und OE. Asynchron= nur WE und OE.
Aber wie gesagt, mit dem aus dem Core Generator sollte es ja gehen.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Salewski wrote:
> Wenn es nicht kommerziell ist, würde ich zunächst den VHDL-Code
> schreiben, irgendwo verfügbar machen und zur Diskussion stellen.
>
Es ist nicht kommerziell. Dass mir die Erfahrung zu einem kommerziellen 
Produkt fehlt weiß ich.

> "Hier sagen doch immer alle" usw hat doch keinen Wert, wenn man nicht
> verstanden hat warum.

Ich denke es war oben ja hauptsächlich das Missverständnis über Fifos 
oder ehr mein Unwissen wie man ein Fifo mit 2 Takteingängen nennt. Dass 
ich 2 Takte an der Stelle brauche ist mir absolut klar und dass ich ein 
evtl vorhandenes Modul, das nur einen Takt hat, nicht nehmen kann wäre 
mir sicher beim umsetzen des Designs aufgefallen, wenn ich versuche den 
2. Takt anzuschließen.

Gründe warum man hauptsächlich synchrone Desings verwenden soll kenne 
ich hier aus dem Forum einige, aber wann ein asynchrones - und damit 
meine ich jetzt das kein Takt vorhanden ist - Design Vorteile hat weiß 
ich nicht, bzw in welchen Situationen man eins braucht.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian H.
>Ich denke es war oben ja hauptsächlich das Missverständnis

Also ich habe jedenfalls etwas den Überblick verloren, insbesondere auch 
durch Falks doch oft recht knappe Antworten. Das liegt sicher daran, 
dass ich bezüglich FPGA/VHDL immer noch Anfänger bin, aber gerade 
Anfänger möchten hier ja etwas lernen.

Ich werde den Thread bei Gelegenheit nochmals in Ruhe lesen...

Aber trotzdem verwundert es mich immer wieder, dass auch bei 
nichtkommerziellen Projekten von vielen aus Hard- und Software so ein 
großes Geheimnis gemacht wird. So nach dem Motto: Ich habe zwar tausend 
Fragen, aber das was ich bauen will ist so genial, dass ich möglichst 
nichts verraten möchte. (Es gibt natürlich auch das umgekehrte -- da 
wird wegen einer trivialen Frage ein riesiger Quelltext gepostet...)

Diese Anmerkung ist eigentlich gar nicht so sehr auf diesen Thread 
bezogen -- es fällt mir bloß gerade in diesem Forum des öfteren auf.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Salewski wrote:
> @Christian H.
>>Ich denke es war oben ja hauptsächlich das Missverständnis
>
Ich sehe mich auch als Anfänger, wenn auch nicht mehr als Einsteiger.

> Ich werde den Thread bei Gelegenheit nochmals in Ruhe lesen...
>
> Aber trotzdem verwundert es mich immer wieder, dass auch bei
> nichtkommerziellen Projekten von vielen aus Hard- und Software so ein
> großes Geheimnis gemacht wird. So nach dem Motto: Ich habe zwar tausend
> Fragen, aber das was ich bauen will ist so genial, dass ich möglichst
> nichts verraten möchte. (Es gibt natürlich auch das umgekehrte -- da
> wird wegen einer trivialen Frage ein riesiger Quelltext gepostet...)
Ja. Manche Leute wollen das Rad neu erfinden aber nicht verraten was das 
Geheimnis dahinter ist. Naja.
Ich kenne auch jemanden der eine "Erfindung" "gemacht" hat, die alle 
Energieprobleme löst. Er will aber nicht verraten wie. Ich soll ihm die 
Thermodynamik dazu erklären. Passende Werte für seine Maschine soll auch 
jemand anders ausrechnen.
Ich bin mal gespannt ob es überhaupt jemals einen Prototyp geben wird. 
Diese Leute wie Dr. Nobel Preis (Sesamstraße) sind halt eine eigene 
Kategorie. ;-)

> Diese Anmerkung ist eigentlich gar nicht so sehr auf diesen Thread
> bezogen -- es fällt mir bloß gerade in diesem Forum des öfteren auf.
Ok. Aber findest du ich hätte an einer Stelle ausführlicher schreiben 
sollen was ich bauen will? Wenn ich es nicht ausführlich genug erzählt 
habe war es nicht mit Absicht.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal zu dem Taktkonzept.
Ich habe 4 ADCs mit 8 Bit, die mit 50MHz abgefragt werden sollen. Dann 
habe ich 16 Bit digitale Eingänge die mit 100MHz abgefragt werden 
sollen.

Würde Folgendes funktionieren:
An jedem Eingang befindet sich erst mal ein Buffer (Wurde mir hier ja 
auch empfohlen, um das Design möglichst schnell zu machen). Die Buffer 
für die ADCs laufen mit den 50MHz die auch die ADCs bekommen. Bei der 
steigenden Flanke werden die Daten übernommen. (Bei der Fallenden wären 
sie ja nicht Valide.)
Die 50MHz werden per DCM auf 100MHz multipliziert.
Dabei nehme ich denjenigen Taktausgang des DCM, dass auf jede Flanke des 
50MHz Signals eine Steigende 100MHz Flanke kommt. Ob das der CLK2x oder 
der CLK2X180 Ausgang des DCMs ist weiß ich jetzt noch nicht, aber einer 
von beiden MUSS es ja sein.
Da die Taktflanken in diesem Fall synchron sind sollte ich doch einfach 
die Ausgänge der 50MHz Flipflops mit Logik verarbeiten können die mit 
diesen 100MHz getaktet werden. Im Prinzip ist es ja als ob die auch mit 
den 100MHz laufen, jedoch nur bei jedem 2. Takt ihren Wert ändern 
können.
Soweit korrekt?

Sollte es nicht sogar funktionieren, wenn ich weitere Logik mit 50 MHz 
betreibe und die Ergebnisse mit den 100MHz abfrage?
Beispiel: Ich möchte wissen ob der Wert von einem ADC größer oder 
kleiner als 128 ist. Da digitale Vergleicher durch die lange Logik 
langsam sind bietet es sich an diesen Vorgang in einem langsamen Takt 
arbeiten zu lassen und selbst dann evtl. noch mit Pipeline.

Vorausetzung ist dass ich hier am Ende des Vergleichers wieder ein 
Flipflop habe das mit den 50MHz getaktet wird. Dieser Ausgang sollte 
dann doch wieder ohne Probleme von Logik verarbeitet werden können, die 
mit 100MHz läuft?
Ich meine es ist ja wieder genau das gleiche: Die Setup-, Hold- und 
Durchlaufzeiten eines Flipflops sind im FPGA ja so kurz, dass sie bei 
>>100MHz funktionieren. Also sollte es doch auch gehen, wenn ein Teil 
nur mit 50MHz läuft.
Mit anderen Worten: Ob man jetzt ein Fipflop hat, dass mit 100MHz läuft 
und einen Enable Eingang hat, der jeden 2. Takt das Flipflop deaktiviert 
oder ob man gleich das Flipflop mit 50MHz betreibt sollte doch keinen 
Unterschied machen. Oder doch? Wenn ja habe ich ein fundamentales 
Verständnisproblem und bitte um Erklärung.
Den einzigen Unterschied den ich sehe ist dass die Möglichkeit mit den 
50MHz einfacher ist. Wenn ich ein Enable Signal habe muss ich noch 
irgendwie rausfinden ob ich die "graden" oder die "ungraden" Flanken 
ignoriere. (Denn die einen entsprechen den fallendan Flanken der 50MHz 
und die anderen den steigenden. Die Signale der ADCs sind aber nur bei 
den Steigenden valide.) Das entfällt beim direkten betreiben mit 50MHz.

Ich hoffe das habe ich jetzt so geschrieben, dass man nicht den ganzen 
Thread lesen muss um zu verstehen worum es geht.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich hoffe das habe ich jetzt so geschrieben, dass man nicht den ganzen
>Thread lesen muss um zu verstehen worum es geht.

Im Prinzip ist das doch ein ganz allgemeines Problem?
Du willst einige Eingänge des FPGA mit einfacher Taktfrequenz (100MHz) 
abfragen, und andere mit halber (50MHz).

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine Anmerkung vom Beckenrandschwimmer:

Grundsätzlich sollte es doch einfacher sein, wenn Du als allgemeinen 
Takt 100 MHz verwendest, und ihn einfach zum Einlesen der ADC-Daten 
teilst (Flip-Flop oder wie auch immer.) Dann kannst Du auf den DCM 
verzichten -- das Einlesen bei jeden zweiten Takt sollte Standard sein.

Der Nachteil wäre, dass der Takt für den ADC im FPGA halbiert werden 
muss, dadurch bekommst Du mehr Jitter. Aber bei 8 Bit und 50 MHz ist das 
nicht tragisch.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Salewski wrote:
> Noch eine Anmerkung vom Beckenrandschwimmer:
>
> Grundsätzlich sollte es doch einfacher sein, wenn Du als allgemeinen
> Takt 100 MHz verwendest, und ihn einfach zum Einlesen der ADC-Daten
> teilst (Flip-Flop oder wie auch immer.) Dann kannst Du auf den DCM
> verzichten -- das Einlesen bei jeden zweiten Takt sollte Standard sein.
>
> Der Nachteil wäre, dass der Takt für den ADC im FPGA halbiert werden
> muss, dadurch bekommst Du mehr Jitter. Aber bei 8 Bit und 50 MHz ist das
> nicht tragisch.
Trotzdem würde ich lieber darauf verzichten.
Außerdem muss ich dann die Laufzeiten zusätzlich berücksichtigen. Aber 
die sollten bei mir je recht übersichtlich sein.

Aber mal prinzipiell: Sind meine Überlegungen richtig? Wenn nicht würde 
mich interessieren wo der Fehler liegt, wenn ja wäre es auch wichtig das 
zu wissen. Irgendwo geht es mir ja schon darum die Sachen mal zu 
verstehen. Sonst lerne ich es ja nie.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian H. (cavorca)

>Die 50MHz werden per DCM auf 100MHz multipliziert.
>Dabei nehme ich denjenigen Taktausgang des DCM, dass auf jede Flanke des
>50MHz Signals eine Steigende 100MHz Flanke kommt. Ob das der CLK2x oder
>der CLK2X180 Ausgang des DCMs ist weiß ich jetzt noch nicht, aber einer
>von beiden MUSS es ja sein.

;-)
Das kann man so gar nicht genau sagen, weil das nämlich beim 
Taktverdopplen zweiduetig ist. Du musst die Phasenausrichtung der beiden 
Takte mit Logik machen. Und zwar musst du mit dem 50 MHz Takt ein FF 
toggeln lassen. mit dem 100 MHz Takt tastest du dieses ab. Mit bissel 
Logik bekommt man daraus die richtige Phase des 100 MHz Taktes, welcher 
mit steigenden Flanke des 50 MHz Taktes übereinstimmt.

>Da die Taktflanken in diesem Fall synchron sind sollte ich doch einfach
>die Ausgänge der 50MHz Flipflops mit Logik verarbeiten können die mit
>diesen 100MHz getaktet werden. Im Prinzip ist es ja als ob die auch mit
>den 100MHz laufen, jedoch nur bei jedem 2. Takt ihren Wert ändern
>können.
>Soweit korrekt?

Ja.
Du kannst aber auch alles mit dem 50 MHz Takt machen. Die 100 MHz 
Digitaleingänge machst du über DDR FlipFlops, das ergibt dann auch 100 
MHz Abtastfrequenenz.

MFG
Falk

Autor: Thomas Ulrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn er hinterher nicht in 100 MHz wieterarbeitet, beadrf es auch nicht 
der Abtastung ( interfacing mit 100 MHz ;-) Dann sollte man mal über das 
Systemdesign nachdenken.

>Mit anderen Worten: Ob man jetzt ein Fipflop hat, dass mit 100MHz läuft
>und einen Enable Eingang hat, der jeden 2. Takt das Flipflop deaktiviert
>oder ob man gleich das Flipflop mit 50MHz betreibt sollte doch keinen
>Unterschied machen.

Doch : 2 Takte -> 2 Taktnetze die Strom ziehen.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> ;-)
> Das kann man so gar nicht genau sagen, weil das nämlich beim
> Taktverdopplen zweiduetig ist.
> mit steigenden Flanke des 50 MHz Taktes übereinstimmt.
Hm. Ich hatte das hier gelesen:
http://toolbox.xilinx.com/docsan/xilinx7/books/dat...
CLK2X* Clock at 2x CLK0 frequency, in phase with CLK0
CLK2X180* Clock at 2x CLK0 frequency shifted 180o with regards to CLK2X 
Das "in phase with CLK0" hätte ich jetzt interpretiert ob das jedes mal 
gleich ist. Wie ich dich verstehe entscheidet es sich zufällig beim 
einschalten welcher der 2X Clocks die steigende Flanke Synchon zu den 
50MHz hat. Also ist das bei Xilinx etwas missverständlich geschieben? 
Wie an der Stelle "in phase" definiert ist, konnte ich auch nicht 
finden. In anderen Dokumenten stand gar nichts dazu.

> Du musst die Phasenausrichtung der beiden
> Takte mit Logik machen. Und zwar musst du mit dem 50 MHz Takt ein FF
> toggeln lassen. mit dem 100 MHz Takt tastest du dieses ab. Mit bissel
> Logik bekommt man daraus die richtige Phase des 100 MHz Taktes, welcher


Mir ist nicht ganz klar, wie ich die richtige Phase anschließend 
verwenden soll.
Eine kombinatorische Clock soll ich ja sicher nicht basteln. Aber 
rausfinden welcher der richtige ist kann ich -wie ich dich verstehe- 
erst zur Laufzeit. Dann sind die Flipflops ja aber schon an das Taktnetz 
angeschlossen, was ich ja beim Designen festlege. Was soll ich also 
machen?
Vielleicht alles doppelt vorsehen und die Daten zur falschen Flanke 
einfach verwerfen? Wäre dann ziemlich viel Zeug, was doppelt vorhanden 
ist... Oder wie geht es richtig?

> Du kannst aber auch alles mit dem 50 MHz Takt machen. Die 100 MHz
> Digitaleingänge machst du über DDR FlipFlops, das ergibt dann auch 100
> MHz Abtastfrequenenz.
OK, damit habe ich noch nie gearbeitet. Die DDR-FFs muss man 
instanzieren und kann sie nicht mit "normalem" Code beschreiben?
In der Beschreibung von Xilinx steht, dass das DDR-FF 2 Takteingänge 
hat. Der zweite sollte dann also der erste invertiert sein. Das mache 
ich aber sicher besser mit einem DCM als mit einem Inverter, da ich 
sonst die Verzögerungszeit des Inverters in den Pfad bekomme. Richtig?

Thomas Ulrich wrote:
> Wenn er hinterher nicht in 100 MHz wieterarbeitet, beadrf es auch nicht
> der Abtastung ( interfacing mit 100 MHz ;-) Dann sollte man mal über das
> Systemdesign nachdenken.

Die Daten will ich schon alle verwenden.

Eigentlich soll es nachher mit 100MHz laufen, vielleicht kann ich aber 
durch die DDR-FFs das ganze parallelisieren und das gleiche mit 50MHz 
erreichen. In die Richtung habe ich bisher noch nicht überlegt. Das 
werde ich aber mal tun.

> Doch : 2 Takte -> 2 Taktnetze die Strom ziehen.
OK. Von wie viel Strom reden wir denn? Finde ich das im Datasheet oder 
ist das realistisch betrachtet ehr Erfahrungssache?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian H. (cavorca)

>> Das kann man so gar nicht genau sagen, weil das nämlich beim
>> Taktverdopplen zweiduetig ist.
>> mit steigenden Flanke des 50 MHz Taktes übereinstimmt.
>Hm. Ich hatte das hier gelesen:
>http://toolbox.xilinx.com/docsan/xilinx7/books/dat...

>CLK2X* Clock at 2x CLK0 frequency, in phase with CLK0
>CLK2X180* Clock at 2x CLK0 frequency shifted 180o with regards to CLK2X

Stimmt schon, aber du kannst vom 100 MHz Takt aus NICHT sagen, welche 
von zwei aufeinanderfolgenden Flanken mit der steigenden Flanke des 50 
MHz Taktes übereinstimmt. Mals mal auf.

CLK2x180 ist quasi um ein 1/4 der 50 MHz verschoben, was komischerweise 
1/2 des 100MHz Taktes ist.

>Mir ist nicht ganz klar, wie ich die richtige Phase anschließend
>verwenden soll.

Zum Takten deiner 50 MHz ADC Daten.

>Eine kombinatorische Clock soll ich ja sicher nicht basteln. Aber

Besser ist das. ;-)

>rausfinden welcher der richtige ist kann ich -wie ich dich verstehe-
>erst zur Laufzeit.

Genau.

> Dann sind die Flipflops ja aber schon an das Taktnetz
>angeschlossen, was ich ja beim Designen festlege. Was soll ich also
>machen?

Einen rücksetzbaren Zähler bauen, der dann alles richtig steuert.

>Vielleicht alles doppelt vorsehen und die Daten zur falschen Flanke
>einfach verwerfen?

Nöö, das wäre Unsinn. Denn du must dann immer noch rausfinden, welche 
Daten die richtigen sind.


>OK, damit habe ich noch nie gearbeitet. Die DDR-FFs muss man
>instanzieren und kann sie nicht mit "normalem" Code beschreiben?

Genau.

>In der Beschreibung von Xilinx steht, dass das DDR-FF 2 Takteingänge
>hat. Der zweite sollte dann also der erste invertiert sein. Das mache
>ich aber sicher besser mit einem DCM als mit einem Inverter, da ich

Bei deinen Frequenzen reicht der Inverter.

>> Doch : 2 Takte -> 2 Taktnetze die Strom ziehen.
>OK. Von wie viel Strom reden wir denn?

Ja nach Grösse des FPGAs zwischen 10..200mA.

MfG
Falk

Autor: Gast (Gast)
Datum:

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

Ja, DCM's sind drin. Und woran könnte es liegen bzw. wie hast du dr 
dabei beholfen?

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> Stimmt schon, aber du kannst vom 100 MHz Takt aus NICHT sagen, welche
> von zwei aufeinanderfolgenden Flanken mit der steigenden Flanke des 50
> MHz Taktes übereinstimmt. Mals mal auf.
OK:

50 MHz:
 +-------+       +-------+       +-------+       +
-+       +-------+       +-------+       +-------+

100MHz:
 +---+   +---+   +---+   +---+   +---+   +---+   +
-+   +---+   +---+   +---+   +---+   +---+   +---+

100MHz ~180°
-+   +---+   +---+   +---+   +---+   +---+   +---+
 +---+   +---+   +---+   +---+   +---+   +---+   +

Habe ich das so richtig verstanden:
die zuordung, welches dieser Tsktsignale 2x und welches 2x 180° ist ist 
zufällt. Was Xilinx mit "in Phase" meint ist nicht die Zuordnung: Bei A 
(hier das obere) ist immer bei einer steigenden Flanke irgend eine 
Flanke vom ursprünglichen Takt und bei B immer eine fallende, _sondern_: 
Wenn bei dem ursprünglichen Signal eine Flanke ist ist auch immer bei 
den Verdoppelten Takten eine Flanke und nicht ein paar ns (bzw ein paar 
Grad) früher oder später.
Richtig?


>>Mir ist nicht ganz klar, wie ich die richtige Phase anschließend
>>verwenden soll.
>
> Zum Takten deiner 50 MHz ADC Daten.
Betonung auf wie ;-)


> Einen rücksetzbaren Zähler bauen, der dann alles richtig steuert.
OK.

> Bei deinen Frequenzen reicht der Inverter.
Die "ordentlichere" Lösung wäre aber der DCM?

Momentan tendiere ich ehr zum DDR-FF als zu der Lösung mit den 100MHz. 
Ob ich die Daten jetzt in 32Bit Breite mit 100MHz in ein Fifo schiebe 
oder in 64Bit Breite mit 50MHz sollte ja keinen Unterschied machen. Oder 
doch?
Auslesen kann ich es ja in beiden Fällen mit 32 Bit Breite.

> Ja nach Grösse des FPGAs zwischen 10..200mA.
ui. Und beim Spartan 3E500? Oder meinst du die Größe des Designs? Ich 
werde dich nicht auf einen Wert festnageln, aber da ist es hoffentlich 
noch ehr im unteren Bereich?

Viele Grüße,
Christian

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich würd da einfach einen 100Mhz Takt reingeben, mit der DCM auf 50 
runterteilen und die 100Mhz für das kurze Stückschen zwischen den 
Digital-Eingängen und den ohnehin nötigen FIFO benutzen. Mit den 50Mhz 
genau so. Du musst ja eh zwischenspeichern, also kannst du gleich mit 
der von dir gewollten Sample-Rate in die FIFOs schreiben und auf der 
Lese-Seite dann den Takt verwenden, der am ehesten zum RAM-Interface 
passt. Für den FX2 brauchst du eh noch einen extra Takt, wenn du nicht 
den internen verwenden willst. Bei Internen FX2-Takt hast du folgendes: 
die 48Mhz sind Harakiri, da muss man extrem mit dem Timing aufpassen, 
einige Zeiten überstreichen klat Datenblatt mehr als eine Taktperiode im 
Worst Case. Mit den 30Mhz kannst du höchstens 30 Mbyte/s an den PC 
übertragen. Kannst du dir dann aussuchen, was für dich das kleinere Übel 
ist. Der Mehr-Stromverbrauch für einen weiteren takt hält sich in 
Grenzen, die Spartan 3e sind recht genügsam.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian H. (cavorca)

>die zuordung, welches dieser Tsktsignale 2x und welches 2x 180° ist ist
>zufällt.

Zufällig? Nein. Aber die Zuordnung steigende Flanke 100 MHz und 
steigende Flanke 50 Mhz ist zweideutig. Mak kann auch die fallende 
Flanke vom 50 MHz Takt erwischen, ausserdem ist nicht gesagt, dass der 
50MHz GENAU 50% Tastverhältnis hat.

>Wenn bei dem ursprünglichen Signal eine Flanke ist ist auch immer bei
>den Verdoppelten Takten eine Flanke und nicht ein paar ns (bzw ein paar
>Grad) früher oder später.
>Richtig?

Ja. Wobei die DCMs AFAIK immer auf die steigende Flanke ausregeln. Oder 
kann man das einstellen?

>> Bei deinen Frequenzen reicht der Inverter.
>Die "ordentlichere" Lösung wäre aber der DCM?

Ja, laut Xilinx bringt das ein paar sub-Nanosekunden.

>Momentan tendiere ich ehr zum DDR-FF als zu der Lösung mit den 100MHz.
>Ob ich die Daten jetzt in 32Bit Breite mit 100MHz in ein Fifo schiebe
>oder in 64Bit Breite mit 50MHz sollte ja keinen Unterschied machen. Oder
>doch?

Doch, der FIFO muss bei 100 MHz doppelt so schnell sein. Geht meist, ist 
aber streng genommen anspruchsvoller vom Timing her.

>Auslesen kann ich es ja in beiden Fällen mit 32 Bit Breite.

>> Ja nach Grösse des FPGAs zwischen 10..200mA.
>ui. Und beim Spartan 3E500? Oder meinst du die Größe des Designs?

Beides.

http://www.geocities.com/Jacquesmartini/digital/pl...

Das war ein 200K Spartan-II, bei 150MHz. Machte dort ~200mA. Mal so als 
Vergleich.

> Ich
>werde dich nicht auf einen Wert festnageln, aber da ist es hoffentlich
>noch ehr im unteren Bereich?

Keine Ahnung. Ich würde das eher oben ansiedeln, so 100mA, ggf mehr.

@  Christian R. (supachris)

>Also ich würd da einfach einen 100Mhz Takt reingeben, mit der DCM auf 50
>runterteilen und die 100Mhz für das kurze Stückschen zwischen den

Ich nicht. Ich würde, wie bereits gesagt, die 50MHz per Takttreiber 
sternförmig zu den ADCs und dem FPGA routen. Dann im FPGA entweder 
verdoppeln oder mit DDR FlipFlop arbeiten.
hat den Vorteil dass

- die ADCs einen möglichst jitterarmen Takt bekommen
- die Taktverteilung sternförmig ist
- man "nur" 50 MHz vetrteilen muss und nicht 100 MHz

MFG
Falk

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @  Christian R. (supachris)
>
>>Also ich würd da einfach einen 100Mhz Takt reingeben, mit der DCM auf 50
>>runterteilen und die 100Mhz für das kurze Stückschen zwischen den
>
> Ich nicht. Ich würde, wie bereits gesagt, die 50MHz per Takttreiber
> sternförmig zu den ADCs und dem FPGA routen. Dann im FPGA entweder
> verdoppeln oder mit DDR FlipFlop arbeiten.
> hat den Vorteil dass
>
> - die ADCs einen möglichst jitterarmen Takt bekommen
> - die Taktverteilung sternförmig ist
> - man "nur" 50 MHz vetrteilen muss und nicht 100 MHz

Stimmt so ist es besser, hab ich gar nicht dran gedacht. Vom (guten) 
Quarzoszillator direkt per Clock-Treiber auf die ADCs und per DCM im 
Spartan auf 100 MHz. Hat man halt nur einen (sehr) geringen Jitter beim 
Logic-Analyser. Aber besser als auf dem ADC.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. wrote:
> Also ich würd da einfach einen 100Mhz Takt reingeben, mit der DCM auf 50
> runterteilen und die 100Mhz für das kurze Stückschen zwischen den
> Digital-Eingängen und den ohnehin nötigen FIFO benutzen. Mit den 50Mhz
> genau so. Du musst ja eh zwischenspeichern, also kannst du gleich mit
> der von dir gewollten Sample-Rate in die FIFOs schreiben und auf der
> Lese-Seite dann den Takt verwenden, der am ehesten zum RAM-Interface
> passt.
Meinst du dann auch die geteilten 50MHz an die ADCs rausgeben? Sonst 
bekomme ich ja Probleme mit den Timings.
Irgendwann muss ich mich auch drum kümmern, wie ich die Daten sortiere. 
Das mache ich lieber vor dem Fifo als danach da vorher die Taktrate noch 
ein wenig niedriger ist.

> Für den FX2 brauchst du eh noch einen extra Takt, wenn du nicht
> den internen verwenden willst. Bei Internen FX2-Takt hast du folgendes:
> die 48Mhz sind Harakiri, da muss man extrem mit dem Timing aufpassen,

ok, kann gut sein, dass ich damals 30MHz hatte und daher so wenig 
Probleme.

> einige Zeiten überstreichen klat Datenblatt mehr als eine Taktperiode im
> Worst Case. Mit den 30Mhz kannst du höchstens 30 Mbyte/s an den PC

Moment. Der Bus ist doch 16 Bit Breit. Das wären dann doch 60 MByte/s. 
Oder kenne ich da einen Flaschenhals noch nicht?
Ich meine im Datasheet steht ja auch an den FIFOs max burst 
rate=96MByte/s
Andererseits wäre ich auch schon mit 10MByte/s zufrieden. Mehr wäre 
natürlich besser, aber Hauptsache erst mal was mehr als die ~1MByte/s 
von Full Speed.

> übertragen. Kannst du dir dann aussuchen, was für dich das kleinere Übel
> ist. Der Mehr-Stromverbrauch für einen weiteren takt hält sich in
> Grenzen, die Spartan 3e sind recht genügsam.




Falk Brunner wrote:
> @ Christian H. (cavorca)
>
>>die zuordung, welches dieser Tsktsignale 2x und welches 2x 180° ist ist
>>zufällt.
>
> Zufällig? Nein. Aber die Zuordnung steigende Flanke 100 MHz und
> steigende Flanke 50 Mhz ist zweideutig. Mak kann auch die fallende
> Flanke vom 50 MHz Takt erwischen, ausserdem ist nicht gesagt, dass der
> 50MHz GENAU 50% Tastverhältnis hat.
>
Nagut, jetzt bin ich noch verwirrter.
Also ist eine Zuordung doch immer fest:
steigende Flanke CLK2X-> Flanke von CLK
fallende Flanke CLK2X180-> Flanke von CLK

Ich meine, wenn ich dann einen FF habe der mit den gleichen 50MHz die 
auch die ADCs bekommen die ADCs sampled Dann ist es doch egal ob ich im 
100MHz Takt zur steigenden oder fallenden Flanke der 50MHz Sample. Dass 
die Daten valide sind stelle ich doch durch den FF sicher der mit 50MHz 
läuft.


>>Wenn bei dem ursprünglichen Signal eine Flanke ist ist auch immer bei
>>den Verdoppelten Takten eine Flanke und nicht ein paar ns (bzw ein paar
>>Grad) früher oder später.
>>Richtig?
>
> Ja. Wobei die DCMs AFAIK immer auf die steigende Flanke ausregeln. Oder
> kann man das einstellen?
>
>>> Bei deinen Frequenzen reicht der Inverter.
>>Die "ordentlichere" Lösung wäre aber der DCM?
>
> Ja, laut Xilinx bringt das ein paar sub-Nanosekunden.
>
Immerhin ;-)

>>Momentan tendiere ich ehr zum DDR-FF als zu der Lösung mit den 100MHz.
>>Ob ich die Daten jetzt in 32Bit Breite mit 100MHz in ein Fifo schiebe
>>oder in 64Bit Breite mit 50MHz sollte ja keinen Unterschied machen. Oder
>>doch?
>
> Doch, der FIFO muss bei 100 MHz doppelt so schnell sein. Geht meist, ist
> aber streng genommen anspruchsvoller vom Timing her.
>
Da sagt mir aber doch die Synthese ob es geht oder nicht?

>>Auslesen kann ich es ja in beiden Fällen mit 32 Bit Breite.
>
>>> Ja nach Grösse des FPGAs zwischen 10..200mA.
>>ui. Und beim Spartan 3E500? Oder meinst du die Größe des Designs?
>
> Beides.
>
> 
http://www.geocities.com/Jacquesmartini/digital/pl...
>
> Das war ein 200K Spartan-II, bei 150MHz. Machte dort ~200mA. Mal so als
> Vergleich.
>
>> Ich
>>werde dich nicht auf einen Wert festnageln, aber da ist es hoffentlich
>>noch ehr im unteren Bereich?
>
> Keine Ahnung. Ich würde das eher oben ansiedeln, so 100mA, ggf mehr.
>
Das ist viel Strom. Hatte da AMD seine Finger im Spiel? ;-)


> Ich nicht. Ich würde, wie bereits gesagt, die 50MHz per Takttreiber
> sternförmig zu den ADCs und dem FPGA routen. Dann im FPGA entweder
Warum eigentlich sternförmig?
ich würde es so anordnen:

Taktquelle -- ADCs -- FPGA

Dann werden die Signale der ADCs genau so viel verzögert, wie der Takt 
zwischen ADCs und FPGA verzögert wird. Dann könnte ich doch die 
Lufzeiten so gut wie ignorieren. Oder ist das eine 
Milchmädchen-Rechnung. Wenn ja: Wo und warum?

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was versteht man denn unter einer sternförmigen Taktverteilung ???

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven wrote:
> Was versteht man denn unter einer sternförmigen Taktverteilung ???

So weit ich weiß: Alle Taktleitungen von der Takquelle zu den ICs die 
den Takt verwenden sind gleich lang.
siehe:
http://www.mikrocontroller.net/articles/SDRAM-Timing

Ich fände es bei mir praktischer, wenn die Taktleitung zum FPGA um die 
Länge der Datenleitungen von ADCs zu FPGA, läger ist als die Taktleitung 
von Quelle zu ADCs. Ich bitte um Widerspruch, wenn das Quatsch ist.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian H. (cavorca)

>Nagut, jetzt bin ich noch verwirrter.

;-)

>Also ist eine Zuordung doch immer fest:
>steigende Flanke CLK2X-> Flanke von CLK
>fallende Flanke CLK2X180-> Flanke von CLK

Nöö, eher so.
steigende Flanke CLK2X-> steigende Flanke von CLK
fallende Flanke CLK2X180-> steigende Flanke von CLK

>Ich meine, wenn ich dann einen FF habe der mit den gleichen 50MHz die
>auch die ADCs bekommen die ADCs sampled Dann ist es doch egal ob ich im
>100MHz Takt zur steigenden oder fallenden Flanke der 50MHz Sample. Dass

Das glaube ich kaum.

>die Daten valide sind stelle ich doch durch den FF sicher der mit 50MHz
>läuft.

Nein, dann auch nicht. Denn dann reduziert sich im schlimmsten Fall ds 
Timing vom 50 MHz FlipFlop zum 100MHz FlipFlop.


>> Doch, der FIFO muss bei 100 MHz doppelt so schnell sein. Geht meist, ist
>> aber streng genommen anspruchsvoller vom Timing her.

>Da sagt mir aber doch die Synthese ob es geht oder nicht?

Nein, das sagt dir der Timinganalyzer nach dem Place & Route. Die 
Angaben nach der Synthese sind ziemlich unbrauchbare Schätzwerte.

>Das ist viel Strom. Hatte da AMD seine Finger im Spiel? ;-)

AKAIF nein. Wenn dann eher Intel, die haben solche dreckigen Trick öfter 
genutzt.

>Warum eigentlich sternförmig?

Weils besser ist ;-)
Fürs Timing und den Jitter.

>Milchmädchen-Rechnung. Wenn ja: Wo und warum?

Weil die ADCs einen gewissen Abstand zueinander haben, da kommt mal fix 
ne halbe Nanosekunde und mehr raus. Und Taktleitungen sollte man sehr 
konservativ behandeln, auch der Welenwiderstand ist hier ein 
zentrales Thema.

>Ich fände es bei mir praktischer, wenn die Taktleitung zum FPGA um die
>Länge der Datenleitungen von ADCs zu FPGA, läger ist als die Taktleitung
>von Quelle zu ADCs. Ich bitte um Widerspruch, wenn das Quatsch ist.

Ist Quatsch. Siehe Artikel zum SDRAM-Timing. Dein "Trick" verschiebt dir 
die Hold-Zeit, auch nicht gut.

MfG
Falk

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian H. wrote:

>> einige Zeiten überstreichen klat Datenblatt mehr als eine Taktperiode im
>> Worst Case. Mit den 30Mhz kannst du höchstens 30 Mbyte/s an den PC
>
> Moment. Der Bus ist doch 16 Bit Breit. Das wären dann doch 60 MByte/s.
> Oder kenne ich da einen Flaschenhals noch nicht?
> Ich meine im Datasheet steht ja auch an den FIFOs max burst
> rate=96MByte/s
> Andererseits wäre ich auch schon mit 10MByte/s zufrieden. Mehr wäre
> natürlich besser, aber Hauptsache erst mal was mehr als die ~1MByte/s
> von Full Speed.

Der FX2 übernimmt die Daten nur bei jeder 2. Taktflanke. Bei 48Mhz IFCLK 
also 48 Mbyte/s. Mehr als 40 Mbyte/s wirst du eh nicht los, schneller 
ist USB nun mal nicht. Die 96 MByte/s Burst sind ein webegag. ich weiß 
nicht, woher die diesen fantasiewert nehmen.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur kurz zum "Phantasiewert 96 MByte/s": habe ein Design gehabt (USB hat 
jemand anders gemacht), da waren mit 8 Bit 40 MByte/s drin :-o Und das 
ist sehr wohl wahr. Ich vermute also, dass mit 16 Bit schon 80 MB/s drin 
gewesen wären.

Wie USB-Teil programmiert wurde, keine Ahnung. Ich weis noch, dass ich 
sowohl Clock (48 MHz), als auch die clock um 135 Grad geschoben zum 
USB-Controller auf eine RDY4 Leitung legen sollte.


Grüße,
Kest

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Laut Datenblatt muss das SLWR immer togglen und ist nur zu jeder 2. 
Flanke aktiv. Ich hatte auch probiert, das dauerhaft aktiv zu lassen um 
bei jeder Flanke zu schreiben, ging aber nicht, dann hat der FX2 jedes 
2. Wort vergessen. Eventuell klappt das im GPIF Modus, weiß ich nicht, 
ich benutze den Slave FIFO Modus, da sind alle Timing-Diagramme im 
Datenblatt so, dass nur bei jeder 2. Flanke geschrieben wird.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @ Christian H. (cavorca)
>
>>Nagut, jetzt bin ich noch verwirrter.
>
> ;-)
>
>>Also ist eine Zuordung doch immer fest:
>>steigende Flanke CLK2X-> Flanke von CLK
>>fallende Flanke CLK2X180-> Flanke von CLK
>
> Nöö, eher so.
> steigende Flanke CLK2X-> steigende Flanke von CLK
> fallende Flanke CLK2X180-> steigende Flanke von CLK
>
Warum nur steigende Flanke von CLK? auf die fallende Flanke von CLK0 
sollten doch die gleichen Flanken von CLK2X(180) kommen wie auf die 
steigende?

Einfache Frage für einfache Antwort die meine Verwirrung hoffentlich 
auflöst:
Ist die Zuordnung immer so: steigende Flanke CLK2X, fallende Flanke 
CLK2X180 oder kann es auch andersherum sein: fallende Flanke CLK2X, 
steigende CLK2X180->steignde Flanke von CLK?

Anders Formuliert: Ist bei fallende Flanke CLK2X und steigende CLK2X180 
das CLK0 Signal immer fest? Also 0 oder 1, aber jedenfalls keine Flanke.

>>Ich meine, wenn ich dann einen FF habe der mit den gleichen 50MHz die
>>auch die ADCs bekommen die ADCs sampled Dann ist es doch egal ob ich im
>>100MHz Takt zur steigenden oder fallenden Flanke der 50MHz Sample. Dass
>
> Das glaube ich kaum.
>
Ich verstehe nicht warum. Dass ich synchron zu den Flanken des 50MHz FFs 
sein muss ist klar. Damit - so habe ich es verstanden - ergibt sich aber 
nur die Bedingung, dass ich den richtigen Takt aussuchen muss. CLK2X 
ODER CLK2X180.
Das alles steht bei mir auf der Annahme: Alle Flipflops im FPGA sind 
etwa gleich schnell. Ist das richtig? Vielleicht ist das ja schon der 
Knackpunkt, dass das falsch ist.
Ich meine: Was man beachten muss bei den Timings sind ja im Prinzip die 
Setup und Hold Zeiten. Beispiel der Ausgang von Flipflop A ist an den 
Eingang von Flipflop B angschlossen. B wird mit 100MHz getaktet. Daten 
sollen bei steigenden Flanken übernommen werden.

Im ersten Fall soll A auch mit den gleichen 100MHz getaktet werden. Das 
sollte ja funktionieren.
Jetzt betrachten wir den Fall, dass A mit 50MHz getaktet wird, undzwar 
so, dass die Flanken der 50 MHz Synchron mit den steigenden 100MHz 
Flanken sind. Dann gibt es 2 Fälle:
1) Steigende bei 50 und bei 100.
Das ist eigentlich das gleiche als ob man beides mit 100MHz betreibt. 
Dadurch dass der letzte Flanke von A aber doppelt so lange her ist 
verlängert sich die Zeit die die Daten an B anliegen. Aber das macht ja 
nichts aus.
2) Fallende bei 50, Steigende bei 100.
Da das FF A bei 100MHz laufen würde (es ist ja ganau so schnell wie B) 
sind bei der Flanke die Daten des letzten Taktes schon valide. Die Setup 
und Hold Zeiten müssen also erfüllt sein (sofern es im reinen 100MHz 
betrieb läuft.)


Versteh mich nicht falsch: Ich glaube dir ja, dass du Recht hast. Du 
hast sicher mehr Erfahrung und Wissen darüber als ich. Aber: Wo ist der 
Fehler in meiner Argumentation?

> Nein, das sagt dir der Timinganalyzer nach dem Place & Route. Die
> Angaben nach der Synthese sind ziemlich unbrauchbare Schätzwerte.
>
Aber ich erfahre es und kann mich auf die Werte verlassen?

> AKAIF nein. Wenn dann eher Intel, die haben solche dreckigen Trick öfter
> genutzt.
War ja eigentlich nur ein Spaß. Aber warum war es denn lange so, dass 
AMD so extrem viel Strom verbraucht hat? Vor einigen Jahren brauchten 
die doch

> Weils besser ist ;-)
> Fürs Timing und den Jitter.
Wie wirkt sich die Leitungslänge auf Jitter aus? Oder nennt man Jitter 
auch den Zeitunterschied der Flanken zweier verschiedener Signale?

>
>>Milchmädchen-Rechnung. Wenn ja: Wo und warum?
>
> Weil die ADCs einen gewissen Abstand zueinander haben, da kommt mal fix
> ne halbe Nanosekunde und mehr raus. Und Taktleitungen sollte man sehr
halbe Nanosekunde wären 10 cm. Ich denke nicht, dass ich über 3 cm 
komme. Aber das wird sich ja beim erstellen der Platine zeigen.


> Ist Quatsch. Siehe Artikel zum SDRAM-Timing. Dein "Trick" verschiebt dir
> die Hold-Zeit, auch nicht gut.
Wie schon oben geschrieben: An den ADC Ausgängen liegen bei 50MHz 
Betrieb die Daten seit mindestens 8 ns an, nach der Flanke noch 
mindestens 3,9 ns.
Ich habe jetzt nicht nachgesehen was die FFs im Spartan für Setup und 
Hold werte fordern, aber ich denke mit diesen Werten leige ich weit im 
grünen bereich. Wenn jetzt aber die Taktverteilung sternförmig mache 
dann liegen die Daten noch etwas länger an. Hm ok. Du hast recht. Das 
macht die Sache ehr einfacher. Aber bei den Zeiten und kurzen Leitungen 
sollte das ja auch nicht soo kritisch sein.

Den Artikel über SDRAM-Timing werde ich sicher nochmal lesen. Aber 
frühestens nächste Woche. Eigentlich habe ich momentan nicht mal Zeit 
hier zu antworten.


@Christian R. und Kest:
Das nur jede 2. Flanke die Daten aufgenommen werden hat mir gestern echt 
den Rest gegeben. Ich will echt mal wissen, was ich damals gemacht habe 
als ich den FX2 an meinem Spartan Board getestet habe. Wahrscheinlich 
habe ich es einfach übersehen, dass die Hälfte nicht ankommt.

Kann es vielleicht sein, dass es nur bei 16 Bit Betrieb der Fall ist, 
dass nur bei jeder 2. Flanke Daten genommen werden und bei 8 Bit bei 
jeder Flanke? Das würde ja zu eurer beider Erfahrungen passen.

Warum tut Cypress so etwas?? Das macht doch alles unnötig komplizierter. 
Ich meine warum nehmen die dann nicht gleich den halben Takt?

Viele Grüße,
Christian

P.S. Die 96MByte/s Burst Rate kann man haben. Zumindest, wenn man nur 16 
Bit überträgt ;-)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian H. (cavorca)

>Warum nur steigende Flanke von CLK?

Weil DCMs bzw. PLLs etc. so funktionieren. Sie werten nur ein Flanke 
aus.

> auf die fallende Flanke von CLK0
>sollten doch die gleichen Flanken von CLK2X(180) kommen wie auf die
>steigende?

Nöö, das klappt nur, wenn CLK ziemlich genau 50% Tastverhältnis hat. Und 
das ist in der Realität selten der Fall. Deshalb gibt es ja den Duty 
Cycle Corretion Modus, wo der DCM ein sauberes 50% Tastverhältnis 
generiert.

>Einfache Frage für einfache Antwort die meine Verwirrung hoffentlich
>auflöst:

;-)

>Ist die Zuordnung immer so: steigende Flanke CLK2X, fallende Flanke
>CLK2X180

AFAIK ja.

 oder kann es auch andersherum sein: fallende Flanke CLK2X,
>steigende CLK2X180->steignde Flanke von CLK?

AFAK nein, es sei denn, man kann das irgendwo noch einstellen.

>Anders Formuliert: Ist bei fallende Flanke CLK2X und steigende CLK2X180
>das CLK0 Signal immer fest? Also 0 oder 1, aber jedenfalls keine Flanke.

Meistens ja, immer nein. Wenn CLK0 genau 50% Tastverhältnis hat, fallen 
auch diese Flanken aufeinander. Vorsicht Falle.

>>Ich meine, wenn ich dann einen FF habe der mit den gleichen 50MHz die
>>auch die ADCs bekommen die ADCs sampled Dann ist es doch egal ob ich im
>>100MHz Takt zur steigenden oder fallenden Flanke der 50MHz Sample. Dass
>
> Das glaube ich kaum.
>
>Ich verstehe nicht warum. Dass ich synchron zu den Flanken des 50MHz FFs
>sein muss ist klar. Damit - so habe ich es verstanden - ergibt sich aber
>nur die Bedingung, dass ich den richtigen Takt aussuchen muss. CLK2X
>ODER CLK2X180.

Nöö, du musst auch die richtige Phase erwischen, sonst werden dein 
Timingreserven unnötig vermindert.

>Das alles steht bei mir auf der Annahme: Alle Flipflops im FPGA sind
>etwa gleich schnell. Ist das richtig?

Ja, tut hier aber nix zur Sache. Schau nochmal in dein Timingdiagramm 
und frage dich was passiert, wenn du eine CLK2x Flanke nach links oder 
Rechts rückst. Wie ändert sich der zeitliche Abstand? Das sind deine 
Timingreserven.

>Flanken sind. Dann gibt es 2 Fälle:
>1) Steigende bei 50 und bei 100.

Genau.

>Das ist eigentlich das gleiche als ob man beides mit 100MHz betreibt.

Eben.

>Versteh mich nicht falsch: Ich glaube dir ja, dass du Recht hast. Du
>hast sicher mehr Erfahrung und Wissen darüber als ich. Aber: Wo ist der
>Fehler in meiner Argumentation?

Die stimmt wahrscheinlich im Grossen und Ganzen in deinem Kopf, 
allerding sind deine Formulierungen etwas schwammig und bisweilen zu 
allgemein.

>Aber ich erfahre es und kann mich auf die Werte verlassen?

Ja.

>War ja eigentlich nur ein Spaß. Aber warum war es denn lange so, dass
>AMD so extrem viel Strom verbraucht hat?

Und Intel baut seit Äonen von Jahren Stromsparwunder? Hab ich was 
verpasst?

>Wie wirkt sich die Leitungslänge auf Jitter aus?

Lange Leitungen auf dem Board können mehr Störungen oder Reflexionen 
einfangen, das macht Jitter.

> Oder nennt man Jitter
>auch den Zeitunterschied der Flanken zweier verschiedener Signale?

Nöö, das ist Skew. Jitter ist die zeitliche Veränderung des Auftretens 
einer Flanke, praktisch das zeitliche Zappeln einer Flanke um einen 
idealen zeitpunkt. Mal bissel früher, mal bissel später.

>macht die Sache ehr einfacher. Aber bei den Zeiten und kurzen Leitungen
>sollte das ja auch nicht soo kritisch sein.

Nein, ist aber dennoch besser. Wieviel wird sich zeigen.

MFG
Falk

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
>> auf die fallende Flanke von CLK0
>>sollten doch die gleichen Flanken von CLK2X(180) kommen wie auf die
>>steigende?
>
> Nöö, das klappt nur, wenn CLK ziemlich genau 50% Tastverhältnis hat. Und
> das ist in der Realität selten der Fall. Deshalb gibt es ja den Duty
> Cycle Corretion Modus, wo der DCM ein sauberes 50% Tastverhältnis
> generiert.
>
Ah, das klärt so einiges. Sag mit doch gleich, dass mein Bild oben 
falsch ist ;-)

Bei Xilinx steht aber, dass CLK(0/2X/2X180) alle 50-50 Duty Cycle haben 
(Wenn man den DCM so einstellt)
The duty cycle of the CLK0 output is 50-50 unless the 
DUTY_CYCLE_CORRECTION attribute is set to FALSE, in which case the duty 
cycle is the same as that of the CLKIN input. The duty cycle of the phase 
shifted outputs (CLK90, CLK180, and CLK270) is the same as that of the CLK0 
output. The duty cycle of the CLK2X, CLK2X180, and CLKDV outputs is 50-50 
unless CLKDV_DIVIDE is a non-integer and the DLL_FREQUENCY_MODE is High 
(see “CLKDV_DIVIDE,” in the Constraints Guide for details).

quelle: 
http://toolbox.xilinx.com/docsan/xilinx7/books/dat...
>>Einfache Frage für einfache Antwort die meine Verwirrung hoffentlich
>>auflöst:
>
> ;-)
>
>>Ist die Zuordnung immer so: steigende Flanke CLK2X, fallende Flanke
>>CLK2X180
>
> AFAIK ja.
OK :-)


>>Anders Formuliert: Ist bei fallende Flanke CLK2X und steigende CLK2X180
>>das CLK0 Signal immer fest? Also 0 oder 1, aber jedenfalls keine Flanke.
>
> Meistens ja, immer nein. Wenn CLK0 genau 50% Tastverhältnis hat, fallen
> auch diese Flanken aufeinander. Vorsicht Falle.
>
Jetzt wiedersprichst du dir.
Sagen wir bei 0° hat CLK0 die Rising Edge.
Oben sagst du jetzt, dass bei 0° auch die steigende von CLK2X und die 
Fallende von CLK2x180. Bei 180° haben CLK2X und CLK2X180 nochmal die 
gleichen flanken. Bei 50-50 DC von CLK0 ist hier noch eine Steigende 
Flanke von CLK0.
Die fallende Flanke von CLK2X und die Steigende von CLK2X180 sind (bei 
50-50 DC) bei 90° und bei 270°. Da sollte doch in der Regel nichts 
passieren. Erst recht nicht bei CLK0 ist 50-50. Wenn dann doch ehr bei 
so extremen fällen wie 25-75 oder 75-25.
Oder nein?


> allerding sind deine Formulierungen etwas schwammig und bisweilen zu
> allgemein.
Ja, das Problem bemerke ich auch. Ich glaube an manchen Stellen fehlen 
mir ein wenig die Fachausdrücke um das was ich meine klar und knapp in 
einem Satz zu sagen.

> Und Intel baut seit Äonen von Jahren Stromsparwunder? Hab ich was
> verpasst?
Das nicht. Wenn ich mich richtig erinnere hatte Intel aber vor AMD die 
Idee, dass man einen Prozessor, wenn er nicht gebraucht wird, auch mal 
mit einer kleineren Frequenz Takten kann und damit die 
Versorgungsspannung reduzueren kann.
Aber egal, darum geht es hier ja eigentlich nich.

> Lange Leitungen auf dem Board können mehr Störungen oder Reflexionen
> einfangen, das macht Jitter.
OK, Akzeptiert.


> Nein, ist aber dennoch besser. Wieviel wird sich zeigen.
OK


Viele Grüße,
Christian

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian H. (cavorca)

>Die fallende Flanke von CLK2X und die Steigende von CLK2X180 sind (bei
>50-50 DC) bei 90° und bei 270°. Da sollte doch in der Regel nichts
>passieren. Erst recht nicht bei CLK0 ist 50-50. Wenn dann doch ehr bei
>so extremen fällen wie 25-75 oder 75-25.

Stimmt.

MFG
Falk

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. wrote:
> Laut Datenblatt muss das SLWR immer togglen und ist nur zu jeder 2.
> Flanke aktiv. Ich hatte auch probiert, das dauerhaft aktiv zu lassen um
> bei jeder Flanke zu schreiben, ging aber nicht, dann hat der FX2 jedes
> 2. Wort vergessen. Eventuell klappt das im GPIF Modus, weiß ich nicht,
> ich benutze den Slave FIFO Modus, da sind alle Timing-Diagramme im
> Datenblatt so, dass nur bei jeder 2. Flanke geschrieben wird.

Wo steht dass man SLWR immer togglen muss? Ich kann das beim besten 
willen nicht finden. Ehr im Gegenteil:

Aus dem TRM:
Slave Write — SLWR
In synchronous mode (IFCONFIG.3 = 0), data on the FD bus is written to 
the FIFO (and the FIFO pointer is incremented) on each rising edge of 
IFCLK while SLWR is asserted. In asynchronous mode (IFCONFIG.3 = 1), 
data on the FD bus is written to the FIFO (and the FIFO pointer is 
incremented) on each asserted-to-deasserted transition of SLWR.
By default, SLWR is active-low; its polarity can be changed via the 
FIFOPINPOLAR register.

Auch im Datasheet sieht es anders aus:
Abbildung 31 auf Seite 51 und Abb. 23 auf S. 47

(Beide Papiere gibts auf 
http://www.cypress.com/products/index.jsp?gid=9&fi...; )

Reden wir evtl. von verschiedenen chips? Wobei ich aber auch nicht 
glaube, dass es beim FX2 anders ist als beim FX2LP

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt, es geht offensichtlich auch bei jeder Flanke ohne Tooggeln. Ich 
bin nach den Bildern 9-12 und 9-13 auf Seite 121 des TRM gegangen. 
Müsste man mal probieren, dann würde ja auch der 30MHz interne Takt 
reichen. Bei unserer Anwendung ist es egal, ich arbeite mit 40Mhz 
externem Takt und kann somit 40MByte/s übertragen, da ich bei jeder 2. 
Flanke 16 Bit schreibe. Klappt bestens. Ich werd aber mal ausprobieren, 
wie es mit SLWR und SLRD dauerhaft auf Low klappt.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK. Ich hoffe ich schaffe es das heute mal auszuprobieren.
In meinem Projekt werde ich auf jeden Fall 30MHz extern nehmen, da ich 
dann im FPGA mit 2 verschiedenen Takten auskomme. Sonst brauche ich 3. 
Aber Geschwindigkeit ist bei mir eh nicht so wichtig, so lange es 
wenigstens etwas schneller als Full-Speed ist.
Wenn man SLWR nicht togglen muss entspannt das doch auch das Timing. 
Sehe ich das richtig? Ich meine die Setup und Hold Zeiten der Daten sind 
ja wesentlich kürzer als die von SLWR. Evtl muss man durchzählen, wann 
der Buffer voll ist, aber man kann ja auch einstellen, dass der 
Full-Flag schon gesetzt wird, wenn noch genau ein mal geschrieben werden 
kann.

Viele Grüße,
Christian

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hatte erst heute Gelegenheit. Ergebnis: Daten werden auch bei SLWR 
permanent LOW alle übertragen.

Ob in der Datenübertragung Fehler sind habe ich noch nicht überprüft. 
Aber ich bin recht sicher, dass zumindest keine Words verschluckt 
werden. Am FX2 hängt ein FPGA in dem ein Zähler implementiert ist. Bei 
jedem Takt bei aktivem SLWR wird der Zähler inkrementiert. Wenn ich in 
der CyConsole 1024 Bytes übertrage ist das letzte Byte jedes mal gleich. 
Auch nachdem ich x mal 1024 Bytes übertrage. Es könnte natürlich auch 
noch sein, dass aus irgendwelchen Gründen auch immer ein Word verdoppelt 
wird, wenn eins verschwindet. Bei nächster Gelegenheit werde ich mal ein 
Programm schreiben, dass Checkt ob alle Daten stimmen. Ich bin auch sehr 
gespannt auf welche Datenrate ich jetzt komme.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt einige 100MB Daten übertragen und sie kommen so weit ohne 
Aussetzer an. Bevor ich wirklich behaupten würde, dass es einwandfrei 
läuft würde ich noch eine GB übertragen. Allerdings läuft die 
Übertragung nur mit 2,5 bis 3,5MByte/s.
Auf dem PC läuft kaum was. Die CPU Nutzung schwankt irgendwo bei 10%. 
Das einzige was ich hier im Forum dazu finden konnte ist dass man 
IOCTL_ADAPT_SET_TRANSFER_SIZE auf einen großen Wert setzen soll. Diese 
Funktion kann ich aber weder bei Google noch im PDF zur CyAPI finden.
Die Daten schreibe ich mit einem FPGA in den FX2. Konfiguration: EP2 
1024kByte, 4fach buffered.
Am USB-Port hängt sonst noch das FPGA Board. USB wird da aber nur als 
Stromversorgung genutzt. Ob intern im Notebook noch Geräte existieren 
die USB nuten weiß ich nicht.
Hat jemand einen Vorschlag was ich noch probieren kann?

Viele Grüße,
Christian

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahja, naja, laut Datenblatt soll es ja wohl auch mit permanentem Low 
klappen. Gut zu wissen, die bestehende Schaltung bau ich jetzt nicht 
mehr um, aber das nächste mal dann.
Im CyAPI musst du SetXFerSize aufrufen, und am besten auf 64k setzen, 
dann erreicht man ungefähr 40 MByte/s.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe schon 8k, 64k und 2M ausprobiert. Nach einem neustart des 
Systems komme ich auch nicht über 4MByte/s.
Ob ein anderes Gerät den Bus blockiert? Allerdings ist es auf einem 
anderen System das gleiche...

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielleicht ist mein Code falsch?
  unsigned char inBuf[1024] = {0};
  long length = 1024;
  InEndpt = (CCyBulkEndPoint *) USBDevice->EndPoints[3];
  InEndpt->SetXferSize(65536);

  
  first=1;
  zeit=GetTickCount();
  for (i=0;i<=datalength-1;i++){
    InEndpt->XferData(inBuf, length);
    if (first==1) {//Erste Daten setzten
      first=0;
      index=inBuf[0]*256 + inBuf[1];
    }
    for (j=0;j<=511;j++){//Daten auf Korrektheit Prüfen FPGA sendet aufsteigende 16 Bit Words
      val=(inBuf[2*j]*256 + inBuf[2*j+1]);
      if (index!=val){
        printf ("Fehler! %d, %d  ", index, val);
      }
      index++;
      if (index==65536) index=0;
    }
  }
Wenn ich den Teil der prüft ob die Daten stimmen rausnehme, ist es auch 
nicht bedeutend Schneller.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo, wenn du jedes Paket einzeln abholst, ist das klar. Musst gleich mit 
einem XFer 64k oder sowas die Daten holen. So packt der nur 1024 byte in 
einen MicroFrame. Damit kommst du rechnerisch auf max. 8.000.000 
Bytes/s. Ein Microframe ist 128µs lang, bei einer Füllung von lediglich 
1024 Byte geht da nicht mehr. Der FX2 kann aber bis zu 11 Pakete á 512 
byte in einen MicroFrame stecken. Bei 10 Paketen, also 5120 byte pr 
Frame kommt man auf 40.000.000 Byte/s. 11 ist das Maximum, mehr passt 
einfach nicht rein. Damit kommt man auf max. 41,96 MByte/s. Kann man 
sich schön auf dem Oszi direkt an D+ oder D- angucken, wie voll die 
Frames dann sind.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah! Super! Vielen Dank!!
Jetzt läuft es auch bei mir mit 37,5 - 39 MiB/s (ohne die Kontrolle ob 
die Daten stimmen. Mit bin ich bei ca 30MiByte/s. Jetzt muss ich mir 
wohl mal ansehen wie man Programme mit mehreren Threads schreibt.)

Ich habe jetzt mal 4,5GiB übertragen. War kein Fehler dabei. Vielleicht 
lasse ich es irgendwann mal eine Nacht durchlaufen.

Gibt es eine maximale Größe für die Länge die ich bei XferData angebe? 
Im PDF steht ja nur was zu isochronous transfers.

Was ich an der Doku auch sehr eigenartig finde ist, das bei den 
Funktionen nicht explizit dabei steht welche Parameter sie haben und von 
welchem Typ die sind.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo, verloren geht bei BULK nix, alles was in den Chip rein kommt, 
bekommt man auch am Host. Die Doku ist wirklich sinnlos, hab das auch 
alles durch probieren rausgefunden. Maximale TransferSize ist wohl 3MB, 
hatte mal einer rausgefunden hier. Bringt aber nix. Das Optimum liegt je 
nach hostcontroller bei 64 oder 128 k. Multithreading ist da wirklich 
angesagt, Daten abholen und Daten auswerten in verschiedenen Threads.

Du hattest jetzt 30MHz IFCLK, und Schreiben bei jeder Flanke, oder? Wenn 
da auch nicht mehr als 40MB/s rauskommen, brauch ich ja erst ma nix an 
der Schaltung im FPGA zu ändern.

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. wrote:
> Jo, verloren geht bei BULK nix, alles was in den Chip rein kommt,
> bekommt man auch am Host.
Meine Sorge war nicht, dass durch den Bulktransfer Daten verloren gehen 
oder verfälscht werden, sondern auf dem Weg zum FX2. Das geht über 2 
Stecker, verschiedene Leitungsimpedanzen, katastrophale 
Masserückleitung,... Aber wenn es hier Funktioniert funktioniert es mit 
einem Ordentlichen Design garantiert. Und das Timing sollte ja auch in 
Ordnung sein, wenn die Übertragung Fehlerfrei läuft.

> Die Doku ist wirklich sinnlos, hab das auch
> alles durch probieren rausgefunden. Maximale TransferSize ist wohl 3MB,
> hatte mal einer rausgefunden hier. Bringt aber nix. Das Optimum liegt je
> nach hostcontroller bei 64 oder 128 k.
OK.
>Multithreading ist da wirklich
> angesagt, Daten abholen und Daten auswerten in verschiedenen Threads.
Ja.
>
> Du hattest jetzt 30MHz IFCLK, und Schreiben bei jeder Flanke, oder? Wenn
Sogar 48MHz IFCLK. (IFCONFIG=0xE3) Und ja, schreiben bei jeder Flanke. 
Mein Rekord war 39,4 MiB/s. Wenn man über längere Zeiten mittelt geht es 
ehr Richtung 38, sofern der PC nix anderes macht.
> da auch nicht mehr als 40MB/s rauskommen, brauch ich ja erst ma nix an
> der Schaltung im FPGA zu ändern.
Mich würde ja schon interessieren was du da baust. Oder darfst du das 
nicht erzählen?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian H. wrote:

> Mich würde ja schon interessieren was du da baust. Oder darfst du das
> nicht erzählen?

Den Nachfolger dieses Geräts: 
http://www.izfp-d.fraunhofer.de/download/micro-use.pdf

Autor: Christian H. (cavorca)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieht interessant aus. Und ich dachte in der Industrie verwendet man ehr 
CAMAC, VME oder PCI oder etwas in der Richtung oder soll das Produkt 
mobiler sein?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PCI Karte haben wir ja auch. Aber für 16 Ultraschallkanäle braucht man 
16 Full-Size PCI-Karten mit jeweils 35 Watt Leistungsaufnahme. Dazu ein 
riesen 19" Industrie-PC mit einer 16 PCI-Slot Backplane. 
Gesamt-Leistungsaufnahme etwa 900 Watt. Und die ganze Sache mit dem PC 
ist dann ortsfest und erschütterungsempfindlich. Um aber ordentliche 
Signale von den Ultraschall-Sensoren zu erhalten müssen die Kabel kurz 
sein. In den meisten Fällen ist der Prüfling aber einige Meter entfernt, 
riesengroß, tonnenschwer und muss durch ein Portal o.ä. abgescannt 
werden. Eine solche USB-Kiste ersetzt 16 Full-Size PCI Karten und ist 
dazu da, um auf einem beweglichen Portal zusammen mit einem kleinen 
Wall-Mount-PC (und evtl weiteren USB-Geräten) zur Datenaufnahme montiert 
zu werden. Zum Host-Rechner gehen dann die Daten per Ethernet.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich hab jetzt die Ansteuerung des FX2LP auch mal auf Lesen/Schreiben 
bei jeder Flanke des IFCLK und durchgehend aktiven SLWR und SLRD 
umgebaut. Klappt prima. Der FPGA schreibt/liest jetzt mit 80 MB/s, bei 
40 MHz externem IFCLK. Weiß gar nicht, wieso ich das anfangs im 
Datenblatt nicht so gesehn hatte.

Erwartungsgemäß ist die Kommunikation zum PC aber auch nicht schneller, 
viel mehr als 40 MByte/s geht ja nicht.

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.