You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a quite strange yet effective way of doing this but it comes from converting 2009 files to 2014 using Accellera's updater XSLs (https://accellera.org/downloads/standards/ip-xact). Kactus2 does its best here but what I see from the mask example above is the result in tooltip;
'hffffffff80000000
.. which flagged as user error since the register width is only 32 bits. It seems in error vs the spec (C.3.6.2) where for unsignedBitVectorExpression, "the length of the bit vector is based on the width of the containing object" (32, then) but we're treating this as a (signed) sign extended 64 bit value here due to the pow(2,32). Would this be a fair assessment?
The text was updated successfully, but these errors were encountered:
Hi mwsealey,
Yes, the issue is in the expression evaluation which does not account for the target bit vector width in any way. In our example designs this has never been an issue before, but as a violation against the standard, should be fixed nonetheless.
Is the issue a major obstacle for your design work or can you find a quick way around it?
I have some IP-XACT from some IP that is using expressions of the form:
ipxact:mask('ffffffff) / $pow(2,0) % $pow(2,32)</ipxact:mask>
This is a quite strange yet effective way of doing this but it comes from converting 2009 files to 2014 using Accellera's updater XSLs (https://accellera.org/downloads/standards/ip-xact). Kactus2 does its best here but what I see from the mask example above is the result in tooltip;
'hffffffff80000000
.. which flagged as user error since the register width is only 32 bits. It seems in error vs the spec (C.3.6.2) where for unsignedBitVectorExpression, "the length of the bit vector is based on the width of the containing object" (32, then) but we're treating this as a (signed) sign extended 64 bit value here due to the pow(2,32). Would this be a fair assessment?
The text was updated successfully, but these errors were encountered: