www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Spartan 3A mit variablem Takt - Abgefahrene Ideen gefragt!


Autor: Mad Physicist (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Folgende Situation.. die Frage ist: Kann man das Board noch retten?

FPGA hat 16bit Bus als Ausgang (LVCMOS33) und einen Clock-Eingang 
(LVCMOS33). Bei jeder steigenden Clock-Flanke soll der FPGA neue Werte 
am Bus ausgeben.

Das Clock-Signal is variabel von DC bis 250 MHz. Alles intern im FPGA 
funktioniert mit dieser Rate nur leider bekomm ich die 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).

Problem: Bei konstanter Clock 250 MHz wäre z.B. auch 10ns Verzögerung 
OK, entsprechend 2 Takte. Aber da die Clock variabel ist, gibt es dann 
Frequenzen, bei denen die Clock-Flanken die Daten-Flanken "überholen" 
(bei 10ns also 100 MHz und 200 MHz).

Irgendwelche Ideen?
DCM, wenn ja wie?
Es wäre akzeptabel, wenn beim Ändern der Frequenz 1 oder 2 Clocks 
verloren gehen.

Autor: dose (Gast)
Datum:

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

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Clock ebenfalls durchs FPGA führen. Also an einem Pin wieder ausgeben 
und die nachfolgende Schaltung mit dem verzögerten Takt betreiben.

Autor: Mad Physicist (Gast)
Datum:

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

Autor: dose (Gast)
Datum:

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

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal rekapitulieren: Der Takt geht von DC bis 250 MHz. Eine DLL, mit der 
man den FPGA-internen Takt um eine feste Zeit vorverlegen könnte, 
scheidet damit aus. Der Takt kommt von außen und vesorgt sowohl FPGA als 
auch nachgeschaltete Logik. Somit ist das Ganze ein synchrones Design 
und hat damit eine Grenzfrequenz, die sich aus der Verzögerungszeit der 
Schaltelemente zwischen zwei Flipflops mit gleicher Taktquelle 
berechnet.
Da ist nix zu machen. Punkt. Du kannst versuchen, die 
Clock-to-Output-zeit des FPGAs so gering wie möglich zu halten, aber das 
ist auch schon alles. Im übrigen stimme ich deiner Aussage unten nicht 
zu. Zitat:

=====8<-----
Problem: Bei konstanter Clock 250 MHz wäre z.B. auch 10ns Verzögerung
OK, entsprechend 2 Takte. Aber da die Clock variabel ist, gibt es dann
Frequenzen, bei denen die Clock-Flanken die Daten-Flanken "überholen"
(bei 10ns also 100 MHz und 200 MHz).
=====8<-----

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. Und selbst wenn diese nachgeschaltete Logik gegen 
Metastabilität gefeit sein sollte, kann es sein, dass sie Daten sieht, 
die das FPGA nie ausgegeben hat. So etwas kann vorkommen, weil durch 
unterschiedliche Verzögerungszeiten bei dem einen Bit schon der neue 
Wert gelesen wird und bei einem anden Bit noch der alte.

Autor: Matthias (Gast)
Datum:

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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mad Physicist (Gast)

>Das Clock-Signal is variabel von DC bis 250 MHz.

Sowas ist immer sehr sinnvoll . . .

> Alles intern im FPGA
>funktioniert mit dieser Rate nur leider bekomm ich die 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).

Du brauchst ein paar Grundlagen und eingescheites Konzept.

>Problem: Bei konstanter Clock 250 MHz wäre z.B. auch 10ns Verzögerung

Und einen Deutschkurs. Das heißt Takt.

>OK, entsprechend 2 Takte. Aber da die Clock variabel ist, gibt es dann
>Frequenzen, bei denen die Clock-Flanken die Daten-Flanken "überholen"
>(bei 10ns also 100 MHz und 200 MHz).

Womit wir wieder beim Thema Murks wären . . .

>DCM, wenn ja wie?

Gar nicht bei so dermassen sinnlos, endlos schwankenden Taktfreqeunzen.

Autor: Mad Physicist (Gast)
Datum:

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

Autor: Ottmar (Gast)
Datum:

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

Autor: Mad Physicist (Gast)
Datum:

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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> wir treffen uns dann im Deutschkurs!  - Mad Physicist
Ja, wird wohl so sein...
> Ist ja kein kommertielles Produkt.
Sowas gibt es potenziell auch gar nicht...  ;-)


> Je nach Eingangs-Takt wählt der FPGA dann unterschiedliche IBUF DELAY
Funktioniert das bei einem Takteingang überhaupt?
Oder: hast du den Lese-Takt überhaupt an einen Taktpin angeschlossen?

> Es wäre akzeptabel, wenn beim Ändern der Frequenz 1 oder 2 Clocks
> verloren gehen.
Du könntest also mit einem konstanten Datenversatz um 1 oder 2 Takte 
leben?

Autor: Ottmar (Gast)
Datum:

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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: Klaus Falser (kfalser)
Datum:

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

Und Taktfrequenz bis 0 Hz mag die DCM auch nicht !

Autor: Ottmar (Gast)
Datum:

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

Autor: Mad Physicist (Gast)
Datum:

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

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute, ihr seid ganz schön abgefahren! Gut, das war in diesem Thead auch 
die Forderung, aber trotzdem.

@ Mad Physicist

Auch wenn Du eine Lösung hinbekommst: Verhindere bitte nicht, dass 
derjenige, der das Problem verursacht hat, etwas daraus lernt. Wer auch 
immer das ist. Wie sagen doch die Briten so treffend: garbage in garbage 
out.

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.