Skip to content

Latest commit

 

History

History
133 lines (110 loc) · 8.95 KB

0126-2023-08-19.md

File metadata and controls

133 lines (110 loc) · 8.95 KB
Raw

19 Aug 2023

Previous journal: Next journal:
0125-2023-08-18.md 0127-2023-08-20.md

raybox-zero

Start TT04 submission repo

Last time I used the "GitHub import" method to copy the tt04-submission-template repo and make tt04-solo-squash.

This time I actually forked tt04-submission-template, since I haven't already done this. That way other people can see the fork easily, and I can pull updates if needed:

  1. Log in to GitHub, go to tt04-submission-template page, and click the "Fork" button. I called it tt04-raybox-zero.
  2. Enable GitHub Actions in the Actions area of the repo.
  3. Enable GitHub Pages step in Settings => Pages.
  4. Clone the repo locally.
  5. Add raybox-zero as a submodule: 
    git submodule add [email protected]:algofoogle/raybox-zero src/raybox-zero
    ...and optionally go into src/raybox-zero and git checkout a specific branch or commit if needed. In any case, the .gitmodules file will specify the details of the submodule.
  6. Update info.yaml as required, and optionally README, etc.
  7. Commit and push changes, and observe the GHAs.

NOTE: After doing a git pull in the main repo, it might also be necessary to do git submodule update --init --recursive to get whichever submodule version is specified in the latest commit of tt04-raybox-zero at the time. More info: https://devconnected.com/how-to-add-and-update-git-submodules/

yosys-abc core dumped

After my initial commit of the repo, I got an unexpected failure in the gds action where Step 1 failed because of this error:

67.1.1. Executing ABC.
sh: line 1:   141 Aborted                 (core dumped) "/build/bin/yosys-abc" -s -f /tmp/yosys-abc-f4KTjg/abc.script 2>&1
ERROR: ABC: execution of command ""/build/bin/yosys-abc" -s -f /tmp/yosys-abc-f4KTjg/abc.script 2>&1" failed: return code 134.
child process exited abnormally

From what I can tell, this is not normal. I will have to see if I can run OpenLane and do the GDS hardening locally, and maybe see if I can configure it to give me more information. If that doesn't work, I will have to try cutting back the design to tease out the cause. I wonder if it is something to do with my negative vector indices as used in my floating-point ports... hmm...

I'm going to see if I can use my own guide on building the GDS locally or otherwise try Matt and Uri's official "Hardening Tiny Tapeout Projects Locally" guide for doing this.

Actually I have to adapt because TT04 does it a little differently. Namely, now the GHA relies on the TinyTapeout/tt-gds-action@tt04 GHA to do the job. See the guts of the TinyTapeout/tt-gds-action@tt04 action, but here's what I had to do inside my MPW8 VM:

  1. Clone my own repo, tt04-raybox-zero.
  2. Clone submodules: git submodule update --init --recursive
  3. Set environment variables:
    • tt03 used:
      • OPENLANE_TAG: 2023.02.14
      • OPENLANE_IMAGE_NAME: efabless/openlane:4cd0986b3ae550cdf7a6d0fba4e0657012f635d8-amd64
    • tt03p5 used the same.
    • I was using this version with MPW8: efabless/openlane:cb59d1f84deb5cedbb5b0a3e3f3b4129a967c988-amd64
    • tt04 uses:
      • OPENLANE_TAG: 2023.06.26
      • OPENLANE_IMAGE_NAME: efabless/openlane:3bc9d02d0b34ad032921553e512fbe4bebf1d833
    • NOTE: I'm trying without that updated OpenLane, first. I will use my MPW8 default for now.
  4. Go into my repo, then clone tt-support-tools as follows: 
    git clone -b tt04 https://github.com/TinyTapeout/tt-support-tools tt
  5. MPW8 VM has Python 3.8.10 already installed. Set up a Python virtual environment: 
    python3 -m venv ~/tt/venv
