@Anton Blanchard: Echo what Tim is saying but with one caveat. We agree that we were missing constraints.

In effect, there are two issues: Constraints would have caught the problems, but would not have solved them because the top-level P&R is just routing together macros and is not doing synthesis; it cannot, for example, add delays between blocks on the top level to solve hold violations. It reminds me to add that it's an open question as to whether we have sufficient constraints for the boundary between the user project and the rest of caraval, or whether it's even possible to define such constraints in a universal way. Can we guarantee the timing of the wishbone clock and data once it crosses over into the user project?

@Tim Edwards For my project, MPW-3 onward I have tried full-chip STA in Typical corner including caravel + User project with netlist + SPEF and made sure that 1. There no hold violation between caravel and user project interface. 2. There is no setup or hold violation inside user project. 3. All the un-constraint report path inside user project are cross review. 4. Multiple time i have reported caravel un-constraint path caravel gpio/Housekeeping https://open-source-silicon.slack.com/archives/C02K4RD241Y/p1640244141189700?thread_ts=1638758421.176000&cid=C02K4RD241Y https://open-source-silicon.slack.com/archives/C02K4RD241Y/p1639070094183500?thread_ts=1638758421.176000&cid=C02K4RD241Y 5. Multiple Time reported on SRAM Library is not good for timing sign-off https://open-source-silicon.slack.com/archives/C01EX4ATEKF/p1645153902157709?thread_ts=1645017346.001749&cid=C01EX4ATEKF MPW-5 onward I have added additional neg-edge data launch in write phase towards SRAM. Big assumption :- OpenSTA tool can be trusted for Timing Signoff.

@Dinesh A Caravel SDC files are mostly corrected. It is still a WIP but they are way better compared to what is used in mpw-2. OpenRAM .lib files are known to be not accurate. They are not the result of a rigorous characterization process according to Matt. According to Matt, the lib files, as they are, should be good enough as the macros cannot have hold violations by design.

@mshalanAs per my discuss with @Matthew Guthaus SRAM write phase uses positive edge of the clock to capture the data, Where are Read path uses negative edge to launch the data. As Caravel Design also uses positive edge to launch and capture the data. More chance of Hold in SRAM Input Interface. If you see the SRAM Library spec for all input hold is : -0.06ns. Which is effectily saying SRAM can capture the data in phase with clock for all the bits? Normally these type of Hold margin can be achievable only in a FF. SRAM will have large clock tree to connect 2KB *32 location = 2 * 1024 * 32 = 65,536 , I can easily expect minimum 2 to 4ns Hold requirement. If SRAM has inbuild 2 to 4ns Hold buffer for input data pin then also I expect atleast 1ns hold across Data + Control Bit. A. Here is my analysis on Input timing hold margin. 1. Input Data pin margin are with-in 1ns 2. Input Control pin margin are ranging from 3 to 11ns B. On output hold margin, as expected margin is order of 16ns