[doc] Rename Hardware -> Development Stages
In advance of adding Device Interface Function (DIF) stage tracking to
the development stages, this change renames `doc/project/hw_stages.md`
to `doc/project/development_stages.md` and updates all the links that
reference it.
Signed-off-by: Sam Elliott <selliott@lowrisc.org>
diff --git a/doc/ug/design.md b/doc/ug/design.md
index 1ab59f9..d6389d2 100644
--- a/doc/ug/design.md
+++ b/doc/ug/design.md
@@ -35,7 +35,7 @@
Designs within the OpenTitan project come in a variety of completion status levels.
Some designs are "tapeout ready" while others are still a work in progress.
Understanding the status of a design is important to gauge the confidence in its advertised feature set.
-To that end, we've designated a spectrum of design stages in the [OpenTitan Hardware Development Stages]({{< relref "doc/project/hw_stages.md" >}}) document.
+To that end, we've designated a spectrum of design stages in the [OpenTitan Hardware Development Stages]({{< relref "doc/project/development_stages.md" >}}) document.
This document defines the design stages and references where one can find the current status of each of the designs in the repository.
## Documentation
@@ -85,7 +85,7 @@
Note that all designs with enabled AscentLint targets will be run through the tool in eight-hour intervals and the results are published as part of the tool dashboards on the [hardware IP overview page](https://docs.opentitan.org/hw), enabling designers to close the lint errors and warnings even if they cannot run the sign-off tool locally.
-Goals for linting closure per design milestone are given in the [OpenTitan Development Stages]({{< relref "doc/project/hw_stages" >}}) document.
+Goals for linting closure per design milestone are given in the [OpenTitan Development Stages]({{< relref "doc/project/development_stages" >}}) document.
## Assertion Methodology
diff --git a/doc/ug/dv_methodology.md b/doc/ug/dv_methodology.md
index 3ce4e3b..3353f0e 100644
--- a/doc/ug/dv_methodology.md
+++ b/doc/ug/dv_methodology.md
@@ -33,7 +33,7 @@
Verification within the OpenTitan project comes in a variety of completion status levels.
Some designs are "tapeout ready" while others are still a work in progress.
Understanding the status of verification is important to gauge the confidence in the design's advertised feature set.
-To that end, we've designated a spectrum of design and verification stages in the [OpenTitan Hardware Development Stages]({{< relref "doc/project/hw_stages.md" >}}) document.
+To that end, we've designated a spectrum of design and verification stages in the [OpenTitan Hardware Development Stages]({{< relref "doc/project/development_stages.md" >}}) document.
It defines the verification stages and references where one can find the current verification status of each of the designs in the repository.
Splitting the effort in such a way enables the team to pace the development effort and allows the progress to be in lock-step with the design stages.
The list of tasks that are required to be completed to enable the effort to transition from one stage to the next is defined in the [checklists]({{< relref "doc/project/checklist" >}}) document.
@@ -44,7 +44,7 @@
DV effort needs to be well documented to not only provide a detailed description of what tests are being planned, but also how the overall effort is strategized and implemented.
The first is provided by the **testplan** document and the second, by the **DV plan** document.
-The [**project status**]({{< relref "doc/project/hw_stages.md#indicating-stages-and-making-transitions" >}}) document tracks to progression of the effort through the stages.
+The [**project status**]({{< relref "doc/project/development_stages.md#indicating-stages-and-making-transitions" >}}) document tracks to progression of the effort through the stages.
In addition to these documents, a nightly **regression dashboard** tabulating the test and coverage results will provide ability to track progress towards completion of the verification stages.
@@ -186,7 +186,7 @@
When progressing through the verification stages, there are key focus areas or testing activities that are perhaps common across all DUTs.
These are as follows.
-### Progressing towards [V1]({{< relref "doc/project/hw_stages#hardware-verification-stages" >}})
+### Progressing towards [V1]({{< relref "doc/project/development_stages#hardware-verification-stages" >}})
These set of tests (not exhaustive) provide the confidence that the design is ready for vertical integration.
@@ -203,7 +203,7 @@
The very first set of real tests validate the SW interface laid out using the regtool.
These prove that the SW interface is solid and all assumptions in CSRs in terms of field descriptions and their accessibility are correctly captured and there are no address decode bugs.
-### Progressing towards [V2]({{< relref "doc/project/hw_stages#hardware-verification-stages" >}})
+### Progressing towards [V2]({{< relref "doc/project/development_stages#hardware-verification-stages" >}})
Bulk of testing in this stage focus on functionally testing the DUT.
There however are certain categories of tests that may need additional attention.
@@ -250,7 +250,7 @@
The level of constraints are then slowly eased to allow deeper state space exploration, until all areas of the DUT are satisfactorily stressed.
Stress tests are ideal for bug hunting and closing coverage.
-### Progressing towards [V3]({{< relref "doc/project/hw_stages#hardware-verification-stages" >}})
+### Progressing towards [V3]({{< relref "doc/project/development_stages#hardware-verification-stages" >}})
The main focus of testing at this stage is to meet our [regression](#nightly) and [coverage](#coverage-collection) goals.
Apart from that, there are cleanup activities to resolve all pending TODO items in the DV code base and fix all compile and run time warnings (if any) thrown by the simulator tools.
@@ -492,7 +492,7 @@
The feedback in this review flows both ways - the language in the design specification could be made more precise, or missing items in both, the design specification as well as in the testplan could be identified and added.
This enables the development stage to progress smoothly.
-Subsequently, the intermediate transitions within the verification stages are reviewed within the GitHub pull-request made for updating the checklist and the [project status]({{< relref "doc/project/hw_stages.md#indicating-stages-and-making-transitions" >}}).
+Subsequently, the intermediate transitions within the verification stages are reviewed within the GitHub pull-request made for updating the checklist and the [project status]({{< relref "doc/project/development_stages.md#indicating-stages-and-making-transitions" >}}).
Finally, after the verification effort is complete, there is a final sign-off review to ensure all checklist items are completed satisfactorily without any major exceptions or open issues.
diff --git a/doc/ug/getting_started_design.md b/doc/ug/getting_started_design.md
index b8e8c46..e13bf5e 100644
--- a/doc/ug/getting_started_design.md
+++ b/doc/ug/getting_started_design.md
@@ -13,7 +13,7 @@
## Stages of a Design
-The life stages of a design within the OpenTitan are described in the [Hardware Development Stages]({{< relref "doc/project/hw_stages.md" >}}) document.
+The life stages of a design within the OpenTitan are described in the [Hardware Development Stages]({{< relref "doc/project/development_stages.md" >}}) document.
This separates the life of the design into three broad stages: Specification, In Development, and Signed off.
This document attempts to give guidance on how to get going with the first stage and have a smooth transition into the Development stage.
They are not hard and fast rules but methods we have seen work well in the project.
@@ -76,7 +76,7 @@
## Full Design
-As the design develops within the OpenTitan repository, it transitions into "D0", "D1", etc., [design stages]({{< relref "doc/project/hw_stages.md" >}}) and will be eventually plugged into the top level.
+As the design develops within the OpenTitan repository, it transitions into "D0", "D1", etc., [design stages]({{< relref "doc/project/development_stages.md" >}}) and will be eventually plugged into the top level.
Following the recommended best practices for digestible pull requests suggests that continuing to stage the design from the initial skeleton into the full featured design is a good way to make steady progress without over-burdening the reviewers.
## Top Level Inclusion
diff --git a/doc/ug/getting_started_dv.md b/doc/ug/getting_started_dv.md
index 724aaf5..0e23691 100644
--- a/doc/ug/getting_started_dv.md
+++ b/doc/ug/getting_started_dv.md
@@ -8,7 +8,7 @@
## Stages of DV
-The life stages of a design / DV effort within the OpenTitan are described in the [Hardware Development Stages]({{< relref "doc/project/hw_stages.md" >}}) document.
+The life stages of a design / DV effort within the OpenTitan are described in the [Hardware Development Stages]({{< relref "doc/project/development_stages.md" >}}) document.
It separates the life of DV into three broad stages: Initial Work, Under Test and Testing Complete.
This document attempts to give guidance on how to get going with the first stage and have a smooth transition into the Under Test stage.
They are not hard and fast rules but methods we have seen work well in the project.
@@ -88,7 +88,7 @@
## Full DV
-Running the sanity and CSR suite of tests while making progress toward reaching the [V1 stage]({{< relref "doc/project/hw_stages#hardware-verification-stages" >}}) should provide a good reference in terms of how to develop tests as outlined in the testplan and running and debugging them.
+Running the sanity and CSR suite of tests while making progress toward reaching the [V1 stage]({{< relref "doc/project/development_stages#hardware-verification-stages" >}}) should provide a good reference in terms of how to develop tests as outlined in the testplan and running and debugging them.
Please refer to the [checklist]({{< relref "doc/project/checklist" >}}) to understand the key requirements for progressing through the subsequent verification stages and final signoff.
The [UART DV](https://github.com/lowRISC/opentitan/tree/master/hw/ip/uart/dv) area can be used as a canonical example for making progress.
