Anton Posted February 10, 2019 Report Share Posted February 10, 2019 Hi, I have a question related to appropriate CCI usage in case of composite IP with top-level configuration parameters. Let's imagine we have a composite IP A that consists of IP B and C, making the A a composite IP, since it consists of multiple IPs. Now let's imagine IP B and C have clock frequency parameter associated. The name of parameter in IP A is clk_frequency and the name of parameter in IP B is clock_frequency. For a sake of better user experience let's image that IP A (a top level one, aggregating B and C) wants to provide a convince top level parameter named clk_freq to manipulate the value of two underlying parameters. And value of clk_freq parameter is not used in the IP A. Acc to example 11 provided in the CCI package a value of multiple parameters can be synchronized using the post write callback mechanism. So this approach can be used for synchronizing values of clk_frequency parameter of IP A with value of clock_frequency parameter of IP B. It's not particularly clear to me what is the best way to implement a top-level convenience parameter in A. The most straight forward way seems to be to implement a regular CCI parameter (cci::cci_param<T> param_name;) at IP A level and synchronize with one of the parameters of B or C. Such an approach seems to involve quite some coding, also a "dummy" parameter have to be created, since clk_freq parameter is not used in the IP A. So it makes me wonder if there is a more appropriate way how this functionality can be achieved. Maybe it's possible to create a handle at a level of IP A and somehow expose it to external configurator? Also that would be interesting to know if it's possible to hide parameters of IP B and C from external configurator. I am pretty sure that described use-case scenario was considered during CCI creation and I am simply missing some obvious point here. I'd appreciate any inputs you can provide to help me to understand what is the most appropriate way to implement that. Thanks. Quote Link to comment Share on other sites More sharing options...
twieman Posted February 18, 2019 Report Share Posted February 18, 2019 Hi Anton, Thanks for posting your questions. Your inquiry about a top-level convenience parameter is something that was discussed during development of the standard. An alias mechanism allowing multiple (synonymous) names for a parameter was considered. However, this is non-essential so it was decided to defer it in the interest of simplicity for the initial release. You are correct, the workaround is to create a separate parameter and synchronize them. It is possible to hide parameters as you’ve expressed. The mechanism for doing so is not standardized but example 14 demonstrates one possible solution. Hope this helps, Trevor 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.