Spartan 3A mit variablem Takt - Abgefahrene Ideen gefragt!

Da de Ideen suchst:

an den Datenausgang einen asynchronen Fifo hängen und mit dem 
asynchronen Takt wieder "synchronisieren". Wenn du einen internen Fifo 
nimmst, dann ist die Taktverzögerung geringer als an dem Pin.

> dose
Jup an diese Idee hatte ich auch schon gedacht. Aber kennst du einen 
async FIFO, der noch bei 250MHz clock arbeitet?

> Harald Flügel
Klar, das würde helfen, ist aber leider nicht möglich. Die Clock kommt 
von außen und nicht aus dem FPGA.

Also danke für die Ideen... aber hat noch jemand eine bessere?

Wie breit sind deine Daten?
Ich habe mal einen Fifo in VHDL geschrieben. Da muss ich mal schauen ob 
dieser adaptierbar ist.

Mad Physicist schrieb:
> Verzögerung
> zwischen Clock und Signalausgabe nur auf Werte um die 6ns (Simulation:
> slew=fast, drive=12, OFD), benötige aber max. 4ns (1/250MHz).

4 ns zwischen Ankunft der Taktflanke draußen am FPGA Pin und gültig 
stabilen Daten an den Ausgangsleitungen? Oder woanders?

Falls ersteres sollte sich mit Datenblatt ermitteln lassen, ob das 
Signal überhaupt den Weg Pad zu Register bzw umgekehrt in unter 2 ns 
erledigen kann. Und da bin ich ziemlich skeptisch.

Und wie hfl geschrieben hat gibt es dann Frequenzen, bei denen Müll 
heraus kommt. Ehrlich gesagt frage ich mich, ob da nicht das Konzept mal 
überdacht gehört.

lg
m

Vielen Dank für Eure Antworten!

> dose
16 bit.. aber FPGA-Design hilft nicht, Clock-to-Output-Delay im FPGA ist 
einfach nicht unter 6ns zu bekommen.

> Harald Flügel
("Im übrigen stimme ich deiner Aussage unten nicht zu. Zitat:")

Im Gegenteil - den Sachverhalt den Du da beschreibst ist genau das was 
ich meine mit "überholen": Dass "wenn die Frequenz dumm liegt, dann 
ändern sich die Datenausgänge des FPGA just zu dem Zeitpunkt, zu dem die 
nachgeschaltete Logik die Daten einliest." Ich hab das nur nicht so 
gekonnt ausgedrückt und wollte im Eingangspost alles möglichst kurz 
halten. Bzw. das Problem ist nicht nur die Metastabilität, sondern auch 
eine leicht unterschiedliche Laufzeit der einzelnen Datenbits, so dass 
einige Bits vom alten und einige vom neuen Zustand erfasst werden.

Ansonsten fürchte ich, dass Du recht hast, dass man nichts tun kann. Das 
dachte ich auch, wollte nur sicher gehen, dass ich nicht einfach zu doof 
bin mit dieser Einschätzung.

> Matthias
Woran das Problem liegt (wie Du und Harald Flügel es beschreiben) ist 
mir durchaus klar. Nur nicht worin die Lösung liegt falls es eine 
gibt...
Datenblatt hab ich gewälzt, allerdings muss man da wohl mehrere 
spezifizierte Einzel-Timigs zusammenzählen.

> Falk Brunner
> Sowas ist immer sehr sinnvoll . . .
...genauso wie diese Zeile der Antwort... Es gibt nun mal gewisse 
Erfordernisse, die sich aus der zu erledigenden Aufgabe ableiten.

> Du brauchst ein paar Grundlagen und eingescheites Konzept.
...ja, aber nicht die Basic-Grundlagen auf MK.net, sondern 
weiterführende. Wenn Du gute Links weißt - ich les gerne zum Thema FPGA!
Wobei ich denke, bis auf diesen Punkt ist das Konzept sehr gut. Leider 
ist mir vorher nicht klar gewesen, dass die entsprechende Verzögerung im 
FPGA so groß wird. Genau genommen hab ich das ganze sowieso nur für 150 
MHz geplant, aber da jetzt der FPGA intern noch bis 250 MHz ohne 
Probleme mitkommt und die nachgeschaltete Elektronik auf 250 MHz 
spezifiziert ist, ist es ärgerlich, dass es an der Schnittstelle hapert. 
Für eine Revision Null und dem ersten Spartan-3A-Projekt allerdings 
akzeptable Performance.

> Und einen Deutschkurs. Das heißt Takt.
Danke!!!!! Es gibt keinen hier im Forum, der "clock" nicht versteht.
<switch-to-Falk-Brunner-Troll-Modus>
Außerdem schreibt man "eingescheites" nicht zusammen, also offenbar 
brauchst Du einen Lücken-Setz-Kurs.
</switch-to-Falk-Brunner-Troll-Modus>

> Gar nicht bei so dermassen sinnlos, endlos schwankenden Taktfreqeunzen.
Hatt's befürchtet. Wobei das Schwanken des Taktes nicht sinnlos ist.
(Außerdem schreibt man "dermaßen" mit scharfem "ß" - wir treffen uns 
dann im Deutschkurs!)

- Mad Physicist

250 MHz sind bei diesem synchronen systemansatz ausgeschlossen. 150 MHz 
kritisch. Wenn 6,66 ns periodenzeit hast und 6 ns c2o dann hast du 
rechnerisch noch 0,66 ns für die delays durch verdrahtung der chips und 
setup zeit des empfängers. Bedenke 10 cm draht sind ca. 0,5 ns.

Wie ist das timing des empfängers überhaupt spezifiziert?

