Overview

This is the EarlGrey Engineering Sample release candidate. All blocks are at least at D2 design stage, and V2S verification stage (except for RV_DM, I2C, RV_DM).

This release is associated with GitHub milestone: M2.5.1

Notes on Block Level Status

This release uses the definition of intermediate milestones D2.5 and V2.5 to describe block level status above D2S and V2S. These definitions are only used within the context of this document, and are not intended to be used as an official OpenTitan milestone definition.

D2.5 versus D3

D2.5 is strictly a subset of the D3 signoff criteria, including the following D3 checklist items:

1. Meets D2(S) signoff criteria
2. Meets D3 signoff criteria for the following items:
   1. TODO_COMPLETE
   2. LINT_COMPLETE
   3. REVIEW_RTL
   4. REVIEW_SW_CHANGE
   5. REVIEW_SW_ERRATA

D2.5 reviews were performed offline and are tracked in checklists available to OpenTitan partners.

V2.5 versus V3

V2.5 is strictly a subset of the V3 signoff criteria, including the following V3 checklist items:

1. Meets V2 or V2S signoff criteria
2. DESIGN_DELTAS_CAPTURED
3. ALL_TODOS_RESOLVED
4. TB_LINT_COMPLETE
5. PRE_VERIFIED_SUBMODULES
6. NO_ISSUES_PENDING

V2.5 coverage metrics are at V2S level, and thus not referenced in the list above. Signoff reviews were performed offline and are tracked in checklists available to OpenTitan partners.

Release Contents

Design

All IPs meet the D2.5 development stage requirements:

1. D3 (14 of 35): lc_ctrl, uart, otp_ctrl, sysrst, adc_ctrl, alert_handler, aon_timer, gpio, pinmux, rom_ctrl, rv_plic, rv_timer, sensor_ctrl, sram_ctrl
2. D2.5 (21 of 35): All other blocks

Design Verification

All IPs are at V2(S) level or above, except for the IPs which had a verification signoff waiver at M2 (I2C, USBDEV, RV_DM).

Note that block-level verification tasks for V2.5 are not part of the M2.5.1 exit criteria, since the verification signoff will be done at M2.5.2. Nevertheless, the following section notes the progress that has been made towards the M2.5.2 goal.

1. V2.5 (13 of 35): flash_ctrl, kmac, keymgr, otp_ctrl, tlul, clkmgr, rstmgr, adc_ctrl, alert_handler, hmac, sensor_ctrl, pwrmgr, lc_ctrl
2. V1 (2 of 35): i2c, rv_dm
3. V0 (1 of 35): usbdev
4. V2S (19 of 35): All other blocks

Details for i2c

I2C was not at V2 for this release but it was very close to achieving it. Overall regression pass rates were over 90% however coverage wasn't up to V2 standards, in particular FSM coverage was low (~50%) and there were some unimplemented coverage points (The i2c_rd_wr_cg, i2c_scl_stretch_cg, i2c_timing_parameters_cg, i2c_cmd_complete_cg).

There was high confidence that the missing coverage points were being stimulated by existing tests and the functionality had been observed working during other DV work.

A detailed waiver and mitigation test strategy document for i2c is available to OpenTitan partners.

Details for rv_dm

A detailed waiver and mitigation test strategy document for rv_dm is available to OpenTitan partners. This released focused on improving top level test coverage for this block.

Details for usbdev

A detailed waiver and mitigation test strategy document for rv_dm is available to OpenTitan partners. This released focused on improving top level test coverage for this block.

Block Level Issues

1. All block level issues assigned to M2.5.1 have been resolved.

Top Level Test Cases

1. All Chip-Level test cases assigned to M2.5.1 have been resolved.
2. All Test-Triage issues identified for M2.5.1 have been resolved.

Manufacturing Readiness

1. All Manufacturing test cases assigned to M2.5.1 have been resolved.

Integration Testing

The following integration tests have been implemented and are passing:

1. USB. Block level smoketest #18063. FPGA targeted testing.
2. SPI_HOST. FPGA targeted testing. #18640
3. SPI Passthrough. FPGA targeted testing #18320
4. I2C host. FPGA targeted testing. #18639
5. I2C device. FPGA targeted testing #18541

CDC and RDC Assessment

Static RDC analysis and dynamic CDC enablement in simulation have been worked on on a best effort basis. The current status is:

