How do I control the verbosity of certain components so that I can set a verbosity to only few of the components?
Lets say, for example in the verification of a particular feature, the test, few set of components/sequences/objects/interfaces etc are involved. I would like to set the verbosity of only these to be UVM_HIGH. I do not want to set the global severity to be set UVM_HIGH since lot of unrelated debug messages could come in which might increase the log size.
What would be a cleaner way of doing this? Its okay to use an additional commandline-plusarg for triggering this. Basically, the requirement would be that the test/components/sequences/objects/interfaces involved for a particular feature verification should take the global severity or the feature specific severity depending on which is higher.
Please note that one cannot use the built in report methods of uvm_component since, the uvm_info statements can be inside uvm_object extended classes as well as interfaces.
You can control the verbosity of a component from command line as a simulation argument. There are two choices:
+uvm_set_verbosity=<comp>,<id>,<verbosity>,<phase>
+uvm_set_verbosity=<comp>,<id>,<verbosity>,time,<phase> This one lets you specify the simulation time you want the applied verbosity to start
comp is the path of the component and wildcard * is supported. Example: uvm_test_top.env.agnt.*
id is the message identifier. you can apply to all messages within the component scope with by setting the id to _ALL_
verbosity is verbosity e.g. UVM_LOW, UVM_MEDIUM, UVM_HIGH, etc.
phase is phase you want the verbosity to be applied to.
For more detail i suggest reading:
The UVM reference manual section on Command Line Processor
UVM Message Display Commands Capabilities, Proper Usage and Guidelines by Clifford E. Cummings
You can use uvm_report_catcher for this. It works with uvm_object and interface. You can also use get_id(), get_message() etc. API for matching particular component/object and can only set verbosity of that component/object.
check my simple example on here on edaplaygroud
I tried different ways and also came up with this way.
Not sure how much it would be helpful for people.
simulate this with run time commands +user_verb=UVM_LOW +UVM_VERBOSITY=UVM_MEDIUM
class user_class extends uvm_object;
string report_id = "user_class";
string user_verb;
typedef uvm_enum_wrapper#(uvm_verbosity) uvm_verbosity_wrapper_e;
uvm_verbosity current_verb;
uvm_verbosity USER_VERBOSITY=UVM_HIGH;
function new (string name="my_class");
super.new(name);
report_id = name;
//void'($value$plusargs("user_verb=%s",user_verb));
//void'(uvm_verbosity_wrapper_e::from_name (user_verb,USER_VERBOSITY));
if ($test$plusargs("user_verb")) begin
current_verb=uvm_top.get_report_verbosity_level(UVM_INFO,"current_verb"); USER_VERBOSITY=uvm_top.get_report_verbosity_level(UVM_INFO,"user_verb");
end
$display("user_verb = %s",user_verb);
$display("current_verb = %s",current_verb);
endfunction : new
task display;
`uvm_info(report_id,"This is my message",USER_VERBOSITY)
endtask
endclass: user_class
module top;
string id;
string report_id = "top";
user_class m_user_class;
initial begin
m_user_class = new("m_user_class");
m_user_class.display;
`uvm_info(report_id,"This is my message",UVM_LOW)
end
endmodule: top
A working example can be found at edaplayground here
Related
Is there a way to override any verbosity switches that have been given and force verbosity to a different value in UVM?
+uvm_set_verbosity=*abc*,_ALL_,UVM_FULL,run
+uvm_set_verbosity=*aes*,_ALL_,UVM_FULL,run
+uvm_set_verbosity=*sel*,_ALL_,UVM_FULL,run
+uvm_set_verbosity=*init*,_ALL_,UVM_FULL,run
For example if cmdline has these switches, what is the easiest way to quiet all these high verbosity without removing individual switches?
Hunting around in the source code of UVM I found the set_report_verbosity_level_hier function in uvm_component. You could call that on uvm_root and set it (quite indiscriminately) to whatever low value you fancy.
initial begin
uvm_root root;
root = uvm_root::get();
root.set_report_verbosity_level_hier(UVM_LOW);
// Whatever you do here.
end
If you want to do that only for some ids you should be able to do that with set_report_id_verbosity_hier.
Notice I just tested the snippet above in a dumb testbench without even a test, so it might have problems with a real-world setup. If you have a more complex phasing of verbosity settings for your components you will need to override them each time they are applied, or toy with m_verbosity_settings directly.
We want to be able to provide a predefined list of things to be done at the end of every SystemVerilog test. Since multiple people are working on this project, it'd be nice if they did not have to think about the things we are doing in the background, but simply call $finish at the end of a test as usual. I know we could create our own custom $finish macro, but we would prefer to not have to change preexisting tests.
Is there any way in SystemVerilog to have a block of code run after a $finish call? Using something like UVM is not an option. I've looked around, but I can't seem to find something that does this behavior.
The final keyword can help you out here. Refer to IEEE Std 1800-2017, section 9.2.3 Final procedures:
A final procedure executes when simulation ends due to an explicit or
implicit call to $finish .
One limitation is that it executes in zero time, which means you can not have any delays, etc. Read the full description for all the details.
Example:
final begin
$display("something");
do_something();
end
If the list of things does not consume time, a final block is the antithesis of an initial block, except it cannot consume any time. Otherwise, it would not be the "final" thing.
If you need steps that consume time, there is no way of doing this without modifying the existing tests. The simplest approach is declaring a global event like test_done in a package p, and then replacing $finish; with ->p::test_done;. But sometimes you need to shut down other free-running process. Doing that requires much more coordination, which is exactly what UVM accomplishes with its phases and objections mechanism.
I am trying to change the UVM verbosity of the simulation after satisfying certain conditions. Verbosity options of different components are passing through the command line as +uvm_set_verbosity. Once the conditions are satisfied, then the simulations should run with the the command line +uvm_set_verbosity option. Till then simulation runs with low verbosity for all components.
Looking through the UVM library code, it appears that there is a function called m_set_cl_msg_args(). This function calls three other functions that appear to consume the command line arguments like: +uvm_set_verbosity, +uvm_set_action, +uvm_set_severity.
So what I did was get the uvm_root instance from the uvm_coreservice singleton, and then use the get_children() function from uvm_component class to recursively get a queue of all of the uvm_components in the simulation. Then call the m_set_cl_msg_args() function on all of the components.
My code looks like:
begin
uvm_root r;
uvm_coreservice_t cs_t;
uvm_component array_uvm[$];
cs_t = uvm_coreservice_t::get();
r = cs_t.get_root();
r.get_children(array_uvm);
foreach(array_uvm[i])
array_uvm[i].m_set_cl_msg_args();
end
Even though this code compiles properly, But this is not changing verbosity. Any idea ?
Moreover I am able to print all the components in array_uvm. So I am guessing
array_uvm[i].m_set_cl_msg_args();
this as a wrong call.
Anyone have any other suggestion to change verbosity during run time.
You should never use functions in the UVM that are not documented in the language reference manual. They can (and do) change in any revision. I'm guessing +uvm_set_verbosity only works at time 0 by default.
There is already a function to do what you want
umm_top.set_report_verbosity_level_hier()
I suggest using +UVM_VERBOSITY=UVM_LOW to start your test, and then define your own switch for activating the conditional setting.
If you want a specific component, use component_h.set_report_verbosity_level() (add the _hier to set all its children)
You can use the UVM's command line processor get_arg_values() method to specify the name of the component(s) you want to set, and then use umm_top.find() to get a handle to the component.
We are developing an ABM under AnyLogic 7 and are at the point where we want to make multiple simulations from a single experiment. Different parameters are to be set for each simulation run so as to generate results for a small suite of standard scenarios.
We have an experiment that auto-starts without the need to press the "Run". Subsequent pressing of the Run does increment the experiment counter and reruns the model.
What we'd like is a way to have the auto-run, or single press of Run, launch a loop of simulations. Within that loop would be the programmatic adjustment of the variables linked to passed parameters.
EDIT- One wrinkle is that some parameters are strings. The Optimization or Parameter Variation experiments don't lend themselves to enumerating a set of strings to be be used across a set of simulation runs. You can set a string per parameter for all the simulation runs within one experiment.
We've used the help sample for "Running a Model from Outside Without Presentation Window", to add the auto-run capability to the initial experiment setup block of code. A method to wait for Run 0 to complete, then dispatch Run 1, 2, etc, is needed.
Pointers to tutorial models with such features, or to a snip of code for the experiment's java blocks are much appreciated.
maybe I don't understand your need but this certainly sounds like you'd want to use a "Parameter Variation" experiment. You can specify which parameters should be varied in which steps and running the experiment automatically starts as many simulation runs as needed, all without animation.
hope that helps
As you, I was confronted to this problem. My aim was to use parameter variation with a model and variation were on non numeric data, and I knew the number of runs to start.
Then i succeed in this task with the help of Custom Variation.
Firstly I build an experiment typed as 'multiple run', create my GUI (user was able to select the string values used in each run.
Then, I create a new java class which inherit from the previous 'multiple run' experiment,
In this class (called MyMultipleRunClass) was present:
- overload of the getMaximumIterations method from default experiment to provide to default anylogic callback the correct number of iteration, and idnex was also used to retrieve my parameter value from array,
- implementation of the static method start,
public static void start() {
prepareBeforeExperimentStart_xjal( MyMultipleRunClass.class);
MyMultipleRunClass ex = new MyMultipleRunClass();
ex.setCommandLuneArguments_xjal(null);
ex.setup(null);
}
Then the experiment to run is the 'empty' customExperiment, which automatically start the other Multiple run experiment thru the presented subclass.
Maybe it exists shortest path, but from my point of view anylogic is correctly used (no trick with non exposed interface) and it works as expected.
I've written some code that has an RTC component in it. It's a bit difficult to do proper emulation of the code because the clock speed is set to 50MHz so to see any 'real time' events take place would take forever. I did try to do simulation for 2 seconds in modelsim but it ended up crashing.
What would be a better way to do it if I don't have an evaluation board to burn and test using scope?
If you could provide a little more specific example of exactly what you're trying to test and what is chewing up your simulation cycles that would be helpful.
In general, if you have a lot of code that you need to test in simulation, it's helpful if you can create testbenches of the sub-modules and test them first. Often, if you simulate at the top (chip) level and try to stimulate sub-modules that are buried deep in the hierarchy of a design, it takes many clock ticks just to get data into and out of the sub-module. If you simulate the sub-module directly you have direct access to the modules I/O and can test the things you want to test in that module in fewer cycles than if you try to get to it from the top level.
If you are trying to test logic that has very deep fifos that you are trying to fill or a specific count of a large counter you're trying to hit, you can either add logic to your code to help create those conditions in fewer cycles (like a load instruction on the counter) or you can force the values of internal signals of your design from the testbench itself.
These are just a couple of general ideas. Again, if you provide more detail about what it is you're simulating there are probably people on this forum that can provide help that is more specific to your problem.
As already mentioned by Ciano, if you provided more information about your design we would be able to give more accurate answer. However, there are several tips that hardware designers should follow, specially for complex system simulation. Some of them (that I mostly use) are listed below:
Hierarchical simulation (as Ciano, already posted): instead of simulating the entire system, try to simulate smaller set of modules.
Selective configuration: most systems require some initialization processes such as reset initialization time, external chips register initialization, etc... Usually for simulation purposes a few of them are not require and you may use a global constant to jump these stages when simulating, like:
constant SIMULATION_ENABLE : STD_LOGIC := '1';
...;
-- in reset condition:
if SIMULATION_ENABLE = '1' then
currentState <= state_executeSystem; -- jump the initialization procedures
else
currentState <= state_initializeSystem;
end if;
Be careful, do not modify your code directly (hard coded). As the system increases, it becomes impossible to remember which parts of it you modified to simulate. Use constants instead, as the above example, to configure modules to simulation profile.
Scaled time/size constants: instead of using (everytime) the real values for time and sizes (such as time event, memory sizes, register file size, etc) use scaled values whenever possible. For example, if you are building a RTC that generates an interrupt to the main system every 60 seconds - scale your constants (if possible) to generate interrupts to about (6ms, 60us). Of course, the scale choice depends on your system. In my designs, I use two global configuration files. One of them I use for simulation and the other for synthesis. Most constant values are scaled down to enable lower simulation time.
Increase the abstraction: for bigger modules it might be useful to create a simplified and more abstract module, acting as a model of your module. For example, if you have a processor that has this RTC (you mentioned) as a peripheral, you may create a simplified module of this RTC. Pretending that you only need the its interrupt you may create a simplified model such as:
constant INTERRUPT_EVENTS array(1 to 2) of time := (
32 ns,
100 ms
);
process
for i in 1 to INTERRUPT_EVENTS'length loop
rtcInterrupt <= '0';
wait for INTERRUPT_EVENTS(i);
rtcInterrupt <= '1';
wait for clk = '1' and clk'event
end for
wait;
end process;