Closed madscientist159 closed 7 years ago
@cliffordwolf Am I correct in assuming that each I/O block output clock can be connected to the global nets without an intermediate buffer?
Digging into this further, it looks like none of the I/O block clock muxes in this example are using the global nets available to the I/O block, instead preferring to use the adjacent high-skew block to block interconnects.
Found the problem; patch incoming shortly.
As project size increases arachne-pnr has an increasing tendency to connect IO block clocks to global clock networks via an intermediate buffer and high-skew local net chain. This, in turn, destroys output timing and makes the result useless for clocked busses.
I have created a minimal testcase (see attached). Note that data_out[0] and data_out[1] correctly connect the I/O buffer clock directly to the global net, whereas data_out[2] is inexplicably connected to a high-skew local net chain after an unnecessary buffer. In practice, we have verified that this use of the high-skew local nets destroys timing to such an extent that using the current open-source toolchain for clocked synchronous systems is impossible.
Is this something that can be easily fixed?
Thanks!
Test case: ice40_io_clock_routing_failure_testcase.zip