[Question] Peripheral SVD Files

[tarek-bochkati]

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.

I am thinking of having a STM32U57x_PERIPHERALS.xml, this file will contain all peripheral tags in the STM32U57x.SVD in that way, we can reduce the common size between both STM32U57x.SVD and STM32U58x.SVD

If it is accepted by specification to have XML includes in the SVD file, we can do the following:

File: STM32U57x.SVD:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!DOCTYPE includes [<!ENTITY STM32U57x_PERIPHERALS SYSTEM "STM32U57x_PERIPHERALS.xml">]>
<device ... >  
  <name>STM32U575</name>
  <!-- ... -->
  <peripherals>
    &STM32U57x_PERIPHERALS;
  </peripherals>
</device>

File: STM32U58x.SVD:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!DOCTYPE includes [<!ENTITY STM32U57x_PERIPHERALS SYSTEM "STM32U57x_PERIPHERALS.xml">]>
<device ... >  
  <name>STM32U585</name>
  <!-- ... -->
  <peripherals>
    &STM32U57x_PERIPHERALS;
    <peripheral>
      <name>AES</name>
      <!-- ... -->
    </peripheral>
  </peripherals>
</device>

[jkrech]

Neither the current specification nor the tools (or known implementations) support the inclusion of entities.

[tarek-bochkati]

an alternative solution is to add a loadFrom attribute to <peripheral>, which works like derivedFrom but loads the peripheral from another xml file

example:

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<device ... >  
  <name>STM32U585</name>
  <!-- ... -->
  <peripherals>
    <!-- ... -->
    <peripheral loadFrom="STM32U585_AES.xml">
      <!-- could override some data if needed -->
    </peripheral>
  </peripherals>
</device>

Update (2023/12/14)

Experimenting on STM32U5xxx SVD Files

applying a simple python script to export each peripheral to a separate file, then re-use them in SVD files (using the loadFrom) reduces the total SVD files size from 94MB to 36.5MB => 61% of size reduction

So IMHO, I definitely vote for this SVD extension Note: this does not conflict with #6

Update (2024/02/28)

If we proceed with this idea, we can add a new extension *.psvd for peripheral SVD and also a psvd.xsd as well. It is important to note that besides the size gain, there is important maintenance gain.

[jkrech]

Considering above extension Version 2.x of SVD, we should probably consider SVDConv to generate a single file 1.x version SVD file on demand, allowing 1.x consumers to use the files.