|
| 1 | +- Start Date: (fill in with date at which the RFC is merged, YYYY-MM-DD) |
| 2 | +- RFC PR: [amaranth-lang/rfcs#0075](https://github.com/amaranth-lang/rfcs/pull/75) |
| 3 | +- Amaranth Issue: [amaranth-lang/amaranth#0000](https://github.com/amaranth-lang/amaranth/issues/0000) |
| 4 | + |
| 5 | +# Property labels |
| 6 | + |
| 7 | +## Summary |
| 8 | +[summary]: #summary |
| 9 | + |
| 10 | +Add a `label` argument to the `Assume`, `Assert` and `Cover` statements, that gets converted to a statement label in the verilog backend. |
| 11 | + |
| 12 | +## Motivation |
| 13 | +[motivation]: #motivation |
| 14 | + |
| 15 | +Formal verification tools like [sby](https://github.com/YosysHQ/sby) or [Jasper](https://www.cadence.com/en_US/home/tools/system-design-and-verification/formal-and-static-verification.html) use the statement labels of `assert`, `assume` and `cover` statements in verilog sources to produce more human friendly messages and names. |
| 16 | +For example `sby` prints a message like |
| 17 | +``` |
| 18 | +Assert failed in $MODULE_NAME: $LABEL |
| 19 | +``` |
| 20 | +instead of |
| 21 | +``` |
| 22 | +Assert failed in top: $FILENAME:$LINENO |
| 23 | +``` |
| 24 | +if a label is present. By choosing a meaningful label it can be easier to identify the failing assertion. |
| 25 | + |
| 26 | +## Guide-level explanation |
| 27 | +[guide-level-explanation]: #guide-level-explanation |
| 28 | + |
| 29 | +The optional `label` argument of the `Assert`, `Assume` and `Cover` statements assigns a string label to the respective statement. For example |
| 30 | +```python |
| 31 | +m = Module() |
| 32 | +a = Signal() |
| 33 | +b = Signal() |
| 34 | +m.d.comb += Assert(a + b == 3, label="one_plus_two_is_three") |
| 35 | +``` |
| 36 | +The verilog backend will convert this label into a statement label for the corresponding `assert` statement. This label will then usually be used by formal verification tooling to refer to this statement. The previous example would generate verilog akin to |
| 37 | +```verilog |
| 38 | +always @* |
| 39 | + one_plus_two_is_three: assert(a + b == 3); |
| 40 | +``` |
| 41 | + |
| 42 | +## Reference-level explanation |
| 43 | +[reference-level-explanation]: #reference-level-explanation |
| 44 | + |
| 45 | +Add a optional `label` argument to `Assume`, `Assert` and `Cover`. This argument can either be `None` or a string containing no whitespaces. If not `None`, the label is used in the `rtlil` backend as the name of the corresponding `$check` cell. Since https://github.com/YosysHQ/yosys/pull/4877 this name will then be converted to a statement label in the `verilog` backend. |
| 46 | + |
| 47 | +## Drawbacks |
| 48 | +[drawbacks]: #drawbacks |
| 49 | + |
| 50 | +- To generate statement labels in the verilog backend https://github.com/YosysHQ/yosys/pull/4877 is required, which raises the minimum required yosys version. |
| 51 | +- Using `str` as the type of labels does not make it clear that no whitespace characters are allowed from the type alone. |
| 52 | +- For `sby` this stops the filename and linenumber of the source of the property from being printed. This might make it harder find the correct file / line. |
| 53 | + |
| 54 | +## Rationale and alternatives |
| 55 | +[rationale-and-alternatives]: #rationale-and-alternatives |
| 56 | + |
| 57 | +Using statement labels for `assert`, `assume` and `cover` seems to be the de facto standard for formal verification in `systemverilog`. For Jasper it is, to my knowledge, the only source used for the name of a property. In particular it also does not use the `src` attribute like `sby` does to attribute the property to the filename / linenumber specified therein. |
| 58 | + |
| 59 | +## Prior art |
| 60 | +[prior-art]: #prior-art |
| 61 | + |
| 62 | +Amaranth supported a `name` argument for properties that was lowered the same way until [RFC 50](https://amaranth-lang.org/rfcs/0050-print.html) was implemented in https://github.com/amaranth-lang/amaranth/commit/bfe541a6d7f63b7a8402d86aa51e741c7d1c97bd, where it was replaced with the message argument. |
| 63 | + |
| 64 | +## Unresolved questions |
| 65 | +[unresolved-questions]: #unresolved-questions |
| 66 | + |
| 67 | +- What should happen with duplicate labels? Should this be a error, or should amaranth generate unique labels and potentially warn on duplicates? |
| 68 | +- Should the argument be called `label` or `name`? `label` would be closer to the corresponding verilog feature of statement labels, but amaranth used to call this `name`. |
| 69 | +- Should labels that have to be escaped in the verilog backend be supported? `write_verilog` supports this, however the generated verilog cannot be parsed by yosys, as it only supports a `simple_identifier` as statement label (See [here](https://github.com/YosysHQ/yosys/blob/18a7c00382cd64d46b61ff6cafe80851ca29cb77/frontends/verilog/verilog_lexer.l#L251-L253)). |
| 70 | +- How should `pysim` handle these labels? |
| 71 | + |
| 72 | +## Future possibilities |
| 73 | +[future-possibilities]: #future-possibilities |
| 74 | + |
| 75 | +None |
0 commit comments