I found almost every driver that extends from uvm_driver has task get_and_drive like below. I checked the uvm source code and uvm_cookbook, but I didn't find get_and_drive. It seems it is not a uvm rule; it is more likely a convention. Who first used the task named get_and_drive(), and why do almost all people use the name get_and_drive in their driver?
task run_phase(uvm_phase phase);
get_and_drive();
endtask : run_phase
task get_and_drive();
forever begin
seq_item_port.get_next_item(req);
send_to_dut(req);
seq_item_port.item_done();
end
endtask : get_and_drive
If you look in the example/integrated/ubus directory, in the ubus_master_driver you'll see a method that's called get_and_drive(). If you go back to OVM, you'll see that in XBUS example also defined the same method in the xbus_master_driver.
Since most people learn by example, I guess the convention just stuck. I think other methodology sites (like Verification Academy) also promote the same convention.
Related
I am studying and debugging one software. There are thousands of functions in this software. I plan to add printf() at the entry and exit point of each function. It will take a lot of time.
Is there one tool/script to do this?
I may use '__cyg_profile_func_enter'. But it can only get address. But I have to run another script to get function name. I also hope to get value of input parameters of this function too.
You should give a try to AOP : Aspect Oriented Programming. Personnaly I've only tried with Java and Spring AOP but there's an API for C too : AspectC (https://sites.google.com/a/gapp.msrg.utoronto.ca/aspectc/home). From what I've seen, it's not the only one.
From what I've red about this library, you can add an pointcut before compiling with AspectC :
// before means it's a before function aspect
// call means it's processed when a function is called
// args(...) means it applies to any function with any arguments
// this->funcName is the name of the function handled by AspectC
before(): call(args(...)) {
printf("Entering %s\n", this->funcName);
}
(not tried by myself but extracted from the reference page https://sites.google.com/a/gapp.msrg.utoronto.ca/aspectc/tutorial)
This is only a basic overview of what can be done and you still have to deal with the compilation (documented in the page linked before) but it looks like it could possibly help you. Give a try with a simple POC maybe.
For some reason my object at the creation time does not pick configuration passed by test. I don't see GET when I enable tracing, only SET.
I have object as following:
class top_env_cfg extends uvm_object;
int set_default_env = 1;
`uvm_object_utils_begin(top_env_cfg)
`uvm_field_int(set_default_env,UVM_DEFAULT);
`uvm_object_utils_end
function new(string name = "top_env_cfg");
super.new(name);
endfunction
endclass
In my test, inside the build_phase I am doing the following:
uvm_config_db#(int)::set(this, "*", "set_default_env" ,0);
In my environment in build_phase I am creating this object as:
env_cfg = top_env_cfg::type_id::create("env_cfg", this);
After creating this object the set_default_env still 1.
What may be wrong, and how I can debug this.
Thanks in advance.
The important thing to understand about the "automated retrieval of config_db resources" is that it does not actually happen automatically. This Verilab paper explains what happens under the hood, and I am quoting the relevant section here:
[...] one question that is often asked with respect to retrieving data is:
do you always have to explicitly call the get() function? The short
answer is that it depends. In the UVM, there are mechanisms to
automate the retrieval of data from the configuration database. In
order to have the resource automatically retrieved two things must
happen:
First, that resource has to be registered with the factory using the field automation macros.
Second, super.build_phase(phase) must be called in the build_phase() function.
The "automated" retrieval will happen when you call super.build_phase() from a uvm_component. In the case that you are referring to in your question, you have a uvm_object (you don't have a UVM build_phase), so you would need to explicitly perform a uvm_config get() call in order to retrieve the resource from the database.
I have seen quite a lot of code that uses the cycle time of the Runnable for implementing some timer/timeout. The problem is that if someone decides to change the cycle time of this Runnable, the timer will be incorrect.
Example:
#define FOO_TIMER_100MS_REACHED (10U)
FUNC(void, FOO_CODE) FOO_Cycle_10ms( void )
{
static uint8 t = 0;
if( t < FOO_TIMER_100MS_REACHED )
{
t++;
}
else
{
; /* 100ms elapsed - do whatever is necessary */
}
}
So, how can I determine the cycle time of periodically triggered function FOO_Cycle_10ms from inside this Runnable?
In respect to the example above I'm looking for something like:
#define FOO_TIMER_100MS_REACHED ((uint8)(100U / CYCLE_TIME_FOO_Cycle_10ms))
The problem is that if someone decides to change the cycle time of this Runnable, the timer will be incorrect.
But can that actually happen? The software component description (SWCD) is always strongly coupled with the implementation. If somebody would change e.g. the runnable name in the SWCD or remove an access point, the code wouldn't compile too.
Other parameters like the runnable to task mapping can be changed by the integrator in a later development stage, but the period is part of the SWCD and thus also coupled with the implementation.
So, IMHO the described issue should not occour. If this does't answer your question, please provide more information about the actual use case.
Well, the SWCD is actually your contract, that should be discussed on changes with the responsible of the SWCD and the developer. If not, then your process is flawed.
On the other side, there are some ways:
Maybe you can create an Constant value from your SWCD Timing Event period
Create a ClientServer Interface to the TimeService (Tm) Module and let it setup. The Tm allows some handy SW timers backed by some GPT Predef Timers
Create a ClientServer interface with StbM-ServiceNeeds to your SWCD.
Then you should be able to access the Synchronized Time Base.
I had the same discussion ones, because this actually happened for a hot-fix.
We saw a potential solution in feeding Os_Service, see SWS_Os_00560, into the components measuring time, but never really tried it.
The Stbm solution we saw also, because we did not have the module in the respective project.
I am no longer "new" to Python, but am now moving into unchartered territory.
Recently I was dissecting some logic circuit code found here. I learned a lot about the practical use of inheritance from this code. Good stuff.
Not much happens in this code until one changes the inputs on a gate, so the interpreter must be used to manipulate the inputs. I got tired of using the interpreter, and so I investigated ways to create a continuous loop that would not rerun the initial code.
I found that Tkinter uses a continuous loop that I could then interrupt with the "after" method to update some of the parameters of the code currently running.
That works well, however I am curious as to whether there is another and/or better way. Anyone know of one or the other?
Some of the code:
tk_TkGUI = Tk()
f_AndTest() ## Initialize the 'And' gate
tk_TkGUI.after(1000, f_ChangeAnInput) ## Invokes Tk 'after' method to update an input
tk_TkGUI.mainloop() ## Must be used in Windows with Tkinter
def f_ChangeAnInput():
A1.B.set(0) ## Change A1.B from 1 to 0
If you want a window, using Tkinter in this way is perfectly fine.
By the way, after doesn't interrupt the loop as you described it. The main loop simply loops over a queue of events and processes them in order. When it reaches the end it waits for more events. Much like when you press a key or move the mouse, after merely puts something in the queue to be processed later. It really is as simple as that.
you could use threading.
import thread
def blaH:
#All your code that isn't related to your tkinter stuffs in here
thread.start_new_thread(blaH,())
the only thing is that you need new ways of both threads to talk to each other, such as global variables.
I only wanted to allow one instance of my C extension class to be made, so I wanted to include the singleton module.
void Init_mousetest() {
VALUE mouseclass = rb_define_class("MyMouse",rb_cObject);
rb_require("singleton");
VALUE singletonmodule = rb_const_get(rb_cObject,rb_intern("Singleton"));
rb_include_module(mouseclass,singletonmodule);
rb_funcall(singletonmodule,rb_intern("included"),1,mouseclass);
### ^ Why do I need this line here?
rb_define_method(mouseclass,"run",method_run,0);
rb_define_method(mouseclass,"spawn",method_spawn,0);
rb_define_method(mouseclass,"stop",method_stop,0);
}
As I understand it, what that line does is the same as Singleton.included(MyMouse), but if I try to invoke that, I get
irb(main):006:0> Singleton.included(MyMouse)
NoMethodError: private method `included' called for Singleton:Module
from (irb):6
from C:/Ruby19/bin/irb:12:in `<main>'
Why does rb_include_module behave differently than I would expect it to? Also any tangential discussions/explanations or related articles are appreciated. Ruby beginner here.
Also it seems like I could have just kept my extension as simple as possible and just hack some kind of interface later on to ensure I only allow one instance. Or just put my mouse related methods into a module... Any of that make sense?
according to http://www.groupsrv.com/computers/about105620.html the rb_include_module() is actually just Module#append_features.
Apparently Module#include calls Module#append_features and Module#included. So in our C code we must also call included. Since clearly something important happens there.