ispLever: Bedeutung und Ursprung eines delay-constraints

[noips (Gast)]

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!

================================================================================
Preference: FREQUENCY NET "pll_clock" 100.000000 MHz ;
            1084 items scored, 3 timing errors detected.
--------------------------------------------------------------------------------


Error:  The following path exceeds requirements by 1.657ns

 Logical Details:  Cell type  Pin type       Cell/ASIC name  (clock net +/-)

   Source:         FF         Q              spi_master_c/n_status_2  (from pll_clock -)
   Destination:    FF         Data in        spi_master_c_MOSI_MASTERio  (to pll_clock +)

   Delay:               6.613ns  (15.9% logic, 84.1% route), 3 logic levels.

 Constraint Details:

      6.613ns physical path delay spi_master_c/SLICE_62 to MOSI_MASTER_MGIOL exceeds
      5.000ns delay constraint less
      0.154ns skew and 
     -0.110ns CE_SET requirement (totaling 4.956ns) by 1.657ns

 Physical Path Details:

   Name    Fanout   Delay (ns)          Site               Resource
REG_DEL     ---     0.476    R38C16A.CLK to     R38C16A.Q0 spi_master_c/SLICE_62 (from pll_clock)
ROUTE         3     0.905     R38C16A.Q0 to     R38C16D.B1 spi_master_c/n_status_2
CTOF_DEL    ---     0.289     R38C16D.B1 to     R38C16D.F1 spi_master_c/SLICE_115
ROUTE         4     0.577     R38C16D.F1 to     R38C18C.D1 spi_master_c/un2_c_status
CTOF_DEL    ---     0.289     R38C18C.D1 to     R38C18C.F1 spi_master_c/SLICE_128
ROUTE         5     4.077     R38C18C.F1 to    IOL_R37A.CE spi_master_c_un6_c_status_4_i (to pll_clock)
                  --------
                    6.613   (15.9% logic, 84.1% route), 3 logic levels.

 Clock Skew Details: 

 Source Clock: 
           Delay              Connection
          3.389ns PLL3_R18C1.CLKOS to R38C16A.CLK     

 Destination Clock Path:

 Destination Clock:
           Delay              Connection
          3.235ns PLL3_R18C1.CLKOS to IOL_R37A.CLK    

Warning:  75.109MHz is the maximum frequency for this preference.

[noips (Gast)]

Weiß niemand was dazu?

Ich habe auch im preference file (.prf) nachgeschaut, da steht nirgends 
von 5.0ns

[Andi Z. (duderino65)]

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

[Klaus F. (kfalser)]

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.

[noips (Gast)]

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?

[Andi Z. (duderino65)]

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

[Klaus Falser (Gast)]

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.

[noips (Gast)]

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!