Extensible RTL‑Level Verification for Future Regression and Co‑Simulatio

PySilicon approaches verification as a layered process that begins with fast, deterministic functional simulation and extends naturally toward RTL‑level verification. The current implementation focuses on architectural correctness and reproducibility, while the design of PySilicon explicitly supports future integration of RTL‑level regression tests.

Functional Simulation as the Authoritative Behavioral Model

All hardware objects (HwObj) define their behavior through Python action methods or PyTorch FX graphs. These definitions drive a fast, event‑driven simulation that serves as the authoritative functional model. This simulation supports:

• hardware‑level unit tests
• environment‑level tests
• full system co‑simulation (e.g., radar → channel → FFT → detector)
• deterministic, reproducible execution
• gating tests in the build DAG

Because the simulation is derived from the same Python specification used for synthesis, it provides strong guarantees of architectural correctness.

Gated Builds Through the Dependency Graph

The build DAG ensures that:

• all functional tests must pass before synthesis
• system‑level tests must pass before Vivado integration
• no partial or inconsistent builds are produced
• firmware, documentation, and hardware remain synchronized

This provides a level of reproducibility and discipline that current AI‑hardware tools lack.

RTL‑Level Verification as a Natural Extension

Although PySilicon does not yet include RTL‑level regression tests, the architecture is explicitly designed to support them. Because all ports, interfaces, and transactional semantics are defined in Python, PySilicon can generate:

• RTL testbenches for custom HLS modules
• Vivado or Xcelium simulation scripts
• cocotb‑based co‑simulation harnesses
• randomized ready/valid and backpressure tests
• concurrency and race‑condition stress tests
• wrappers for AMD IP blocks (FFT engines, DMA, SmartConnect, etc.)

These capabilities can be added incrementally without redesigning PySilicon.

Practical Considerations for RTL Testing

Some RTL‑level tests can be delegated to Vitis HLS, but HLS has known limitations:

• difficulty testing concurrent modules
• inability to test pre‑built AMD IP blocks
• limited support for system‑level interactions

For full RTL verification, PySilicon will need to generate low‑level Verilog/SystemVerilog testbenches or cocotb drivers. This is engineering work, not a conceptual barrier.

Positioning for the Current Paper

The current implementation already provides:

• deterministic functional simulation
• gating unit tests
• reproducible synthesis
• unified hardware/firmware/simulation semantics

These capabilities exceed what any existing AI‑assisted hardware toolchain offers. RTL‑level verification is a planned extension, and the architecture is designed to support it cleanly.

A concise statement for the paper:

PySilicon focuses on deterministic functional simulation and reproducible synthesis. Because all hardware objects and transactional semantics are defined in Python, PySilicon can auto‑generate RTL testbenches and Vivado/Xcelium simulation flows in future work. This is an engineering extension rather than a conceptual limitation of the architecture.