Hallo zusammen!
Ich erstelle ein Design und arbeite mit dem Entwicklungsboard Hpe-mini
von Gleichmann Electronics Research.
Im Place & Route report werden bei Frequency-Preference Timing-Fehler
gemeldet(siehe unten). Dabei erscheint ein delay-constraint von 5.0 ns.
Woher kommt dieser Wert? Ich habe ein Tutorial durchgearbeitet und da
wurde ein constraint selbst festgelegt und dann wurde nach PAR Pfade
gemeldet, die nicht hinkommen. Aber in meinem Design habe ich keine
delay-constraints eingegeben und frag mich woher dieser Wert von 5 ns
kommt. Steht der Wert in irgend einem Zusammenhang mit der Frequenz 100
MHz?
Für jede Art von Hilfe bin ich sehr dankbar!
hallo,
also ich kenn mich da nicht so gut aus aber ich kann dir ja von meinen
erfahrungen berichten.
ich habe festgestellt, dass dieses delay grösstenteils aus einer
zusammenschaltung von kombinatorik kommt. je länger der kombinatorische
pfad is desto mehr delay hast du.
ich habe daraufhin mache pfade zwischen getaktet. damit habe ich die
pfade aufgetrennt. mein design läuft normalerweise mit 25mhz. für den
systemtakt habe ich im design planner eine frequenz von 100mhz
angegeben. damit will ich das routing verbessern und bin mir, meiner
meinung nach sicher, dass das design auch mit 25mhz läuft.
wenn das ein unkritischer pfad ist dann kannst du ihn aus dieser
timing-synthese nehmen und er wird nicht geprüft. das mach ich bei mir
bei solchen pfaden, bei denen ich mir sicher bin das die signale zur
zeit des eintaktens auf jedenfall anliegen.
Design Planner -> Spreadsheed View -> Block.
dort kannst du die signale auswählen die unkritisch sind.
soweit meine beobachtungen. für korrekturen bin ich offen :-). würde mir
auch weiterhelfen.
aber ich hoffe dass alles soweit richtig ist.
mfg
Andi
Angenommen Dein Tool nimmt 100 MHz an (vielleicht ein default, oder Du
hast es angegeben), dann sind das 10 ns Periodendauer.
Wenn Du nun vom Ausgang eines FFs das mit fallender Flanke arbeitet
spi_master_c/n_status_2 (from pll_clock -)
auf ein Signale geführt, das mit steigender Flanke arbeitet
spi_master_c_MOSI_MASTERio (to pll_clock +)
--> dann hast Du 5 ns constraint.
Besten Dank für die Antworten!!!
Andi Z. schrieb:> ich habe festgestellt, dass dieses delay grösstenteils aus einer> zusammenschaltung von kombinatorik kommt. je länger der kombinatorische> pfad is desto mehr delay hast du.
Du meinst hier wahrscheinlich das reale Delay im Signal. Diese 5.0 ns
sind aber ein Delay-Constraint, also eine Einschränkung, die sich das
Tool vorgibt und der die Signale aller Pfade nach dem Place and Route
genügen müssen. So verstehe ich das.
Andi Z. schrieb:> wenn das ein unkritischer pfad ist dann kannst du ihn aus dieser> timing-synthese nehmen und er wird nicht geprüft. das mach ich bei mir> bei solchen pfaden, bei denen ich mir sicher bin das die signale zur> zeit des eintaktens auf jedenfall anliegen.> Design Planner -> Spreadsheed View -> Block.> dort kannst du die signale auswählen die unkritisch sind.
Und wie kann man von einem Signal sicher wissen, dass es zum Zeit des
Eintaktens auf jeden Fall anliegt. Ist nicht gerade das die Aufgabe
dieser automatischen Timing-Analyse, zu prüfen ob die Signale zur
richtigen Zeit anliegen und zu melden, wenn das nicht der Fall ist. Ich
habe in dem oben erwähnten Tutorial gesehen, dass asynchrone Signale
(z.B. asynch. Reset) in dieser Block-Preference aus der Timing-Analyse
ausgeschlossen werden sollen, weil sie ja vom Takt unabhängig sind.
Klaus Falser schrieb:> Wenn Du nun vom Ausgang eines FFs das mit fallender Flanke arbeitet> spi_master_c/n_status_2 (from pll_clock -)>> auf ein Signale geführt, das mit steigender Flanke arbeitet> spi_master_c_MOSI_MASTERio (to pll_clock +)>> --> dann hast Du 5 ns constraint.
Das klingt ziemlich einleuchtend! Die Zeichen +/- bei pll_clock bedeuten
also, steigende/fallende Flanke. Und ich habe gerätselt, wie ich das
verstehen soll. Eigentlich arbeite ich in diesem Design nur mit
steigenden Flanken, darum verstehe ich nicht warum die syntetisierte
Schaltung FF mit fallender Flanke verwendet. Ich verwende allerdings
Reference Disigns von Lattice und die habe ich mir nicht sehr gründlich
durchgeschaut. Normal muss das doch immer im Code zu finden sein, wenn
irgend wo FFs verwendet werden, die mit fallender Flanke getaktet sind,
oder? Oder kann das auch sonst wie zustande kommen?
hallo,
ja stimmt. ich meinte damit auch die asynchronen signale. ich habe hier
allerdings auch andere signale wie z.B die lese-adressen für den ram.
hier habe ich z.B. 160-320ns für eine taktperiode. da kann ich mir
sicher sein dass die adresse, die mit der fallenden flanke generiert
wird, keine 80-160 ns benötigt um am ram an zuliegen. die adressen
werden zwar durch kombinatorik erzeugt und haben ein delay, aber zum
zeitpunkt des auslesens sind die adressen am ram.
mfg
Andi
noips schrieb:> ie Zeichen +/- bei pll_clock bedeuten> also, steigende/fallende Flanke. Und ich habe gerätselt, wie ich das> verstehen soll.
Das ist nur eine Vermutung von mir, da ich die Lattice Tools nicht
kenne.
Allerding wäre es plausibel.
Klaus Falser schrieb:> Das ist nur eine Vermutung von mir, da ich die Lattice Tools nicht> kenne.> Allerding wäre es plausibel.
Die Vermutung hat gestimmt. Ich habe die kritische Stelle jetzt
gefunden, dank deinem Hinweis! Außerdem verstehe ich jetzt, wie dieses
delay-constraint zustande kommt. Ich dachte mir, dass das mit der
Frequenz zu tun haben wird, aber ich fragte mich wieso nicht 10 ns
(Periodendauer eben) sondern 5 ns. Die fallende Flanke ist die
Erklärung. Die Stelle ist in dem Reference Design von Lattice, dass ich
fertig heruntergeladen habe. Das ist eine State-Machine, bei der
next_state bei fallender Flanke zugewiesen wird und dann erfolgt bei der
nächsten steig. Flanke die Zuweisung "current_state <= next_state". Aber
das Signal MOSI, das im geposteten Report erscheint ist auch von
next_state abhängig und darum ist der Abstand zwischen fallende und
steigende Flanke hier entscheidend.
Vielen Dank! Dein Hinweis hat mich weiter gebracht!
