Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
  • Timing & Clocking39
  • Reset & CDC34
  • Memory & Buses57
    • SRAM and ROM
    • Register Files
    • Valid/Ready Handshake
    • AXI-Lite
    • AXI-Stream
    • Bus Integration
    • Synchronous FIFO
    • Register-Map and CSR RTL
      • CSR Contract and Address Map
      • Field Access Types
      • Hardware/Software Arbitration
      • Byte Strobes and Partial Writes
      • Atomic and Shadowed Updates
      • Interrupt Register Pattern
      • Adapter and Signoff
      • Generated Register Workflow
      • The Firmware Side: a C Driver for W1C, RC and Shadow Registers
    • Memory Reliability
    • Peripheral RTL Integration
    • Full AXI4: RTL Roadmap
  • Advanced RTL28
  • Senior & Interview76
  • Glossary and Notation
Loading lesson

‹Register-Map and CSR RTL
  1. Topics
  2. RTL Design
  3. Memory & Buses
  4. Register-Map and CSR RTL
  5. Generated Register Workflow

Part 7 · Memory & Buses · Intermediate

Generated Register Workflow

Use one reviewed register specification to generate consistent RTL, software, documentation, and verification artifacts.

Why this matters

A hand-edited generated register file and a stale spec drift apart without any error. A generator removes transcription mistakes, but it cannot choose set-versus-clear priority or access rights.

After this lesson you can: describe a register-generation flow from one specification to RTL, software headers and documents, with CI checks that catch drift.

The packet-processor map is now stable enough to automate. A machine-readable source records addresses, fields, reset values, access types, descriptions, and hardware update hooks; generated outputs must preserve the semantics established in the preceding lessons.

Diagram
register: STATUS
offset: 0x04
fields:
  - { name: busy,  bits: "0", access: ro,  reset: 0 }
  - { name: done,  bits: "1", access: w1c, reset: 0, hw_set: done_event }
  - { name: error, bits: "2", access: w1c, reset: 0, hw_set: error_event }

Generated artifact

Required review

Synthesizable CSR RTL

Decode, byte strobes, collision priority, reset, side effects

C/C++ headers

Offsets, masks, shifts, volatile access helpers

Human-readable documentation

Field meaning, sequences, reserved behavior, errors

Verification model

Reset values, access policy, prediction and mirror behavior

Integration package

Typed requests, field outputs, hardware update inputs

Generated files are build products, not alternate sources of truth. Check in either the specification plus reproducible generator version or the generated outputs according to project policy, but never hand-edit generated RTL and leave the schema stale.

Register spec goes to a schema and lint check, then to a pinned generator, which produces CSR RTL, C headers, documentation and a UVM model. All four outputs feed a CI gate.
One reviewed specification feeds a pinned generator; every output goes through one CI gate that fails on a regeneration diff or a failing field test

Read the picture from the top: the only hand-edited file is the specification. Everything below the generator is rebuilt, never edited.

  1. Lint and schema-validate the specification.

  2. Regenerate every artifact with a pinned generator version.

  3. Fail CI on an uncommitted regeneration diff.

  4. Run field-semantic tests, including hardware/software collisions.

  5. Review software documentation and RTL together before assigning a released map version.

Common pitfall

A generator removes transcription errors; it does not choose the correct semantics. Read-clear hazards, set-versus-clear priority, atomic groups, and security access still require architecture review.

Interview

Describe register generation as a consistency flow: one specification, pinned generation, deterministic diffs, semantic tests, and reviewed escape hatches for genuinely custom behavior.

Check yourself What should happen when a developer manually edits generated RTL?

Regeneration or CI should overwrite or reject the change. The source specification or generator template must be updated so every derived artifact remains consistent.

Remember

  • One machine-readable source, a pinned generator version, and a failing CI check on any uncommitted regeneration diff.

  • Generated files are build products. Never hand-edit them and leave the schema stale.

  • The generator does not decide collision priority, read-clear hazards, atomic groups or security access.

Rule of thumb: generate the registers, then still review the semantics.

Keep going

  • Interview: run a mock interview on this topic

Related topics

  • CSR contract and address map

  • Adapter and signoff

  • The firmware side: a C driver

Previous

230 / 350

Next: The Firmware Side: a C Driver for W1C, RC and Shadow Registers

Up next

Up nextThe Firmware Side: a C Driver for W1C, RC and Shadow Registers

Sign in to save progress

Practice this lessonReport an error

See also

  • CSR Contract and Address Map
  • Field Access Types
  • Hardware/Software Arbitration