Feature · Design Context

Every reference checked against the real design

Give Ṛta your structural Verilog netlist and it verifies that every port, pin, cell and net your SDC refers to actually exists. No netlist? It says so honestly instead of guessing.

In plain words

What does "design context" mean?

Your SDC references objects: ports like data_in, pins like u_reg/clk, nets and cells. Design context is the netlist that proves those objects exist. Without it, a typo is invisible. With it, every reference is verified.

Ṛta uses the netlist in three ways:

✓Object existence: SDC-055/056 checks whether the referenced port or pin exists.
✓Hierarchy: instances resolve to full paths like u_core/u_reg.
✓Pin classification: clock, reset, scan and test pins are identified, which powers the advanced rules.


$ rta check top.sdc --netlist top.v --top top
Design context: top (4 ports, 2 instances)
  ✓ references: 61/61 resolved
  ✗ SDC-055 [get_ports datat_in] - no such port
      closest match: data_in (L14)

Real-world example

Two modes, two very different answers

SDC-only mode

Ṛta checks syntax and structure, but object references cannot be verified. It says so explicitly: object existence and coverage are unverifiable without a netlist.

Design-aware mode

Every reference is resolved against the netlist. Typos are caught, coverage is per-object, reset trees and scan pins are classified, exceptions are proven.

✓ The honest middle ground. Even in SDC-only mode, Ṛta never pretends references are valid. It reports NETLIST_REQUIRED and moves on, which is far more useful than a false "all good".

Try it

Validate against your netlist

Design-aware check

$ rta check your_block.sdc --netlist top.v --top top
# --top names the top module when the netlist is ambiguous

Try it in the app ↗ All features