Verification Pipeline

When you submit a repository — via the web form or the CLI (rr pkg publish) — the registry runs an automated pipeline that discovers your IP, checks it, and assigns trust badges.

Pipeline stages

1. Clone

The registry performs a shallow clone (--depth 1) of your repository at the specified branch or tag. Only public GitHub repositories are supported for web submissions. The clone timeout is 120 seconds.

2. Entity discovery

The dependency resolver scans all .vhd, .vhdl, .v, and .sv files to discover:

• VHDL entities (including architecture bodies, package declarations, and component instantiations)
• Verilog/SystemVerilog modules (including import statements, `include directives, and bind statements)

For each entity, the resolver builds a full dependency chain — every file needed to compile that entity, in the correct order. This is the same resolver used by rr lint and rr sim locally.

3. Test infrastructure detection

The pipeline scans for test frameworks and testbenches using these rules:

The scan counts both the number of detected testbenches and the total test-related files (Python + HDL).

4. Verification (lint)

Each discovered entity is verified by attempting compilation with GHDL (for VHDL) or Verilator (for Verilog/SystemVerilog). The full dependency chain is compiled — not just the top-level file.

An entity passes verification if the entire chain compiles without errors.

5. Badge assignment

Every entity receives badges based on what the pipeline can verify:

Badges are cumulative — an entity can have both linted and tested.

Note: The tested badge means test infrastructure is detected, not that tests were executed. We verify that tests exist and identify the framework, but we do not run them. Running tests against a simulation engine is planned for a future simulated badge.

6. Role classification

Entities are classified by their position in the dependency graph:

Scan response

The pipeline returns:

• Per-entity results: name, language (e.g. vhdl-2008), library, file list, dependency count, verification status, and badges
• Test info: detected frameworks, testbench count, total test file count
• Overall status: scanned (entities found) or empty (no HDL entities discovered)

Web vs CLI

The web form is designed as a "try before you commit" experience. Scan your repo, review the results, then publish via the CLI when you're ready.

Badge roadmap

Badges are incremental — each tier builds on the previous one:

Verified badge (planned)

The verified badge does not require proprietary vendor toolchains. Instead, it works like this:

1. You provide a Dockerfile in your repository that sets up your test environment (cocotb + GHDL, VUnit + NVC, etc.)
2. The registry builds your container and runs your tests inside it
3. If tests pass, your IP gets the verified badge

To prevent gaming, the registry enforces quality thresholds:

• Minimum test count — a single trivial test is not enough
• Minimum simulation time — tests must actually simulate, not just instantiate
• Test diversity — tests should exercise different scenarios, not repeat the same assertion

The philosophy: you prove your IP works, in your own environment. We just validate the results.

Provenance badge (planned)

Signed build attestation via Sigstore: bitstream hash, source inputs, dependency chain, build environment, and timestamps. Cryptographic proof that a specific bitstream came from a specific source.

Supported languages