Skip to content

Latest commit

 

History

History
157 lines (133 loc) · 10.7 KB

0167-2023-10-27.md

File metadata and controls

157 lines (133 loc) · 10.7 KB
Raw

27 Oct 2023

Previous journal: Next journal:
0166-2023-10-26.md 0168-2023-10-28.md

NOTE: The prior journal entry 0166, even though dated 2023-10-26, was started on the same date as THIS entry (2023-10-27). 0166 was a bit more rambling with loose notes. This one is a LITTLE better. I expect 0168 will wrap it all up properly.

Next steps

  • Try snippet in CUP/UPW, which will hopefully test both:
    • Re-hardening top_ew_algofoogle
    • Making sure my instantiation of the macro in UPW is OK
  • Check the full Caravel GDS carefully. Maybe also check the macro's GDS too
  • FIGURE OUT THE POLARITY OF la_oenb AND io_oeb
    • From what I've learned so far, a 0 bit in la_oenb means "this is an SoC OUTPUT, being sent to la_data_in"
    • Might need to test it with dv-TB or cocotb.
  • Implement la_oenb sense for reset safety, and maybe also use 1 more for masking out all other inputs that depend on LAs (e.g. so that a floating state can't screw up SPI, and maybe forces ON the debug stuff).
  • Try and do a full test/sim with cocotb?
  • If it turns out to be bad to do the mapping/constants that I'm doing in UPW, then maybe we can just instantiate an extra mapping/switching macro. I assume this is how Matt would've done muxing, anyway.
  • Repeat hardening in newer CUP/caravel. Find out what Ellen and Pawel are using.
  • How might I use a total of 4 full-time inputs? Maybe the 4th can select between SPI textures and bitwise textures.
  • ESD protection for analog: Seems to be built-in to the pads even when using analog. See this and search for ESD.
  • This is important to know: setting io_oeb[*] for analog pins:

    On a caravel frame, the user_project_wrapper pins analog_io[28:0] will connect to the corresponding gpio cells for the digital io_out[35:7] cells. For any cells used for analog I/O, I recommend you set the corresponding digital io_oeb[*] signal to high, although this might not be necessary depending on your verilog/rtl/user_defines.v settings.

Testing my macro in CUP (caravel_user_project)

NOTE: This is an older version of caravel_user_project (i.e. mpw-8c). Need to try with a newer version too. Find out what Ellen and Pawel are using.

Prep clean CUP

  1. Using desktop PC's MPW8 VM
  2. Go into ~/asic_tools
  3. Archive old work on caravel_user_project/:
    • Rename to CUP-wrapped-group-test-2023-04-04 -- looks like it was me adapting solo_squash_caravel to the wrapped group submission (which never went ahead because of abandoned Google OpenMPW shuttles).
    • Compress old CUPs (currently ~6GB each): 
      tar cjf CUP-Progress-backup-2023-03-28.tar.bz2 CUP-Progress-backup-2023-03-28 && rm -rf CUP-Progress-backup-2023-03-28
tar cjf CUP-wrapped-group-test-2023-04-04.tar.bz2 CUP-wrapped-group-test-2023-04-04 && rm -rf CUP-wrapped-group-test-2023-04-04
  4. Extract clean CUP copy: tar xjf MPW8-Clean-caravel_user_project.tar.bz2 (5.8GB)
  5. Rename it: mv caravel_user_project CUP-0167-EW-raybox-zero
  6. NOTE: ~/CUP is a symlink to ~/asic_tools/caravel_user_project, let's make caravel_user_project itself a symlink to CUP-0167-EW-raybox-zero: 
    cd ~/asic_tools
ln -s CUP-0167-EW-raybox-zero caravel_user_project
  7. cd ~/CUP && realpath .
# /home/zerotoasic/asic_tools/CUP-0167-EW-raybox-zero

Run CUP example project test

Don't worry: We'll use this same CUP to integrate raybox-zero after doing these example project tests.

  1. cd verilog/dv/io_ports   # 'io_ports' is one of the example project's tests.
make  # Run tests.
  2. OK, that seems to work.
  3. cd ../la_test1   # Now let's try 'la_test1'
make
  4. Works too, but very slow.

Instantiate my design (top_ew_algofoogle)

  1. Clone raybox-zero repo, ew branch: 
    cd ~/CUP/verilog/rtl
git clone -b ew git@github.com:algofoogle/raybox-zero  #NOTE: 'ew' branch
  2. Delete user_proj_example.v and edit user_project_wrapper.v to paste in the instantiation snippet.
  3. Edit verilog/includes/includes.rtl.caravel_user_project and replace the user_proj_example.v line with all our relevant source files. Result: 
    # Caravel user project includes
-v $(USER_PROJECT_VERILOG)/rtl/user_project_wrapper.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/top_ew_algofoogle.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/debug_overlay.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/fixed_point_params.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/helpers.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/lzc.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/map_overlay.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/map_rom.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/pov.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/rbzero.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/reciprocal.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/row_render.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/spi_registers.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/vga_mux.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/vga_sync.v
-v $(USER_PROJECT_VERILOG)/rtl/raybox-zero/src/rtl/wall_tracer.v

  4. cd ~/CUP/verilog/dv
mkdir test_rbzero_snippet1
  5. Borrow files from here

Figuring out LA direction

  • SoC drives la_oenb (it's an SoC output, design input).
  • Here's an example snippet from the mpw-8c version of caravel_user_project: 
    assign la_write = ~la_oenb[63:32] & ~{BITS{valid}};
// Assuming LA probes [65:64] are for controlling the count clk & reset  
assign clk = (~la_oenb[64]) ? la_data_in[64]: wb_clk_i;
assign rst = (~la_oenb[65]) ? la_data_in[65]: wb_rst_i;
  • The example shows that for clk and rst, when a bit in la_oenb is LOW (0), the corresponding la_data_in is valid. Hence, 0 must mean "Output from SoC to design".
  • Thus, if any la_oenb bit is HIGH (1), then la_data_in must be Hi-Z (floating), and the SoC is ready to read it as an input from our design instead (i.e. our design should assert la_data_out).
  • In the la_write case, any given bit in that is 1 when la_oenb is LOW (0=Output from SoC, input to design) and valid is 0 (i.e. NOT a valid WB write?? I dunno). In THAT case, if they're all 0, the counter increments. Otherwise, the counter gets set to the mask of la_write and la_input. Again this implies that a LOW on an la_oenb bit is data our design is RECEIVING from the SoC.
  • Thus, given our LA usage is all about inputs into our design, we should want all corresponding la_oenb bits to be 0. For any that are not, the input is not being driven, so we must take a default.
  • The thing that makes this extra confusing is that with VexRiscv, the reg_la*_oenb registers expect POSITIVE polarity in order to enable VexRiscv=>Design outputs, i.e. setting a bit in that register to 1 enables it as an output from the SoC, to the design.
  • Matt has confirmed my assumptions, which are as follows:
    • If you set a bit to 1 in reg_la*_oenb via firmware, it gets inverted and becomes a 0 in la_oenb as received by the design hardware.
    • This indicates that the respective la_data_input is valid, and is providing a value as an input to the design (i.e. an output from the Management SoC).
    • You can then set/clear the corresponding bit in reg_la*_data to drive that value into the respective la_data_input line so the design can sense it.
  • I still need to check this, though, because even in his example screenshot, the same value is being written to reg_la1_oenb and reg_la1_iena... this implies that it's enabling the bits as inputs and outputs at the same time.
  • Matt is running the la_test1 example which includes this: 
    // Configure LA probes [31:0], [127:64] as inputs to the cpu 
// Configure LA probes [63:32] as outputs from the cpu
reg_la0_oenb = reg_la0_iena = 0x00000000;    // [31:0]
reg_la1_oenb = reg_la1_iena = 0xFFFFFFFF;    // [63:32]
reg_la2_oenb = reg_la2_iena = 0x00000000;    // [95:64]
reg_la3_oenb = reg_la3_iena = 0x00000000;    // [127:96]
    Note how it says this pattern sets LA[63:32] (i.e. all of reg_la1_oenb) to be outputs (using high bits), and sets everything else to be inputs? Additionally, iena==0 means "input" while oenb==1 "output". Oh well, whatever.

Different files that make up a macro

  • gds: known
  • lef: 'Library Exchange Format'.

    Abstract description of the layout for P&R

    • Readable ASCII Format.
    • Contains detailed PIN information for connecting.
    • Does not include front-end of the line (poly, diffusion, etc.) data.
    • Contains blockages for DRC (Ref: slides)
  • def: 'Design Exchange Format'. DEF is like GDS, but more structured maybe??
  • lib: 'Liberty Timing Models'
  • mag: Magic circuit layout or cell file?
  • v: Verilog... wrapper/abstraction/blackbox, maybe?

Notes