Promote policy to chapter level

Signed-off-by: Jeff Scheel <[email protected]>

src/acceptance_criteria.adoc

@@ -1,12 +1,12 @@
 [[acceptance_criteria]]
-=== Acceptance Criteria
+== Acceptance Criteria
 
 *Version:* 1.2 +
 *One line description:* What must be complete before TSC can approve a specification for ratification +
 *Author(s)*: Mark I Himelstein, Stephano Cetola +
 *Status:* Approved +
 
-==== Version History
+*Version History:* +
 [width="100%",cols="<5%,<15%,<50%,<20%",options="header",]
 |===
 |Ver |Date |Details |Name(s)
@@ -24,13 +24,23 @@ https://docs.google.com/spreadsheets/d/1iXUZdNH6aZ-EDxsOqhYW82Ha6L7K4uVZt0-Rw9ZR
 Status Checklist] |Stephano Cetola
 |===
 
-===== Milestone
+=== Rationale
+
+This document acts as a minimum viable definition of tasks, while the
+https://docs.google.com/spreadsheets/d/1iXUZdNH6aZ-EDxsOqhYW82Ha6L7K4uVZt0-Rw9ZR-nY/edit?usp=sharing[ISA
+Status Checklist] contains the details. For any given specification, see
+the relevant status checklist for how that specification meets the
+requirements defined in this policy.
+
+=== Related documentation
+
+==== Milestone
 See the
 https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit?usp=sharing[Specification
 Lifecycle and Milestone Definitions] for more detailed milestone
 definitions.
 
-===== Task
+==== Task
 
 See the
 https://docs.google.com/spreadsheets/d/1iXUZdNH6aZ-EDxsOqhYW82Ha6L7K4uVZt0-Rw9ZR-nY/edit?usp=sharing[ISA
@@ -41,15 +51,7 @@ for Non-ISA Specifications] are much more flexible based on the nature
 of Non-ISA Specifications. This document is meant only as a guide for
 Non-ISA Specifications and Architectural Overview specifications.
 
-==== Rationale
-
-This document acts as a minimum viable definition of tasks, while the
-https://docs.google.com/spreadsheets/d/1iXUZdNH6aZ-EDxsOqhYW82Ha6L7K4uVZt0-Rw9ZR-nY/edit?usp=sharing[ISA
-Status Checklist] contains the details. For any given specification, see
-the relevant status checklist for how that specification meets the
-requirements defined in this policy.
-
-==== Policy
+=== Policy
 
 The TG must complete or provide waivers for all of the
 link:#list-of-tasks[List of Tasks] to reach the given milestone. The TG
@@ -62,9 +64,9 @@ checklist] by:
 . Providing milestone date projections and a monthly status updates +
 . Identifying any delays and providing mitigation plans
 
-===== List of Tasks
+==== List of Tasks
 
-====== Freeze
+===== Freeze
 
 . *Document Complete* - the document must describe the semantics of
 instructions or operations and any other extension-specific visible
@@ -95,7 +97,7 @@ waiver. The committee may ask for revisions in the POC. +
 (e.g. encumbered information, friendly terminology, anonymous
 contributor) currently in development.
 
-====== Ratification Ready
+===== Ratification Ready
 
 . *Resolve Freeze Waivers* - Either resolve freeze waivers or get new
 waivers for vote-ready updating the status of the old waivers. +
@@ -123,7 +125,7 @@ RISC-V profile. +
 (e.g. encumbered information, friendly terminology, anonymous
 contributor) currently in development.
 
-===== Waivers
+==== Waivers
 
 Waivers for Freeze are approved by Tech Chairs 6+ majority vote. Waivers
 for ratification are approved by TSC 6+ majority vote.
@@ -132,7 +134,7 @@ For ratification, any infrastructure that does not exist and will not
 exist within the next year requires a Committee Chairs majority vote to
 waive, and for the TSC to be notified of the waiver (and may override).
 
-==== Exceptions
+=== Exceptions
 
 The CTO is the escalation path for all policy issues, with the authority
 to resolve them or, if necessary, escalate further to the TSC or the

src/act.adoc

@@ -1,5 +1,5 @@
 [[act]]
-=== Architectural Compatibility Test
+== Architectural Compatibility Test
 
 *Version:* 1.2 +
 *One line description:* These are the rules that explain the rationale
@@ -8,8 +8,7 @@ architectural tests, and conditions for waiving failures. +
 *Author(s):* Allen Baum, Ken Dockser +
 *Status:* Approved +
 
-==== Version History
-
+*Version History:* +
 [width="100%",cols="<5%,<15%,<50%,<20%",options="header",]
 |===
 |Ver |Date |Details |Name(s)
@@ -24,7 +23,7 @@ architectural tests, and conditions for waiving failures. +
 |===
 
 
-==== Rationale
+=== Rationale
 
 RISC-V Architectural Tests (ACT) are an evolving set of tests that are
 created to help ensure that SW written for a given RISC-V Profile will
@@ -47,9 +46,9 @@ The RISC-V Architectural Tests are *_not_* a substitute for rigorous
 design verification; it is the responsibility of the implementer to
 deploy extensive testing.
 
-==== Policy
+=== Policy
 
-===== Who Must Test
+==== Who Must Test
 
 Anyone who develops RTL or a functional model for a RISC-V core and
 wants to be listed as RISC-V ISA Compatible (e.g., in order to use the
@@ -67,7 +66,7 @@ the new design listed as RISC-V ISA Compatible by passing the
 appropriate RISC-V ACT and by self-certifying that the changed design is
 RISC-V compatible.
 
-===== What Must be Tested
+==== What Must be Tested
 
 The RTL or functional model of the core design must run and pass all of
 the tests within the ACT that RISC-V International says are required for
@@ -100,7 +99,7 @@ the tests in a repository README file. This will also include which
 reference model to use for the test as well as any other environmental
 requirements (e.g., amount of RAM).
 
-===== Where to Report Test Results
+==== Where to Report Test Results
 
 The ACT framework will generate a test report file with the name +
 <instanceID>-<test-date>.html with the <test-date> in YYYY-MM-DD format
@@ -141,14 +140,14 @@ Vendors can submit their test results by filing a Pull Request that adds
 the test report into a directory named for the vendor in the
 https://github.com/riscv/riscv-arch-test-reports repository
 
-===== *When to Report Test Results*
+==== When to Report Test Results
 
 To retain their RISC-V ISA Compatibility listing, cores must pass the
 ACT yearly if ACT tests, toolchain, reference simulators, or framework
 change from those used to generate the test report, and issue errata if
 new issues are found.
 
-===== Test-Case Waivers
+==== Test-Case Waivers
 
 There are some special cases where it is not possible for an
 implementation to pass all of the tests due to issues that may be
@@ -169,7 +168,7 @@ the same PR number as the waiver.
 Waivers are categorized into Flawed-Test,Constraint-Based, and
 Errata-Based types.
 
-====== Flawed-test test-case waiver
+===== Flawed-test test-case waiver
 
 If there is a demonstrable bug in the test, reference model, or tool
 chain that causes a test to fail, a Flawed-Test Test-Case Waiver may be
@@ -188,7 +187,7 @@ test-report for the most recent test-suite. +
 architecture. Cases that involve architectural ambiguity should be
 resolved by clarification in the specification.
 
-====== Constraint-based test-case waiver
+===== Constraint-based test-case waiver
 
 Constraint waivers may be granted in special cases including when:
 
@@ -203,7 +202,7 @@ In order to qualify for and be granted a constraint-based waiver:
 * The implementer must document the constraint and its rationale to TSC,
 and demonstrate that it is an architecturally valid configuration.
 
-====== Errata-based test-case waiver
+===== Errata-based test-case waiver
 
 Errata-based waivers may be granted in special cases including when:
 
@@ -256,7 +255,7 @@ implementations (e.g., the physical design is substantially changed) as
 these are considered new designs; implementers are expected to use this
 opportunity to fix known bugs.
 
-===== Test-case waiver conditions
+==== Test-case waiver conditions
 
 When a test-case waiver is granted, it
 
@@ -284,7 +283,7 @@ All waivers must be approved by a majority vote of the appropriate ISA
 Committee (i.e., privileged or unprivileged) and the SW or other related
 non-ISA HC..
 
-===== Test Case Failures due to ISA restrictions or ambiguity
+==== Test Case Failures due to ISA restrictions or ambiguity
 
 If a design fails on a test case, and the implementer believes that the
 failure is due to either an ambiguity in the ISA or that the ISA is
@@ -320,7 +319,7 @@ ACT point to a major gap in the understanding of the architecture or the
 design verification process.
 ====
 
-==== Exceptions
+=== Exceptions
 
 Exceptions to the test requirements are handled through the waiver
 process and changes to the ISA as mentioned above.
@@ -332,3 +331,4 @@ be only supported through vendor efforts and not through RISC-V.
 
 Any escalation should occur to the CTO who may choose to resolve the
 issue, or escalate to the TSC or the CEO or the BOD.
+

src/act_priv_spec_1_11.adoc

@@ -1,16 +1,15 @@
 [[act_priv_spec_1_11]]
-=== ACT Requirements for Privileged 1.11 Specification
+== ACT Requirements for Privileged 1.11 Specification
 
 *Version:* 0.2 +
 *One line description:* This policy describes simplified Architectural
 Compatibility Test (ACT) requirements for the privileged specification.
 This policy is temporary and will be replaced by a standard ACT suite in
 the future. +
 *Author(s):* Greg Favor, Arun Thomas +
-*Status:* Approved +
-
-==== Version History
+*Status:* Archived +
 
+*Version History:* +
 [width="100%",cols="<5%,<15%,<50%,<20%",options="header",]
 |===
 |Ver |Date |Details |Name(s)
@@ -21,7 +20,7 @@ the future. +
 |0.1 |2021-05-03 |Original draft |Greg Favor, Arun Thomas
 |===
 
-==== Rationale
+=== Rationale
 
 https://docs.google.com/document/u/2/d/1ZKSLQ5HPT3E_CqTVOQlBPs7qJ9v1mpnMDXHhtOQJFcU/edit[Architectural
 Compatibility Tests (ACT)] are required for Privileged Specification
@@ -32,7 +31,7 @@ compatibility testing methodology based on running operating system and
 hypervisor software that exercises new features added in Privileged
 Specification 1.12.
 
-==== Policy:
+=== Policy:
 
 . In lieu of member’s running ACT suite for Privileged Specification
 1.12 features which are intended to be used for compatibility,
@@ -70,5 +69,5 @@ corner cases. +
 . This policy is temporary and applies only to Privileged Specification
 1.12 ratification.
 
-==== Transition to start using policy: +
+=== Transition to start using policy: +
 Immediate

src/architecture_review.adoc

@@ -1,13 +1,12 @@
 [[architecture_review]]
-=== Architecture Review
+== Architecture Review
 
 *Version:* 1.2 +
 *One line description:* This policy cover the opcode encoding, mnemonics, and CSR +
 *Author(s):* Greg Favor, Krste Asanović +
 *Status:* Approved +
 
-==== Version History
-
+*Version History:* +
 [width="100%",cols="<5%,<15%,<50%,<20%",options="header",]
 |===
 |Ver |Date |Details |Name(s)
@@ -20,15 +19,15 @@
 
 |===
 
-==== Rationale
+=== Rationale
 
 We need to produce robust extensions that are consistent with the ratified RISC-V specifications and RISC-V overall strategy. 
 
 We also need to coordinate assignments of opcode encodings, mnemonics,
 CSRs, etc so we have a consistent set of conventions across extensions,
 handle different profile targets, and manage encoding resources.
 
-==== Policy
+=== Policy
 
 There was a previous policy that covered some of the same areas as this
 policy and this policy fully supersedes any older policy covering the
@@ -47,7 +46,7 @@ There are four pieces to this process:
 * Opcode assignment review +
 * CSR assignment review
 
-===== Process details
+==== Process details
 
 * The four ISA committee chairs and their delegates, will work together
 to accomplish this policy. +
@@ -84,7 +83,7 @@ feedback.). The queue will be reviewed by one of the chairs of the ICs
 at every chairs meeting and rolled up to the BOD monthly for the high
 priority extensions.
 
-===== AR Review During the Specification Development Lifecycle
+==== AR Review During the Specification Development Lifecycle
 
 In the process of developing the RISC-V Specification, Architecture
 Review (AR) serves a pivotal function. This review can occur at various
@@ -99,15 +98,15 @@ and enhancements are needed. Lastly, AR is required during the Ratification-Read
 phase if the specification text has undergone any significant changes (i.e. past 
 simple typo corrections, formatting corrections, and very simple clarifications).
 
-==== Exception handling
+=== Exception handling
 
 All exception requests should be forwarded to the ISA committees. It is
 unlikely any will be granted.
 
 Any escalation should occur to the CTO who may choose to resolve the
 issue, or escalate to the TSC or the CEO or the BOD.
 
-==== Transition to start using policy
+=== Transition to start using policy
 
 Effective immediately. This will be the acting policy while awaiting
 approval (possibly with modifications before approval). Any extension