Design Microarch

1. Interface-First Design

Define interfaces before implementation:

Module Interface Template:
- Clock and reset naming (clk, rst_n)
- Data signals: prefix-based naming (in_vld, in_rdy, in_data)
- Control signals: clear semantic names
- Parameter naming: ALL_CAPS with explicit types

2. Module Partitioning

Split modules by:

• Functionality: Each module has one clear purpose
• Timing: Separate combinatorial and sequential logic
• Reusability: Generic modules vs application-specific modules

3. Naming Conventions

Signal naming:

• Active-low suffix: _n (rst_n)
• Valid/ready pairs: xxx_vld, xxx_rdy, xxx_data
• Vector prefix: v_ for independent signals of same type
• Consistent prefix for related signals

Module naming:

• Descriptive and unique: sc_bus_arbiter not arbiter
• One module = one file
• File name = module name

Parameter naming:

• ALL_CAPS: DATA_WIDTH, FIFO_DEPTH
• Explicit type: parameter integer unsigned DATA_WIDTH = 8

4. Clock Domain Crossing

For async designs:

• Identify all clock domains upfront
• Plan synchronizers (2-stage for control, FIFO/Handshake for data)
• Use gray code counters for pointers

5. Reset Strategy

• Define reset type per module (async vs sync)
• Synchronous release always
• Reset value should be documented

Quick Reference

Design Decision Checklist

Before coding, answer:

• What are the interfaces (inputs/outputs/parameters)?
• Is this single or multiple clock domains?
• What's the reset strategy?
• How should the module be partitioned?
• What naming conventions apply?
• Are there reusable sub-modules?
• What's the parameterization strategy?

Common Mistakes

Architectural Patterns

FIFO Pattern

Interfaces:
- Write side: wr_clk, wr_rst_n, wr_en, wr_data, full
- Read side: rd_clk, rd_rst_n, rd_en, rd_data, empty
Key decisions: Depth, width, clock domains, full/empty logic

State Machine Pattern

Interfaces:
- Control inputs, status outputs
- State-specific data paths
Key decisions: Encoding (one-hot/binary), state partitioning, FSM type (Moore/Mealy)

Arbiter Pattern

Interfaces:
- Request/Grant pairs per master
- Shared resource interface
Key decisions: Arbitration policy, priority scheme, fairness

Integration with Other Skills

• rtl-coding-style: This skill focuses on microarchitecture; rtl-coding-style focuses on coding style
• verification-env: Consider verification needs during microarchitecture design
• verification-testplan: Microarchitecture decisions affect testability

Real-World Impact

Good microarchitecture:

• Clean interfaces → easy integration
• Consistent naming → faster debugging
• Clear partitioning → maintainable code
• Early CDC planning → reliable operation

Poor microarchitecture:

• Interface changes late in project → schedule slips
• Inconsistent naming → 2-3x debugging time
• Monolithic modules → hard to test, verify, reuse
• Unplanned CDC → field failures38:["$","$L41",null,{"content":"$42","frontMatter":{"name":"design-microarch","description":"Use when processing RTL modules at the microarchitecture level - including FIFO, state machines, counters, arbiters, decoders, or any Verilog/SystemVerilog hardware design. Load this skill immediately upon identifying RTL design tasks, before diving into brainstorming，planning or implementation."}}]