Week 3 · Day 13 · 7 hours

Verilog RTL II – Memories/Register Blocks

Parameterization, FSM, memories, FIFO, arbiter, interrupts

Open supporting lesson → Week 3 assessment View in full programme
Daily plan

What you will learn and practise

Complete the stages in order and retain the requested evidence.

Theory · 2h

Register arrays; RAM/ROM models
Sync/async reads
Address decode and write enable
Config/status registers
W1C and sticky status concepts

Guided lab · 2h

1. Register array
2. 8×8 and 16×32 register files
3. ROM
4. Single-port RAM
5. Sync read RAM

Independent lab · 2h

6. Address/write-enable decode
7. Config/status/RO/WO/RW regs
8. W1C register
9. Sticky status
10. HW-set/SW-clear
11. Register bank integration

Debug and assignment · 1h

Debug address aliasing and W1C behavior
Mini-project: config/status register block

Expected deliverable

Register block with read/write tests

Practical work

Implement synthesizable memory/register structures and a configuration/status register block with correct access behavior.

Setup
  1. Create project_workspace/week3_verilog_rtl2/day13_registers with rtl, tb, sim and logs directories.
  2. Document addresses and access type for the integrated register bank.
  3. Test both valid and boundary addresses.
Execution steps
  1. Implement a register array and 8x8/16x32 register files.
  2. Implement ROM and single-port RAM models.
  3. Implement synchronous-read RAM.
  4. Add address and write-enable decode.
  5. Implement config/status RO, WO and RW registers.
  6. Implement W1C and sticky-status behavior.
  7. Implement HW-set/SW-clear behavior.
  8. Integrate the register bank.
Written assignment
  1. Compare synchronous and asynchronous read behavior.
  2. Explain address decoding and address aliasing.
  3. Define RO, WO and RW register behavior.
  4. Explain W1C semantics.
  5. Explain sticky status and HW-set/SW-clear priority.
Debug challenge

Repair address-aliasing and W1C defects, then demonstrate corrected read/write behavior.

Evidence to retain
  • Register/memory RTL
  • register map
  • read/write testbench
  • simulation log
  • debug notes
Completion criteria
  • Read/write tests pass
  • Access permissions behave correctly
  • W1C/sticky behavior is demonstrated without address aliasing
Executable lab

Build, run and retain evidence

project_workspace/week3_verilog_rtl2/day13_registers/

Required files
    Mandatory tests
      Compile
      Run
      Waveform
      PASS criteria
        Knowledge check

        Review before completing Day 13

        1. Concept

          What does W1C mean for a status register?

          Review answer

          Write-one-to-clear: writing a 1 to a status bit clears that bit, while writing 0 leaves that bit unchanged.

        2. RTL reasoning

          Why can partial address decoding cause two registers to appear at the same effective address?

          Review answer

          If not all required address bits are decoded, different addresses can satisfy the same select condition, creating address aliases.

        3. Debugging

          A W1C implementation clears the entire status register whenever any 1 is written. What is wrong?

          Review answer

          The clear operation is too broad. Only status bits corresponding to written-one positions should be cleared, subject to the documented hardware-set/clear priority.

        4. Short answer

          Why must simultaneous hardware-set and software-clear priority be documented?

          Review answer

          Both actions can target the same status bit in the same cycle. A defined priority makes the resulting state deterministic and verifiable.

        Skills and assessment traceability

          Assessment: