Missing (or undocumented?) support for derived clocks

[millerresearch]

I have an ice40 design with a cpu running at 50MHz and an sdram controller running at 100MHz. The clocks are generated from the same PLL using GENCLK and GENCLK_HALF parameters and global buffers, so I'm expecting them to have minimal skew. After place & route, nextpnr reports timing PASS in spite of delays of 14+ nsec on clock-crossing paths. I'm assuming this means the clocks are being treated as asynchronous. I can insert synchronising FFs into the memory request/response handshake path, but that's a big latency cost. Is there any way to constrain nextpnr so that it will try to keep paths between the derived clock domains within the delay limit of the faster clock, and also ensure that setup+hold times are safe?

[smunaut]

Beware with assumption about the PLL clocks outputs alignements. A lot less modes are officially (by the lattice tools) than what you actually can do in yosys/nextpnr and I'm not sure there are actual specifications regarding alignements.

I have never checked GENCLK vs GENCLK_HALF but at least with SHIFTREG there are several nano-seconds of skew between outputs and I wouldn't be surprised if GENCLK_HALF was also delayed a bit because of the divider.

[smunaut]

Oh and also wrt to the original question, nextpnr doesn't support :

• Generating frequency specification for derived clocks in the ice40 depending on the PLL configuation, you need to add the frequency constraint yourself.
• Doesn't support cross clock constraints at all. Path are analyzed in the final report but not constrained in anyway.

[madscientist159]

Are cross clock constraints a planned feature? Would make a couple of designs we have a lot easier if so...

[daveshah1]

Yes but I can't give an ETA