• Static RDC at 30 setup errors, 870 analysis warnings and 29 analysis errors.
• Dynamic CDC: 24 out of 43 DV environments are enabled.

Static CDC analysis was clean a few days before the release, but has now regressed to 7 setup warnings and 67 analysis errors due to last minute fixes to the spi_device RTL and updates to the spi_device synthesis constraints. These regressions (mostly waiver cleanups) will be fixed as part of M2.5.2.

The following known issues will not be addressed in the design and will require software workarounds.

Known Issues

• [i2c] Unexpected data in ACQ FIFO after deep sleep wakeup #18510
  • This problem likely occurs due to the fact that sleep wakeup is very fast on the FPGA since power-up delays are not correctly modeled. Also, the I2C may actually latch data before it has been fully configured and enabled.
  • Workaround: as discussed on the issue, a FIFO reset after I2C configuration solves the problem.
• [adc_ctrl] Limitations in wakeup detection #18511
  • There is a chance that the adc_ctrl FSM transitions from the low-power sampling mode into the normal power sampling mode without waking up the rest of the system. This can happen if the filter thresholds match during low power, but not after transitioning into normal power mode, since the FSM currently has no way to fall back into low-power sampling mode.The FSM may hence get stuck in the normal power mode that consumes significantly more power.
  • Workaround: while the problem cannot be completely avoided, this issue can be mitigated by taking only one sample after transitioning into normal power mode.
• [spi_device] TPM interrupt for Write FIFO #15785
  • This is a feature request for adding interrupts based on FIFO fill-status. The feature could however not be implemented due to schedule constraints.
  • Workaround: software will have to work around this limitation and use a polling-based approach.
• [i2c] Potential frequency output mismatch #18492
  • The I2C frequency does not always match the configured values. Investigations are still ongoing, but a suspected root cause is that there is an issue with how the programmed cycle counties are translated into actual cycles in the I2C bock.
  • Workaround: the I2C still works - just the frequency is not accurate. Potential workarounds are to either use the I2C as is, or compensate for the wrong translation logic by programming cycle counts that adjust for the measured frequency offset.
• [usbdev] aon_wake maintains pull up assertion over VBUS disconnection #18562
  • Suggested RTL improvement to increase stability during disconnection/interruption to VBUS/SENSE while OT is in deep sleep.
  • Workaround: When software returns from Deep Sleep and discovers a Disconnection event, it should be aware that the host may or may not have spotted a disconnection, and thus introduce a deliberate disconnect period by ensuring that usbdev pull up is disabled before deactivating the aon_wake module. See Issue for more details.
• [spi_host] SPI Top level test - FPGA #15074
  • As documented here on that issue, there are currently no plans to test the muxed spi_host1 at the FPGA level for M2.5.2.
• [lc_ctrl] TAP required delay before JTAG commands after reset #18724
  • The life cycle TAP is not immediately available after reset, due to the boot sequence. I.e., the power manager first waits for OTP, LC to initialize first. If the device is in PROD* or DEV, the power manager also waits for the ROM_CTRL to complete its checks before sending the strap sampling request to the TAP selection logic in the pinmux. This means that connecting to the life cycle controller TAP may fail if attempted too early.
  • From a hardware perspective this behavior is as expected (hence this is not a bug). The agent intending to connect to the LC TAP should either
    • wait long enough for the chip to boot before attempting to connect via JTAG (delay for the ASIC is yet to be determined).
    • or alternatively, attempt to read out a known JTAG register such as the device ID in a polling loop. This method may require assertion TRSTN before any attempt.

Design Verification Coverage Assessment

All blocks are at the required 90% coverage level or above, with the exception of the following blocks:

1. PRIM_LFSR: (Coverage) 89.17
   1. Not a concern since close to 90%
2. PRIM_PRESENT: (Coverage) 75.95 2. Not a concern, since the modes used in comportable IPs are tested as part of the comportable IPs, and coverage is collected as part of the comportable IP testbenches.
3. RV_DM: (Pass rate) 71.67, (Coverage) 81.52 3. Implications are known and mitigation strategies as documented in the M2 waiver document are being worked on. 4. An updated waiver document will be available as part of the M2.5.2 milestone that focuses on DV closure.
4. USB_DEV: (Pass rate) 48.79, (Coverage) 76.36 5. Implications are known and mitigation strategies as documented in the M2 waiver document are being worked on. 6. An updated waiver document will be available as part of the M2.5.2 milestone that focuses on DV closure.

Regression Snapshot