The difficulty in verifying runtime recalibration is not the recalibration request itself.
It is the possibility that the request overlaps with everything else the link is doing.
Traffic may be idle, bursty or saturated. The link may be operating at a supported high data rate or with repaired or degraded lanes. Firmware may request recalibration while the power controller is preparing to enter a lower-power state. An error, timeout or reset may interrupt the sequence.
A single directed test cannot represent that state space.
A more scalable approach is to model runtime recalibration as a scenario matrix and generate tests from explicit, reviewable dimensions.
UCIe 3.0 introduces runtime recalibration as part of its link-management and power-efficiency enhancements. Combined with higher data rates and expanded management behaviour, this makes cross-layer interaction testing an important part of chiplet verification.
For the wider verification architecture, including formal verification, emulation, FPGA prototyping, interoperability and post-silicon sign-off, see the Alpinum UCIe 3.0 chiplet verification guide.
1. Define the Dimensions Before Writing Sequences
Start with the variables that can change the required behaviour.
A practical initial matrix might include:
trigger:
periodic
firmware_requested
condition_detected
simultaneous_request
traffic:
idle
low_rate
saturated
bidirectional
mixed_protocol
rate:
supported_base_rate
48_gt_s
64_gt_s
lane_state:
nominal
repaired
degraded
power:
active
entering_low_power
leaving_low_power
thermal_throttle
outcome:
success
rejected
timeout
interrupted
retry
reset_recovery
Not every Cartesian-product combination will be legal, supported or useful. The generator therefore needs explicit constraints.
For example:
- A product may not support 64 GT/s with a repaired-lane configuration.
- Some recalibration triggers may be unavailable during particular power transitions.
- A timeout scenario may require a controllable partner model.
- Mixed-protocol traffic may not apply to every delivered configuration.
These are product or verification constraints. They are not reasons to hide the dimension.
2. Put Product Support in Data
Avoid scattering support rules throughout sequence code.
Represent them in a product-configuration object:
product = {
"rates": [
"48_gt_s",
"64_gt_s",
],
"traffic_modes": [
"idle",
"low_rate",
"saturated",
"bidirectional",
],
"lane_states": [
"nominal",
"repaired",
"degraded",
],
"power_states": [
"active",
"entering_low_power",
"leaving_low_power",
],
"supports_repaired_lane_at_64_gt_s": False,
"firmware_trigger_enabled": True,
"timeout_injection_enabled": True,
}
The same source should:
- Configure the verification environment
- Generate supported scenarios
- Identify prohibited combinations
- Explain coverage exclusions
- Support integration and post-silicon correlation
This makes exclusions reviewable.
Without a shared configuration source, a testbench can generate a combination that the product does not support, or omit one that it does.
3. Generate Scenarios with Explicit Validity Rules
A simplified scenario generator could look like this:
from dataclasses import dataclass
from itertools import product as cartesian_product
@dataclass(frozen=True)
class Scenario:
trigger: str
traffic: str
rate: str
lane_state: str
power: str
outcome: str
def is_valid(scenario: Scenario, product_config: dict) -> tuple[bool, str]:
if scenario.rate not in product_config["rates"]:
return False, "unsupported product data rate"
if scenario.traffic not in product_config["traffic_modes"]:
return False, "unsupported traffic mode"
if scenario.lane_state not in product_config["lane_states"]:
return False, "unsupported lane state"
if scenario.power not in product_config["power_states"]:
return False, "unsupported power state"
if (
scenario.trigger == "firmware_requested"
and not product_config["firmware_trigger_enabled"]
):
return False, "firmware-triggered recalibration is disabled"
if (
scenario.rate == "64_gt_s"
and scenario.lane_state == "repaired"
and not product_config["supports_repaired_lane_at_64_gt_s"]
):
return False, "64 GT/s is unsupported with repaired lanes"
if (
scenario.outcome == "timeout"
and not product_config["timeout_injection_enabled"]
):
return False, "timeout injection is unavailable"
if not policy_allows(
scenario.trigger,
scenario.power,
scenario.outcome,
):
return False, "prohibited by product policy"
return True, "supported"
scenarios = []
exclusions = []
for values in cartesian_product(
TRIGGERS,
TRAFFIC_MODES,
RATES,
LANE_STATES,
POWER_STATES,
OUTCOMES,
):
scenario = Scenario(*values)
valid, reason = is_valid(scenario, product)
if valid:
scenarios.append(scenario)
else:
exclusions.append(
{
"scenario": scenario,
"reason": reason,
}
)
The important output is not only the generated scenario list.
It is also the exclusion report.
Every excluded combination should have a reason such as:
- Unsupported product configuration
- Prohibited specification or product-policy state
- Redundant equivalence class
- Unavailable fault-injection mechanism
- Deferred to another verification environment
- Accepted residual risk
“Not generated” is not an adequate closure argument.
4. Separate Stimulus from the Expected Result
A common verification mistake is allowing the stimulus sequence to decide whether the design passed.
The stimulus should create the condition. Independent checkers should evaluate the behaviour.
- For each scenario, define expected properties such as:
- Recalibration begins only from an allowed state.
- Both link partners agree on the transition.
- Packet and transaction ordering guarantees are preserved.
- Credits are neither lost nor duplicated.
- Completion occurs within the configured bound.
- A timeout produces the specified status.
- Recovery reaches an allowed endpoint.
- Traffic resumes only when policy permits.
- Firmware receives the expected notification.
- Reset does not leave either partner in an ambiguous state.
These checks can be distributed across:
- Protocol assertions
- State-transition assertions
- End-to-end scoreboards
- Credit-conservation checks
- Firmware-status monitors
- Common-timeline event correlation
- Formal properties for bounded completion and liveness
Formal verification is particularly useful for control-heavy interleavings that are difficult to reproduce consistently in simulation.
It should use the same state, configuration and policy model as the rest of the verification environment,not a separate interpretation of expected behaviour.
5. Give Every Scenario a Stable Identity
A failure should be reproducible without copying an entire simulator command line from a regression dashboard.
Create a stable scenario identifier from the matrix dimensions:
def make_scenario_id(scenario: Scenario) -> str:
return (
f"recal"
f"trigger_{scenario.trigger}"
f"traffic_{scenario.traffic}"
f"rate_{scenario.rate}"
f"lane_{scenario.lane_state}"
f"power_{scenario.power}"
f"outcome_{scenario.outcome}"
)
Store the following metadata with every execution:
- Scenario ID
- Random seed
- Product-configuration version
- RTL version
- Firmware version
- Partner-model or verification-IP version
- Fault-injection settings
- Expected endpoint
- Coverage bins
- Test result
- Failure signature
The same identity can be reused in simulation, formal analysis, emulation, FPGA prototyping and post-silicon planning.
An emulation implementation may run production firmware rather than a verification sequence. A laboratory implementation may use traffic generators and telemetry. The scenario identity can still preserve the original verification intent.
6. Build Coverage from Risk, Not Equal Weighting
A six-dimensional cross can become extremely large.
Do not treat every combination as equally important.
Prioritise combinations in which independently controlled mechanisms can interfere:
- Recalibration during saturated traffic
- Recalibration during low-power entry
- Simultaneous requests from both link partners
- Repaired or degraded lanes at the highest supported rate
- Firmware request combined with timeout
- Recalibration interrupted by reset
- Retry while priority management traffic is active
- Recalibration during mixed-protocol traffic
- Recovery followed immediately by another power transition
Create mandatory coverage bins for these combinations.
Lower-risk combinations may use pairwise sampling or representative equivalence classes, provided that the rationale is recorded and reviewed.
A useful coverage report should distinguish between:
- Required and covered
- Required and failing
- Required and blocked
- Excluded with an approved reason
- Unsupported by the delivered product
- Planned in another environment
- Accepted as residual risk
A single percentage hides these differences.
7. Use a Repeatable Debugging Pattern
When a scenario fails, debug it in a consistent order.
A. Confirm Scenario Legality
Was the generated combination supported by the selected product configuration and the current implementation revision?
B. Find the First Divergent Event
Do not begin with the final timeout.
Compare the common timeline for:
- Trigger
- Acknowledgement
- Traffic quiescence or permitted continuation
- State entry
- Calibration activity
- Completion status
- Traffic restoration
C. Separate Local and Partner Behaviour
Determine whether the initiating link partner, responding link partner, firmware policy or verification environment violated the expected contract.
D. Check Conservation Properties
Look for lost or duplicated:
- Credits
- Packets
- Acknowledgements
- Outstanding transactions
- Management operations
E. Re-run with Controlled Simplification
Reduce traffic, remove the power transition or disable one injected fault while preserving a traceable relationship to the original scenario ID.
This helps distinguish the triggering interaction from the underlying defect.
F. Preserve the Failure Signature
Cluster future failures by:
- First divergent event
- Violated property
- State-transition mismatch
- Recovery endpoint
Do not group failures only by final test name.
8. Carry the Matrix into Longer-Running Environments
Some defects require software scale, extended execution or real platform behaviour.
Move selected matrix scenarios into emulation or FPGA prototyping when they involve:
- Real firmware download or policy
- Operating-system interaction
- Repeated recalibration
- Long-duration traffic
- Resource leakage
- Thermal or power-management policy
- Large numbers of recovery cycles
The test implementation will change, but the scenario dimensions and expected evidence should remain consistent.
That is the main advantage of a matrix-driven approach: verification intent remains portable even when the execution platform changes.
Final Checklist
Before closing runtime-recalibration verification, confirm that:
- Scenario dimensions are explicit.
- Data rate and lane state are modelled separately.
- Product constraints are stored in structured data.
- Every exclusion has an approved reason.
- Stimulus and checking are independent.
- Control properties are analysed formally where appropriate.
- High-risk crosses are mandatory.
- Scenario identity is reproducible.
- Firmware, RTL and model versions are recorded.
- Long-running scenarios move to a suitable platform.
- Post-silicon correlation points are defined.
- Residual risks have named decision owners.
Runtime recalibration should not be treated as one feature test.
It is a family of cross-layer state transitions involving link control, traffic, firmware, power management and recovery.
Model it that way, and the programme gains more meaningful coverage, more reproducible failures and a clearer sign-off argument.
For the complete verification architecture and sign-off checklist, read the UCIe 3.0 chiplet verification guide from Alpinum Consulting.
Which matrix dimension produces the greatest verification risk in your programme: traffic load, lane condition, firmware ownership, power transition or recovery outcome?
Top comments (0)