[SVD] optional peripherals

[tarek-bochkati]

assuming this simple use case

• STM32U57x devices are without HW crypto => should deliver STM32U57x.SVD | 7982 KB
• STM32U58x devices are with HW crypto => should deliver STM32U58x.SVD | 8002 KB

the 2 SVD files are 99.66% identical.

We would like to have a condition tag where we can filter out some peripherals based on the device name. Example:

<peripheral>
      <name>AES</name>
      <condition>Dname==STM32U58*</condition>
      <!-- ... -->
</peripheral>

Also some peripherals could not exist a device based on the device package (not enough pins), so we can provide an SVD per device without delivering a huge number of SVD files. Thus may imply that we can have multiple condition tag in the same peripheral. Example:

<peripheral>
      <name>AES</name>
      <condition>Dname==STM32U58*</condition>
      <condition>Dname==STM32U5A*</condition>
      <!-- ... -->
</peripheral>

Then the tool before loading the SVD can filter out the non-existing peripherals. This will help us optimize the DFP size when unzipped in the user PC.

Update 11-12-2023

It would beneficial to push this condition to register and field and maybe interrupt nodes

[jkrech]

Hi Tarek, that is a great idea. One of the benefits of both the specification as well as the tools being part of an Open-Source project is, that you cannot only suggest such improvements in the specification but you can also contribute. https://github.com/Open-CMSIS-Pack/svd-spec SVDConv utility is here: https://github.com/Open-CMSIS-Pack/devtools/tree/main/tools/svdconv One thing we must consider though, is that there is already many implementations out there reading the SVD files, which are outside of this repository.

[tarek-bochkati]

@jkrech I don't have the right to move this issue to https://github.com/Open-CMSIS-Pack/svd-spec Could you please do it for me

[jkrech]

@tarek-bochkati, this issue got moved to the svd-spec repository now.

[edriouk]

1. I would recommend using attributes in conditions instead of text:

   • it is possible to specify several attributes in a condition: Dname, Dcore, Dtz, etc.
   • much easier to add new attributes without changing the code
   • we can reuse already existing code to perform wildcard matching for attributes

2. This proposal represents OR logic. Could we have situations where NOT and AND logic would be required?

[tarek-bochkati]

Thanks @edriouk for your proposal.

1.\ I think that with attribute we can achieve the same goal. And if it is easier to implement, I think this is the way to go, specially that this proposal goes side by side with conditions presentation in the PDSC format.

2.\ in my current situation I can foresee a future use of NOT logic. so I might say that for completeness we should implement similar mechanism to the PDSC conditions.

@edriouk do you think that we can inherit the same condition syntax from PDSC ?

Note: we foresee benefits if we have conditions support in register and field and maybe interrupt nodes

<!-- ... -->
<device>
  <conditions>
    <condition id="AES">
      <accept Dname="STM32U58*"/>
      <accept Dname="STM32U5A*"/>
    </condition>
  </conditions>
  <!-- ... -->
  <peripherals>
    <peripheral condition="AES">
      <name>AES</name>
      <!-- ... -->
    </peripheral>
  </peripherals>
<device>

[edriouk]

@tarek-bochkati , using the same syntax as PDSC would be great! SVDconv and RTE model use the same base classes for XML elements, therefore it is not difficult to generalize condition logic bring it to SVD

[jkrech]

We should consider to convert from the new format (2.x) to the old format (1.x) using SVDConv on demand for use by consumers limited to version 1.x.

[thorstendb-ARM]

When starting SVD, I had the idea of having one SVD file per peripheral, and Device files to gather them up (xml include). This could also be easily converted to the current format. This does not require any filter syntax.

[tarek-bochkati]

@thorstendb-ARM, I agree on the idea, please check issue #5

IMHO, these 2 changes do not overlap, but they are complementary. I'm thinking of having the filter even in peripheral SVD files.

Note: we foresee benefits if we have conditions support in register and field and maybe interrupt nodes