add_ip_from_ipxact only accept the 2022 and not the 2014 standard

[mtravaillard]

While trying to play around with this function and with the ipxact example from Kactus2, i figured out that add_ip_from_ipxact only accept the 2022 standard.
The ipxact examples with Kactus2 are based on the 2014 standard.

@Risto97 should we had support for the 2014 standard to the ipxact function or it is not used anymore ?

[Risto97]

Hello @mtravaillard ,

I think it should be possible to easily support the IPXact 2014, in the current xlst stylesheets.
We need to check the delta between 2014 -> 2022 and make sure it didnt affect the sections we are interested in:

• Document vendor, library, name, version for add_ip call (it did not)
• ConfigurableLibraryRefType/LibraryRefType for find_and_link_ips() (it did not either)
• Finally fileSet, file, ... for ip_sources() (This I would have to double check)

The issue might just be in this line

SoCMake/cmake/ipxact/importer/ip_lib_with_filetype_modifier.xslt

Line 4 in 77db064

xmlns:ipxact="http://www.accellera.org/XMLSchema/IPXACT/1685-2022"

(and similar ones in other stylesheets)

So you can try to modify that the 2014 and see what happens.

I could probably simplify the stylesheets a little bit, they are a bit overcomplicated now.

An alternative would be to upvert the 2014 -> 2022 files, using the official scripts https://www.accellera.org/downloads/standards/ip-xact (end of the page).
In this case its cleaner to just support 2014, it would be more tricky to support import from 2009 and older standards possibly.

Let me know if you have any questions about how this works, and IPXact in general.

[mtravaillard]

Hello @Risto97, sorry it might be a long message :)

Thanks for those information, i think it would be better to only support 2022, as it's the last standard so i guess that it tends to be the most used now.

I could probably simplify the stylesheets a little bit, they are a bit overcomplicated now.

If you have the time, i'm not against it haha. i'm still discovering the standard and how those different types of xml files are described and behaving...

An alternative would be to upvert the 2014 -> 2022 files, using the official scripts https://www.accellera.org/downloads/standards/ip-xact (end of the page).

Thanks for this idea, I will add a cmake function to do this so the user won't have to bother to do it manually. This way we only have to support one standard in our scripts, the latest, and we have a clean way of supporting the 2014 one by using the official script.

Let me know if you have any questions about how this works, and IPXact in general.

Yes i have a few questions for now, first, about this function:

SoCMake/cmake/ipxact/importer/get_find_ips.xslt

Line 20 in 77db064

