Forum: FPGA, VHDL & Co. Frage zu Setup & Hold verschiedener Clock-Domains


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


Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen,

ich versuche gerade einen eigenen VHDL-Core in ein Cyclone5 SoC zu 
integrieren.

Der Avalon-Slave-Bus läuft auf 50MHz, was für meinen Core zu langsam 
ist.

Ich hatte deshalb eine PLL instanziiert, die einen weiteren 50MHz auf ca 
180MHz erhöht.

Zwischen dem Slave-Interface (Adress- und Kommando-Dekoder läuft auf 
50MHz) und dem schnellen Core werden nur 4 Signale ausgetauscht, die ich 
synchronisiert habe (im wesentlichen ein Start-Signal und den Status des 
schnelleren Cores).

Die eigentlichen Daten, die dann über das Slave-Interface ausgelesen 
werden ändern sich nicht mehr, sobald eins der synchronisierten Signale 
sagt:"ich bin fertig". Bei der Datenübergabe ist es das gleiche, bis das 
Start-Signal gegeben wird, wurden die Daten schon lange hochgeladen und 
ändern sich nicht mehr.

Ich frag mich nun ... Das Synthese-Tool kann nichts davon wissen, dass 
es da keine Setup & Hold Zeiten einhalten muss, weil es nicht wissen 
kann, dass ich diese Daten nur abfrage, wenn sie sich quasi nicht mehr 
ändern.

Hat jemand eine Idee, ob das problematisch für die Synthese ist und wie 
man Constraints setzen kann, um Setup & Hold für diese Daten quasi zu 
deaktivieren?

Oder sollte man das über ein Fifo oder Dual-Port-Ram (irgendwie) ziehen 
und das Synthese-Tool wäre damit zufriedener?

Viele Grüße,
Mampf

: Bearbeitet durch User
von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Du kannst ein Timing Ignore Constraint verwenden.

von Da D. (dieter)


Bewertung
0 lesenswert
nicht lesenswert
auch set_false_path genannt ;-)

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ah, damit bin ich schon weiter gekommen und hab jetzt herausgefunden, 
dass man asynchrone Clock-Groups definieren kann per zB.
set_clock_groups -asynchronous -group {clk_A} -group {clk_B}

Perfekt, das werde ich ausprobieren :)

Danke für den Schubser in die richtige Richtung!

*edit*: wobei das wohl die messy-Lösung ist. Aber mal kucken^^

: Bearbeitet durch User
von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Was ist daran schlimm? Nur du kannst wissen, wie das Timing zueinander 
ist und sorgst für einen geregelten Domänenübergang. Und das sagst du 
damit der Toolchain: sie muss nicht nach dem zeitlichen Zusammenhang 
schauen.

: Bearbeitet durch Moderator
von Erik B. (erik_b976)


Bewertung
0 lesenswert
nicht lesenswert
Idealerweise fügst du neben den false-pathes noch max-delays hinzu.

Denn auch die tollste Umsynchronisierung sollte irgendwann mal fertig 
werden und ohne irgendwelche constraints hat er keine Veranlassung da 
irgendetwas zu buffern oder zu beschleunigen.

