Lattice Diamond: asynchrone Taktübergänge constrainen

Der Fehler rührt m.E. daher, daß P&R der Meinung ist, er müßte da ein 'normales' Signal über die primären Taktleitungen führen:

"Müße" oder "muss" ?! Manchmal ist der Code halt so geschrieben, das für das Synthesetool das Ganze ein Takt ist (wenn beispielsweise in VHDL mit dem Attribut 'event oder äähnlichem gearbeitet wird. Also möglicherweise liegt das Problem nicht in den constraints sondern im "Logik-code."

Set_false_path ist bei CDC eigentlich immer die Standardmethode. Und ja manchmal bekommt man das log nie warningsfrei.

in dem report oben scheint mir der skew zu hoch, vielleicht ungünstig gelgenen Eingangpins benutzt und die nicht gleich am Pad abgetaktet? Vielleicht ist auch der Baustein tatsächlich zu langsam für das Design.

Es gibt mehrere Taktdomänen (und verschiedene Taktquellen, inkl.

umschalten),

"Takt umschalten" galt/gilt als inherent "unsauber". Xilinx hat extra glitchfreie Taktumshalter (BUFGMUX o.ä.) fur sowas eingeführt. Ansonsten heisst es eben mit wenigen takten und dafür mit CE arbeiten. Da könnte was hilfreiches stehen: https://www.mikrocontroller.net/attachment/314042/MachXO2sysCLOCKPLLDesignandUsageGuide.pdf

Wenn ich mich dunkel erinnere, habe ich solche Probleme mit 'BLOCK PATH'-Anweisungen im *.lpf ausgemerzt. Genauer: https://www.latticesemi.com/support/answerdatabase/1/9/6/1964

Kann aber sein, dass man da noch explizite Clock-Gruppen fuer die betreffenden Pins definieren musste.

Bradward B. schrieb:

"Takt umschalten" galt/gilt als inherent "unsauber". Xilinx hat extra glitchfreie Taktumshalter (BUFGMUX o.ä.) fur sowas eingeführt.

Bei Lattice gibt es dafür den Dynamic Clock Mux (DCMA).

Die Taktumschaltung funktioniert (es wird geprüft, ob der externe Takt 'im Rahmen' ist und wenn ja, schalte ich um, sonst auf 'Reservetakt'). Nur wie Lattice da mit den Constrainerei umgeht, sehe ich nicht.

Also möglicherweise liegt das Problem nicht in den constraints sondern im "Logik-code."

Ja, gut möglich. An der Stelle ist ein Latch, wo auf der steigenden Flanke vom externen SPI chip-select die Daten (data_out) für's restliche Design validiert werden. Die Enable-Signale sind einsynchronisiert, weil der SPI-Master für mich asynchron ist.

Wo und wann welches Constraint (sdc/ldc/lpf) verwendet oder ignoriert wird, ist (für mich) immer noch recht undurchsichtig.

Auch die aktuellen Zahlen aus dem Report sind ungewöhnlich. Erst ist der NBR router der Meinung alles ist ok:

1

NBR Summary

2

-----------

3

  Number of unrouted connections : 0 (0.00%)

4

  Number of connections with timing violations : 0 (0.00%)

5

  Estimated worst slack<setup> : 0.305ns

6

  Timing score<setup> : 0

7

-----------

8

Notes: The timing info is calculated for SETUP only and all PAR_ADJs are ignored.

Aber nur für die Setup-Zeiten.

Der timing score passt auch, nur die hold-Zeiten (noch) nicht:

1

Completely routed.

2

End of route.  5844 routed (100.00%); 0 unrouted.

3

4

Hold time timing score: 16, hold timing errors: 9

5

6

Timing score: 0 

7

8

Dumping design to file design.ncd.

9

10

PAR_SUMMARY::Run status = Completed

11

PAR_SUMMARY::Number of unrouted conns = 0

12

PAR_SUMMARY::Worst  slack<setup/<ns>> = 0.305

13

PAR_SUMMARY::Timing score<setup/<ns>> = 0.000

14

PAR_SUMMARY::Worst  slack<hold /<ns>> = -2.982

15

PAR_SUMMARY::Timing score<hold /<ns>> = 16.021

16

PAR_SUMMARY::Number of errors = 0

17

18

Total CPU  time to completion: 13 mins 42 secs 

19

Total REAL time to completion: 13 mins 46 secs 

20

21

par done!

...

Martin S. schrieb:

Genauer: https://www.latticesemi.com/support/answerdatabase/1/9/6/1964

Danke! Das werde ich noch ausprobieren.

Martin S. schrieb:

Wenn ich mich dunkel erinnere, habe ich solche Probleme mit 'BLOCK PATH'-Anweisungen im *.lpf ausgemerzt. Genauer: https://www.latticesemi.com/support/answerdatabase/1/9/6/1964

Super!

Damit hat es jetzt geklappt, der Timing-Report ist 'sauber':

1

NBR Summary

2

-----------

3

  Number of unrouted connections : 0 (0.00%)

4

  Number of connections with timing violations : 0 (0.00%)

5

  Estimated worst slack<setup> : 0.907ns

6

  Timing score<setup> : 0

7

-----------

8

Notes: The timing info is calculated for SETUP only and all PAR_ADJs are ignored.

9

10

...

11

12

End of route.  5787 routed (100.00%); 0 unrouted.

13

14

Hold time timing score: 0, hold timing errors: 0

15

16

Timing score: 0

Im report summery (Bild) kann man sehen, ob die Constraints für die Takte richtig sind. Die Takt-Constraints habe ich momentan im ldc-File stehen.

Die Pfad-Constraints stehen wie empfohlen im lpf-File.

1

BLOCK PATH FROM CLKNET "CLK_A" TO CLKNET "CLK_B" ;

Um die richtigen Namen zu finden such man im Timing Analysis View nach roten Einträgen. Die Instanznamen (in Klammern) können direkt im lpf eingesetzt werden.

Danke!

Rick D. schrieb:

Wo und wann welches Constraint (sdc/ldc/lpf) verwendet oder ignoriert wird, ist (für mich) immer noch recht undurchsichtig.

Modulo allmaehlich einsetzende Demenz :-) :

• SDC: Synthese-relevante Constraints fuer Synplify
• LDC: Dito fuer LSE
• LPF: Constraints post-map fuer PnR (Ort und Zeit)

Die ersten beiden gelten also entweder oder je nach eingesetzter Synthese-Option. Zumindest war das bis v3.12 so.