Khushi Posted March 28 Report Share Posted March 28 Hello Is it possible in ipxact to describe ports which are enclosed in ifdef macro. For example module m( input [31:0] addr, output [31:0] data, `ifdef ABC in abc_in, out abc_out, `endif ); endmodule If yes, how to describe such ports in ipxact. If not, then what is the recommended way to model such RTL IP Thank you Quote Link to comment Share on other sites More sharing options...
kock Posted March 29 Report Share Posted March 29 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 Quote Link to comment Share on other sites More sharing options...
Khushi Posted July 16 Author Report Share Posted July 16 Thank you Erwin. Yes, a configurable IPXact make more sense for this. But as isPresent is going away, can we use multiple component views to handle this so that we are more aligned with native standard. Can you think of adding "ifdef" capability in next revision of the standards. It can be just an optional element in port definition which specify the macro name and if present it means the generator needs to wrap that port in a ifdef Thanks you Khushi Quote Link to comment Share on other sites More sharing options...
kock Posted August 12 Report Share Posted August 12 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.