Open tarek-bochkati opened 8 months ago
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.
@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
@tarek-bochkati, this issue got moved to the svd-spec repository now.
I would recommend using attributes in conditions instead of text:
This proposal represents OR logic. Could we have situations where NOT and AND logic would be required?
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>
@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
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.
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.
@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
andfield
and maybeinterrupt
nodes
assuming this simple use case
STM32U57x.SVD
|7982 KB
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:
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:
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
andfield
and maybeinterrupt
nodes