Lattice Diamond: asynchrone Taktübergänge constrainen

[Rick D. (rickdangerus)]

Ich habe hier ein Design für einen MachXO2, wo im 'Timing Analysis View' 
Fehler angezeigt werden:

Error: The following path exceeds requirements by 7.116ns
 
 Logical Details:  Cell type  Pin type       Cell/ASIC name  (clock net +/-)

   Source:         FF         Q              gpio_i0/receive_data_23__I_0_153_i3  (from gpio_i0/data_out_23__N_372 +)
   Destination:    FF         Data in        mylogic_i0/stamper_i0/r.stage_2_state__i4  (to clk_fast +)

   Delay:               4.297ns  (30.6% logic, 69.4% route), 3 logic levels.

 Constraint Details:

      4.297ns physical path delay SLICE_92 to mylogic_i0/stamper_i0/SLICE_312 exceeds
      8.351ns delay constraint less
      9.371ns skew and
      1.649ns feedback compensation and
      0.150ns DIN_SET requirement (totaling -2.819ns) by 7.116ns

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:

The following 6 signals are selected to use the primary clock routing resources:
    clk_ext  (driver: dcma_i0, clk load #: 1)
    clk_fast (driver: pll_i0/PLLInst_0, clk load #: 162)
    clk_slow (driver: pll_i0/PLLInst_0, clk load #: 285)
    clk_spi  (driver: extern_SPI_CLK, clk load #: 146)
    clk_osch (driver: osch_i0, clk load #: 25)
    gpio_i0/data_out_23__N_372 (driver: SLICE_736, clk load #: 10)

Für das letzte Signal in der Liste werden sich dann zusätzliche 
Constraints ausgedacht, die nicht erfüllt werden (können).
Auch an anderer Stelle gibt es timing-Fehler.

Ich habe jetzt schon mehrere Varianten ausprobiert:
- im ldc: set_false_path
- im ldc: create clock_groups -asynchronous "..."
- im lpf: PROHIBIT PRIMARY NET "..."

Mit keiner Methode bekomme ich meinen Post-P&R-Timing-Report sauber.

Die Frequenzen (bzw. Periodendauern) der externen Takte sind angegeben. 
Für die Takte aus der PLL (clk_fast + clk_slow) werden automatisch die 
richtigen Constraints erstellt.

Es gibt mehrere Taktdomänen (und verschiedene Taktquellen, inkl. 
umschalten), so daß die Signalübergänge asynchron sind. Ich bekomme es 
dem Tool aber nicht so recht verklickert.

Hat da jemand eine Idee?

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

> 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

[Martin S. (strubi)]

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.

[Rick D. (rickdangerus)]

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:

NBR Summary
-----------
  Number of unrouted connections : 0 (0.00%)
  Number of connections with timing violations : 0 (0.00%)
  Estimated worst slack<setup> : 0.305ns
  Timing score<setup> : 0
-----------
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:

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

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

Timing score: 0 

Dumping design to file design.ncd.

PAR_SUMMARY::Run status = Completed
PAR_SUMMARY::Number of unrouted conns = 0
PAR_SUMMARY::Worst  slack<setup/<ns>> = 0.305
PAR_SUMMARY::Timing score<setup/<ns>> = 0.000
PAR_SUMMARY::Worst  slack<hold /<ns>> = -2.982
PAR_SUMMARY::Timing score<hold /<ns>> = 16.021
PAR_SUMMARY::Number of errors = 0

Total CPU  time to completion: 13 mins 42 secs 
Total REAL time to completion: 13 mins 46 secs 

par done!

...

Martin S. schrieb:
> Genauer: https://www.latticesemi.com/support/answerdatabase/1/9/6/1964
Danke! Das werde ich noch ausprobieren.