Revamp certificate naming and versioning scheme

[james-ball-qualcomm]

I've been thinking about the certificate naming scheme and versioning scheme and how those map to the standards naming schemes and versioning scheme. This will not be 1:1 relationships because we have have many certification releases for a single standard release. As long as the database tracks the relationship between the two naming schemes (CRD and TSC standards/profiles/platforms) we should be good.

Here's a proposal:
MC100 is the most minimal microcontroller. It has no optional extensions, a few in-scope extension parameters, and many out-of-scope extension parameters. Its first release will be call MC100-v1 with an implicit 0 minor release and 0 patch release so with those included is MC100-v1.0.0. After this we might to decide to add an optional feature to MC100 such as PMP so we create MC100-v1.1.0 to indicate it is a new MC100 release with one or more optional features. Later we get enough customer demand for MC100 with a PMP but also with a CLIC. and they want them mandatory. So, instead of creating MC100-v2.0.0 we decide to create MC120-v1.0.0. Then we get need for an MC120 but with with Zicond mandatory so we create MC120-v1.1.0 (minor release). Next we create a microcontroller that has CLIC & PMP mandatory but with U-mode and S-mode optional and sPMP optional called MC200-v1.0.0. Then we want a microcontroller that is similar to MC100 but with the Zc extension mandatory so we call it MC100-v2.0.0.

[jalobaba]

Let's explore apps processors. We'll focus on ratified profiles. We'll need to add more scope to them to also specify M-mode and probably debug and trace. So, first we have to decide if our certificate names will match profile names or we'll have our own names that map to theirs. If the latter we can follow the microcontroller scheme proposed and call them AC something.

Seems like we'll have a certificate product name (e.g., MC100 or AC100) and a certificate version number (e.g., v1, v1.1, v1.2.1, v2, v3.4.5, etc.) that follows semantic numbering. What I'm not clear about is when we add new mandatory or optional extensions, do we update the product name (MC100 becomes MC101, MC110, or MC200) or do we keep the product name the same and update the certificate version number (e.g., v1 becomes v1.1 or v2). Seems like the former because the latter would be used as we increase allowed parameters (move from out-of-scope to in-scope). If we add things to the scope of the certificate that aren't strictly just ISA extensions like debug or trace we'd update the version major number. The version minor number would be updated when supporting more parameters.

Say AC100 is RVB23 without V and H but with M-mode and no debug, trace, PMP or MTT. This is the first apps processor we certify. Then we add optional support for H so now this is AC110. Then we add optional support for V so this is AC120. At the same time we create AC200 that is RVA23 with both H and V mandatory as defined by RVA23.

Say we want to add an optional M- mode PMP or MTT to all our apps processor certificates. Would that mean changing the product name for AC120 to AC121 or AC130 and the product name for AC200 to AC201 or AC210 or do we keep the product name the same and increase the version major number?

[james-ball-qualcomm]

Here's a list of all the use cases I think our CRD naming/versioning will need to support. Please review this list and indicate if something isn't clearly worded, inaccurate, vague, or I'm missing a case.

1. CRD updated to improve descriptions (no functional changes)
2. Fix bugs in the certification tests. Could cause implementations that passed with the bugs in place to now fail.
3. Increase scope of certification tests to move out-of-scope parameters (listed in the CRD) to in-scope parameters or allow more values for existing in-scope parameters. We aren't adding any new extensions to the CRD; we are just testing more of the architecturally defined behaviors of CRD listed extensions. Could cause one or more certificates that passed with the original smaller scope to fail.
4. Increase scope of certification tests to test aspects of existing CRD listed extensions without any changes to their CRD listed parameters. For example, assume when we originally issued a certificate we didn't test exception priority and then added tests for that. Could cause one or more certificates that passed with the original smaller scope to fail.
5. Add certification tests for an extension previously not included in existing CRDs. Naming/versioning might want to differentiate between small extensions (e.g., Zicond) and large extensions (e.g., U-mode, PMP, H, or V). Naming/versioning might also want to differentiate between extensions added as optional vs. mandatory to CRDs.
6. TSC creates a new version of an existing standard. It could be a major release or a minor release. The TSC has versions for extensions, the Unpriv ISA manual, Priv ISA manual, Profiles, Platforms, and non-ISA standards (e.g., debug, trace, IOMMU, AIA).

[james-ball-qualcomm]

Focusing on RVCP changes:

Case	Change	Examples	Solution	Old Name	New Name
RVCP1	Correct CRD	Typo or improve clarity	+1 patch	MC100v1.0.0	MC100v1.0.1
RVCP2	Fix test bug	Wrong test result	+1 minor	MC100v1.1	MC100v1.2
RVCP3	Increase flexibility	Add values to existing in-scope parameters	+1 minor	MC100v1.1	MC100v1.2
RVCP4	Increase scope	Test more behaviors of existing features and/or move out-of-scope parameters to in-scope	+1 major	MC100v1.1	MC100v2.0
RVCP5	New optional feature (small)	Zicond	+1 name	MC100	MC101
RVCP6	New optional feature (large)	H, V, PMP, CLIC	+10 name	MC100	MC110
RVCP7	New mandatory feature (small or large)	H, V, PMP, CLIC	+100 name	MC100	MC200

Focusing on TSC changes:

Case	Change	Example	Solution	Notes
TSC1	ISA extension (new or update)	AME, I/D Consistency	RVCP5-7
TSC2	Non-ISA extension (new or update)	IOMMU, Debug	RVCP5-7
TSC3	New release of Priv/ISA ISA manual	Priv 1.13	RVCP5-7	Just a named grouping of versioned extensions
TSC4	Profile (new or update)	RVA22, RVA23, RVB23	RVCP5-7	Just a named grouping of versioned extensions
TSC5	Platform (new or update)	Server	RVCP5-7	Just a named grouping of versioned extensions

[james-ball-qualcomm]

Proposed RVCP Certificates:

Certificate	Profile	Key Mandatory Extensions	Key Optional Extensions
MC100	None	RVI32+C+M+Sm+Zicntr+Zicsr	None
MC200	RVM23 (if it happens)	MC100+B+Zce+Zicond	A, F, D, CLIC, PMP, Debug, Trace
AC100	RVB23	All in RVB23	PMP, new atomics, ptr masking, SS&LP, Sv48, Sv57, Zama16b
AC110	RVB23	AC100+H	Same as AC100
AC120	RVB23	AC100+V	Same as AC100 + vector crypto
AC200	RVA23	All in RVA23 (includes H & V)	Same as AC120, Debug, Trace
AC210	RVA23	AC200	Same as AC200 + MTT (when ratified)

[james-ball-qualcomm]

I've put this in slides at https://docs.google.com/presentation/d/1dc7-uWNIHd6qMNlhWxfwCnzACQaSL2vfkHqP_qdpkac