Timing Analysis Improvements meta-issue

[daveshah1]

This is to track some of the things that a new timing analysis engine in nextpnr needs:

• hold time analysis and satisfaction (by making routes longer/inserting feed-through LUTs)
• min/max delay, false paths and multicycle paths between:
  • two clock domains
  • a "wildcard" and a start or end pin
  • a clock domain and a start or end pin
  • possibly between two arbitrary pins but this may adversely affect efficient STA implementations
• IO timing constraints
  • setup/hold and clock-to-out relative to a clock input or output
  • skew
  • combinational delay between pins
  • needs icestorm/trellis improvements for better IO timing data (IO type/voltage/capacitance(?) dependence)
• Timing constraint inputs
  • at least Python API, vendor format (perhaps generic SDC parser for this)
• Improved timing reports
  • multiple failing paths per clock domain
  • inter clock domain delays
  • IO timing as above
  • need a way to configure what is reported, and more advanced reporting (perhaps HTML/JSON/whatever output as well as just dumping to the CLI)
• Speed up timing analysis as it bottlenecks timing-driven placement
  • based on #289

[mithro]

FYI We are working on plugins for Yosys which read the SDC / XDC constraints into attributes values (the same ones which could be used to specify these constraints directly on Verilog primitives) and writes them back out.

[mithro]

https://github.com/SymbiFlow/yosys-symbiflow-plugins

[whitequark]

I've looked at the XDC plugin. I think the overall approach is fine but it should not reuse the Yosys pass infrastructure to introduce Tcl commands scoped to that one plugin.

[daveshah1]

Having at least some support for constraints in Yosys could be tempting, as it might make sense to make different synthesis decisions in some cross clock situations.

[mithro]

@daveshah1 - I don't think @whitequark is complaining about having the constraints in Yosys -- @whitequark is complaining about the very hacky way we are using the TCL parser in the plugin.

@daveshah1 - Yes, having the timing constraints in synthesis will be eventually important for things like retiming and optimizing for area.

[whitequark]

(I think @daveshah1 was agreeing with me? Anyway, yeah, totaly in favor of having an SDC parser in Yosys)

[daveshah1]

It was a more general point about moving the constraints to Yosys where possible, the exact implementation would need refining. Perhaps we should have an SDC/XDC bindings library with generic callbacks that could be glued to both Yosys and nextpnr (for doing during-PnR stuff with it too).

[whitequark]

I recall seeing such a library somewhere already... @mithro might know?

[daveshah1]

There's one in VPR but I don't know whether it has enough capabilities for a more generic constraints system

[mithro]

The VPR parser is at https://github.com/kmurray/libsdcparse

[whitequark]

Ah yes that's the one I was thinking of. I like that approach much better than using the Tcl interpreter for a few reasons; I know Xilinx also doesn't parse SDC/XDC files with Tcl.

[mithro]

On the argument of TCL interpreter verse custom paser thoughts, see https://github.com/SymbiFlow/symbiflow-arch-defs/pull/1581#discussion_r452352318

[mithro]

Hrm, I think I actually meant to link https://github.com/SymbiFlow/symbiflow-arch-defs/pull/1581

[litghost]

I know Xilinx also doesn't parse SDC/XDC files with Tcl.

100% agree. However I do want to point out some suprising things. We do know Vivado supports some form of variable replacement and function expansion in XDC (https://github.com/SymbiFlow/symbiflow-arch-defs/pull/1581#discussion_r452328691). For example:

set net [get_nets clk]
set route  [list  [get_nodes -of_object [get_wires CLBLM_R_X25Y92/CLBLM_M_C]] CLBLM_R_X25Y92/CLBLM_M_CMUX CLBLM_R_X25Y92/CLBLM_LOGIC_OUTS22 INT_R_X25Y92/NL1BEG_N3 INT_R_X25Y92/FAN_ALT1 INT_R_X25Y92/FAN_BOUNCE1 INT_R_X25Y92/BYP_ALT4 INT_R_X25Y92/BYP4 CLBLM_R_X25Y92/CLBLM_M_BX  ]
set_property FIXED_ROUTE $route $net

does work in a XDC file. if statements do not work.

In general, I agree that using a general purpose TCL parser is unsuitable compared with a specialized SDC and / or XDC parser. However Vivado's XDC support has some things that look a lot like a TCL subset than what you'd expect from a simple file parser.

[whitequark]

However Vivado's XDC support has some things that look a lot like a TCL subset than what you'd expect from a simple file parser.

Yes, you're right. Now that you mention it, I noticed some of this behavior, but did not correctly attribute it.

In general, I agree that using a general purpose TCL parser is unsuitable compared with a specialized SDC and / or XDC parser.

I wouldn't say that it's "unsuitable". I would prefer a specialized SDC/XDC parser, but I would also accept a Tcl-based SDC/XDC parser that disables most commands, similar to what Vivado does.

[litghost]

In general, I agree that using a general purpose TCL parser is unsuitable compared with a specialized SDC and / or XDC parser.

I wouldn't say that it's "unsuitable". I would prefer a specialized SDC/XDC parser, but I would also accept a Tcl-based SDC/XDC parser that disables most commands, similar to what Vivado does.

Ah, I misunderstood. I believe I got your position now. Thanks.

[Aaron-Hartwig]

We've been using nextpnr for our designs at Oxide and are very interested in the capabilities outlined at the top of this issue. What is the best way to help their development?

[rowanG077]

@Aaron-Hartwig

I have started working on this recently under the supervision of @gatecat. Right now I have build a simple SDC parser and working on having False paths. From there I will go on implementing the other constraints and depending how much time/progress I have I will also look into hold times and some other things on the list.

Please let us know what you guys are missing the most. I can't promise I will prioritize it but I will try anyway.

[Aaron-Hartwig]

@rowanG077 - awesome! I think we care most about the first three points, and if I was to attempt some sort of priority on that it would be:

1. IO timing constraints
2. min/max + false path + multipath
3. hold times

I don't put a ton of value in that priority list since each piece is important in its own right.

I can't promise I will prioritize it but I will try anyway.

No worries! Let me know if/how I can support this work. Admittedly I'm unfamiliar with the codebase, but I can also help with testing and feedback.