Reusable ASIC Designs (RAD) – Design¶

Overview¶

The Reusable ASIC Designs (RAD) environment provides a consistent, high‑quality foundation for building reusable SystemVerilog IP within the ABE project. RAD focuses on RTL quality. RAD helps designs achieve:

Consistency across modules
Clean structure for simulation, lint, formal, and synthesis
Compatibility with open‑source tools
Readiness for verification

This document describes the design workflow. It covers what happens after writing RTL and before formal verification and DV.

Audience¶

ASIC architects and RTL designers producing reusable IP

Purpose¶

Establish consistent design conventions
Ensure RTL correctness before formal verification or DV
Provide standard flows for formatting, linting, and synthesis
Speed up adding new designs to the RAD library

Key Features¶

Unified Make targets for RTL formatting, linting, and synthesis
Verible‑based SystemVerilog formatting and linting
Verilator‑based SystemVerilog linting
Yosys‑based synthesis flow (via sv2v)
Standardized directory structure and naming
Reusable shared components under rad/shared

Getting Started¶

Set Up and Install the Environment¶

See ABE Python Development for Python environment setup details.

make py-venv-all
source .venv/bin/activate
make py-install-all

Install Required Tools¶

Run:

make deps-design

This prints any missing host‑side tools. Installation is platform‑specific and outside the scope of this document.

Run Examples¶

make DESIGN=rad_async_fifo rtl-format
make DESIGN=rad_async_fifo rtl-lint-verible
make DESIGN=rad_async_fifo rtl-lint-verilator
make DESIGN=rad_async_fifo synth
make DESIGN=rad_async_fifo synth-report

Examine Outputs¶

rtl-* targets print to the console
synth writes results to out_synth/<design>/

Explore Relevant Directory Layout¶

.
├── mk
│   ├── 00-vars.mk
│   ├── 10-helpers.mk
│   ├── 20-python.mk
│   ├── 30-rtl.mk
│   ├── 40-synth.mk
├── src
│   └── abe
│       ├── rad
│       │   ├── rad_async_fifo
│       │   │   ├── rtl
│       │   │   │   ├── rad_async_fifo_mem.sv
│       │   │   │   ├── rad_async_fifo_rptr.sv
│       │   │   │   ├── rad_async_fifo_sync.sv
│       │   │   │   ├── rad_async_fifo_wptr.sv
│       │   │   │   ├── rad_async_fifo.sv
│       │   │   │   └── srclist.f
│       │   ├── shared
│       │   │   ├── rtl
│       │   │   │   ├── rad_pulse_gen.sv
│       │   │   │   └── rad_timescale.svh
├── Makefile

Makefiles¶

Makefiles are in directory mk

Common flags come from 00-vars.mk.
RTL commands are in 30-rtl.mk.
Synthesis commands are in 40-synth.mk.

Common commands:

make rtl-help
make synth-help

Guidelines for Creating New RAD RTL Designs¶

These guidelines help maintain consistency and tooling compatibility across the RAD library:

Directory Structure¶

Create designs under:

src/abe/rad/rad_<design>/rtl/

Example:

src/abe/rad/rad_async_fifo/rtl/

File Naming¶

RTL filenames should begin with:

rad_<design>*

This naming pattern helps tools find files automatically and keeps designs organized.

Source List File¶

Each design includes:

src/abe/rad/rad_<design>/rtl/srclist.f

This file lists:

SystemVerilog source files
Include directories
Compile-time defines

Every tool (Verilator, Verible, sv2v, Yosys, DV) uses the same srclist.f.

Timescale And Shared Headers¶

RTL should include the shared timescale:

`include "rad_timescale.svh"

Consider using reusable components from:

src/abe/rad/shared/rtl

This avoids reimplementing utilities such as:

Pulse generators
Synchronizers
Common CDC helpers

Clock and Reset Naming¶

For designs with a single clock and reset:

Name the clock clk
Use an active-low reset named rst_n

The DV base classes assume these names, minimizing verification effort. This convention also maintains consistency across all RAD IP.

Reference Design¶

rad_async_fifo is a complete example. It shows the recommended directory structure, conventions, and Make integration.

Static RTL Tools¶

RTL Formatting With Verible¶

Formatting makes code uniform and easy to read.

Uses Verible
Configured in .verible-format

Run:

make DESIGN=<design> rtl-format

RTL Linting With Verible¶

Verible catches:

Style and naming issues
Structural problems
Common SystemVerilog pitfalls

Run:

make DESIGN=<design> rtl-lint-verible

RTL Linting With Verilator¶

Verilator checks for deeper issues:

Type mismatches
Unsupported constructs
Missing signals
Simulation readiness

Run:

make DESIGN=<design> rtl-lint-verilator

Verilator linting is important because RAD DV uses Verilator as the default simulator.

Synthesis Flow¶

Yosys synthesis checks that designs can be synthesized and provides statistics.

End‑to‑End Flow¶

sv2v converts SystemVerilog → Verilog
Yosys synthesizes the Verilog
Reports are written to:

out_synth/<design>/

Invoke Synthesis¶

make DESIGN=<design> synth

Examine Synthesis Outputs¶

File	Description
`<design>.v`	sv2v converted Verilog
`<design>_net.v`	Gate-level netlist
`<design>_net.json`	Structural JSON netlist
`stat_width.txt`	Wire/port/cell counts
`yosys.log`	Full synthesis log

View Statistics¶

make DESIGN=<design> synth-report

Graph Visualization¶

make DESIGN=<design> synth-dot

Creates:

out_synth/<design>/<design>.dot

This graph helps you understand how modules connect.

FAQ¶

Should I run Verible before checking in RTL?¶

Yes. RAD uses consistent formatting across all designs. Run:

make DESIGN=<design> rtl-format

See RTL Formatting for details.

Why does Verilator catch errors that Verible misses?¶

Verilator checks meaning (like a compiler). Verible checks structure and style. They work together to find different types of errors.

See RTL Linting – Verible and RTL Linting – Verilator for details.

Should every RAD design go through synthesis?¶

Yes. Running synthesis early has several benefits:

Verifies the design can be synthesized
Catches issues linters may miss
Helps avoid problems later in formal verification or DV

See Synthesis Flow for details.

Why does synthesis use sv2v?¶

Yosys provides excellent Verilog support. sv2v enables consistent conversion from SystemVerilog to Verilog, allowing us to use Yosys effectively.

See End‑to‑End Flow for details.

What if my module needs vendor-specific cells?¶

Wrap vendor cells in SystemVerilog wrappers. This keeps the RAD synthesis flow open‑source and portable.

Can I add custom lint rules?¶

Yes. Edit:

.rules.verible_lint for Verible
00-vars.mk for Verilator flags

Why separate design, formal, and DV directories?¶

Separate directories provide:

Independent Make flows
Reproducible builds
Clean organization

See RAD Formal and RAD DV for details on those flows.

References¶

Licensing¶

See the LICENSES directory at the repository root.