von Blechbieger (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Asynchrone Clock-Groups halte ich für riskant da man in komplexen 
Designs oder bei späteren Erweiterungen leicht zu viele Pfade 
abschneidet.

Lieber den CDC Report in TimeQuest anschauen und alle Signale dort falls 
noch nicht geschehen synchronisieren oder wenn schon synchronisiert mit 
set_false_path oder set_multicycle_path deaktivieren.

von Andreas F. (chefdesigner)


Bewertung
-1 lesenswert
nicht lesenswert
Wie sollte das passieren? Ich meine, wenn ein Signal aus einer Domain 
kommt, hat es ohnehin keinen Bezug zu einer neuen Domain. Jeder Versuch, 
des Synthesizers dort Bezüge herzustellen, muss scheitern. Signale, die 
man in der neuen Domain zielsicher benötigt und bei denen keine spikes 
erlaubt sind, muss man in jedem Fall einsynchronisieren und damit ist 
das Problem gelöst. Ob man dem Synthesizer das noch mitgibt oder nicht, 
ist nur eine Frage der Einfachheit der Betrachtung.

Da kann nichts anderes bei rauskommen.

Welche Signale sollten denn von so einem Ausschluss betroffen sein, oder 
anders gefragt, welche sollten profitieren, wenn man sie nicht pauschal 
ausschließt?

von Blechbieger (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Wenn du sicher bist dass du alle Signale die Taktgrenzen kreuzen 
synchronisiert hast, ja dann kannst du guten Gewissens asynchrone 
Taktgruppen benutzen. Mir ist es aber schon öfters passiert dass ich in 
FSM versehentlich Signale aus anderen Taktdomänen benutze und vergesse 
sie zu synchronisieren. In der Simulation macht das ja keine Probleme. 
Im CDC Report bekommt man die dann schön angezeigt.

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Blechbieger schrieb:
> Mir ist es aber schon öfters passiert dass ich in
> FSM versehentlich Signale aus anderen Taktdomänen benutze und vergesse
> sie zu synchronisieren.
Das wäre dann also die Synthese als Designhilfe misbraucht ;-)

Andi F. schrieb:
> ist nur eine Frage der Einfachheit der Betrachtung.
> Da kann nichts anderes bei rauskommen.

Technisch ja, aber die Synthesen arbeiten ja meistens in der 
delay-Zeit-gesteuerten Platzierung und dabei ist so, dass eine Vorgabe 
der MAX-Zeit der Synthese helfen kann. Der weitere und gfs wichtigere 
Punkt ist, dass durch ein ausdrückliches constraint immer formell 
festgelegt werden kann, wie ein design arbeiten muss. Die Software kann 
das dann prüfen und bestätigen. Ohne diese Angabe geht das nicht.

In den Fällen, in denen richtigerweise ein Signal nicht nach einer 
dedizierten Zeit zur Verfügung steht, sondern wie vermutet, allein durch 
routing und resource-Verfügbarkeit irgendwann schon stabil sein wird, 
ist es in der Tat egal.

In den Fällen, in denen fälschlicherweise ein Signal dann zu spät zur 
Verfügung steht, wie bei Bussen, wäre es nur dann egal, wenn die 
entstehende Inkonsistenz akzeptabel ist. Klassisches Beispiel sind 
Konfigurationsparameter aus einer Wertebank, die von Außen irgendwann 
geschrieben werden und das System umschalten. Die Daten werden dann so 
oder so inkonsistent und haben eine Unterbrechung.

In den anderen Fällen, muss synchronisiert werden und durch die Vorgabe 
eines MAX-Delays kann in gewissen Grenzen steuern, dass Busse nicht 
soweit auseinander laufen, dass die Daten inkonsistent werden, sondern 
nur der Zeitpunkt undefiniert bleibt. D.h. ein Parameter aus einer 
solchen Bank führt beim Umschalten durch einen User nicht zu einem 
Sprung mit falschen spikes sondern nur zu einem Übergang von einem 
gültigen Zustand zu einem anderen Zustand.

Schönes Beispiel: Manuelle Steuerung eines MIDI-Parameters über ein 
Poti. Man dreht in Humangeschwindigkeit von 10% auf 100% und der Filter 
morphed schön weich herunter, obwohl IIR-Filter sehr empfindlich sind 
gegenüber Parameteränderungen. Im ungünstigsten Fall springt aber der 
Wert von 127 nicht auf 128 sondern auf 255 und dann auf 128, weil das 
MSB zu früh erwischt wurde und die Abfrageschleife eine Weile braucht, 
um wieder diesen asynchronen Port zu erwischen. Dann hat man mehrere ms 
lang einen falschen Parameter und hört einen Mist.

Lösung: Max-constraint, doppelt Sychronisieren und eine 
Plausibilitätsabfrage (2 Folgewerte stabil ?). Dann klappt es auch mit 
dem Sound. Mein erster Synthie vor 15 Jahren hatte so einen Defekt und 
ich musst ein wenig suchen, um zu kapieren, was da passiert. Eigentlich 
sollte ein FPGA der permanent synched, so schnell sein, dass da nichts 
passiert, aber es gibt auch eine Fehlerfortpflanzung in das design durch 
die Optimierungen. Die Geschichte entspricht ein wenig dem Problem mit 
dem im Design verteilten Reset, den wir hier schon mehrfach diskutiert 
hatten, welche trotz Synchronisation zu Fehlern führt, weil die Funktion 
breitgerechnet wird.

Die Thematik scheint in der Tat nicht jedem geläufig und ist ein gern 
genommenes Problem. Es gibt aktuell im Markt lustigerweise einen 
FPGA-basierten Synthesizer, der genau diese Macke zu haben scheint. Auch 
bei gesteuerten Übergängen aus der DAW mit konsistenten Parametern 
produziert das Gerät einen Filtersprung an Stellen, wo nichts hörbares 
passieren sollte.

von Mampf F. (mampf) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Da der Thread noch aktiv ist ... :)