source ~/tt/venv/bin/activate
  6. Install Python dependencies: 
    pip install -r tt/requirements.txt
  7. Run: ./tt/tt_tool.py --create-user-config which outputs: 
    Preparing to run yowasp-yosys. This might take a while...
./src/raybox-zero/src/rtl/pov.v:15: Warning: converting real value 6.144000e+03 to binary 24'000000000001100000000000.
./src/raybox-zero/src/rtl/pov.v:17: Warning: converting real value 0.000000e+00 to binary 24'000000000000000000000000.
./src/raybox-zero/src/rtl/pov.v:18: Warning: converting real value 4.096000e+03 to binary 24'000000000001000000000000.
./src/raybox-zero/src/rtl/pov.v:19: Warning: converting real value -2.048000e+03 to binary 24'111111111111100000000000.
./src/raybox-zero/src/rtl/reciprocal.v:27: Warning: converting real value 6.004236e+03 to binary 24'000000000001011101110100.
./src/raybox-zero/src/rtl/reciprocal.v:31: Warning: converting real value 4.100415e+03 to binary 24'000000000001000000000100.
2023-08-19 17:07:33,434 - project    - INFO     - creating include file
    ...and contents of src/user_config.tcl: 
    set ::env(DESIGN_NAME) tt_um_algofoogle_raybox_zero
set ::env(VERILOG_FILES) "\
    $::env(DESIGN_DIR)/top.v \
    $::env(DESIGN_DIR)/raybox-zero/src/rtl/fixed_point_params.v \
    $::env(DESIGN_DIR)/raybox-zero/src/rtl/rbzero.v \
    $::env(DESIGN_DIR)/raybox-zero/src/rtl/debug_overlay.v \
    $::env(DESIGN_DIR)/raybox-zero/src/rtl/map_overlay.v \
    $::env(DESIGN_DIR)/raybox-zero/src/rtl/map_rom.v \
    $::env(DESIGN_DIR)/raybox-zero/src/rtl/pov.v \
    $::env(DESIGN_DIR)/raybox-zero/src/rtl/lzc.v \
    $::env(DESIGN_DIR)/raybox-zero/src/rtl/reciprocal.v \
    $::env(DESIGN_DIR)/raybox-zero/src/rtl/wall_tracer.v \
    $::env(DESIGN_DIR)/raybox-zero/src/rtl/row_render.v \
    $::env(DESIGN_DIR)/raybox-zero/src/rtl/vga_mux.v \
    $::env(DESIGN_DIR)/raybox-zero/src/rtl/vga_sync.v"

# Project area: 8x2 tiles
set ::env(DIE_AREA) "0 0 1359.76 225.76"
set ::env(FP_DEF_TEMPLATE) "$::env(DESIGN_DIR)/../tt/def/tt_block_8x2.def"
  8. Run: OPENLANE_IMAGE_NAME=efabless/openlane:cb59d1f84deb5cedbb5b0a3e3f3b4129a967c988-amd64 ./tt/tt_tool.py --harden

I've left this running, and I'll look at this more tomorrow. Already, using my environment with my different OpenLane version, it has made its way past step 1 and up to step 17. Let's see how far it gets...

What I've already done

  • Take raybox-zero as it currently is.
  • Run make clean_sim in my desktop PC's MPW8 VM: Get a 19~23% run rate (23% is typical).
  • Disable map and debug overlay code.
  • Run again, and see if the performance changes: Pretty much a constant 24%.

Next steps

  • Work in Progress: Try fitting this variation of the design in TT04.
  • See if we can get local OpenLane GDS hardening to run per TT04 specs.
  • If it is way too big, try some optimisations, or instead try working out how big certain modules are.
    • WARNING: Some stuff is hardcoded (e.g. pov), which means some synth optimisations will happen that we probably don't want.
  • Try running on FPGA.
  • Try slowing down the FPGA clock using PLL.

Notes

  • 8bitworkshop seemed to be having trouble when I tried to have more than 10 files. The 11th was not showing up after a refresh, though I also couldn't create another file with its same name (because it complained it already existed).