| # OTBN functional coverage |
| |
| We distinguish between *architectural* and *micro-architectural* functional coverage. |
| The idea is that the points that go into architectural coverage are those that a DV engineer could derive by reading the block specification. |
| The points that go into micro-architectural coverage are those that require knowledge of the block's micro-architecture. |
| Some of these will come from DV engineers; others from the block's designers. |
| These two views are complementary and will probably duplicate coverage points. |
| For example, an architectural coverage point might be "the processor executed `ADDI` and the result overflowed". |
| This might overlap with something like "the `overflow` signal in the ALU was true when adding". |
| |
| # Block-based coverage |
| |
| ## Call stack |
| |
| The [call stack](../README.md#call-stack) is exposed as a special register behind `x1`. |
| It has a bounded depth of 8 elements. |
| We expect to see the following events: |
| |
| - Push to the call stack |
| - Pop from the call stack |
| - Push and pop from the call stack on a single instruction |
| - An instruction with multiple reads from `x1` |
| |
| All four of these events should be crossed with the three states of the call stack: empty, partially full, and full. |
| |
| > Coverage for these points is tracked in the `call_stack_cg` covergroup. |
| > We track all possible combinations of push/pop flags (8 possibilities) in `flags_cp`. |
| > The 3 different fullness states are tracked as `fullness_cp`. |
| > These are then crossed to give `flags_fullness_cross`. |
| |
| ## Loop stack |
| |
| The [loop stack](../README.md#loop-stack) is accessed by executing `LOOP` and `LOOPI` instructions. |
| Events concerning the start of loops are tracked at those instructions, but we can't track things like loop completion there. |
| |
| > Coverage for these points is tracked with cover properties in the `otbn_loop_if` interface. |
| |
| We expect to: |
| - Complete a loop. |
| Tracked as `LoopEnd_C`. |
| - Complete the last loop on the stack (emptying it) after the stack has been full. |
| Tracked as `FullToEmpty_C`. |
| - Complete a loop with one instruction and an iteration count of one. |
| Tracked as `ShortestLoop_C`. |
| - Complete a loop with the maximal number of iterations. |
| Obviously, this isn't a reasonable thing to do for real in a test (there's a 32-bit iteration counter!). |
| The testbench will have to force a signal to skip past some iterations. |
| Tracked as `MaximalLoop_C`. |
| - Run through a "badly nested" loop, where the body contains the final instruction from an outer loop (checking that we don't wrongly skip back). |
| Tracked as `BadNestingEnd_C` and `BadNestingMiddle_C`. |
| - Jump into a loop body from outside. |
| Tracked as `JumpIntoLoop_C`. |
| - Jump/branch to the final instruction of a loop |
| Tracked as `JumpToLoopEnd_C`. |
| |
| ## CSRs and WSRs |
| |
| Accesses to CSRs and WSRs are tracked in the coverage for the instructions that access them. |
| See [CSRRS](#csrrs) and [CSRRW](#csrrw) for CSRs; [BN.WSRR](#bnwsrr) and [BN.WSRW](#bnwsrw) for WSRs. |
| |
| ## Random numbers |
| |
| Random numbers are exposed to OTBN code through the `RND` and `URND` CSRs and WSRs. |
| A new random number can be prefetched for `RND` with the `RND_PREFETCH` CSR. |
| |
| We track uses of each of these CSRs and WSRs in the instructions that access them. |
| See [CSRRS](#csrrs) and [CSRRW](#csrrw) for CSRs; [BN.WSRR](#bnwsrr) and [BN.WSRW](#bnwsrw) for WSRs. |
| However, we also want to see some interactions between `RND` and `RND_PREFETCH`. |
| These are all tracked with cover properties in `otbn_rnd_if.sv`. |
| |
| Specifically, we expect to see: |
| |
| - An read of `RND` (either CSR or WSR) before any write to `RND_PREFETCH`. |
| This is tracked with the `RndWithNoPrefetch_C` cover property. |
| - Two consecutive writes to `RND_PREFETCH` without a random value arriving between. |
| This is tracked with the `PrefetchPrefetch_C` cover property. |
| - Two consecutive writes to `RND_PREFETCH`, where a random value arrives between them. |
| This is tracked with the `FullPrefetch_C` cover property. |
| - A write to `RND_PREFETCH` followed by a read from `RND` after the random value has arrived. |
| This is tracked with the `FullRead_C` cover property. |
| - A write to `RND_PREFETCH` followed by a read from `RND` before the random value has arrived. |
| This is tracked with the `PrefetchingRead_C` cover property. |
| |
| |
| |
| ## Flags |
| |
| Each flag in each flag group should be set to one from zero by some instruction. |
| Similarly, each flag in each flag group should be cleared to zero from one by some instruction. |
| |
| > These events are tracked in `flag_write_cg`. |
| > This is called from `on_insn()` once for each flag group that is being written. |
| > The covergroup contains eight coverpoints (for each flag set and cleared). |
| > These are then crossed with the flag group. |
| |
| ## Instruction counter |
| |
| See the instruction counter saturate. |
| |
| > This is tracked in the `insn_cnt_if` interface with the `InsnCntSaturated_C` cover property. |
| |
| ## Key sideload interface |
| |
| We expect to see reads from this interface (both when a key is present and when it is not). |
| The coverage for these reads is tracked in the [BN.WSRR](#bnwsrr) instruction which does the reading. |
| |
| ## Integrity protection |
| |
| The contents of IMEM and DMEM, the register file, and other pieces of internal state are protected by ECC integrity bits. |
| We want to see errors/alerts caused by corrupting each of these pieces of state. |
| Rather than tracking this with functional coverage, we rely on testplan entries. |
| |
| See the `mem_integrity` and `internal_integrity` entries in the testplan for more details. |
| |
| ## Lifecycle escalation |
| |
| The lifecycle controller can send a "lifecycle escalation" signal to tell OTBN to clear its internal state and to raise its own fatal error. |
| |
| We expect to see this happen. |
| However, we don't track coverage for this explicitly since it's handled at the testplan level (with the `lc_escalation` testpoint). |
| |
| ## Error promotion |
| |
| If the `CTRL.software_errs_fatal` field is set then a software error which would normally trigger a recoverable alert will trigger a fatal alert. |
| We expect to see each software error triggered and upgraded to a fatal alert. |
| |
| This is tracked in the `promoted_err_cg` covergroup. |
| |
| Note that we already track seeing each software error triggered (but not upgraded) with the coverage for `ERR_BITS` in the [external CSRs](#ext-csrs) section below. |
| |
| ## Scratchpad memory |
| |
| A portion of DMEM is inaccessible from the bus. |
| We want to see accesses (read and write) to both endpoints of the inaccessible portion of DMEM when OTBN is in an idle state (so would otherwise allow them). |
| These are tracked in the `addr_cp` coverpoint in `scratchpad_writes_cg`. |
| |
| We also want to see a successful write to the top word of accessible DMEM. |
| We don't track that explicitly, since it is covered by the `otbn_mem_walk` test. |
| |
| ## External (bus-accessible) CSRs {#ext-csrs} |
| |
| The OTBN block exposes functionality to a bus host through bus-accessible CSRs. |
| Behavior of some CSRs depends on [OTBN's operational state](../../README.md#design-details-operational-states). |
| |
| For every CSR (no matter its access restrictions), we want to see an attempt to read it and an attempt to write it. |
| The CSRs are tracked in covergroups based on the CSR name, with the format: `ext_csr_<name>_cg`. |
| Each has an `access_type_cp` coverpoint which will track read and write attempts. |
| |
| If writes to the CSR behave differently depending on the operational state, we cross attempts to write with the operational state. |
| For CSRs like `CMD`, which have an immediate effect, this is easy to handle. |
| For CSRs that need a follow-up read to check their value, this is handled with the `ext_csr_wr_operational_state_cg` covergroup. |
| We track the last write state for a CSR and then sample that covergroup when the value is read back. |
| |
| ### CMD |
| |
| Coverage is tracked in the `ext_csr_cmd_cg` covergroup. |
| |
| We want to see all valid commands (plus at least one invalid command) being written in each operational state. |
| This ensures commands are ignored as expected when OTBN is busy or locked. |
| It also ensures that bad commands are ignored as expected. |
| |
| The `cmd_cp` bin covers the different types of commands. |
| It is crossed with the operational state in `cmd_state_cross`. |
| We check that we see a read (as well as a write) with the `access_type_cp` coverpoint. |
| |
| ### CTRL |
| |
| Coverage is tracked in the `ext_csr_ctrl_cg` covergroup. |
| |
| We expect to see this written with each of zero and one in the idle state (where it should take an effect). |
| This is tracked in `value_cp`. |
| |
| We check that we see a read (as well as a write) with the `access_type_cp` coverpoint. |
| |
| We expect to see this written in each operational state, tracked with the `ext_csr_wr_operational_state_cg` covergroup. |
| |
| We also want to see this be set back to zero after an operation has run with it set to one, then trigger a software error. |
| This ensures that we can indeed disable the fatal error promotion mechanism. |
| |
| **TODO: This part is not currently tracked.** |
| |
| ### STATUS |
| |
| Coverage is tracked in the `ext_csr_status_cg` covergroup. |
| |
| We want to see a read of all valid status codes. |
| This is tracked in `status_cp`. |
| We check that we see a write (as well as a read) with the `access_type_cp` coverpoint. |
| |
| ### ERR_BITS |
| |
| Coverage is tracked in the `ext_csr_err_bits_cg` covergroup. |
| |
| We want to see that every valid bit is read at least once. |
| This is tracked in coverpoints with names of the form `err_bits_<errcode>_cp`. |
| We also want to see a read in each operational state. |
| This is tracked in `state_cp`. |
| |
| We want to see a write to this register in each operational state when it was previously nonzero. |
| This checks that the clearing behaviour works properly. |
| We don't have to follow up with another read because we've got continuous checks that the RTL value of this register matches the ISS. |
| This is tracked in `clear_state_cross`. |
| |
| We want to see both reads and writes. |
| This is tracked in `access_type_cp`. |
| |
| ### FATAL\_ALERT_CAUSE |
| |
| Coverage is tracked in the `ext_csr_fatal_alert_cause_cg` covergroup. |
| |
| We want to see that every valid bit is read at least once. |
| This is tracked in coverpoints with names of the form `fatal_alert_cause_<errcode>_cp`. |
| We also want to see a read in each operational state. |
| This is tracked in `state_cp`. |
| |
| We check that we see a write (as well as a read) with the `access_type_cp` coverpoint. |
| |
| ### INSN_CNT |
| |
| Coverage is tracked in the `ext_csr_insn_cnt_cg` covergroup. |
| |
| We want to see a read returning a zero and a non-zero value. |
| This is tracked in `insn_cnt_cp`. |
| We also want to see a read in every operational state. |
| This is tracked in `state_cp`. |
| |
| We want to see a write to this register in each operational state when it was previously nonzero. |
| This checks that the clearing behaviour works properly. |
| We don't have to follow up with another read because we've got continuous checks that the RTL value of this register matches the ISS. |
| This is tracked in `clear_state_cross`. |
| |
| ### LOAD_CHECKSUM |
| |
| We want to see a write to the register (that changes its value), followed by an update caused by writing to memory, finally followed by a read of the register value. |
| This is tracked in the `ext_csr_load_checksum_wur_cg` covergroup. |
| |
| We also want to see a write in every operational state, followed by a read before the next write. |
| This is tracked in the `ext_csr_wr_operational_state_cg` covergroup. |
| |
| # Instruction-based coverage |
| |
| As a processor, much of OTBN's coverage points are described in terms of instructions being executed. |
| Because OTBN doesn't have a complicated multi-stage pipeline or any real exception handling, we don't track much temporal information (such as sequences of instructions). |
| |
| As well as instruction-specific coverage points detailed below, we include a requirement that each instruction is executed at least once. |
| |
| For any instruction with one or more immediate fields, we require "toggle coverage" for those fields. |
| That is, we expect to see execution with each bit of each immediate field being zero and one. |
| We also expect to see each field with values `'0` and `'1` (all zeros and all ones). |
| If the field is treated as a signed number, we also expect to see it with the extremal values for its range (just the MSB set, for the most negative value; all but the MSB set, for the most positive value). |
| |
| > The code to track this is split by encoding schema in `otbn_env_cov`. |
| > Each instruction listed below will specify its encoding schema. |
| > Each encoding schema then has its own covergroup. |
| > Rather than tracking toggle coverage as described above, we just track extremal values in a coverpoint. |
| > This also implies toggle coverage for both signed and unsigned fields. |
| > For unsigned fields of width `N`, the extremal values are `0` and `(1 << N) - 1`, represented by the bits `'0` and `'1` respectively. |
| > For signed fields of width `N+1`, the extremal values are `-(1 << N)` and `(1 << N) - 1`. |
| > These are represented by `{1'b1, {N{1'b0}}}` and `{1'b0, {N{1'b1}}}`: again, these toggle all the bits. |
| > For example, `beq` uses the `B` schema, which then maps to the `enc_b_cg` covergroup. |
| > This encoding schema's `OFF` field is tracked with the `off_cp` coverpoint. |
| > Finally, the relevant cross is called `off_cross`. |
| |
| For any instruction that reads from or writes to a GPR, we expect to see that operand equal to `x0`, `x1` and an arbitrary register in the range `x2 .. x31`. |
| We don't have any particular coverage requirements for WDRs (since all of them work essentially the same). |
| |
| > As for immediates, the code to track this is split by encoding schema in `otbn_env_cov`. |
| > Each register field gets a coverpoint with the same name, defined with the `DEF_GPR_CP` helper macro. |
| > If the encoding schema has more than one instruction, the coverpoint is then crossed with the mnemonic, using the `DEF_MNEM_CROSS` helper macro. |
| > For example, `add` is in the `enc_bnr_cg` covergroup. |
| > This encoding schema's `GRD` field is tracked with the `grd_cp` coverpoint. |
| > Finally, the relevant cross is called `grd_cross`. |
| |
| For any source GPR or WDR, we require "toggle coverage" for its value. |
| For example, `ADD` reads from its `grs1` operand. |
| We want to see each of the 32 bits of that operand set and unset (giving 64 coverage points). |
| Similarly, `BN.ADD` reads from its `wrs1` operand. |
| We want to see each of the 256 bits of that operand set and unset (giving 512 coverage points). |
| |
| > Again, the code to track this is split by encoding schema in `otbn_env_cov`. |
| > The trace interface takes a copy of GPR and WDR read data. |
| > The relevant register read data are then passed to the encoding schema's covergroup in the `on_insn` method. |
| > To avoid extremely repetitive code, the actual coverpoints and crosses are defined with the help of macros. |
| > The coverpoints are named with the base-2 expansion of the bit in question. |
| > For example, the cross in the `enc_bnr_cg` that tracks whether we've seen both values of bit 12 for the `grs1` operand is called `grs1_01100_cross` (since 12 is `5'b01100`). |
| |
| If an instruction can generate flag changes, we expect to see each flag that the instruction can change being both set and cleared by the instruction. |
| This needn't be crossed with the two flag groups (that's tracked separately in the "Flags" block above). |
| For example, `BN.ADD` can write to each of the flags `C`, `M`, `L` and `Z`. |
| This paragraph implies eight coverage points (four flags times two values) for that instruction. |
| |
| > Again, the code to track this is split by encoding schema in `otbn_env_cov`. |
| > The trace interface takes a copy of flag write data. |
| > It doesn't bother storing the flag write flags, since these are implied by the instruction anyway. |
| > There is a coverage coverpoint tracking both values for each of the flags that can be written. |
| > This is then crossed with the instruction mnemonic. |
| > For example, the coverpoint for the C flag (bit zero) in the `bnaf` encoding used by `BN.ADD` is called `flags_00_cp`. |
| > Some instructions only write the `M`, `L` and `Z` flags. |
| > These are found in the `bna`, `bnan`, `bnaqs` and `bnaqw` encoding groups. |
| > For these instructions, we only track bits `1`, `2` and `3` of the flags structure. |
| |
| For any instruction that can cause multiple errors in a single cycle, we expect to see each possible combination of errors. |
| This is described in more detail in the per-instruction text below. |
| If an instruction below doesn't describe triggering multiple errors, that means we don't think it's possible. |
| |
| ## ADD |
| |
| This instruction uses the `R` encoding schema, with covergroup `enc_r_cg`. |
| The instruction-specific covergroup is `insn_addsub_cg` (also used for `SUB`). |
| |
| - Cross the three possible signs (negative, zero, positive) for each input operand (giving 9 points). |
| Tracked as `sign_a_sign_b_cross`. |
| |
| ## ADDI |
| |
| This instruction uses the `I` encoding schema, with covergroup `enc_i_cg`. |
| The instruction-specific covergroup is `insn_addi_cg`. |
| |
| - Cross the three possible signs (negative, zero, positive) for each input operand (giving 9 points). |
| Tracked as `sign_cross`. |
| |
| ## LUI |
| |
| This instruction uses the `U` encoding schema, with covergroup `enc_u_cg`. |
| There are no further coverage points. |
| |
| ## SUB |
| |
| This instruction uses the `R` encoding schema, with covergroup `enc_r_cg`. |
| The instruction-specific covergroup is `insn_addsub_cg`. |
| |
| - Cross the three possible signs (negative, zero, positive) for each input operand (giving 9 points). |
| Tracked as `sign_a_sign_b_cross`. |
| |
| ## SLL |
| |
| This instruction uses the `R` encoding schema, with covergroup `enc_r_cg`. |
| The instruction-specific covergroup is `insn_sll_cg`. |
| |
| - A shift of a nonzero value by zero. |
| Tracked as `nz_by_z_cp`. |
| - A shift of a value by `0x1f` which leaves the top bit set. |
| Tracked as `shift15_cp`. |
| |
| ## SLLI |
| |
| This instruction uses the `Is` encoding schema, with covergroup `enc_is_cg`. |
| The instruction-specific covergroup is `insn_slli_cg`. |
| |
| - A shift of a nonzero value by zero. |
| Tracked as `nz_by_z_cp`. |
| - A shift of a value by `0x1f` which leaves the top bit set. |
| Tracked as `shift15_cp`. |
| |
| ## SRL |
| |
| This instruction uses the `R` encoding schema, with covergroup `enc_r_cg`. |
| The instruction-specific covergroup is `insn_srl_cg`. |
| |
| - A shift of a nonzero value by zero. |
| Tracked as `nz_by_z_cp`. |
| - A shift of a value by `0x1f` which leaves the bottom bit set. |
| Tracked as `shift15_cp`. |
| Note that this point also checks that we're performing a logical, rather than arithmetic, right shift. |
| |
| ## SRLI |
| |
| This instruction uses the `Is` encoding schema, with covergroup `enc_is_cg`. |
| The instruction-specific covergroup is `insn_srli_cg`. |
| |
| - A shift of a nonzero value by zero. |
| Tracked as `nz_by_z_cp`. |
| - A shift of a value by `0x1f` which leaves the bottom bit set. |
| Tracked as `shift15_cp`. |
| Note that this point also checks that we're performing a logical, rather than arithmetic, right shift. |
| |
| ## SRA |
| |
| This instruction uses the `R` encoding schema, with covergroup `enc_r_cg`. |
| The instruction-specific covergroup is `insn_sra_cg`. |
| |
| - A shift of a nonzero value by zero. |
| Tracked as `nz_by_z_cp`. |
| - A shift of a value by `0x1f` which leaves the bottom bit set. |
| Tracked as `shift15_cp`. |
| Note that this point also checks that we're performing an arithmetic, rather than logical, right shift. |
| |
| ## SRAI |
| |
| This instruction uses the `Is` encoding schema, with covergroup `enc_is_cg`. |
| The instruction-specific covergroup is `insn_srai_cg`. |
| |
| - A shift of a nonzero value by zero. |
| Tracked as `nz_by_z_cp`. |
| - A shift of a value by `0x1f` which leaves the bottom bit set. |
| Tracked as `shift15_cp`. |
| Note that this point also checks that we're performing an arithmetic, rather than logical, right shift. |
| |
| ## AND |
| |
| This instruction uses the `R` encoding schema, with covergroup `enc_r_cg`. |
| The instruction-specific covergroup is `insn_log_binop_cg` (shared with other logical binary operations). |
| |
| - Toggle coverage of the output result, not to `x0` (to ensure we're not just AND'ing things with zero) |
| Tracked as `write_data_XXXXX_cross`, where `XXXXX` is the base-2 representation of the bit being checked. |
| |
| ## ANDI |
| |
| This instruction uses the `I` encoding schema, with covergroup `enc_i_cg`. |
| The instruction-specific covergroup is `insn_log_binop_cg` (shared with other logical binary operations). |
| |
| - Toggle coverage of the output result, not to `x0` (to ensure we're not just AND'ing things with zero) |
| Tracked as `write_data_XXXXX_cross`, where `XXXXX` is the base-2 representation of the bit being checked. |
| |
| ## OR |
| |
| This instruction uses the `R` encoding schema, with covergroup `enc_r_cg`. |
| The instruction-specific covergroup is `insn_log_binop_cg` (shared with other logical binary operations). |
| |
| - Toggle coverage of the output result, not to `x0` (to ensure we're not just OR'ing things with `'1`) |
| Tracked as `write_data_XXXXX_cross`, where `XXXXX` is the base-2 representation of the bit being checked. |
| |
| ## ORI |
| |
| This instruction uses the `I` encoding schema, with covergroup `enc_i_cg`. |
| The instruction-specific covergroup is `insn_log_binop_cg` (shared with other logical binary operations). |
| |
| - Toggle coverage of the output result, not to `x0` (to ensure we're not just OR'ing things with `'1`) |
| Tracked as `write_data_XXXXX_cross`, where `XXXXX` is the base-2 representation of the bit being checked. |
| |
| ## XOR |
| |
| This instruction uses the `R` encoding schema, with covergroup `enc_r_cg`. |
| The instruction-specific covergroup is `insn_log_binop_cg` (shared with other logical binary operations). |
| |
| - Toggle coverage of the output result, not to `x0` (to ensure we're not just XOR'ing things with zero) |
| Tracked as `write_data_XXXXX_cross`, where `XXXXX` is the base-2 representation of the bit being checked. |
| |
| ## XORI |
| |
| This instruction uses the `I` encoding schema, with covergroup `enc_i_cg`. |
| The instruction-specific covergroup is `insn_log_binop_cg` (shared with other logical binary operations). |
| |
| - Toggle coverage of the output result, not to `x0` (to ensure we're not just XOR'ing things with zero) |
| Tracked as `write_data_XXXXX_cross`, where `XXXXX` is the base-2 representation of the bit being checked. |
| |
| ## LW |
| |
| This instruction uses the `I` encoding schema, with covergroup `enc_i_cg`. |
| The instruction-specific covergroup is `insn_xw_cg` (shared with `SW`). |
| |
| - Load from a valid address, where `<grs1>` is above the top of memory and a negative `<offset>` brings the load address in range. |
| Tracked as `oob_base_neg_off_cross`. |
| - Load from a valid address, where `<grs1>` is negative and a positive `<offset>` brings the load address in range. |
| Tracked as `neg_base_pos_off_cross`. |
| - Load from address zero. |
| Tracked as `addr0_cross`. |
| - Load from the top word of memory |
| Tracked as `top_addr_cross`. |
| - Load from an invalid address (aligned but above the top of memory) |
| Tracked as `oob_addr_cross`. |
| - Load from a calculated negative invalid address (aligned but unsigned address exceeds the top of memory) |
| Tracked as `oob_addr_neg_cross`. |
| - Load from a "barely invalid" address (just above the top of memory) |
| Tracked as `barely_oob_addr_cross`. |
| - Misaligned address tracking. |
| Track loads from addresses that are in range for the size of the memory. |
| Cross the different values modulo 4 for `grs1` and `offset`. |
| Tracked as `align_cross`. |
| |
| It is possible for LW to trigger multiple errors in a single cycle. |
| The possible errors are: underflow call stack, invalid DMEM address, and overflow call stack. |
| It's not possible to under- and overflow the call stack in a single cycle. |
| Similarly, if we underflow the call stack, we won't have an address at all (valid or otherwise). |
| This leaves a single combination to check: |
| |
| - Overflow the call stack when loading from an invalid address. |
| Tracked as `overflow_cs_invalid_addr_cp`. |
| |
| ## SW |
| |
| This instruction uses the `I` encoding schema, with covergroup `enc_s_cg`. |
| The instruction-specific covergroup is `insn_xw_cg` (shared with `LW`). |
| |
| - Store to a valid address, where `<grs1>` is above the top of memory and a negative `<offset>` brings the load address in range. |
| Tracked as `oob_base_neg_off_cross`. |
| - Store to a valid address, where `<grs1>` is negative and a positive `<offset>` brings the load address in range. |
| Tracked as `neg_base_pos_off_cross`. |
| - Store to address zero |
| Tracked as `addr0_cross`. |
| - Store to the top word of memory |
| Tracked as `top_addr_cross`. |
| - Store to an invalid address (aligned but above the top of memory) |
| Tracked as `oob_addr_cross`. |
| - Store to a calculated negative invalid address (aligned but unsigned address exceeds the top of memory) |
| Tracked as `oob_addr_neg_cross`. |
| - Store to a "barely invalid" address (aligned but overlapping the top of memory) |
| Tracked as `barely_oob_addr_cross`. |
| - Misaligned address tracking. |
| Track stores from addresses that are in range for the size of the memory. |
| Cross the different values modulo 4 for `grs1` and `offset`. |
| Tracked as `align_cross`. |
| |
| It is possible for SW to trigger multiple errors in a single cycle. |
| The possible errors are: underflow call stack and invalid DMEM address. |
| These can happen together, giving a single combination to check: |
| |
| - Underflow the call stack when reading the value to be stored and try to write it to an invalid address. |
| Tracked as `underflow_cs_invalid_addr_cp`. |
| |
| ## BEQ |
| |
| This instruction uses the `B` encoding schema, with covergroup `enc_b_cg`. |
| The instruction-specific covergroup is `insn_bxx_cg` (shared with `BNE`). |
| |
| All points should be crossed with branch taken / branch not taken. |
| |
| - See each branch direction (forwards, backwards, current address). |
| Tracked as `eq_dir_cross`. |
| - Branch to a misaligned address (offset not a multiple of 4) |
| PC is always 4-bit aligned and offset is a multiple of 2 by definition. |
| Therefore the only misalignment would be by setting the second bit of the offset to 1. |
| Offset alignment is tracked in `eq_offset_align_cross`. |
| - Branch forwards to an invalid address, above the top of memory |
| Tracked as `eq_oob_cross`. |
| - Branch backwards to an invalid address (wrapping past zero) |
| Tracked as `eq_neg_cross`. |
| - Branch instruction at end of a loop. |
| Tracked as `eq_at_loop_end_cross` (which also crosses with whether the branch was taken or not). |
| |
| The "branch to current address" item is problematic if we want to take the branch. |
| Probably we need some tests with short timeouts to handle this properly. |
| |
| It is possible for BEQ to trigger multiple errors in a single cycle. |
| The possible errors are: underflow call stack, bad target address, and branch at end of loop. |
| Since the target address check only triggers if the branch is taken, which requires a value for comparison, it's not possible to underflow the call stack and see a bad target address at the same time. |
| This leaves two possible combinations: |
| |
| - Underflow the call stack in a branch at the end of a loop. |
| Tracked as `underflow_at_loop_end_cross`. |
| - Take a branch to an invalid address where the branch instruction is at the end of a loop. |
| Tracked as `bad_addr_at_loop_end_cross`. |
| |
| ## BNE |
| |
| This instruction uses the `B` encoding schema, with covergroup `enc_b_cg`. |
| The instruction-specific covergroup is `insn_bxx_cg` (shared with `BEQ`). |
| |
| All points should be crossed with branch taken / branch not taken. |
| |
| - See each branch direction (forwards, backwards, current address). |
| Tracked as `eq_dir_cross`. |
| - Branch to a misaligned address (offset not a multiple of 4) |
| PC is always 4-bit aligned and offset is a multiple of 2 by definition. |
| Therefore the only misalignment would be by setting the second bit of the offset to 1. |
| Offset alignment is tracked in `eq_offset_align_cross`. |
| - Branch forwards to an invalid address, above the top of memory |
| Tracked as `eq_oob_cross`. |
| - Branch backwards to an invalid address (wrapping past zero) |
| Tracked as `eq_neg_cross`. |
| - Branch instruction at end of a loop. |
| Tracked as `eq_at_loop_end_cross` (which also crosses with whether the branch was taken or not). |
| |
| The "branch to current address" item is problematic if we want to take the branch. |
| Probably we need some tests with short timeouts to handle this properly. |
| |
| It is possible for BNE to trigger multiple errors in a single cycle. |
| The possible errors are: underflow call stack, bad target address, and branch at end of loop. |
| Since the target address check only triggers if the branch is taken, which requires a value for comparison, it's not possible to underflow the call stack and see a bad target address at the same time. |
| This leaves two possible combinations: |
| |
| - Underflow the call stack in a branch at the end of a loop. |
| Tracked as `underflow_at_loop_end_cross`. |
| - Take a branch to an invalid address where the branch instruction is at the end of a loop. |
| Tracked as `bad_addr_at_loop_end_cross`. |
| |
| ## JAL |
| |
| This instruction uses the `J` encoding schema, with covergroup `enc_j_cg`. |
| The instruction-specific covergroup is `insn_jal_cg`. |
| |
| - See each jump direction (forwards, backwards, current address). |
| Tracked as `dir_cp`. |
| - Jump to a misaligned address (offset not a multiple of 4) |
| Offset alignments are tracked in `offset_align_cp`. |
| - Jump forwards to an invalid address, above the top of memory |
| Tracked as `oob_cp`. |
| - Jump backwards to an invalid address (wrapping past zero) |
| Tracked as `neg_cp`. |
| - Jump when the current PC is the top word in IMEM. |
| Tracked as `from_top_cp`. |
| - Jump instruction at end of a loop. |
| Tracked as `at_loop_end_cp`. |
| |
| Note that the "jump to current address" item won't be a problem to test since it will quickly overflow the call stack. |
| |
| It is possible for JAL to trigger multiple errors in a single cycle. |
| The possible errors are: overflow call stack, bad target address, and jump at end of loop. |
| All four combinations are possible: |
| |
| - Overflow call stack when jumping to an invalid address. |
| Tracked as `overflow_and_invalid_addr_cp`. |
| - Overflow call stack from a jump at the end of a loop. |
| Tracked as `overflow_at_loop_end_cp`. |
| - Jump to an invalid address from the end of a loop. |
| Tracked as `invalid_addr_at_loop_end_cp`. |
| - Overflow call stack when jumping to an invalid address from the end of a loop. |
| Tracked as `overflow_and_invalid_addr_at_loop_end_cp`. |
| |
| ## JALR |
| |
| This instruction uses the `I` encoding schema, with covergroup `enc_i_cg`. |
| The instruction-specific covergroup is `insn_jalr_cg`. |
| |
| - See each jump offset (forwards, backwards, zero). |
| Tracked as `off_dir_cp`. |
| - Jump with a misaligned base address which `<offset>` aligns. |
| Pairs of base address / offset alignments tracked in `align_cross`. |
| - Jump with a large base address which wraps to a valid address by adding a positive `<offset>`. |
| Tracked as `pos_wrap_cp`. |
| - Jump with a base address just above top of IMEM but with a negative `<offset>` to give a valid target. |
| Tracked as `sub_cp`. |
| - Jump with a negative offset, wrapping to give an invalid target. |
| Tracked as `neg_wrap_cp`. |
| - Jump to an aligned address above top of IMEM. |
| Tracked as `oob_cp`. |
| - Jump to current address. |
| Tracked as `self_cp`. |
| - Jump when the current PC is the top word in IMEM. |
| Tracked as `from_top_cp`. |
| - Jump instruction at end of a loop. |
| Tracked as `at_loop_end_cp`. |
| |
| Note that the "jump to current address" item won't be a problem to test since it will quickly over- or underflow the call stack, provided `<grd>` and `<grs1>` aren't both `x1`. |
| |
| It is possible for JALR to trigger multiple errors in a single cycle. |
| The possible errors are: underflow call stack, overflow call stack, bad target address, and jump at end of loop. |
| If we underflow the call stack, we can't also overflow it, nor do we have a target address. |
| This means the only error that can occur in combination with underflowing the call stack is a jump at the end of a loop. |
| Otherwise, all other combinations are possible. |
| |
| - Underflow call stack in a jump instruction at the end of a loop. |
| Tracked as `underflow_at_loop_end_cp`. |
| - Overflow call stack when jumping to an invalid address. |
| Tracked as `overflow_and_bad_addr_cp`. |
| - Overflow call stack from a jump at the end of a loop. |
| Tracked as `overflow_at_loop_end_cp`. |
| - Jump to an invalid address from the end of a loop. |
| Tracked as `bad_addr_at_loop_end_cp`. |
| - Overflow call stack when jumping to an invalid address from the end of a loop. |
| Tracked as `overflow_and_bad_addr_at_loop_end_cp`. |
| |
| ## CSRRS |
| |
| This instruction uses the `I` encoding schema, with covergroup `enc_i_cg`. |
| The instruction-specific covergroup is `insn_csrrs_cg`. |
| |
| - Write with a non-zero `bits_to_set` to each valid CSR. |
| - Write to an invalid CSR. |
| |
| These points are tracked with `csr_cross` in `insn_csrrs_cg`. |
| It crosses `csr_cp` (which tracks each valid CSR, plus an invalid CSR) with `bits_to_set_cp` (which tracks whether `bits_to_set` is nonzero). |
| |
| It is possible for CSRRS to trigger multiple errors in a single cycle. |
| The possible errors are: underflow call stack, overflow call stack, and invalid CSR. |
| It's not possible to under- and overflow the call stack in a single cycle. |
| The other two combinations are possible: |
| |
| - Underflow the call stack and access an invalid CSR |
| Tracked as `underflow_with_bad_csr_cp`. |
| - Overflow the call stack and access an invalid CSR |
| Tracked as `overflow_with_bad_csr_cp`. |
| |
| ## CSRRW |
| |
| This instruction uses the `I` encoding schema, with covergroup `enc_i_cg`. |
| The instruction-specific covergroup is `insn_csrrw_cg`. |
| |
| - Write to every valid CSR with a `<grd>` other than `x0`. |
| - Write to every valid CSR with `<grd>` equal to `x0`. |
| - Write to an invalid CSR. |
| |
| These points are tracked with `csr_cross` in `insn_csrrw_cg`. |
| It crosses `csr_cp` (which tracks each valid CSR, plus an invalid CSR) with `grd_cp_to_set_cp` (which tracks whether `grd` is equal to `x0`. |
| |
| It is possible for CSRRW to trigger multiple errors in a single cycle. |
| The possible errors are: underflow call stack, overflow call stack, and invalid CSR. |
| It's not possible to under- and overflow the call stack in a single cycle. |
| The other two combinations are possible: |
| |
| - Underflow the call stack and access an invalid CSR |
| Tracked as `underflow_with_bad_csr_cp`. |
| - Overflow the call stack and access an invalid CSR |
| Tracked as `overflow_with_bad_csr_cp`. |
| |
| ## ECALL |
| |
| This instruction uses the `I` encoding schema, but with every field set to a fixed value. |
| Encoding-level coverpoints are tracked in covergroup `enc_ecall_cg`. |
| |
| No special coverage points for this instruction. |
| |
| ## LOOP |
| |
| This instruction uses the `loop` encoding schema, with covergroup `enc_loop_cg`. |
| The instruction-specific covergroup is `insn_loop_cg`. |
| |
| - Loop with a zero iteration count (causing an error) |
| Tracked as the `'0` bin of `iterations_cp`. |
| - Loop with a count of `'1` (the maximal value) |
| Tracked as the `'1` bin of `iterations_cp`. |
| - Loop when the loop end address would be above the top of memory. |
| Tracked as `oob_end_addr_cp`. |
| - Loop when the loop stack is full, causing an overflow. |
| Tracked as `loop_stack_fullness_cp`. |
| - Loop at the end of a loop. |
| Tracked as `at_loop_end_cp`. |
| - Duplicate loop end address, matching top of stack |
| Tracked as `duplicate_loop_end_cp`. |
| |
| It is possible for LOOP to trigger multiple errors in a single cycle. |
| The possible errors are: underflow call stack, zero loop count, and loop at end of loop. |
| It's not possible to underflow the call stack and see a zero loop count (because if we underflow the call stack, we have no loop count), so we get two pairs: |
| |
| - Underflow the call stack and loop at the end of a loop. |
| Tracked as `underflow_at_loop_end_cp`. |
| - Loop with a zero loop count at the end of a loop. |
| Tracked as `zero_count_at_loop_end_cp`. |
| |
| ## LOOPI |
| |
| This instruction uses the `loopi` encoding schema, with covergroup `enc_loopi_cg`. |
| The instruction-specific covergroup is `insn_loopi_cg`. |
| |
| - Loop with a zero iteration count (causing an error) |
| This is tracked in `enc_loopi_cg` with the `'0` bin of `iterations_cp`. |
| - Loop when the loop end address would be above the top of memory. |
| Tracked as `oob_end_addr_cp`. |
| - Loop when the loop stack is full, causing an overflow. |
| Tracked as `loop_stack_fullness_cp`. |
| - Loop at the end of a loop. |
| Tracked as `at_loop_end_cp`. |
| - Duplicate loop end address, matching top of stack |
| Tracked as `duplicate_loop_end_cp`. |
| |
| It is possible for LOOPI to trigger multiple errors in a single cycle. |
| The possible errors are: zero loop count and loop at end of loop. |
| These can happen together: |
| |
| - Loop with a zero loop count at the end of a loop. |
| Tracked as `zero_count_at_loop_end_cp`. |
| |
| ## BN.ADD |
| |
| This instruction uses the `bnaf` encoding schema, with covergroup `enc_bnaf_cg`. |
| There is no instruction-specific covergroup. |
| |
| - Extremal values of shift for both directions where the shifted value is nonzero. |
| This is tracked in `enc_bnaf_cg` as `st_sb_nz_shifted_cross`. |
| - A nonzero right shift with a value in `wrs2` whose top bit is set |
| This is tracked in `enc_bnaf_cg` as `srl_cross`. |
| |
| ## BN.ADDC |
| |
| This instruction uses the `bnaf` encoding schema, with covergroup `enc_bnaf_cg`. |
| The instruction-specific covergroup is `insn_bn_addc_cg`. |
| |
| - Extremal values of shift for both directions where the shifted value is nonzero |
| This is tracked in `enc_bnaf_cg` as `st_sb_nz_shifted_cross`. |
| - A nonzero right shift with a value in `wrs2` whose top bit is set |
| This is tracked in `enc_bnaf_cg` as `srl_cross`. |
| - Execute with both values of the carry flag for both flag groups (to make sure things are wired through properly) |
| Tracked as `carry_cross`. |
| |
| ## BN.ADDI |
| |
| This instruction uses the `bnai` encoding schema, with covergroup `enc_bnai_cg`. |
| There is no instruction-specific covergroup. |
| |
| No special coverage. |
| |
| ## BN.ADDM |
| |
| This instruction uses the `bnam` encoding schema, with covergroup `enc_bnam_cg`. |
| The instruction-specific covergroup is `insn_bn_addm_cg`. |
| |
| - Execute with the two extreme values of `MOD` (zero and all ones) |
| Tracked as `mod_cp`. |
| - Don't perform a subtraction (because the sum is less than `MOD`) when `MOD` is nonzero. |
| Tracked as `sum_lt_cp`. |
| - A calculation where the sum exactly equals a nonzero `MOD` |
| Tracked as `sum_eq_cp`. |
| - A calculation where the sum is greater than a nonzero `MOD`. |
| Tracked as `sum_gt_cp`. |
| - Perform a subtraction where the sum is at least twice a nonzero value of `MOD`. |
| Tracked as `sum_gt2_cp`. |
| - A calculation where the intermediate sum is greater than `2^256-1`, crossed with whether the subtraction of `MOD` results in a value that will wrap. |
| Tracked as `overflow_wrap_cross`. |
| |
| ## BN.MULQACC |
| |
| This instruction uses the `bnaq` encoding schema, with covergroup `enc_bnaq_cg`. |
| The instruction-specific covergroup is `insn_bn_mulqaccx_cg` (shared with the other `BN.MULQACC*` instructions). |
| |
| - Cross `wrs1_qwsel` with `wrs2_qwsel` to make sure they are applied to the right inputs |
| This is tracked in `enc_bnaq_cg` as `qwsel_cross`. |
| - See the accumulator overflow |
| This is tracked in `insn_bnmulqaccx_cg` as `overflow_cross`. |
| |
| ## BN.MULQACC.WO |
| |
| This instruction uses the `bnaq` encoding schema, with an extra field not present in `bn.mulqacc`. |
| Encoding-level coverpoints are tracked in covergroup `enc_bnaqw_cg`. |
| The instruction-specific covergroup is `insn_bn_mulqaccx_cg` (shared with the other `BN.MULQACC*` instructions). |
| |
| - Cross `wrs1_qwsel` with `wrs2_qwsel` to make sure they are applied to the right inputs |
| This is tracked in `enc_bnaqw_cg` as `qwsel_cross`. |
| - See the accumulator overflow |
| This is tracked in `insn_bnmulqaccx_cg` as `overflow_cross`. |
| |
| ## BN.MULQACC.SO |
| |
| This instruction uses the `bnaq` encoding schema, with an extra field not present in `bn.mulqacc`. |
| Encoding-level coverpoints are tracked in covergroup `enc_bnaqs_cg`. |
| The instruction-specific covergroup is `insn_bn_mulqaccx_cg` (shared with the other `BN.MULQACC*` instructions). |
| |
| - Cross `wrs1_qwsel` with `wrs2_qwsel` to make sure they are applied to the right inputs |
| This is tracked in `enc_bnaqs_cg` as `qwsel_cross`. |
| - See the accumulator overflow |
| This is tracked in `insn_bnmulqaccx_cg` as `overflow_cross`. |
| - Cross the generic flag updates with `wrd_hwsel`, since the flag changes are different in the two modes. |
| This is tracked in `enc_bnaqs_cg` as `flags_01_cross`, `flags_10_cross` and `flags_11_cross`. |
| |
| ## BN.SUB |
| |
| This instruction uses the `bnaf` encoding schema, with covergroup `enc_bnaf_cg`. |
| There is no instruction-specific covergroup. |
| |
| - Extremal values of shift for both directions where the shifted value is nonzero |
| This is tracked in `enc_bnaf_cg` as `st_sb_nz_shifted_cross`. |
| - A nonzero right shift with a value in `wrs2` whose top bit is set |
| This is tracked in `enc_bnaf_cg` as `srl_cross`. |
| |
| ## BN.SUBB |
| |
| This instruction uses the `bnaf` encoding schema, with covergroup `enc_bnaf_cg`. |
| The instruction-specific covergroup is `insn_bn_subcmpb_cg`. |
| |
| - Extremal values of shift for both directions where the shifted value is nonzero |
| This is tracked in `enc_bnaf_cg` as `st_sb_nz_shifted_cross`. |
| - A nonzero right shift with a value in `wrs2` whose top bit is set |
| This is tracked in `enc_bnaf_cg` as `srl_cross`. |
| - Execute with both values of the carry flag for both flag groups (to make sure things are wired through properly) |
| Tracked as `fg_carry_flag_cross`. |
| |
| ## BN.SUBI |
| |
| This instruction uses the `bnai` encoding schema, with covergroup `enc_bnai_cg`. |
| There is no instruction-specific covergroup. |
| |
| No special coverage. |
| |
| ## BN.SUBM |
| |
| This instruction uses the `bnam` encoding schema, with covergroup `enc_bnam_cg`. |
| The instruction-specific covergroup is `insn_bn_subm_cg`. |
| |
| - Execute with the two extreme values of `MOD` (zero and all ones) |
| Tracked as `mod_cp`. |
| - A non-negative intermediate result with a nonzero `MOD` (so `MOD` is not added). |
| Tracked as `diff_nonneg_cp`. |
| - An intermediate result that exactly equals a nonzero `-MOD`. |
| Tracked as `diff_minus_mod_cp`. |
| - A negative intermediate result with a nonzero `MOD`, so `MOD` is added and the result is positive. |
| Tracked as `diff_neg_cp`. |
| - A very negative intermediate result with a nonzero `MOD` (so `MOD` is added, but the top bit is still set) |
| Tracked as `diff_neg2_cp`. |
| |
| ## BN.AND |
| |
| This instruction uses the `bna` encoding schema, with covergroup `enc_bna_cg`. |
| There is no instruction-specific covergroup. |
| |
| - Extremal values of shift for both directions where the shifted value is nonzero |
| Tracked in `enc_bna_cg` as `st_sb_nz_shifted_cross`. |
| - Toggle coverage of the output result (to ensure we're not just AND'ing things with zero) |
| Tracked in `enc_bna_cg` as `wrd_XXXXXXXX_cross`, where `XXXXXXXX` is the base-2 representation of the bit being checked. |
| |
| ## BN.OR |
| |
| This instruction uses the `bna` encoding schema, with covergroup `enc_bna_cg`. |
| There is no instruction-specific covergroup. |
| |
| - Extremal values of shift for both directions where the shifted value is nonzero |
| Tracked in `enc_bna_cg` as `st_sb_nz_shifted_cross`. |
| - Toggle coverage of the output result (to ensure we're not just OR'ing things with zero) |
| Tracked in `enc_bna_cg` as `wrd_XXXXXXXX_cross`, where `XXXXXXXX` is the base-2 representation of the bit being checked. |
| |
| ## BN.NOT |
| |
| This instruction uses the `bnan` encoding schema, with covergroup `enc_bnan_cg`. |
| There is no instruction-specific covergroup. |
| |
| - Extremal values of shift for both directions where the shifted value is nonzero |
| Tracked in `enc_bnan_cg` as `st_sb_nz_shifted_cross`. |
| - Toggle coverage of the output result (to ensure nothing gets clamped) |
| Tracked in `enc_bnan_cg` as `wrd_XXXXXXXX_cp`, where `XXXXXXXX` is the base-2 representation of the bit being checked. |
| |
| ## BN.XOR |
| |
| This instruction uses the `bna` encoding schema, with covergroup `enc_bna_cg`. |
| There is no instruction-specific covergroup. |
| |
| - Extremal values of shift for both directions where the shifted value is nonzero |
| Tracked in `enc_bna_cg` as `st_sb_nz_shifted_cross`. |
| - Toggle coverage of the output result (to ensure we're not just XOR'ing things with zero) |
| Tracked in `enc_bna_cg` as `wrd_XXXXXXXX_cross`, where `XXXXXXXX` is the base-2 representation of the bit being checked. |
| |
| ## BN.RSHI |
| |
| This instruction uses the `bnr` encoding schema, with covergroup `enc_bnr_cg`. |
| There is no instruction-specific covergroup. |
| |
| No special coverage. |
| |
| ## BN.SEL |
| |
| This instruction uses the `bns` encoding schema, with covergroup `enc_bns_cg`. |
| There is no instruction-specific covergroup. |
| |
| - Cross flag group, flag and flag value (2 times 4 times 2 points) |
| Tracked in `enc_bns_cg` as `flag_cross`. |
| |
| ## BN.CMP |
| |
| This instruction uses the `bnc` encoding schema, with covergroup `enc_bnc_cg`. |
| There is no instruction-specific covergroup. |
| |
| - Extremal values of shift for both directions where the shifted value is nonzero |
| Tracked in `enc_bnc_cg` as `st_sb_nz_shifted_cross`. |
| - A nonzero right shift with a value in `wrs2` whose top bit is set |
| Tracked in `enc_bnc_cg` as `srl_cross`. |
| |
| ## BN.CMPB |
| |
| This instruction uses the `bnc` encoding schema, with covergroup `enc_bnc_cg`. |
| The instruction-specific covergroup is `insn_bn_subcmpb_cg`. |
| |
| - Extremal values of shift for both directions where the shifted value is nonzero |
| Tracked in `enc_bnc_cg` as `st_sb_nz_shifted_cross`. |
| - A nonzero right shift with a value in `wrs2` whose top bit is set |
| Tracked in `enc_bnc_cg` as `srl_cross`. |
| - Execute with both values of the carry flag for both flag groups (to make sure things are wired through properly) |
| Tracked as `fg_carry_flag_cross`. |
| |
| ## BN.LID |
| |
| This instruction uses the `bnxid` encoding schema, with covergroup `enc_bnxid_cg`. |
| The instruction-specific covergroup is `insn_bn_xid_cg` (shared with `BN.SID`). |
| |
| - Load from a valid address, where `grs1` is above the top of memory and a negative `offset` brings the load address in range. |
| Tracked as `oob_base_neg_off_cross`. |
| - Load from a valid address, where `grs1` is negative and a positive `offset` brings the load address in range. |
| Tracked as `neg_base_pos_off_cross`. |
| - Load from address zero |
| Tracked as `addr0_cross`. |
| - Load from the top word of memory |
| Tracked as `top_addr_cross`. |
| - Load from an invalid address (aligned but above the top of memory) |
| Tracked as `oob_addr_cross`. |
| - Load from a calculated negative invalid address (aligned but unsigned address exceeds the top of memory) |
| Tracked as `oob_addr_neg_cross`. |
| - Misaligned address tracking. |
| Track loads from addresses that are in range for the size of the memory. |
| We track all possible alignments of the sum as `addr_align_cross`. |
| The reason for not tracking offset and register value misalignments separately is because the offset would always be shifted by 5 bits, which makes it always aligned. |
| - See an invalid instruction with both increments specified |
| Tracked in `enc_bnxid_cg` as a bin of `incd_inc1_cross`. |
| - See `grd` greater than 31, giving an illegal instruction error |
| Tracked as `bigb_cross`. |
| - Cross the three types of GPR for `grd` with `grd_inc` |
| Tracked in `enc_bnxid_cg` as `grx_incd_cross`. |
| - Cross the three types of GPR for `grs1` with `grd_inc` |
| Tracked in `enc_bnxid_cg` as `grs1_inc1_cross`. |
| |
| It is possible for BN.LID to trigger multiple errors in a single cycle. |
| The possible errors are: underflow call stack (for `grs1`), underflow call stack (for `grd`), both increments set, invalid WDR index and bad data address. |
| If we underflow the call stack for `grs1`, there's no architectural address, so that can't happen at the same time as a bad data address. |
| Similarly, if we underflow the call stack for `grd`, there's no WDR index, so that can't cause an invalid WDR index. |
| However, every other combination is possible. |
| Binning together the two underflows unless it makes a difference to the possible behaviour gives the following list: |
| |
| - Underflow call stack and set both increments. |
| Tracked as `underflow_and_inc_both_cross`. |
| - Underflow call stack for `grs1` and have a bad WDR index in `*grd`. |
| Tracked as `underflow_and_badb_cross`. |
| - Underflow call stack for `grd` and compute a bad address from `*grs1`. |
| Tracked as `underflow_and_bad_addr_cross`. |
| - Set both increments and have a bad WDR index. |
| Tracked as `inc_both_and_bad_wdr_cross`. |
| - Set both increments and load from a bad address. |
| Tracked as `inc_both_and_bad_addr_cross`. |
| - Have a bad WDR index when loading from a bad address. |
| Tracked as `bad_wdr_and_bad_addr_cross`. |
| - Underflow call stack for `grs1`, setting both increments and have a bad WDR index in `*grd`. |
| Tracked as `underflow_and_inc_both_and_bad_wdr_cross`. |
| - Underflow call stack for `grd`, setting both increments and compute a bad address from `*grs1`. |
| Tracked as `underflow_and_inc_both_and_bad_addr_cross`. |
| - Set both increments and have both a bad WDR index and a bad address. |
| Tracked as `inc_both_and_bad_wdr_and_bad_addr_cross`. |
| |
| ## BN.SID |
| |
| This instruction uses the `bnxid` encoding schema, with covergroup `enc_bnxid_cg`. |
| The instruction-specific covergroup is `insn_bn_xid_cg` (shared with `BN.LID`). |
| |
| - Store to a valid address, where `grs1` is above the top of memory and a negative `offset` brings the load address in range. |
| Tracked as `oob_base_neg_off_cross`. |
| - Store to a valid address, where `grs1` is negative and a positive `offset` brings the load address in range. |
| Tracked as `neg_base_pos_off_cross`. |
| - Store to address zero |
| Tracked as `addr0_cross`. |
| - Store to the top word of memory |
| Tracked as `top_addr_cross`. |
| - Store to an invalid address (aligned but above the top of memory) |
| Tracked as `oob_addr_cross`. |
| - Store to a calculated negative invalid address (aligned but unsigned address exceeds the top of memory) |
| Tracked as `oob_addr_neg_cross`. |
| - Misaligned address tracking. |
| Track stores to addresses that are in range for the size of the memory. |
| We track all possible alignments of the sum as `addr_align_cross`. |
| The reason for not tracking offset and register value misalignments separately is because the offset would always be shifted by 5 bits, which makes it always aligned. |
| - See an invalid instruction with both increments specified |
| Tracked in `enc_bnxid_cg` as a bin of `incd_inc1_cross`. |
| - See `grd` greater than 31, giving an illegal instruction error |
| Tracked as `bigb_cross`. |
| - Cross the three types of GPR for `grs2` with `grs2_inc` |
| Tracked in `enc_bnxid_cg` as `grx_incd_cross`. |
| - Cross the three types of GPR for `grs1` with `grd_inc` |
| Tracked in `enc_bnxid_cg` as `grs1_inc1_cross`. |
| |
| It is possible for BN.SID to trigger multiple errors in a single cycle. |
| The possible errors are: underflow call stack (for `grs1`), underflow call stack (for `grs2`), both increments set, invalid WDR index and bad data address. |
| If we underflow the call stack for `grs1`, there's no architectural address, so that can't happen at the same time as a bad data address. |
| Similarly, if we underflow the call stack for `grs2`, there's no WDR index, so that can't cause an invalid WDR index. |
| However, every other combination is possible. |
| Binning together the two underflows unless it makes a difference to the possible behaviour gives the following list: |
| |
| - Underflow call stack and set both increments. |
| Tracked as `underflow_and_inc_both_cross`. |
| - Underflow call stack for `grs1` and have a bad WDR index in `*grs2`. |
| Tracked as `underflow_and_badb_cross`. |
| - Underflow call stack for `grs2` and compute a bad address from `*grs1`. |
| Tracked as `underflow_and_bad_addr_cross`. |
| - Set both increments and have a bad WDR index. |
| Tracked as `inc_both_and_bad_wdr_cross`. |
| - Set both increments and store to a bad address. |
| Tracked as `inc_both_and_bad_addr_cross`. |
| - Have a bad WDR index when storing to a bad address. |
| Tracked as `bad_wdr_and_bad_addr_cross`. |
| - Underflow call stack for `grs1`, setting both increments and have a bad WDR index in `*grs2`. |
| Tracked as `underflow_and_inc_both_and_bad_wdr_cross`. |
| - Underflow call stack for `grs2`, setting both increments and compute a bad address from `*grs1`. |
| Tracked as `underflow_and_inc_both_and_bad_addr_cross`. |
| - Set both increments and have both a bad WDR index and a bad address. |
| Tracked as `inc_both_and_bad_wdr_and_bad_addr_cross`. |
| |
| ## BN.MOV |
| |
| This instruction uses the `bnmov` encoding schema, with covergroup `enc_bnmov_cg`. |
| There is no instruction-specific covergroup. |
| |
| No special coverage otherwise. |
| |
| ## BN.MOVR |
| |
| This instruction uses the `bnmovr` encoding schema, with covergroup `enc_bnmovr_cg`. |
| The instruction-specific covergroup is `insn_bn_movr_cg`. |
| |
| - See an invalid instruction with both increments specified |
| Tracked in `enc_bnmovr_cg` as a bin of `incd_inc1_cross`. |
| - Since MOVR signals an error if either of its source registers has a value greater than 31, cross whether the input register value at `grd` is greater than 31 with whether the register value at `grs` is greater than 31 |
| Tracked in `enc_bnmovr_cg` as `big_gpr_cross`. |
| |
| It is possible for BN.MOVR to trigger multiple errors in a single cycle. |
| The possible errors are: underflow call stack (for `grs`), underflow call stack (for `grd`), both increments set, invalid WDR index (from `*grs`) and invalid WDR index (from `*grd`). |
| If we underflow the call stack for `grs`, there's no WDR index from `*grs`, so it's not also possible to see an invalid WDR index from that. |
| Similarly, if we underflow the call stack for `grd` then there's no WDR index from `*grd`, so it's not also possible to see an invalid WDR index from that. |
| Binning together the two underflows and WDR indices unless it makes a difference to the possible behaviour gives the following list: |
| |
| - Underflow call stack and set both increments. |
| Tracked as `underflow_and_inc_both_cp`. |
| - Underflow call stack for `grs` and have a bad WDR index in `*grd`. |
| Tracked as `underflow_and_bad_grd_cp`. |
| - Underflow call stack for `grd` and have a bad WDR index in `*grs`. |
| Tracked as `underflow_and_bad_grs_cp`. |
| - Set both increments and have a bad WDR index. |
| Tracked as `inc_both_and_bad_wdr_cp`. |
| - Underflow call stack for `grs`, setting both increments and have a bad WDR index in `*grd`. |
| Tracked as `underflow_grs_and_inc_both_and_bad_wdr_cp`. |
| - Underflow call stack for `grd`, setting both increments and have a bad WDR index in `*grs`. |
| Tracked as `underflow_grd_and_inc_both_and_bad_wdr_cp`. |
| |
| ## BN.WSRR |
| |
| This instruction uses the `bnwcsr` encoding schema, with covergroup `enc_wcsr_cg`. |
| There is no instruction-specific covergroup. |
| |
| - Read from each valid WSR and an invalid WSR. |
| Tracked with `wsr_cross` in `enc_wcsr_cg`. |
| - Read from each key sideload WSR, getting a valid response. |
| Tracked as part of `key_avail_cross` in `insn_bn_wsrr_cg`. |
| - Read from each key sideload WSR, getting a KEY_INVALID error. |
| Tracked as part of `key_avail_cross` in `insn_bn_wsrr_cg`. |
| |
| These points are tracked with `wsr_cross` in `enc_wcsr_cg`. |
| |
| ## BN.WSRW |
| |
| This instruction uses the `bnwcsr` encoding schema, with covergroup `enc_wcsr_cg`. |
| There is no instruction-specific covergroup. |
| |
| - Write to each valid WSR, including read-only WSRs. |
| - Write to an invalid WSR |
| |
| These points are tracked with `wsr_cross` in `enc_wcsr_cg`. |