Ich hab den PLL-Clock auf asynchron gesetzt und die 4 wichtigen 
Steuersignale synchronisiert.

Die eigentlichen Daten, die zum Core gehen bzw vom Core kommen, sind 
quasi statisch wenn sie über die 4 Steuersignale übernommen werden.

Das Resultat war ein voller Erfolg ... Statt dümpelige 120MHz erreicht 
der Core (sogar in 4 facher Instanziierung) 175MHz und funktoniert 
einwandfrei :) Das FPGA ist nun zu 85% voll (das ist vom DE10 nano der 
Cyclone 5, in dem auch noch die Fabrik für die Dual-Arms dazu 
synthetisiert wird).

Hat also super geklappt :)

: Bearbeitet durch User
von Andreas F. (chefdesigner)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Ich hab den PLL-Clock auf asynchron gesetzt und die 4 wichtigen
> Steuersignale synchronisiert.
Bist Du sicher, dass er dann diese Signale überhaupt verfolgt und 
überprüft hat?

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Andi F. schrieb:
> Mampf F. schrieb:
>> Ich hab den PLL-Clock auf asynchron gesetzt und die 4 wichtigen
>> Steuersignale synchronisiert.
> Bist Du sicher, dass er dann diese Signale überhaupt verfolgt und
> überprüft hat?

Das ist egal ... Dafür hat man die Synchronisierung, damit aus 
nicht-passenden Signalen wieder passende zu der jeweiligen Clock-Domain 
gemacht wird :)

: Bearbeitet durch User
von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Das ist egal ... Dafür hat man die Synchronisierung, damit aus
> nicht-passenden Signalen wieder passende zu der jeweiligen Clock-Domain
> gemacht wird :)

Ganz so einfach ist es nun auch wieder nicht...

Wenn Du (egal wie) die Timing-Pfade auftrennst, weiss der Fitter zwar, 
dass die Clocks asynchron, aber nicht, dass dir die Signallaufzeiten für 
die Synchronisierung zwischen den Clock Domains enorm wichtig sind.

Er ist also frei, die Übergänge zwischen den Clock Domains quer über den 
ganzen Chip zu ziehen (und wird das, insbesondere wenn's platzmässig eng 
wird, wahrscheinlich auch tun).

Wenn Du das optimieren willst, musst Du mit set_max_delay rumfummeln 
(und das ist ein gewaltiger Mist, nach meiner Erfahrung).

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Wenn Du (egal wie) die Timing-Pfade auftrennst, weiss der Fitter zwar,
> dass die Clocks asynchron, aber nicht, dass dir die Signallaufzeiten für
> die Synchronisierung zwischen den Clock Domains enorm wichtig sind.

Das setzt voraus, dass die Signallaufzeiten enorm wichtig sind?

Bei meiner Anwendung ist es egal, ob das eine oder andere Signal 10ns 
später kommt.

Die Signale haben auch keinen zeitlichen Bezug zueinander, der 
eingehalten werden muss.

Wäre das anders, hätte ich da schon größere Bedenken :)

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.