Inconsistent timing results/failed timing on newer Vivado versions

[GregAC]

When building the current main branch with Vivado version 2024.1 a timing failure is reported in the project summary (seen in the Vivado GUI when running make -C ./build/lowrisc_sonata_system_0/synth-vivado/ build-gui after fusesoc has run synthesis) as well as in the critical warning log.

If a full timing analysis is run on this apparently failed build it reports timing is fine and changes its mind about WNS.

This behaviour is not seen under v2021.1 and the WNS reported in the project summary is consistent with the WNS reported by running the timing analyzer.

I suspect this is some tooling issue, possibly to do with the overconstraining that's been introduced. Perhaps there's something in our flow that works with v2021.1 but breaks on newer versions?

Short term we should use v2021.1 as the sign-off tool and for generating releases. Longer term we should aim to be using the latest version of Vivado and should investigate what's going on here.

@elliotb-lowrisc @marnovandermaas please note the above.

[GregAC]

Also just seen a segfault when building with 2024.1. Something I've seen once before with 2023.1 as well though it wasn't persistent.

So I guess our flow is pushing things in a lesser explored direction and triggering some bugs...

[GregAC]

Now seeing a consistent segfault in 2024.1 happens during some routing optimization stage as far as I can tell. Oddly I wasn't seeing it with the exact same checkout earlier!

[elliotb-lowrisc]

Does it happen if you use set opt 0 in flow/vivado_hook_opt_design_pre.tcl? That should disable my optimisations, just to check they aren't triggering the issue.

In my experience with physical design tools, segfaults are neither uncommon nor (usually) consistent. If some segfault or other bug was blocking development then the solution sometimes was to ask the tool vendor for a special build with the bug fixed, though I expect you need to be paying a lot in licence fees for that to be an option.

My preference would be for us to all be using the latest version of Vivado in toolnas, even if installed locally. Better to have everyone experiencing similar build results if we want to avoid surprises.

[GregAC]

I've started doing some other stuff in the same working directly so unknown if that fixes it, suspect it will though.

2021.1 is the latest version in toolnas, though it's mostly accidental that's the latest version, simply no-one has bothered to update it.

However we do seem to be getting better QoR with 2021.1 so I'm happy to declare that the 'official' tool version of Sonata for now but we should look at moving to a newer version.

[marnovandermaas]

My 2024.1 is working fine on main. Will now check the SRAM PR.

[GregAC]

Latest main build I did on 2024.1 did pass setup timing but had a hold timing violation.

Ultimately there's definitely some difference in how v2021.1 optimizes vs v2024.1

[elliotb-lowrisc]

Vivado 2024.1 seems to write out different implementation TCL scripts ("top_sonata.tcl") to Vivado 2021.1. One key difference is that the timing summary file is now written out before the post-route optimisation that I added in a post-route hook. This made it seem like the timing failed in my trial, when post-route optimisation actually cleaned that up with ease for a timing clean final design.

The timing results that show by default in the Vivado Project Manager (fusesoc build-gui target) appear to be those written out after routing, not the final state of the design after post-route optimisation. This explains the behaviour noted earlier where timing failures disappeared when timing reporting was re-run.

I think I can use some Vivado options I've uncovered to move post-route optimisation into its own stage, rather than using a post-route hook. This should work for both versions of Vivado. This approach might have a bit less flexibility than before (as we are limited by the Vivado options a bit), but should be doable.

[GregAC]

Thanks for investigating @elliotb-lowrisc

I don't think there's any need to ensure we support both versions. For 1.0 let's keep 2021.1 as a our release and sign-off tool as that's what you've been working with and what CI uses. Post 1.0 we can look at moving to 2024.1. So if there's a simpler/better way to get things working with 2024.1 if you don't have to care about 2021.1 we can use that.