Vorsicht folgender vorschlag erfordert sehr gute kenntnisse der STA!!!
Bei manchen FPGA's lässt sich die c2o duch umgehen des globalen clock 
trees für die output register optimieren. Das würde so funktionieren:
 - der clock eingang wird direkt bei den daten ausgängen plaziert 
(mittig)
 - das clock signal wird zunächst direkt mit den output FF's verbunden
 - danach geht der clock auf das globale clock net und versorgt den rest
Ob dies für deinen FPGA zielführend ist, kann ich dir nicht sagen.

Ottmar

@Ottmar (Gast)

Danke für Deine Einschätzung!

Den fortgeschrittenen Ansatz mit (wie ich das verstehe) womöglich 
manuellem Routing auf dem FPGA werde ich mal im Hinterkopf behalten, 
erscheint mir mit meinem derzeitigen Kenntnisstand unrealistisch. 
Dennoch eine sehr interessante Idee!

Eine murksige Lösung, die mir eingefallen ist, wäre folgende: In der 
Anwendung ändert sich der Takt andauernd um wenige Hz aufgrund einer 
Regelschleife und gelegentlich um große Schritte bei Wechsel des 
Betriebsmodus. Man baut also auf dem FPGA einen Frequenzzähler. Je nach 
Eingangs-Takt wählt der FPGA dann unterschiedliche IBUF DELAY und/oder 
invertiert das Clock-Signal um setup/hold time im Empfänger einzuhalten.
Muss man natürlich Hysterese vorsehen und ist evtl. nicht über den 
ganzen Temperaturbereich funktionell, aber für mich reicht's notfalls, 
wenn es bei Zimmertemperatur läuft. Ist ja kein kommertielles Produkt.

- Mad Physicist

Hab nochmal darüber nachgedacht. Es ist nicht ganz so aussichtslos.

Du brauchst zwei clock modes und einen clock switch. In einem low 
frequency (LF) mode gehst du dierkt auf das interne clock netzwerk und 
somit auf die IO FF's. Timing wie gehabt.
Im high frequency (HF) mode gehst du über die DCM und kompensierst damit 
die internen delays des clocktrees. Bzw. es wäre auch denkbar den 
feedback pfad der DCM über einen bidirectionalen buffer nach außen zu 
legen um auch die delay schwankungen der output buffer zu kompensieren.
Umschalten zwischen LF und HF mode kannst du ab der min. arbeitsfrequenz 
der DCM's

Wenn deine 6ns c2o bisher aus 2ns clocktree und 4ns output buffer 
bestanden dann kommst du so auf 4 ns. Wenn deine zahlen worst case 
waren, dann werden sie bei zimmertemperatur noch besser sein.

Ottmar

Lothar Miller schrieb:
>> gehst du über die DCM
> So ein DCM ist aber recht allergisch gegen variable Takte. Der wird
> nicht schon nach 1-2 Takten wieder eingeschwungen sein...

Für frequenzsprünge absolut richtig. Aber eine gewisse "langsame" 
frequenzänderung können sie ab. Was die DCM's hier mitmachen kann der TO 
ja mal analysieren. :-)

@ Lothar Miller & Ottmar
Vielen Dank für die Ideen!

> Du könntest also mit einem konstanten Datenversatz um 1 oder 2 Takte
> leben?
Ja. Und der darf sich bei Frequenzwechsel auch gelegentlich um 1-2 Takte 
verschieben (solange Hysterese vorhanden, d.h. die Änderung der Freq um 
einen kleinen Betrag hin und zurück darf nicht dazu führen, dass der 
Versatz sich vor und zurück ändert; das darf nur bei großen Änderungen 
passieren).

>> Je nach Eingangs-Takt wählt der FPGA dann unterschiedliche IBUF DELAY
>Funktioniert das bei einem Takteingang überhaupt?
>
Technisch kein Problem. Ich kann entweder einen IBUFG oder einen 
IBUF_DLY_ADJ an einem GCLK-Input verwenden.

Mit anpassparer delay kann mann dann einen BUFG nachschalten um wieder 
aufs globale clock netz zu kommen. Verlängert natürlich die Zeit; 
insgesamt clock-to-output ca. 10ns laut Simulation.

> Für frequenzsprünge absolut richtig. Aber eine gewisse "langsame"
> frequenzänderung können sie ab.
...genau das ist meine Angst: Dass mir die DLL bei den durch die 
Regelschleife verursachten kleinen Taktänderungen raus fliegt und das 
wäre nicht akzeptabel. Und die schwingt dann auch nicht schnell ein 
sondern muss laut Datenblatt vollständig zurückgesetzt werden.

> Und Taktfrequenz bis 0 Hz mag die DCM auch nicht !
Genau, allerdings für Frequenzen unterhalb der DCM-Minimalfrequenz (5 
MHz) kann das Design locker ohne irgendwelche zusätzlichen Vorkehrungen 
arbeiten.

@Ottmar
> Du brauchst zwei clock modes und einen clock switch. In einem low
> frequency (LF) mode gehst du dierkt auf das interne clock netzwerk und
> somit auf die IO FF's. Timing wie gehabt.
> Im high frequency (HF) mode gehst du über die DCM und kompensierst damit
> die internen delays des clocktrees.
>
Das ist ein ganz interessanter Ansatz... kombiniert Frequenzzähler und 
DLL. Nicht ganz so "murksig" wie der ursprüngliche Freqzähler-Ansatz. 
Wie gesagt, kann aber sein, dass die DLL öfters rausfliegt und das wäre 
nicht gut. Aber vielleicht kann man durch manuelles Anpassen der 
Verzögerung in der DLL was erreichen.

- Mad Physicist