[flash_ctrl] Separate invalid and disabled states.

- fixes #11825

Part of the D2S design fixes was to unify the disabled behavior across
more of the flash controller state machines. However this created a
problem for RMA entry.

When RMA entry is done, the RMA fsm also requests flash operationst to be
disabled. Previosuly, this caused the RMA fsm itself to transition into
an invalid state.  This caused 2 problems:

1. At the end of RMA, a fatal alert is generated. While this is
   not bad behavior in any meaningful way, it is very inconsistent with alert
   defintion because no fatal event has occurred. This leads to unnecessary
   DV work.

2. Since the RMA fsm transitions out of its ack state, it means the ack
   indication sent to life cycle controller will be held for only 1 cycle.
   This is most definitely not enough for CDC and means RMA cannot be completed.

This commit separates the idea of "disabled" and "invalid" for most of the fsms.
Disabled simply means functionally disabled from future operations, while
invalid is both disabled AND alert generation.

At the end of RMA transition, the device is simply "disabled" and not "invalid".
Invalid then can only be caused by an explicit error, or the FSMs going
completely to an undefined state.

This makes the overall definition more consistent.

Signed-off-by: Timothy Chen <timothytim@google.com>
8 files changed
tree: 29d50cbefd6783239fbe93d4209f24c02dba5810
  1. .github/
  2. ci/
  3. doc/
  4. hw/
  5. rules/
  6. site/
  7. sw/
  8. test/
  9. third_party/
  10. util/
  11. .bazelignore
  12. .bazelrc
  13. .bazelversion
  14. .clang-format
  15. .dockerignore
  16. .flake8
  17. .gitignore
  18. .style.yapf
  19. .svlint.toml
  20. .svls.toml
  21. _index.md
  22. apt-requirements.txt
  23. azure-pipelines.yml
  24. bazelisk.sh
  25. BUILD.bazel
  26. check_tool_requirements.core
  27. CLA
  28. COMMITTERS
  29. CONTRIBUTING.md
  30. LICENSE
  31. meson-config.txt
  32. meson.build
  33. meson_init.sh
  34. meson_options.txt
  35. python-requirements.txt
  36. README.md
  37. tool_requirements.py
  38. topgen-reg-only.core
  39. topgen.core
  40. WORKSPACE
  41. yum-requirements.txt
README.md

OpenTitan

OpenTitan logo

About the project

OpenTitan is an open source silicon Root of Trust (RoT) project. OpenTitan will make the silicon RoT design and implementation more transparent, trustworthy, and secure for enterprises, platform providers, and chip manufacturers. OpenTitan is administered by lowRISC CIC as a collaborative project to produce high quality, open IP for instantiation as a full-featured product. See the OpenTitan site and OpenTitan docs for more information about the project.

About this repository

This repository contains hardware, software and utilities written as part of the OpenTitan project. It is structured as monolithic repository, or “monorepo”, where all components live in one repository. It exists to enable collaboration across partners participating in the OpenTitan project.

Documentation

The project contains comprehensive documentation of all IPs and tools. You can access it online at docs.opentitan.org.

How to contribute

Have a look at [CONTRIBUTING]({{< relref “CONTRIBUTING.md” >}}) and our documentation on project organization and processes for guidelines on how to contribute code to this repository.

Licensing

Unless otherwise noted, everything in this repository is covered by the Apache License, Version 2.0 (see LICENSE for full text).