Jump to content

Top level parameters in composite IP with CCI

Recommended Posts

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 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.


Link to comment
Share on other sites

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,

Link to comment
Share on other sites

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.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...