timing closure degraded

Users
1

Between oss-cad-suite 20251204 (with nextpnr-0.9-43) and 20260415 (nextpnr-0.10-33),

something changed such that nextpnr-ecp5, for the same exact design that used to pass 48 MHz timing, now fails achieving only 30 MHz.

I bisected the issue to oss-cad-suite 20260331.

nextpnr version did not change from the day before, so the issue might be somewhere else.

Any idea why timing closure degraded so much ?

2

Could be related to ABC regression · Issue #5802 · YosysHQ/yosys · GitHub

1 Like
3

Is there a runtime workaround that can be used ?

4

Have you tried an earlier version, something like a month old?

5

I know exactly when the problem started occuring; but I like that there is improved LUT usage with the latest oss-cad-suite, just that timing closure is degraded.

I was hoping there is a way to work around the issue at runtime and benefit from the lower LUT usage.

6

I suspect these two things may be related and that it’s probably not possible to get one without the other.

7

Is there by any chance an ETA when a fix would be available ?

Or I shouldn’t hold my breath waiting on a fix.

8

The testcase given in issue 5801 behaves correctly with Yosys 0.65 after an ABC regression was fixed; @tambewilliam can you check your design with that?

1 Like
9

Thank you,

I no longer see the timing closure degradation using oss-cad-suite 20260513, which comes with yosys 0.65+7

1 Like