Skip to content

Latest commit

 

History

History
148 lines (124 loc) · 9.75 KB

0181-2023-12-02.md

File metadata and controls

148 lines (124 loc) · 9.75 KB

2 Dec 2023

Previous journal: Next journal:
0180-2023-12-01.md 0182-2023-12-03.md

Getting algofoogle-multi-caravel up to efabless

Issues to work out

  • When doing an OpenMPW submission, do you need to embed the source of everyone's designs? Given git submodules seem broken in the efabless git server, what can we do?
    • Is there an official way to do it with submodules?
    • Would submodules work if they were all hosted by efabless too?
    • Must we just copy all the source directly into the repo from everyone's projects?
    • What did Tholin do? Just copied in each, it seems.
    • We must ensure everyone's designs can harden under the same CUP.
  • I want to work with a git submodule in my main repo, and then (assuming necessary) convert it to inline content (without a submodule) in CUP.
  • I want to try two different versions of raybox-zero and ensure they don't conflict (even though they will have some modules with the same names):
    • There could be a raybox-zero-common dir, for things that don't change.
    • Then we could have raybox-zero-original and raybox-zero-retimed.
    • OR call them raybox-zero-combo and raybox-zero-fsm.
    • Make sure that each variation
    • Can we cheat by just using `include statements all the way, and referencing relative paths?
  • Don't forget tests!
  • Need to create a mux. NOTE: If we use a tri-state solution (i.e. instead of a mux) then I think each design can just share a common bus, but we must make sure there are no buffers inserted on macro pins (i.e. a config.json requirement, as per TT also).
  • Reduce no. of LAs. Use more IOs.

I think I need to do the following, which is probably what the other people wanting to do a submission would also need to do:

  1. Create a combo repo called (maybe) ztoa-team-multi-caravel.
  2. Create my own separate CUPs with different instantiations of raybox-zero branches.
  3. Harden in those separate CUPs, and then transfer all related files manually (or via a script) into ztoa-team-multi-caravel.
  4. Be sure to note in the README (and even in subdirs) what the respective repos are.
  5. When the other repos are copied in to ztmc, prove that they still harden the same way.
  6. FOCUS: JUST GET IT WORKING FOR ONE RAYBOX-ZERO INSTANCE, FIRST, AND UP TO EFABLESS!
  7. VERIFY: Can ALL 38 GPIOs be used by a user design? My assumption that this is OK: At the right time, the firmware will just have to agree to disable all the other SoC functions that share GPIOs.

Map

  • https://github.com/algofoogle/algofoogle-multi-caravel:
    • Anton's collection of projects to individually harden and then combine into another repo to submit for GFMPW-1
    • Intended branches:
      • gf180-base: Clean setup from which other projects can stem. If its gets updated for any reason, hopefully we can merge from gf180-base to the respective other project branches (though hopefully we shouldn't need to).
      • gf180-rbz-combo: verilog/rtl/raybox-zero is a submodule on a branch that implements a lower-speed (15MHz?) hardening solution for raybox-zero pretty much as it comes from sky130, maybe just with pin placement tweaked.
      • gf180-rbz-fsm: verilog/rtl/raybox-zero is a submodule on a branch that uses the 'safer' parallel FSM modules, and is reported by OpenLane to achieve better timing (22.72MHz?)
      • gf180-ss: solo_squash
      • gf180-vsr: tt05-vga-spi-rom
  • https://repositories.efabless.com/algofoogle/ztoa-team-multi-caravel:
    • Needs a mux block and proper wiring. This could be ugly: Even with 30 IOs, that's 90 per project (io_in, io_out, io_oeb for each)
    • Copy all of the individual projects into this one and maintain on efabless.
    • NO branches.
    • Make sure all can be hardened within this repo, and combined into UPW.
    • Create combined README, plus probably individual READMEs within subdirectories, with links to respective original repos.
    • Must pass precheck.
    • Make sure SPDX data is correct -- licenses throughout.
    • Method for updating:
      • Harden in source repo/branch to make sure it all works OK.
      • Copy algofoogle-multi-caravel@gf180-rbz-fsm contents for verilog/rtl/raybox-zero-fsm -- remove .git* stuff if any.
      • Make sure READMEs are updated and reference their respective source repo commits. This should include both the source CUP repo's commit, and whatever its project submodule commit is.
      • Make sure all verilog/rtl/raybox-zero-fsm/src/rtl/*.v are up-to-date in verilog/includes/*
      • NOTE: Decide where the top module should live for each macro. In its respective subdiretory of verilog/rtl/... is probably best.
      • CHECK whether user_defines needs to be updated. Might not need to worry too much given mux.
      • Update a snippet in user_project_wrapper.v -- make sure it is compatible with our mux.
      • Copy in openlane/PROJECTNAME
      • Update combo README.
      • Update lvs/user_project_wrapper/lvs_config.json if needed.
      • Update openlane/user_project_wrapper if needed.
      • Do a test harden.

List of stuff I've done to algofoogle-multi-caravel:

  • Add to .gitignore: 
    caravel
dependencies
JUNK
mgmt_core_wrapper
  • Added raybox-zero@ew submodule (later @gf180?)
  • Created openlane/top_ew_algofoogle/config.json
  • Updated openlane/user_project_wrapper/{config.json,macro.cfg}
  • Updated verilog/includes/*
  • Updated verilog/rtl/user_defines.v
  • Updated verilog/rtl/user_project_wrapper.v
  • Added hardened files: def, lef, gds, lib, mag, maglef, sdc, sdf, signoff, spef, spi, verilog/gl
  • Updated README
  • Updated lvs/user_project_wrapper/lvs_config.json

Things to check:

  • All IO/port mappings are correct
  • Update README
  • Update docs/
  • Tests should be in place
  • Do full GL test inc. when we have mutliple designs muxed

What I did

  • Cloned https://github.com/algofoogle/algofoogle-multi-caravel
  • git checkout 3be3f7804e20d0785cae63dba2fe0d0c1ca57992: Puts us at the "Removed (most) example stuff" commit.
  • git checkout -b gf180-base: gf180-base branch is now a relatively clean base for making a new branch for each project.
  • git push -u origin gf180-base: Make sure gf180-base branch is on GitHub.
  • Made gf180-base the default branch in GitHub.
  • Updated README a bit to explain that this a base repo with multiple branches for each project.
  • Removed contents of docs/ because it is a little outdated and belongs more to user_proj_example.
  • Disabled automatic running of GitHub Actions, and otherwise updated:
    • Added submodule recursion to checkout, and changed checkout from v2 to v3.
    • Changed user_proj_example to REPLACEME_project_macro_name
    • Changed user_project_flow_gf180mcuC to user_project_flow_gf180mcuD
  • Set user_defines for GPIOs 5..7 just to reflect their default SoC functions. Note that this means GPIO 6 will always power up as an OUTPUT, so beware.
  • Put REPLACEME_... markers all over the place.
    • REPLACEME_project_macro_name: Replaces user_proj_example; should be the name of your top module, macro, instance, etc.
    • REPLACEME_all_other_rtl_source_files: Expand to a list of each of the .v files that make up the RTL source of your project
    • REPLACEME_clock_port: Appears in UPW's config.json. The CLOCK_PORT to use, which I think is typically the name of the macro's top port at which the clock signal comes in.
    • REPLACEME_project_macro_name.REPLACEME_clock_net: I think this is the name of the net (inside the design) that will actually be used for doing CTS...? I suppose in this way we MIGHT be able to do clock gating, muxing, etc...? There is confusion about this.
  • Hopefully the only user_proj_example stuff that's left now is in openlane/EXAMPLE-user_proj_example
  • A few other bits and pieces.

Still to do:

  • user_defines: Decide what their default configuration should be if we have multiple projects and a mux. Probably all INPUT_NOPULL to be safe?

Making gf180-rbz-fsm out of gf180-base

  1. git pull && git checkout gf180-base
  2. git checkout -b gf180-rbz-fsm
  3. Look at what actual changes were done in the main-gf180 branch.
  4. git submodule add -b gf180 [email protected]:algofoogle/raybox-zero verilog/rtl/raybox-zero-fsm
  5. I Set CLOCK_PERIOD in UPW's config.json to 44 to match that in top_ew_algofoogle/config.json, hoping it will help timing calculations at least a little.
  6. ...etc...

First harden attempt with new structure and gf180-rbz-fsm

Ref: https://github.com/algofoogle/algofoogle-multi-caravel/commit/adc99d6e84d75cd79e3d0bb182027691188395b9

  • top_ew_algofoogle hardens at 44ns period; only fanout errors.
  • UPW fails with hold validations at 44ns period; maybe we need to constrain it more? 35ns? 25ns?

Next steps

  • Rename top_ew_algofoogle (esp. in gf180-rbz-fsm) and decide whether to keep the equivalent of top_ew_algofoogle.v in raybox-zero or in verilog/rtl/...?
  • Put FSM around shmul.
  • Include some simple verification circuits: blinker, etc.
  • Work out what's going on with UPW hold vios.
  • Clean up LAs and IOs, and if possible slim down or get rid of output muxes.
  • Place design closer to middle, and change pin ordering?
  • Change suffix (footer) from SNIPPET1_NoShare to SNIPPET2_ShareIns