<xsl:text>find_ip(</xsl:text>

It will add a call to find_ip() and look for a vendor__library__nameConfig.cmake file and it's trying to find a config file but won't find it, even if it's in the same folder...
For now, in my small test, I have used the add_ip_from_ipxact like add_ip_from_fusesoc have been used with x-heep (calling this function several times to import several IPs and their dependencies).
So do we really need to add this function, as the IP it is looking for have already been linked to the IP_LIB or should i try to modify it to pass some hints to the final call to find_package so it knows where it can look for it?

---

I also wanted to know, i'm new to .xslt files, and to xmlstarlet or xsltproc. Is one of this executables available by default on every machine ? Would using some python script instead makes sense ?

I'm asking this, because in the future of this project, we would like to use ipxact to describe the top level architectures and the different connections between the IPs and interconnect, etc.

We could for examples import IPs if they have an ipxact definition or a .core files to put all the different files in the IP_LIB. Both would be support, as ipxact seems to be the standard and used in the industry and .core files, from fusesoc, seems to be the most used in the open source community.

Then, using a python script, we would generate the "top" ipxact file and using this file, we would generate a .sv or .v top level module.

All this part is still being discussed and to be determined how to be done, if you have any advice as you have more experiences on ipxact it would be useful.
For now, i think i will keep the .xslt files for the ipxact importing part. To generate the top ipxact, as it's not made to be written directly by an human, we thought with benoit that it would be useful to use python, as we could make scripts to easily make those connections between IPs doable for an human, without using a GUI like vivado or kactus2 for example...

[Risto97]

Hello @mtravaillard ,

No worries, happy to help.

Thanks for those information, i think it would be better to only support 2022, as it's the last standard so i guess that it tends to be the most used now.

Yes, but it can happen that there is a tool stuck on older IPXact, depending on how much effort it is we can see if its worth it or not.

Thanks for this idea, I will add a cmake function to do this so the user won't have to bother to do it manually. This way we only have to support one standard in our scripts, the latest, and we have a clean way of supporting the 2014 one by using the official script.

I had that but never pushed it, as I just converted all my files to IPxact 2022 and started tracking that.
Keep in mind that you probably want to do the conversion at the CMake configure phase.

It will add a call to find_ip() and look for a vendor__library__nameConfig.cmake file and it's trying to find a config file but won't find it, even if it's in the same folder...

Maybe we should append the dir CMAKE_PREFIX_PATH inside this function? I do it outside right now, the issue is that we need to write it directly to CMake cache for it to be globally set.
Because find_package() will look for packages in CMAKE_PREFIX_PATH among other paths.

So do we really need to add this function, as the IP it is looking for have already been linked to the IP_LIB or should i try to modify it to pass some hints to the final call to find_package so it knows where it can look for it?

Not sure I understand, the function add_ip_from_ipxact() is parsing the IPXact file, and it creates a CMake package vendor__library__nameConfig.cmake, inside this file there is the SoCMake IP, created from the XML file.
If you have it already generated, you don't need to call it again, find_ip() should be enough in that case.

Maybe I should prepare an example of how this should be used on Leon2 examples from accellera.

I also wanted to know, i'm new to .xslt files, and to xmlstarlet or xsltproc. Is one of this executables available by default on every machine ? Would using some python script instead makes sense ?

They are not available by default, but are quite common, very often a dependency of other packages.
Stylesheets are the standard way of transforming, or getting information out of XML files.
Since this is run at CMake configure phase, I would be a bit careful with having Python script there, as ideally should be as fast as possible to parse the XML.
I have not however compared the performance, although I had bad experience with doing XML schema validation with Python libraries, its just too slow.

For now, i think i will keep the .xslt files for the ipxact importing part. To generate the top ipxact, as it's not made to be written directly by an human, we thought with benoit that it would be useful to use python, as we could make scripts to easily make those connections between IPs doable for an human, without using a GUI like vivado or kactus2 for example...

This function in SoCMake can help you bringing the IPs, files and dependencies from already written IPXact files.
For example you can get all the AMBA interface definitions from ARM https://developer.arm.com/Architectures/AMBA#Downloads.

When it comes to GUI tools, I agree with you that they are not very useful. I considered Kactus2 at the beginning but it is GUI centric, so it doesn't help much for automation. Maybe the codebase it is built on can be used, but I still didn't like how it works.

Then, using a python script, we would generate the "top" ipxact file and using this file, we would generate a .sv or .v top level module.

It sounds reasonable, but consider it is a considerable effort to write a tool that can properly support IPXact.
Maybe a simple script can get you to a point, but the standard is quite extensive.

[mtravaillard]

Hello @Risto97,

Maybe we should append the dir CMAKE_PREFIX_PATH inside this function? I do it outside right now, the issue is that we need to write it directly to CMake cache for it to be globally set.
Because find_package() will look for packages in CMAKE_PREFIX_PATH among other paths.

Not sure I understand, the function add_ip_from_ipxact() is parsing the IPXact file, and it creates a CMake package vendor__library__nameConfig.cmake, inside this file there is the SoCMake IP, created from the XML file.
If you have it already generated, you don't need to call it again, find_ip() should be enough in that case.
Maybe I should prepare an example of how this should be used on Leon2 examples from accellera.

I will try to be more clear about the problem i'm facing, so I tried on the Leon2 example and this this small CMakeLists.txt:

cmake_minimum_required(VERSION 3.27)

# Add SoCMake
include("./deps/deps.cmake")

project(ipxact_test)

add_ip_from_ipxact("/home/maxime/Documents/ip-xact/Leon2_1685-2022/Leon2/amba.com/AMBA2/APB/r2p0/APB.xml")
add_ip_from_ipxact("/home/maxime/Documents/ip-xact/Leon2_1685-2022/Leon2/st.com/SPG/tlm_tac/2.0/tlm_tac.xml")

The problem is that when I do the cmake command to do the configuration, it raise an error because it doesn't find the AMBA2_APBConfig file...

The first call to add_ip_from_ipxact create the file that we need with an add_ip function.
The second function, have apb as a dependency, so it's looking for the config file by adding the find_ip() function in the generated Config.cmake file but has the path is not cached, it will not find it.

What do you think , should we append the CMAKE_PREFIX_PATH when creating a *Config.cmake or change this behaviour ?

[Risto97]

I see what you mean, and I agree that it is not the nicest how it works now.
I was handling the CMAKE_PREFIX_PATH on top.

I was a bit hesitant to writing to CMAKE_PREFIX_PATH directly because:

1. You need to write it directly to the cache
2. You need to append to the existing cache entry, meaning you need to actually check if the path you want to add is not already in the CMAKE_PREFIX_PATH, making it not scale super well. Othewise you keep appending and the list grows on every reconfigure.

I think there is a better solution though, we can add this at the end of add_ip_from_ipxact() function.

set(${ip_vendor}__${ip_library}__${ip_name}_DIR "${ip_source_dir}" CACHE INTERNAL "" FORCE)

This will actually be faster, as now find_package() does not need to look in all the directories listed in CMAKE_PREFIX_PATH instead the <package>_DIR will be searched first, and it will find it immediately.