uwes

hi, a couple of things: 1. add -uvmhome $UVMHOME to the commandline 2. remove the args: $UVMHOME/src/uvm_pkg.sv $UVMHOME/src/dpi/uvm_dpi.cc -incdir $UVMHOME/src in total you should have irun -uvmhome $UVMHOME test.sv in addition you would also benefit if you use a more recent ius version such as a 12.1+ release. regards /uwe

>Can we use semaphore in Systemverilog function? depends what you mean. you can instantiate it in a function, call put(),try_get() BUT you cant directly invoke get() since this could block if there are insufficient keys avail. and since you are in a function you cant have anything blocking in there. >Can we call put and get implementation task from the function in UVM? what do you mean TLM/semaphore or something else?

an old post in the forum: http://www.uvmworld.org/forums/showthread.php?319-Multiple-TLM-Implementation-Ports&p=1140&viewfull=1#post1140

no, uvm_bitstream_t applies only to all integral types accessed via set_config_int. set_config_string uses "string" as type for the config_db and set_config_object uses "uvm_object" as type. /uwe

No, I said use as type "uvm_bitstream_t". All integral type for set-config-int are mapped to this one.

Set-config-int corresponds to uvm_config_db#(uvm_bitstream_t). /uwe

i think the recommended path is to make an extension container object and add there all additional properties for your reg2bus translation process. pass the object in the extension parameter of your register access. you could for instance add a field there "is_blocking" and use that field in your register adapter to make the downstream bus access blocking/non-blocking.

how do you create create your driver?

hi, if a analysis_imp would end in a "task" it could not be statically determined if this connection adheres to the contract of an analysis connection (which is zero time). this is because the task COULD take time violating the TLM contract. you can fork/join_none something within the function if this is required but the write() needs to return instantly. /uwe

hi, an analysis-imp ends up in a write() function! because the "function" is a strong guarantee that it will never take time. the analysis-tlm connection is guaranteed to complete in zero time. it sounds like an "analysis" tlm connection is not what you want. /uwe

hi, yes you can do that. you need to iterate over all domains, all phase-nodes, then get the objection object of that phase node and then finally you can invoke <objection>.display_objections() to print the info. if you use a recent IUS you can use the tcl command "uvm_objection" to do that. /uwe

hi, i cant see see the issue here. please validate your install, upgrade to latest ius or provide more info via a request in the cadence support system regards /uwe

this look like a broken ius install on your side (i checked 11.10p001) and as it runs fine here uwes@ilvnc3[none]~/src/uvm/distrib/examples/simple/hello_world$ irun -access rw -uvmhome ../../.. +UVM_VERBOSITY=UVM_LOW -quiet +define+UVM_OBJECT_MUST_HAVE_CONSTRUCTOR -incdir . hello_world.sv (btw are you on the right architecture for your install?) runs fine.

please state your versions of uvm, ius and your full command line. /uwe

hi, if you use irun (=the suggested path) then you dont need more than "irun -uvmhome <your-uvm>" NO pli,NO dpi, no c compile.. the default when using the uvm versionb cadence is shipping would be irun -uvmhome `ncroot`/tools/uvm-1.1 for you this should be all: irun -access rw -uvmhome $(UVM_HOME) +UVM_VERBOSITY=$(UVM_VERBOSITY) -quiet +define+UVM_OBJECT_MUST_HAVE_CONSTRUCTOR -incdir . hello_world.sv

sv does not support it

http://uvm.git.sourceforge.net/git/gitweb.cgi?p=uvm/uvm;a=blob_plain;f=distrib/release-notes.txt;hb=f297c564b14ca53e161e216347840f32107808d0 /uwe

http://uvm.git.sourceforge.net/git/gitweb.cgi?p=uvm/uvm;a=blob_plain;f=distrib/release-notes.txt;hb=f297c564b14ca53e161e216347840f32107808d0 /uwe

release-notes /uwe

hi, typically you should NOT peek/poke directly from the transaction layer into the physical/bit layer. this is not a good solution for reuse and scalability. btw: if you know and accept the downsides it might be the coding wise faster solution. /uwe

hi, i would avoid using thread/process like commands on an executing sequence like fork/join/kill/suspend/disable. the reason for this is that inside the sequencer/sequence/driver there are handshakes and other processes working. forcefully ending parts of the engine may cause hangs, lockups etc. you may have a look at the mantis collection showing some issues. if you really want a sequence to stop you should be using the official api "seq.kill()" or as hook "do_kill()" /uwe

hi, probably you have to type the ::get() correctly as if(!uvm_config_db#( virtual intf#(2))::get(this, "", "vif", hook)) `uvm_fatal("NOVIF",{"virtual interface must be set for: ",get_full_name(),".vif"}); /uwe

hi, coexistence of ovm/uvm can be done easily, loosely coupled (for instance ovm tlm talking to uvm tlm) could be done but as soon as there is more interaction like phase synchronization, common-build etc things get complicated. an alternative path to address this problem is to create a facade around uvm and makes it look like ovm. as very simple example you could do a "typedef ovm_component uvm_component;". doing so allows you to run an ovm based tb straight on uvm without changing a single line in the code. obviously the solution works the better the closer you are to the common ovm/uvm core. /uwe

hi, i dont think its the right path to update the sequencer to accomplish your scenario. a driver and even a sequencer are pure "slaves" of the scenario generation. they dont do anything on their own - they just execute what they are being told) so they cannot figure out on their own if this is the last item or not (you could do a wait for some time in the sequence and as result you dont have a "do" during this time). i think its better to use one of the following options: 1. make a base sequence which in its body do'es your final item. your normal sequences derive from the base and call as last statement in body() the base via super.body() 2. you use a sequence library which runs the set of your normal sequences (=subsequences) followed by your last-sequence as part of the uvm sequence library strategy 3. you auto instantiate the last item in case the sequencer doesnt have an item AND you notifed via a flag that the next try_next_item() returning a null should result in a last_item. anyway, i wouldnt interfere with a sequencer (for instance you miss the super.run_phase() calls already in your code) /uwe

hi, i agree with that (xz checking in the interface/monitor/collector) everything else only two state. i think the overall principle to save your time when coding verification environments is abstraction (go from cycles/time to events, from xy01 to 01, bit-wiggle to transactions) and since abstraction typically involves information loss you need to perform the appropriate checks at the right level (physical checks like xy at the physical level, logical/data checks at the higher levels) /uwe