RFC: an intent contract for structural evaluation of generated RTL

[shsridhar-beep]

Structural properties (clock-domain crossings, reset semantics, power-on coverage) are only evaluable when the task declares the intent an oracle consumes. SV-Gap's manifest currently declares clock groups, asynchrony, reset assertion and deassertion semantics, crossing protocol, and power-on coverage expectations: see schemas/manifest-v1.example.toml.

The question for this thread: does this contract express the production questions you actually need answered?

• Which intent fields are missing for your property classes?
• Which declarations would your team refuse to write down, and why?
• What would make this contract adoptable as a benchmark-task standard?

Sanitized answers only; question classes, not proprietary designs. One sentence is a useful contribution.

[shsridhar-beep]

First data against this thread's question from outside the project: the independent RTL designer review returned this week (protocol, returned files, and claim boundaries: independent review result, raw files under artifacts/independent-review-v0.1/). While judging the controlled witness pairs and the repository questionnaire, the reviewer identified intent the current manifest does not carry. Posting his findings here as candidate fields for this contract:

1. Reset source context. His REF-RDC-001 judgment carried the qualifier that we do not know where arst_n comes from: a reset arriving from a reset distribution tree may already be synchronized upstream, so whether a reset synchronizer is even needed depends on the source. Candidate declaration: a reset source class (raw external, distribution tree, generated on-die) or an explicit externally-synchronized attestation per reset.

2. MTBF target. Whether a two-stage synchronizer suffices is not a yes/no structural fact; three stages or feedback may be required depending on the metastability budget. Candidate declaration: a target MTBF or a synchronizer-depth policy the oracle checks against, instead of the current implicit two-stage assumption.

3. Value-skip tolerance on multi-bit crossings. Gray coding gives coherency, not completeness: the destination may skip values. Whether that is acceptable is functional intent, not a structural universal. Candidate declaration: a per-crossing completeness expectation (every value must be observed, or monotonic sampling is acceptable).

4. Synchronous co-operand assumption. The combinational-logic-before-synchronizer rule assumes co-operands are timed synchronously; today that assumption is implicit. Candidate: declare it in the contract, or scope the rule's claim to say it.

Open question for the thread: which of these belong in the task-level contract, and which in the evaluator's configuration? A benchmark task can honestly declare that its reset arrives raw, but few tasks can state an MTBF budget. Is default-with-override the right shape?

The reviewer is credited by name in published results. If he wants to correct this summary or extend it here, that is welcome, and disagreement is data.

[seshuparavastu]

The summary of my review looks accurate to me. Just to add to what is already said :

For the Reset source context, using a Reset Distribution Tree is much more area area efficient, otherwise you end up using a reset sync for each module.

For the REF-XPROP-001 - I would expect the simulator to catch this in the X propagation mode.