Dave,
I have a component and i want to change one of its variables depending upon the randomization in the environment. i do the following in build phase :
set_config_string(denali_cfg_name, "lpddr2_rank0x16_0_name", {`"`DUNITCTE`",$psprintf(".u_ddr_mem_wrapper%0d.lpddr3_rank0x16_0", ch)});
Now i want it to load a different value after i am donw with the randomization. ie have this value = {`"`DUNITCTE`",$psprintf(".u_ddr_mem_wrapper%0d.lpddr2_rank0x16_0", ch)}
set/get_config_xxx are usually used during the build phase to define the testbench component hierarchy and to do component level configuration - hence Dave's comment.
However, there is nothing to stop you changing the configuration settings during the run phase using set/get_config.
Please note that a more efficient alternative is to put all the configuration strings, ints etc inside a configuration object for a specific component or collection of components. This means that during the run phase you can update one of the members inside the configuration object and everything referring to it will see the same value. This avoids having to use set/get_config and means that everything is in sync.
My agent gets its configuration object from its environment. The monitor and driver that are instantiated in the agent also get their configurations from the same source. When the environment called set_config_object it passed a '0' for the clone argument. So, does this mean that when the driver changes an int in the configuration the monitor see the change without recalling get_config_object?
Yes. Without cloning what you have is a shared configuration object.
You need to be careful here because there is no notification mechanism to tell the monitor that the value has changed. You should use a TLM analysis or put port for that.
I am intrigued by your suggestion of a TLM analysis port or put port. The interface that I am modeling is for RS-422 communication.
For active agents the testbench is driving the single-ended serial data so the driver needs to tell the monitor the bit rate and framing information such as if parity is included and number of stop bits.
For passive agents the DUT is driving the single-ended serial data. So, I need to "monitor" the host interface and "update" the monitor any time a write to the divisor register or control register occurs.
To complicate things in my environment there can be multiple active and multiple passive agents.
As per my understanding here, in case of active agenet we want to share few configuration between driver and monitor.
Lets say the configuration are : bit rate, parity included or not, and number of stop bits. I believe that same confiugration will be there in the DUT as well. And driver have to inform/do the same configuration in the DUT as well. Correct me if I am worng.
Now, if any driver is doing the register write to do this configuration in the DUT then one monitor can monitor this regsiter read/write interface. And monitor can know the different configuration parameter. So, this way driver and monitor dont have to share any object.
I think this way is more better then sharing configuration object/handle between driver and monitor.
it seems that , here we want to share the some configuration between driver and monitor. If we use set/get_config_int method to update the configuration, And if same handle is shared then why we have to use TLM analysis port.
It really depends on the synchronization required by the application. There were not a lot of specifics when I posted my response. You typically read configuration data into local variables, or use them to compute some local variables at some point in your process. If another process updates that data, how quickly do you need to respond to that change? If you can wait until the next time the configuration data is read, and you are sure to re-read all the data that could be updated, then a shared handle would be fine. If your process needs to react immediately and change its behavior because of an update, then you should use a TLM port.
BTW, you can't use set/get_config_int to share handles, only set/get_config_object. And it is better to have one configuration object that represents the shared data rather than individual objects.
As far as i know we cannot configure the components in Run phase,
usually BUILD phase does this job of configuring,
please correct me if I am wrong.
Thanks,
Rami.
It really depends on what you mean by configure. You can do a get_config at anytime once you have performed all set_config's
Dave Rich
Mentor Graphics
http://go.mentor.com/drich
Dave,
I have a component and i want to change one of its variables depending upon the randomization in the environment. i do the following in build phase :
set_config_string(denali_cfg_name, "lpddr2_rank0x16_0_name", {`"`DUNITCTE`",$psprintf(".u_ddr_mem_wrapper%0d.lpddr3_rank0x16_0", ch)});
Now i want it to load a different value after i am donw with the randomization. ie have this value = {`"`DUNITCTE`",$psprintf(".u_ddr_mem_wrapper%0d.lpddr2_rank0x16_0", ch)}
Thanks
Vikram
set/get_config_xxx are usually used during the build phase to define the testbench component hierarchy and to do component level configuration - hence Dave's comment.
However, there is nothing to stop you changing the configuration settings during the run phase using set/get_config.
Please note that a more efficient alternative is to put all the configuration strings, ints etc inside a configuration object for a specific component or collection of components. This means that during the run phase you can update one of the members inside the configuration object and everything referring to it will see the same value. This avoids having to use set/get_config and means that everything is in sync.
My agent gets its configuration object from its environment. The monitor and driver that are instantiated in the agent also get their configurations from the same source. When the environment called set_config_object it passed a '0' for the clone argument. So, does this mean that when the driver changes an int in the configuration the monitor see the change without recalling get_config_object?
Yes. Without cloning what you have is a shared configuration object.
You need to be careful here because there is no notification mechanism to tell the monitor that the value has changed. You should use a TLM analysis or put port for that.
Dave Rich
Mentor Graphics
http://go.mentor.com/drich
I am intrigued by your suggestion of a TLM analysis port or put port. The interface that I am modeling is for RS-422 communication.
For active agents the testbench is driving the single-ended serial data so the driver needs to tell the monitor the bit rate and framing information such as if parity is included and number of stop bits.
For passive agents the DUT is driving the single-ended serial data. So, I need to "monitor" the host interface and "update" the monitor any time a write to the divisor register or control register occurs.
To complicate things in my environment there can be multiple active and multiple passive agents.
What would you recommend?
Hi ,
As per my understanding here, in case of active agenet we want to share few configuration between driver and monitor.
Lets say the configuration are : bit rate, parity included or not, and number of stop bits. I believe that same confiugration will be there in the DUT as well. And driver have to inform/do the same configuration in the DUT as well. Correct me if I am worng.
Now, if any driver is doing the register write to do this configuration in the DUT then one monitor can monitor this regsiter read/write interface. And monitor can know the different configuration parameter. So, this way driver and monitor dont have to share any object.
I think this way is more better then sharing configuration object/handle between driver and monitor.
Regards, Jignesh
----------
JigneshT
Hi Dave,
it seems that , here we want to share the some configuration between driver and monitor. If we use set/get_config_int method to update the configuration, And if same handle is shared then why we have to use TLM analysis port.
----------
JigneshT
It really depends on the synchronization required by the application. There were not a lot of specifics when I posted my response. You typically read configuration data into local variables, or use them to compute some local variables at some point in your process. If another process updates that data, how quickly do you need to respond to that change? If you can wait until the next time the configuration data is read, and you are sure to re-read all the data that could be updated, then a shared handle would be fine. If your process needs to react immediately and change its behavior because of an update, then you should use a TLM port.
BTW, you can't use set/get_config_int to share handles, only set/get_config_object. And it is better to have one configuration object that represents the shared data rather than individual objects.
Dave Rich
Mentor Graphics
http://go.mentor.com/drich