Earlgrey-M2.5.2-RC0
Overview
This is the EarlGrey Engineering Sample release candidate. All blocks are at least at D2.5 design stage, and V2.5 verification stage (except for RV_DM, USBDEV, PWM and PATTGEN).
This release is associated with GitHub milestone: M2.5.2
D2.5 versus D3
D2.5 is strictly a subset of the D3 signoff criteria, including the following D3 checklist items:
- Meets D2(S) signoff criteria
- Meets D3 signoff criteria for the following items:
- TODO_COMPLETE
- LINT_COMPLETE
- REVIEW_RTL
- REVIEW_SW_CHANGE
- REVIEW_SW_ERRATA
D2.5 reviews were performed offline and are tracked in checklists available in OpenTitan.org internal documents.
V2.5 versus V3
V2.5 is strictly a subset of the V3 signoff criteria, including the following V3 checklist items:
- Meets V2 or V2S signoff criteria
- DESIGN_DELTAS_CAPTURED
- ALL_TODOS_RESOLVED
- TB_LINT_COMPLETE
- PRE_VERIFIED_SUBMODULES
- 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 in OpenTitan.org internal documents.
Release Contents
Design
All IPs meet the D2.5 development stage requirements:
- 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
- D2.5 (21 of 35): All other blocks
Design Verification
All IPs are at V2.5 level, except for the IPs which have a verification signoff waiver (USBDEV, RV_DM), or which are explicitly not required to fully work for the ES tapeout (PWM, PATTGEN).
The following section notes the progress that has been made towards the M2.5.2 goal.
- V2.5 (31 of 35): usbdev, i2c, rv_dm, entropy_src, spi_device, spi_host, csrng, flash_ctrl, kmac, lc_ctrl, sysrst_ctrl, keymgr, edn, otp_ctrl, uart, tlul, otbn, sram_ctrl, rv_core_ibex, clkmgr, pwrmgr, rstmgr, adc_ctrl, alert_handler, aes, aon_timer, hmac, rom_ctrl, rv_timer, rv_plic, gpio, sensor_ctrl, pinmux
- V1 (1 of 35): RV_DM
- V0 (1 of 35): USBDEV
- V2S (2 of 35): pwm and pattgen
Note that PWM and PATTGEN are functionally not needed for ES, since the use cases under consideration do not make use of these blocks.
Block Level Issues
- All block level issues assigned to M2.5.2 have been resolved.
Top Level Test Cases
- All Chip-Level test cases assigned to M2.5.2 have been resolved.
- All Test-Triage issues identified for M2.5.2 have been resolved.
Manufacturing
- All Manufacturing test cases assigned to M2.5.2 have been resolved.
Integration Testing
The following integration tests have been implemented and are passing:
- USB. Block level smoketest #18063. FPGA targeted testing.
- SPI_HOST. FPGA targeted testing. #18640
- SPI Passthrough. FPGA targeted testing #18320.
- I2C host. FPGA targeted testing. #18639
- I2C device. FPGA targeted testing #18541.
Coverage Assessment
All blocks are at the required 90% coverage level or above, with the exception of the following blocks:
- RV_DM: (Pass rate) 71.67, (Coverage) 81.52
- Implications are known and mitigation strategies as documented in the M2 waiver document available in the opentitan.org partner domain.
- An updated waiver document will be available as part of the M2.5.2 milestone that focuses on DV closure.
- USB_DEV: (Pass rate) 48.79, (Coverage) 76.36
3. Implications are known and mitigation strategies as documented in the M2 waiver document available in the opentitan.org partner domain.
4. An updated waiver document will be available as part of the M2.5.2 milestone that focuses on DV closure.
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: 39 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. The static analysis environment has not been cleaned up as part of M2.5.2 due to resourcing and tooling constraints. However, dynamic CDC has progressed well and 39 of 43 simulation environments now use CDC randomization.
Known Issues
The following known issues will not be addressed in the design and will require software workarounds.
- [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.
- [lc_ctrl/top] Clean up life cycle endpoints #19058
- This is a cleanup task that has been identified while reviewing the design.
- [pwrmgr/sram_ctrl] Use synchronizers on all LC signals #19051
- We identified that not all life cycle signals in pwrmgr and sram_ctrl are properly synchronized with prim_lc_sync. For Earlgrey ES, this is not critical since:
- pwrmgr has the same clock root as lc_ctrl, and hence the signals are synchronous
- sram_ctrl is not used while lc_ctrl and otp_ctrl are initialized, and hence there is enough time for the signals to stabilize after initialization.
- For PROD and other integrations, though, this should be cleaned up.
- We identified that not all life cycle signals in pwrmgr and sram_ctrl are properly synchronized with prim_lc_sync. For Earlgrey ES, this is not critical since:
- [otbn] Fix OTBN usage of life cycle control signals #19050
- OTBN escalates locally upon detecting invalid life cycle signal encodings. This does not follow the design guidance for life cycle signals that specifically notes that CDC stagger must be tolerated. The reason why this issue did not need an ECO was that the relevant signal happens to be driven by flash_ctrl which is in the same clock domain as OTBN, and hence this is not a real problem for the earlgrey configuration.
- 5 ECOs were implemented as part of M2.5.2:
- [i2c] Hold off NACK detection until posedge SCL #19014 #19015
Difference Among Release Candidates
Only one release candidate available for this milestone.