Extension and implementation of `Component`

[skaupper]

Lately I looked into scripting of a vendor independent IP workflow.
I've stumbled across this repo and it seems quite fitting for handling the IP-XACT files.

Since I have to make some adaptions anyway, I wondered if you would welcome it, if I tried to integrate it into this repo here?
The things I could imagine doing include:

• Extending the data model for Component and its required sub models
• Implement the corresponding FromXml and ToXml methods
• Integrate the official conversion scripts found here to convert between the schema versions.

I'd want to make the data model conformant with the latest standard (that is 1685-2022) and convert XML files of older versions to it using the XSLT scripts provided by Accellera itself.

For the data model I would focus on the parts I need for my use case (so definitely no address spaces or memory maps etc.).

What do you think?

[Paebbels]

Hi @skaupper,

in general you idea sounds very very good. Let me give some remarks:

Lately I looked into scripting of a vendor independent IP workflow.
I've stumbled across this repo and it seems quite fitting for handling the IP-XACT files.

Have you also looked at the other parts of EDA² wich are offering more layers when working with EDA tools. IPXACT is just one gear of a bigger gearbox :)

Since I have to make some adaptions anyway, I wondered if you would welcome it, if I tried to integrate it into this repo here?

Yes, please propose your changes as long as the fit into that repository scope (handling IPXACT). If you have ideas that go beyond, IPXACT e.g. a generalized format without all the bugs of IPXACT, we can discuss that and maybe open another repository under the umbrella of EDA² (if you like).

• Extending the data model for Component and its required sub models

For sure. I just implemented some parts of IPXACT, as ai figured out it's an almost never ending story ...
I also noticed lots of architectural mistakes in IPXACT and how static this format is. So I lost my drive ...
I'll support you as best as I can. The GitHub Action pipeline should be up-to-date. I'll finish fully automatic releases this weekend (pyTooling/Actions).

• Implement the corresponding FromXml and ToXml methods

Ok, check.

• Integrate the official conversion scripts found here to convert between the schema versions.

Hmmm. So this is XLST based?
I never did XLST with Python. I noticed Python has no good XML support at all. We need to check what it can do and how fast it performs these tasks.

I'd want to make the data model conformant with the latest standard (that is 1685-2022) and convert XML files of older versions to it using the XSLT scripts provided by Accellera itself.

I have a request (and bug) in #17, which requires some restructuring. My idea is to split of them schema files to a new Python package and fix the package resource files. This package could also contain the needed XLST files for your usecase.

For the data model I would focus on the parts I need for my use case (so definitely no address spaces or memory maps etc.).

Yes, please focus on what you need. I can extend it later myself, or other contributors might help out if and when needed.

---

P.S. the used coding style is not 100% PEP8 and Black conforming. I started to use Python (and other languages) before they invented some of the (in my point of view) stupid PEP8 and Black rules. You'll see my code is clean and structured, but I don't stick to all rules :) I use PyCharm as an editor. VS Code should be fine too - some projects have VS Code settings.

[skaupper]

Have you also looked at the other parts of EDA² wich are offering more layers when working with EDA tools. IPXACT is just one gear of a bigger gearbox :)

Tbh. I haven't looked too deeply in the other parts since we already have a rather extensive workflow and I try to not rip apart the whole thing. If I have some downtime I will take a look if we some of the tools may improve the current workflow without disrupting it too much.

Yes, please propose your changes as long as the fit into that repository scope (handling IPXACT). If you have ideas that go beyond, IPXACT e.g. a generalized format without all the bugs of IPXACT, we can discuss that and maybe open another repository under the umbrella of EDA² (if you like).

First I will focus on the standard IPXACT to parse IP information provided by Xilinx, Efinix etc.

Hmmm. So this is XLST based?
I never did XLST with Python. I noticed Python has no good XML support at all. We need to check what it can do and how fast it performs these tasks.

The lxml package contains a XSLT class which worked just fine with the 2 IP files I tested.
Converting from 1685-2009 to 1685-2022 worked fine and the schema validated without issue (except for some attributes that Xilinx added to some nodes..).

I have a request (and bug) in #17, which requires some restructuring. My idea is to split of them schema files to a new Python package and fix the package resource files. This package could also contain the needed XLST files for your usecase.

When working on it, I can move the schemas and the corresponding conversion scripts in a separate package. I am not too familiar with Python's packaging system (I have done like 2-3 internal Python packages) but I see what I can come up with.

[skaupper]

Just to be clear about that: I will try working on this when my remaining workload is low, so depending on other stuff I will have more or less time to work on this.

But since you are fine with it, I will try to integrate my work as good as possible with your existing work.

[Paebbels]

Tbh. I haven't looked too deeply in the other parts since we already have a rather extensive workflow and I try to not rip apart the whole thing. If I have some downtime I will take a look if we some of the tools may improve the current workflow without disrupting it too much.

The idea of EDA² is to offer individual layers in such an EDA flow. Of cause it will somehen offer a full stack, but for now it's individual layers. E.g. if you need to manage files, filesets, designs in a projects, pyEDAA.ProjectModel gives you an abstract implementation and an API. In addition, ProjectModel can read and write other project descriptions like Vivado XPR or OSVVM projects.

The idea is sharing of common parts in an EDA toolflow.

First I will focus on the standard IPXACT to parse IP information provided by Xilinx, Efinix etc.

That's fine for me.

The lxml package contains a XSLT class which worked just fine with the 2 IP files I tested.

So, the XSLT is just version 1, but not XSLT 2 or XSLT 3...

When working on it, I can move the schemas and the corresponding conversion scripts in a separate package.

You can propose them here: https://github.com/edaa-org/IPXACT-Schema. This repos has the XSD files and will be packaged by me, so you can use it from code. pyTooling has an API for simplifying resource files.

[Paebbels]

The release of v0.5.0 (#40) is running in a release pipeline. If it succeeds, a release will be ready in circa 10 minutes.