0188-2023-12-10.md

10 Dec 2023

Previous journal:	Next journal:
0187-2023-12-09.md	0189-2023-12-11.md

GFMPW-1 Finalisation plan for today

0. DONE: Planning
1. Create SDC for mux. Probably the main thing to fix is pins connected to LA. Is it possible that mux_conf_clk will confuse timing for downstream designs? A few cycles of test hardens to figure out what's going on. Fallback: Relax timing for anything related to my own designs.
2. Review what everyone has sent me, and review our own minutes from yesterday's call.
3. Understand everyone's designs/requirements and document them, including:
   • IO pads (inc. bidirectional needs and ordering)
   • Clock source/frequency
   • Reset needs
   • Area/density
   • Other timing
4. Create a new branch (based on gf180-base or gf180-mux2?) and start adding everyone's resources inc. GDS and other hardened files. Don't bring in their UPWs, but rather integrate them into my UPW and mux.
5. Place all macros that I have so far, and try full UPW harden.
6. Timing/routing iteration -- the yucky part! Decide how to cut losses if it's not working out.
7. RTL and GL tests for MY existing macros. Will require first cut of firmware to control the mux.
8. Build flattened repo for Efabless and do initial ztoa-team-group-caravel submission/tapeout job. Hopefully we'll get to our first valid tapeout early this way, then update when we can.
9. Make sure I can separately harden everyone's macros from their source, and that UPW still hardens OK after that.
10. Tests for others' designs.
11. Update doco a bit. Review Tip 2312B.
12. New update for Efabless repo.
13. Finish updating/placing my other designs.
14. Run UPW harden again.
15. Another timing/routing loop.
16. Documentation for GFMPW-1 'scoring'. Link to external doco for extra benefit (without needing to do more commits) and ask others to keep it updated.
17. Final submission.
18. Check for any missing/disconnected pins, and other yosys warnings.
19. Formal verification -- fix if issues.

Other things to do/try/check

• Bring in Uri's README, Diego's description, and link to respective docs/repos.
• Search code for TODOs and SMELLs
• Check for a deliberate misnamed wire in UPW, and see if it (a) still hardens anyway; and (b) whether we can find a warning somewhere about that misnamed wire... and from there check for any others!
• It seems from Pawel's PR that you don't need to include all source files in includes.rtl.caravel_user_project... instead just the top wrapper.
• Review mux 'reg' concern. Compare Tholin's case which also uses reg, but it should behave as a wire anyway because of sensitivity to * and no <= (i.e. no non-blocking assignment).
• Note that when I hardened the mux with wb_clk_i as CLOCK_PORT it seemed to give a different layout maybe with more buffers, but I could be wrong: That param should only be used for STA?
• Nudge TRZFs slightly left or right (30~40um) to avoid vertical PDN collisions. Not essential, but might help improve stability. Irrelevant.
• External reset option for mux. Maybe make IO[5] a USER_INPUT by default in user_defines so we can always use it as a reset unless otherwise configured by firmware. DONE
• Could change mux registers to be clocked on wb_clk_i and just gated on mux_conf_clk??
• Hold, Slack, Cap, Slew margins.
• Flip Uri's macro
• Inserting extra buffers in mux.
• Direct IOs (at least inputs) to Pawel's design. Focus on high-side IOs for shortest path. Given 13 needed, try: IO[37:25]
• Hold vios on TRZF1 reset line (LA[55])...
  • The issue appears to be that a change in LA[55]=>trzf_rst will actually propagate too fast to the D of an internal DFF, ahead of how quickly wb_clk_i=>trzf_clk will.
  • For now I might not need to be too concerned about hold vios on reset lines, because this is why I provide the alternate means of doing a reset.
  • I've made it multi-cycle in base_top_design_mux.sdc for now:

    set_multicycle_path -setup 2 -through [get_ports {i_design_reset[0]}]
    set_multicycle_path -hold 1  -through [get_ports {i_design_reset[0]}]

    ...but this alone made no difference to hold vios in the UPW hardening reports. Adding this to base_user_project_wrapper.sdc AND signoff.sdc also makes no difference:

    set_multicycle_path -setup 2 -through [get_ports {la_data_in[55]}]
    set_multicycle_path -hold 1  -through [get_ports {la_data_in[55]}]

  • NOTE: Do we also need to broaden this multi-cycle path spec to cover trzf_rst?
  • I tried changing the mux's config.json to have extra hold slack margin and use wb_clk_i as the clock port (for STA), but this gave worse results (going from -0.25 to nearly -2.00). Not sure which is more valid, in this case.
  • Instead try moving the reset lines to low bits of 2nd LA bank (i.e. LA[39:32])?
  • With these hold vios, keeping a design in reset should not be a problem... it might just be a problem that it doesn't cleanly come out of reset, if that reset is done by LA.
• Why are there antenna problems on la_data_in[23:8]? They're shorter than some other wires, surely!? Maybe they're not a problem because of heuristic diode insertion at ports...?

Notes from Discord

• Check mux case and reg concern. Compare with Tholin's mux (also using case). See also, this
• Diego's reset input will be from an IO, not from mux reset logic.
• Include an option for EVERYONE to make GPIO[5] function as a reset via extra mux register. Reg can disable it if (a) nobody wants it; (b) it would otherwise be confused with the ser_rx function.
• Obstruction layers can be used to block out stuff that's still coming.
• Matt might have time to try formal verification assertions of the mux.
• Pawel has provided IO mapping: https://github.com/embelon/gf180-wb-hyperram/blob/main/verilog/rtl/wrapped_wb_hyperram.v (this is from GFMPW0, but Pawel will do the same for GFMPW1?)
• Should some designs (esp. Pawel's) take their inputs directly and skip the mux, if they're close enough? Pawel's is a prime example.
• PR from Pawel to provide latest design: algofoogle/algofoogle-multi-caravel#1