I’m in process of creating a Verification Plan to verify some of Open Core Protocol’s features.
-
Should all parameters of the protocol be explicitly defined?
-
Secondly I made this test-bench architecture
Does it seem reasonable to you? I’ve no one to consult but you guys :D
Anyways, I made a global configuration, and agents can get this configuration using get method. My question is, can I through this configuration enable/disable sequencer and driver of that agent. If you ask why, I guess that if someone wanna verify a real RTL DUT using this VIP will need this agent to become passive isn’t it?
In reply to haithamx15:
It looks like you have a configuration in your environment and want to control your OCP agents. I think this is not a good ülace, because the environment has to be customized with respect to a certain test. For this reason you should move your configuration object up to the test.
All configuration data has to be defined in any place, but you can modify them depending on your actual configuration, i.e. number of masters, slaves etc. You can even randomize your configurations. Your configuration data can cover any aspects like ‘has_coverage’ or ‘is_active’, etc.
In reply to chr_sue:
In reply to haithamx15:
It looks like you have a configuration in your environment and want to control your OCP agents. I think this is not a good ülace, because the environment has to be customized with respect to a certain test. For this reason you should move your configuration object up to the test.
All configuration data has to be defined in any place, but you can modify them depending on your actual configuration, i.e. number of masters, slaves etc. You can even randomize your configurations. Your configuration data can cover any aspects like ‘has_coverage’ or ‘is_active’, etc.
Seems reasonable, however those configurations concern the testbench itself, there are some parameters that are concerned with OCP protocol itself. for example addr_width. parameters that enable or disables some of the ocp features. Should those also be put in the configuration class? A better places for such parameters is a class isn’t it?
In reply to haithamx15:
There are different categories of configuration data. All what is related to data/addr_width might be better in a package or as a class/interface/module parameter.
In reply to chr_sue:
In reply to haithamx15:
There are different categories of configuration data. All what is related to data/addr_width might be better in a package or as a class/interface/module parameter.
Thank you!
Last question, should all parameters that concern that protocol should be explicitly defined, or is it enough if I use the parameters that concern the area that I’m verifying?
