Tony’s design notebook

week 1: 9/14-9/21

work completed

• attended the online meeting
• read rhrough the integer bas e of the RV32 ISA from the provided link
• actually happened to take a class on the very same thing in grad comp arch, as the course focuses on RISC-V too

notes

areas of interest:

• out of the offered areas, im most interested in the bus / SoC work, particularly APB, AMBA, interrupt routing
• would also be open to core stuff, especially something like the CSR / trap unit
• I have verification experience, and have been working with formal verification tools in a reserarch lab for a while now - happy to jump no verification as well
  • ive been meaning to learn UVM, as my experience is limited. if you think thats in scope, would love to get involved.
  • i have access to a couple of FPGAs which i could use for emulation

week 2: 9/22-9/28

work completed

• read the excerpt on the architecture of a single cycle MIPS processor from Patterson and Hennessy
• compared the MIPS implementation to what I know about the RV32 ISA

notes from reading

• the control block is often the clock speed bottleneck, which is one of the central motivations for pipelining in processor design
• sacrificing some space in the instruction is often worthwhile to make the placement of signal consistent or at least similar for many instructions
• The ISA shapes the architecture - it is almost like a datapath spec
• where possible, the decoding of instructions is hierarchical in a single-cycle MIPS processor, which helps simplify the control logic a lot

week 3: 9/29-10/5

work completed

• read thorugh other members miro board contributions
• wired created modules togehter by adding a control unit and control table
• noted which names were chosen in case of collision and pointed out any observed mishaps in the reasoning section

week 4: 10/6-10/12

work completed

• no work really
• attended most of tuesdays meeting (had to leave early for another meeting)
• read through MICRO-ARCHITECTURE/“Schema credits and control signals”
  • nicely done! this is a great reference doc

week 5: 10/13-10/19/26

• forked the repo to get started on my modules
• got through about half of Ray Salemi’s introduction to the UVM on verificationacademy
• started working on the control unit, but looking at the architecture noticed a couple of things, and have some questions + notes to raise:
• notes
  • top could use some extra signals like rst and dbg_pc, dbg_instr, dbg_reg_we, dbg_rd, dbg_rd_data, dbg_mem_we, dbg_mem_addr, dbg_mem_data
  • regfile could use a reset input too.
  • is the pc reset value 0?
  • a shared encodings package would be nice.
• questions
  • does the assembler.py already exist, what .mem format does it output, and how does it encode branch/jump offsets?
  • what is the verification plan + sign off criteria? are we free to decide that? who wrties the reference model?
  • is UVM on an NYU license server the idea or do we want to make it UVM-style and keep it open source? Id honestly lean towards the former since we have other verification already and id be pretty excited to do real UVM
  • for systemC, are we all able to use 3.0.2 ?