Now that parameters support "when", needed to remove CONFIG_PTR_ADDRESS from MC-1 YAML.

[james-ball-qualcomm]

No description provided.

[jalobaba]

I noticed that you added a patch version (1.11.0 vs original 1.11") in MC-1 for TIME_CSR_IMPLEMENTED. This surprises me because I've been assuming that 1.11 and 1.11.0 were the same thing (a missing patch default is the same as saying 0). I'd like to better understand this.

Thanks for making the changes to the CRD code & template.

One other question. Do we need to make similar changes to the Profile code & template? It will have the same problem I'm guessing.

[dhower-qc]

I noticed that you added a patch version (1.11.0 vs original 1.11") in MC-1 for TIME_CSR_IMPLEMENTED. This surprises me because I've been assuming that 1.11 and 1.11.0 were the same thing (a missing patch default is the same as saying 0). I'd like to better understand this.

Thanks for making the changes to the CRD code & template.

One other question. Do we need to make similar changes to the Profile code & template? It will have the same problem I'm guessing.

Great question. We are borrowing the scheme used by several Ruby dependency systems to manage versions. In fact, we directly use the Gem library for version comparisons; see https://docs.ruby-lang.org/en/3.2/Gem/Version.html for a full description.

The important part here is the '~>' operator that you see in the CRD. From the Gem::Version doc:

Specification From  ... To (exclusive)
">= 3.0"      3.0   ... ∞
"~> 3.0"      3.0   ... 4.0
"~> 3.0.0"    3.0.0 ... 3.1
"~> 3.5"      3.5   ... 4.0
"~> 3.5.0"    3.5.0 ... 3.6
"~> 3"        3.0   ... 4.0

So when we say "~>1.11", it will accept any version >= 1.11 and < 2.0. Notably, that means version 1.12 is accepted, which is why CONFIG_PTR_ADDRESS, introduced in 1.12, shows up as a parameter. "~> 1.11.0", on the other hand, accepts anything that is >= 1.11.0 and < 1.12.

As for the profile spec, I'd say the answer to your question isn't clear yet. It's not obvious (to me) if RVI intended to lock an extension version in when they ratified the RVA profiles, or if the intent was that future extension versions are also acceptable. Extension versions aren't even mentioned in the profile, even though they exist in the ISA manual. And it's messy because RVI hasn't been following semantic versioning.