kock

Hi Kushi, In this forum we cannot discuss EDA vendor tools so please consult with Synopsys directly. Best regards, Erwin

Hi Yohuang, I need to read the SV on this. My understanding is that unsized constant numbers need to be represented as int (32 bit) and therefore the substraction is also represented as int (32 bits) (Section 11.6.1 and 11.6.2 in IEEE Std 1800-2012). So no up conversion to longint here. Best regards, Erwin

Hi Yohuang, param_A and param_B should be casted to there own type and range first. Then the subtraction is applied and the result should be casted to the type and range of my_param. Please note that there is a newer version 1685-2022. Please use this version if you can because it supersedes 1685-2014. Best regards, Erwin

Hi Yohang, Thanks for your interest in TGI. You can mail the IP-XACT Working Group members directly using ip-xact@lists.accellera.org to report issues or, if you prefer, you can list them in this forum. As mentioned earlier, the WG is preparing an TGI Application Note which will list many issues found already. Best regards, Erwin

No we have no public test suite. EDA vendor are working on this on themselves.

Hi Yohuang, Indeed the TGI is not backward compatible between IP-XACT versions. For 2022 we decided to refactor a lot. The IP-XACT Working Group is preparing a TGI Application Note to explain its usage more clearly. Best regards, Erwin

Hi Yohang, No, the parameterIDs that I mentioned are handles to the ipxact:parameter or ipxact:moduleParameter elements. You can get the values of the parameterId attributes using the TGI calls String value = getAttributeValue( parameterID, "parameterId" ) // Returns resolved expression value String valueExpression = getAttributeValueExpression( parameterID, "parameterId" ) // Returns expression Indeed, you can pass down parameter values through the hierarchy. In order to get the configured parameter values, you have to propose them from the top. A designInstantiation element passes actual parameter values to design. So that designID needs to be a configured one rather than an unconfigured one in order to take the value from the designInstantiation element. If not, the default values of the design parameters are used. Best regards, Erwin

Hi Yohuang, In your example, you can get an unconfigured componentID assuming that you have a configured componentInstanceID for instance U1 as follows: String componentID = getUnconfiguredID( componentInstanceID ) This componentID can also be obtained in another way, for instance, through the VLNV of the component. If you apply getConfigurableElementIDs on the componentID, you get the IDs of the component parameters that are configurable (meaning that they can be set by a configurable element) String[] parameterIDs = getConfigurableElementIDs( componentID ) Best regards, Erwin

Hi Ameya, You can use the program xsltproc on linux. E.g. xlstproc from1.5_to_1685_2009.xsl <input_xml_file> > <output_xml_file> Best regards, Erwin

Hi, You can download IP-XACT XML documents from Accellera and from ARM. They are mainly bus and abstraction definitions. Accellera also provides the Leon2 example. Other IP-XACT XML files are typically provided by IP providers when purchasing IP. Best regards, Erwin

Hi, I believe the regex used is specified here: https://www.w3.org/TR/xmlschema-2/#dt-regex Best regards, Erwin

Hi Kushi, I suggest you use the Accellera Vendor Extensions for 1685-2022 (accellera-cond:isPresent). It is not likely that we will re-introduce conditionality in the IEEE standard again. Best regards, Erwin

Hi, You need to run the following scripts in sequence to convert from 1.5 to 1685-2022: from1.5_to_1685_2009.xsl from1685_2009_to_1685_2014.xsl from1685_2014_to_1685_2022.xsl Best regards, Erwin

Hi Mats, Indeed you need to unroll. Best regards, Erwin

Hi Kushi, The idea of 1685-2014 is to support this with the isPresent element. This functionality has been removed in 1685-2022 but it can be supported with the Accellera Vendor Extensions for 1685-2022. Please see https://accellera.org/images/downloads/standards/ip-xact/1685-2022-VE-1.0-Specification.zip My own opinion is that this RTL code describes 2 different IPs (one with ABC defined and one with ABC undefined) and that you should create two different IP-XACT components to describe those two different RTL IPs. This is an example of a configurable IP that can be used to create two configured IPs. The configured IPs are supported by the IP-XACT component schema. The configurable IP must be handled with a generator (e.g. using TGI). The generator takes the value of ABC as input and generates the IP-XACT component for the configured IP. Best regards, Erwin