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
Du kannst ein Timing Ignore Constraint verwenden.
Ah, damit bin ich schon weiter gekommen und hab jetzt herausgefunden, dass man asynchrone Clock-Groups definieren kann per zB.
1 | 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
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
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.
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.
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?
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.
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.
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
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?
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
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).
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 :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.