[checklist] General language and style tidy-up
This commit intends to unify the language and style of all checklist
items and to correct typos etc. It is not intended to alter the meaning
of any items.
Signed-off-by: Tom Roberts <tomroberts@lowrisc.org>
diff --git a/doc/project/checklist.md b/doc/project/checklist.md
index 69facce..644bed1 100644
--- a/doc/project/checklist.md
+++ b/doc/project/checklist.md
@@ -7,12 +7,12 @@
## D1
-For a transition from D0 to D1, the following items are expected be completed.
+For a transition from D0 to D1, the following items are expected to be completed.
### SPEC_COMPLETE
-Specification mostly (90%) complete, all features are defined.
-Specification is submitted into the repo as a markdown document.
+The specification is 90% complete, all features are defined.
+The specification is submitted into the repository as a markdown document.
It is acceptable to make changes for further clarification or more details after the D1 stage.
### CSR_DEFINED
@@ -23,27 +23,27 @@
### CLKRST_CONNECTED
-Clock(s)/Reset(s) connected to all sub-modules.
+Clock(s) and reset(s) are connected to all sub-modules.
### IP_TOP
-Unit `.sv` exists, meet comportability requirements.
+The unit `.sv` exists and meets comportability requirements.
### IP_INSTANTIABLE
-Unit is able to be instantiated and bound in top level RTL.
+The unit is able to be instantiated and connected in top level RTL files.
The design must compile and elaborate cleanly without errors.
-The unit must not break top level functionality such as propagating X through TL-UL interface, continuously asserting the interrupts, or creating undesired TL-UL transactions.
+The unit must not break top level functionality such as propagating X through TL-UL interfaces, continuously asserting alerts or interrupts, or creating undesired TL-UL transactions.
### PHYSICAL_MACROS_DEFINED_80
-All expected memories identified, representative macros instantiated.
+All expected memories have been identified and representative macros instantiated.
All other physical elements (analog components, pads, etc) are identified and represented with a behavioral model.
It is acceptable to make changes to these physical macros after the D1 stage as long as they do not have a large impact on the expected resulting area (roughly "80% accurate").
### FUNC_IMPLEMENTED
-Mainline functional path is implemented to allow for a basic functionality test by verification.
+The mainline functional path is implemented to allow for a basic functionality test by verification.
("Feature complete" is the target for D2 status.)
### ASSERT_KNOWN_ADDED
@@ -52,27 +52,27 @@
### LINT_SETUP
-Lint run setup, compiles and runs. It is acceptable to have lint errors and
-warnings at this stage.
+A lint flow is setup which compiles and runs.
+It is acceptable to have lint warnings at this stage.
## D2
### NEW_FEATURES
-Any new features added since D1 are documented, reviewed with DV/SW/FPGA.
+Any new features added since D1 are documented and reviewed with DV/SW/FPGA.
The GitHub Issue, Pull Request, or RFC where the feature was discussed should be linked in the `Notes` section.
### BLOCK_DIAGRAM
-Block diagrams updated.
+Block diagrams have been updated to reflect the current design.
### DOC_INTERFACE
-Documented non-registered block interfaces.
+All IP block interfaces that are not autogenerated are documented.
### MISSING_FUNC
-Documented the missing functionalities.
+Any missing functionality is documented.
### FEATURE_FROZEN
@@ -80,44 +80,45 @@
### FEATURE_COMPLETE
-All features specified have been completed.
+All features specified are implemented.
### AREA_CHECK
-Area check completed either on FPGA or on Design Compiler.
+An area check has been completed either on FPGA or using Synopsys Design Compiler.
### PORT_FROZEN
-100% ports. Port is frozen.
+All ports are implemented and their specification is frozen.
### ARCHITECTURE_FROZEN
-100% architectural states exists (RAMs, CSRs, etc)
+All architectural state (RAMs, CSRs, etc) is implemented and the specification frozen.
### REVIEW_TODO
-Review and sign off TODOs.
+All TODOs have been reviewed and signed off.
### STYLE_X
-Conforming to [style guide regarding X usage](https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md#dont-cares-xs).
+The IP block conforms to the [style guide regarding X usage](https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md#dont-cares-xs).
### LINT_PASS
-Lint passes. Waiver reviewed.
+The lint flow passes cleanly.
+Any lint waiver files have been reviewed.
### CDC_SETUP
-CDC run set up. No must fix errors, waiver file created.
+A CDC checking run has been set up (if tooling is available).
+The CDC checking run shows no must-fix errors, and a waiver file has been created.
### FPGA_TIMING
-Block is synthesized as part of continuous integration checks and meets timing there.
+The IP block is synthesized as part of the continuous integration checking and meets timing there.
### CDC_SYNCMACRO
-CDC Sync flops use behavioral synchronization macros(`prim_flop_2sync`) not
-2flops.
+All CDC synchronization flops use behavioral synchronization macros (e.g. `prim_flop_2sync`) not manually created flops.
### SEC_CM_IMPLEMENTED
@@ -143,111 +144,115 @@
### NEW_FEATURES_D3
-Any approved new features since D2 documented, and reviewed with DV/SW/FPGA
+Any approved new features since D2 have been documented and reviewed with DV/SW/FPGA
### TODO_COMPLETE
-Resolve all TODOs.
+All TODOs are resolved.
### LINT_COMPLETE
-Lint clean. Lint waiver file reviewed and signed off by tech steering committe.
+The lint checking flow is clean.
+Any lint waiver files have been reviewed and signed off by the technical steering committee.
### CDC_COMPLETE
-CDC clean. CDC waiver file reviewed and signed off by tech sterring committe.
+The CDC checking flow is clean.
+CDC waiver files have been reviewed and signed off by the technical steering committee.
### REVIEW_RTL
-Hold Design Review: Hold an RTL smoke check review by an independent designer.
+A simple design review has been conducted by an independent designer.
### REVIEW_DELETED_FF
-Hold Design Review: Sign off deleted flops list (one last time).
+Any deleted flops have been reviewed and signed off.
### REVIEW_SW_CSR
-Review Design Change with SW: Review CSRs
+Any design changes which affect CSRs have been reviewed by the software team.
### REVIEW_SW_FATAL_ERR
-Review Design Change with SW: Review Fatal Errors
+Any fatal error mechanisms have been reviewed by the software team.
### REVIEW_SW_CHANGE
-Review Design Change with SW: Review other SW visible changes
+Any other software-visible design changes have been reviewed by the software team.
### REVIEW_SW_ERRATA
-Review Design Change with SW: Review known "Won't Fix" bugs and "Errata".
+All known "Won't Fix" bugs and "Errata" have been reviewed by the software team.
## V1
-To transition from V0 to V1, the following items are expected be completed.
-Prefix "SIM" is applicable for simulation-based DV approach, whereas the prefix "FPV" is applicable for formal property-based verification approach.
+To transition from V0 to V1, the following items are expected to be completed.
+The prefix "SIM" is applicable for simulation-based DV approaches, whereas the prefix "FPV" is applicable for formal property-based verification approaches.
### DV_DOC_DRAFT_COMPLETED
-DV document drafted, indicating the overall DV goals, strategy, the testbench environment details with diagram(s) depicting the flow of data, UVCs, checkers, scoreboard, interfaces, assertions and the rationale for the chosen functional coverage plan.
+A DV document has been drafted, indicating the overall DV goals, strategy, the testbench environment details with diagram(s) depicting the flow of data, UVCs, checkers, scoreboard, interfaces, assertions and the rationale for the chosen functional coverage plan.
Details may be missing since most of these items are not expected to be fully understood at this stage.
### TESTPLAN_COMPLETED
-Testplan completely written (in HJson format) indicating:
+A testplan has been written (in HJson format) indicating:
- Testpoints (a list of planned tests), each mapping to a design feature, with a description highlighting the goal of the test and optionally, the stimulus and the checking procedure.
-- The functional coverage plan captured as a list of covergroups, with a description highlighting what feature is expected to be covered by each covergroup.
- It may optionally contain additional details such as coverpoints and crosses of individual aspects of the said feature that are covered.
+- The functional coverage plan captured as a list of covergroups, with a description highlighting which feature is expected to be covered by each covergroup.
+ It may optionally contain additional details such as coverpoints and crosses of individual aspects of the said feature that is covered.
### TB_TOP_CREATED
-Top level testbench with DUT instantiated and following interfaces hooked up (as applicable): TileLink, clocks and resets, interrupts and major DUT interfaces.
-All interfaces may not be hooked up at this point.
+A top level testbench has been created with the DUT instantiated.
+The following interfaces are connected (as applicable): TileLink, clocks and resets, interrupts and major DUT interfaces.
+Some minor interfaces may not be connected at this point.
Inputs for which interfaces have not yet been created are tied off to 0.
### PRELIMINARY_ASSERTION_CHECKS_ADDED
-All available interface assertion monitors hooked up (example: tlul_assert).
+All available interface assertion monitors are connected (example: tlul_assert).
### SIM_TB_ENV_CREATED
-UVM environment created with major interface agents and UVCs connected and instantiated.
-TLM port connections made from UVC monitors to the scoreboard.
+A UVM environment has been created with major interface agents and UVCs connected and instantiated.
+TLM port connections have been made from UVC monitors to the scoreboard.
### SIM_RAL_MODEL_GEN_AUTOMATED
-RAL model is generated by using [regtool]({{< relref "/util/reggen/README.md" >}}) and instantiated in UVM environment.
+A RAL model is generated using [regtool]({{< relref "/util/reggen/README.md" >}}) and instantiated in the UVM environment.
### CSR_CHECK_GEN_AUTOMATED
-CSR check is generated by using [regtool]({{< relref "/util/reggen/README.md" >}}) and bound in the TB environment.
+A CSR check is generated using [regtool]({{< relref "/util/reggen/README.md" >}}) and bound in the TB environment.
### TB_GEN_AUTOMATED
-Full testbench automation completed if applicable. This may be required for verifying multiple flavors of parameterized DUT designs.
+Full testbench automation has been completed if applicable.
+This may be required for verifying multiple flavors of parameterized DUT designs.
### SIM_SMOKE_TEST_PASSING
-Smoke test exercising a basic functionality of a major DUT datapath passing.
-What functionality to test and to what level may be driven by higher level (example: chip) integration requirements.
-These are captured when the testplan is reviewed with the key stakeholders, and the test(s) updated as necessary.
+A smoke test exercising the basic functionality of the main DUT datapath is passing.
+The functionality to test (and to what level) may be driven by higher level (e.g. chip) integration requirements.
+These requirements are captured when the testplan is reviewed by the key stakeholders, and the test(s) updated as necessary.
### SIM_CSR_MEM_TEST_SUITE_PASSING
-CSR test suite added for ALL interfaces (including, but not limited to the DUT's SW device acess port, JTAG access port etc. whichever ones are applicable) that have access to system memory map:
+CSR test suites have been added for ALL interfaces (including, but not limited to the DUT's SW device acess port, JTAG access port etc.) that have access to the system memory map:
- HW reset test (test all resets)
- CSR read/write
- Bit Bash
- Aliasing
-Memory test suite added for ALL interfaces that have access to system memory map if the DUT has memories:
+Memory test suites have been added for ALL interfaces that have access to the system memory map if the DUT has memories:
- Mem walk
-Ensure all these tests verify back-2back access with zero delays, along with partial reads and partial writes.
+All these tests should verify back to back accesses with zero delays, along with partial reads and partial writes.
### FPV_MAIN_ASSERTIONS_PROVEN
Each input and each output of the module is part of at least one assertion.
-Assertions for main functional path are implemented and proven.
+Assertions for the main functional path are implemented and proven.
### SIM_ALT_TOOL_SETUP
@@ -255,48 +260,47 @@
### SIM_SMOKE_REGRESSION_SETUP
-Smoke regression set up for code health.
-A small suite of tests identified as the smoke regression suite.
-If the testbench has more than one build configurations, then each configuration has at least one test added to the smoke regression suite.
+A small suite of tests has been identified as the smoke regression suite and is run regularly to check code health.
+If the testbench has more than one build configuration, then each configuration has at least one test added to the smoke regression suite.
### SIM_NIGHTLY_REGRESSION_SETUP
-Nightly regression for running all constrained-random tests with multiple random seeds (iterations) setup.
+A nightly regression for running all constrained-random tests with multiple random seeds (iterations) has been setup.
Directed, non-random tests need not be run with multiple iterations.
Selecting the number of iterations depends on the coverage, the mean time between failure and the available compute resources.
For starters, it is recommended to set the number of iterations to 100 for each test.
-It may be trimmed down once the test has stabilized, and the same level coverage is achieved with fewer iterations.
+It may be trimmed down once the test has stabilized, and the same level of coverage is achieved with fewer iterations.
The nightly regression should finish overnight so that the results are available the next morning for triage.
### FPV_REGRESSION_SETUP
-FPV regression set up by adding the module to `hw/formal/fpv_all` script.
+An FPV regression has been set up by adding the module to the `hw/formal/fpv_all` script.
### SIM_COVERAGE_MODEL_ADDED
-Structural coverage collection model checked in.
-This is a simulator-specific file (i.e. proprietary format) that captures what hierarchies and what types of coverage is collected.
+A structural coverage collection model has been checked in.
+This is a simulator-specific file (i.e. proprietary format) that captures which hierarchies and what types of coverage are collected.
For example, pre-verified sub-modules (including some `prim` components pre-verified thoroughly with FPV) can be black-boxed - it is sufficient to only enable the IO toggle coverage of their ports.
-Functional coverage shell object created - this may not contain coverpoints or covergroups yet, but it is primed for development in post-V1.
+A functional coverage shell object has been created - this may not contain coverpoints or covergroups yet, but it is primed for development post-V1.
### TB_LINT_SETUP
[VeribleLint](https://google.github.io/verible/verilog_lint.html) for the testbench is [set up]({{< relref "hw/lint/doc/README.md" >}}) to run in nightly regression, with appropriate waivers.
-* For DV testbench, an entry is expected to be added at `hw/<top-level-design>/lint/<top-level-design>_dv_lint_cfgs.hjson`
-* For FPV testbench, an entry is expected to be added at `hw/<top-level-design>/lint/<top-level-design>_fpv_lint_cfgs.hjson`
+* For a constrained random testbench, an entry has been added to `hw/<top-level-design>/lint/<top-level-design>_dv_lint_cfgs.hjson`
+* For an FPV testbench, an entry has been added to `hw/<top-level-design>/lint/<top-level-design>_fpv_lint_cfgs.hjson`
### PRE_VERIFIED_SUB_MODULES_V1
-Sub-modules that are pre-verified with their own testbenches have already reached V1 or higher stage.
+Sub-modules that are pre-verified with their own testbenches have already reached V1 or a higher stage.
### DESIGN_SPEC_REVIEWED
-Design / micro-architecture specification reviewed and signed off.
+The design / micro-architecture specification has been reviewed and signed off.
If a product requirements document (PRD) exists, then ensure that the design specification meets the product requirements.
### TESTPLAN_REVIEWED
-Draft DV document (proposed testbench architecture) & the complete testplan reviewed with key stakeholders (as applicable):
+The draft DV document (proposed testbench architecture) and the complete testplan have been reviewed with key stakeholders (as applicable):
- DUT designer(s)
- 1-2 peer DV engineers
- Software engineer (DIF developer)
@@ -306,7 +310,7 @@
### STD_TEST_CATEGORIES_PLANNED
-Following categories of post-V1 tests focused on during the testplan review (as applicable):
+The following categories of post-V1 tests have been focused on during the testplan review (as applicable):
- Security / leakage
- Error scenarios
- Power
@@ -316,88 +320,90 @@
### V2_CHECKLIST_SCOPED
-V2 checklist reviewed to understand scope and estimate effort.
+The V2 checklist has been reviewed to understand the scope and estimate effort.
## V2
-To transition from V1 to V2, the following items are expected be completed.
+To transition from V1 to V2, the following items are expected to be completed.
+The prefix "SIM" is applicable for simulation-based DV approaches, whereas the prefix "FPV" is applicable for formal property-based verification approaches.
### DESIGN_DELTAS_CAPTURED_V2
-It is possible for the design to have undergone some changes since the DV document and testplan was reviewed in V0 stage.
-All design deltas captured adequately and appropriately in the DV document and the testplan.
+It is possible for the design to have undergone some changes since the DV document and testplan were reviewed in the V0 stage.
+All design deltas have been captured adequately and appropriately in the DV document and the testplan.
### DV_DOC_COMPLETED
-DV document is fully written.
+The DV document is fully complete.
### FUNCTIONAL_COVERAGE_IMPLEMENTED
-Functional coverage plan fully implemented.
-All covergoups created and sampled in the reactive components of the testbench (passive interfaces, monitors and scoreboards).
+The functional coverage plan is fully implemented.
+All covergoups have been created and sampled in the reactive components of the testbench (passive interfaces, monitors and scoreboards).
### ALL_INTERFACES_EXERCISED
-For simulations, interfaces connected to all sidebands and exercised.
-For the FPV, assertions added for all interfaces including sidebands.
+For simulations, all interfaces are connected to all sidebands and exercised.
+For an FPV testbench, assertions have been added for all interfaces including sidebands.
### ALL_ASSERTION_CHECKS_ADDED
-All planned assertions written and enabled.
+All planned assertions have been written and enabled.
### SIM_TB_ENV_COMPLETED
-UVM environment fully developed with end-to-end checks in scoreboard enabled.
+A UVM environment has been fully developed with end-to-end checks in the scoreboard enabled.
### SIM_ALL_TESTS_PASSING
-All tests in the testplan written and passing with at least one random seed.
+All tests in the testplan have been written and are passing with at least one random seed.
### FPV_ALL_ASSERTIONS_WRITTEN
-All assertions implemented and proven: 90%.
+All assertions are implemented and are 90% proven.
Each output of the module has at least one forward and one backward assertion check.
-FPV module converges within reasonable runtime.
+The FPV proof run converges within reasonable runtime.
### FPV_ALL_ASSUMPTIONS_REVIEWED
-All assumptions implemented and reviewed.
+All assumptions have been implemented and reviewed.
### SIM_FW_SIMULATED
-For chip-level, verified pieces of FW code (DIFs) in simulation.
+Chip-level tests exist to verify example firmware code (DIFs) in simulation.
### SIM_NIGHTLY_REGRESSION_V2
-Nightly regression with multiple random seeds passing: 90%
+A nightly regression with multiple random seeds is 90% passing.
### SIM_CODE_COVERAGE_V2
-Code coverage requirements: line, toggle, fsm (state & transition), branch, assertion: 90%
+Line, toggle, fsm (state & transition), branch and assertion code coverage has reached 90%.
### SIM_FUNCTIONAL_COVERAGE_V2
-Functional coverage requirements: 70%
+Functional coverage has reached 70%.
### FPV_CODE_COVERAGE_V2
-Code coverage requirements: branch, statement, functional: 90%
+Branch, statement and functional code coverage for FPV testbenches has reached 90%.
### FPV_COI_COVERAGE_V2
-COI coverage requirements: 75%
+COI coverage for FPV testbenches has reached 75%.
### TB_LINT_PASS
-Lint for the testbench passes. Waiver reviewed.
+The lint checking flow for the testbench passes cleanly.
+Any waiver files have been reviewed.
### PRE_VERIFIED_SUB_MODULES_V2
-Sub-modules that are pre-verified with their own testbenches have already reached V2 or higher stage.
+Sub-modules that are pre-verified with their own testbenches have already reached V2 or a higher stage.
### NO_HIGH_PRIORITY_ISSUES_PENDING
-All high priority (tagged P0 and P1) design bugs addressed and closed.
+All high priority (tagged P0 and P1) design bugs have been addressed and closed.
If the bugs were found elsewhere, ensure that they are reproduced deterministically in DV (through additional tests or by tweaking existing tests as needed) and have the design fixes adequately verified.
### ALL_LOW_PRIORITY_ISSUES_ROOT_CAUSED
@@ -407,7 +413,7 @@
### DV_DOC_TESTPLAN_REVIEWED
-Fully written DV document & the complete testplan reviewed with key stakeholders (as applicable):
+The DV document and testplan are complete and have been reviewed by key stakeholders (as applicable):
- DUT designer(s)
- 1-2 peer DV engineers
- Chip architect / design lead
@@ -419,50 +425,50 @@
### V3_CHECKLIST_SCOPED
-V3 checklist reviewed to understand scope and estimate effort.
+The V3 checklist has been reviewed to understand the scope and estimate effort.
## V3
-To transition from V2 to V3, the following items are expected be completed.
-Prefix "SIM" is applicable for simulation-based DV approach only, while "FPV" is for FPV approach only.
+To transition from V2 to V3, the following items are expected to be completed.
+The prefix "SIM" is applicable for simulation-based DV approaches, whereas the prefix "FPV" is applicable for formal property-based verification approaches.
### DESIGN_DELTAS_CAPTURED_V3
-Although rare, it is still possible for the design to have undergo some more last-minute changes.
-All additional design deltas captured adequately and appropriately in the DV document and the testplan.
+Although rare, it is possible for the design to have undergone some last-minute changes since V2.
+All additional design deltas have been captured adequately and appropriately in the DV document and the testplan.
### X_PROP_ANALYSIS_COMPLETED
-X Propagation Analysis complete
+X Propagation analysis has been completed.
### FPV_ASSERTIONS_PROVEN_AT_V3
-All assertions implemented and proven: 100%.
+All assertions are implemented and 100% proven.
There are no undetermined or unreachable properties.
### SIM_NIGHTLY_REGRESSION_AT_V3
-Nightly regression with multiple random seeds passing: 100% (with 1 week minimum soak time)
+A nightly regression with multiple random seeds is 100% passing (with 1 week minimum soak time).
### SIM_CODE_COVERAGE_AT_100
-Code coverage requirements: line, toggle, fsm (state & transition), branch, assertion: 100%
+Line, toggle, fsm (state & transition), branch and assertion code coverage has reached 100%.
### SIM_FUNCTIONAL_COVERAGE_AT_100
-Functional coverage requirements: 100%
+Functional coverage has reached 100%.
### FPV_CODE_COVERAGE_AT_100
-Code coverage requirements: branch, statement, functional: 100%
+Branch, statement and functional code coverage for FPV testbenches has reached 100%.
### FPV_COI_COVERAGE_AT_100
-COI coverage requirements: 100%
+COI coverage for FPV testbenches has reached 100%.
### ALL_TODOS_RESOLVED
-There are no TODO items in the entire testbench code, including common components and UVCs.
+There are no remaining TODO items anywhere in the testbench code, including common components and UVCs.
### NO_TOOL_WARNINGS_THROWN
@@ -470,20 +476,20 @@
### TB_LINT_COMPLETE
-Lint for the testbench is clean.
-Lint waiver file reviewed and signed off by tech steering committe.
+The lint flow for the testbench is clean.
+Any lint waiver files have been reviewed and signed off by the technical steering committee.
### PRE_VERIFIED_SUB_MODULES_V3
-Sub-modules that are pre-verified with their own testbenches have already reached V3 stage.
+Sub-modules that are pre-verified with their own testbenches have already reached the V3 stage.
### NO_ISSUES_PENDING
-All design and testbench bugs addressed and closed.
+All design and testbench bugs have been addressed and closed.
## S1
-For a transition from S0 to S1, the following items are expected be completed.
+For a transition from S0 to S1, the following items are expected to be completed.
### DIF_EXISTS
@@ -511,11 +517,11 @@
## S2
-For a transition from S1 to S2, the following items are expected be completed.
+For a transition from S1 to S2, the following items are expected to be completed.
### DIF_FEATURES
-DIF has functions to cover all specified hardware functionality.
+The DIF has functions to cover all specified hardware functionality.
### DIF_HW_USAGE_REVIEWED
@@ -527,15 +533,15 @@
### DIF_HW_PARAMS
-DIF uses automatically generated HW parameters and register definitions.
+The DIF uses automatically generated HW parameters and register definitions.
### DIF_DOC_HW
-HW IP Programmer's guide references specific DIF APIs that can be used for operations.
+The HW IP Programmer's guide references specific DIF APIs that can be used for operations.
### DIF_CODE_STYLE
-DIF follows the DIF-specific guidelines in [`sw/device/lib/dif/README.md`]({{< relref "sw/device/lib/dif/README.md" >}}) and the OpenTitan C style guidelines.
+The DIF follows DIF-specific guidelines in [`sw/device/lib/dif/README.md`]({{< relref "sw/device/lib/dif/README.md" >}}) and the OpenTitan C style guidelines.
### DIF_DV_TESTS
@@ -543,7 +549,7 @@
## S3
-For a transition from S2 to S3, the following items are expected be completed.
+For a transition from S2 to S3, the following items are expected to be completed.
### DIF_HW_DESIGN_COMPLETE
@@ -555,11 +561,11 @@
### DIF_REVIEW_C_STABLE
-Fully re-review C interface and implementation, with a view to the interface not changing in future.
+The C interface and its implementation have been fully re-reviewed, with a view to the interface not changing in future.
### DIF_TEST_UNIT_COMPLETE
-Unit tests cover (at least):
+Unit tests exist to cover (at least):
- Device Initialisation
- All Device FIFOs (including when empty, full, and adding data)
@@ -569,4 +575,4 @@
### DIF_TODO_COMPLETE
-Ensure all DIF TODOs are complete.
+All DIF TODOs are complete.
