Search the Community
Showing results for tags 'cci'.
Found 4 results
I want to get the list of all the parameter handles belonging to an sc_module/sc_object. get_param_handles with a predicate of hierarchical name also would not work as in case of sub-system, a hierarchical instance can match to the param name of a sub component. Any suggestions ?
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.
I am looking for the updated source code for greensocs CCI implementation. Earlier it was at https://github.com/OSCI-WG/cci.git but now I am not able to find it Anybody knows from where I can get this ? Thanks Sumit
Hi, I tried using the SystemC CCI draft release.(cci-0.9.0_pub_rev_20171219.tgz) Currently the following examples fail to compile: ex07_Parameter_Information ex16_User_Defined_Data_Type Please find the failure logs attached. I have also noticed that the CCI source contains systemc.h (src/cci_core/systemc.h)header file, from a cursory look it looks as if a wrapper around the header file (systemc) from SystemC library. Would it cause build issues when using SystemC CCI with legacy models which includes the systemc.h header file? Thanks and Regards, Ameya Vikram Singh verifyLogs.tar.xz