dave_59

try_put() is a function that returns true if the put succeeds, which is always the case for an unbounded mailbox. That is exactly what an analysis_fifo is. You can have multiple subscribers on one analysis port. One subscriber would be the scoreboard, and the other is this component that you seem to require. Look at the code for the uvm_in_order_comparator.

Don't implement any write functions and use analysis fifos instead. Have your component arbitrate by peeking into each fifo and then selecting one of them to get() from the fifo.

You are going to have to explain a little more about the resource you want to share. The analysis port write methods are functions and therefore cannot be active concurrently. Perhaps you meant to use three analysis fifos and have the subscriber class arbitrate which fifos it does a get() from.

You can use the bind construct to instantiate an interface. See my DVCon12 paper. http://events.dvcon.org/2012/proceedings/papers/01P_3.pdf

Suggest you look here https://verificationacademy.com/courses/basic-uvm and here http://www.doulos.com/knowhow/sysverilog/

You'll need to show more context. Is this code itself inside another procedural block? Event controls in front of statements behave like a separate statement, and should be read as "wait for a change on 'a', then execute the statement that follows. task A; // or begin @(a) // wait for a change on a do_function0; do_function1; endtask // or end In a procedural block of code, each statement is executed when the previous statement completes.

The SystemVerilog 1800-2012 LRM, which just finished ballot approval and awaits final IEEE approval expected by the end of this year, adds support for multiple inheritance in a style similar to Java's multiple interface inheritance. Unfortunately, this comes too late to be used by the existing UVM base class library. However, the end user's code can take advantage of it and hopefully new features added to the UVM will be able to take advantage of it as well.

Answered here

When you say "Does not work" you need to be more explicit. I'll assume you mean you are getting a compile error. uvm_test_top.env.my_env0.my_sb0.disable_scoreboard(0); is not a hierarchical reference in the LRM terminology, it is a class member select. I'm also going to assume my_sb0 is a handle to a class that is a base class to my_scoreboard, so you will need to cast that the same as you did with handle_sb. In any case, using find is preferred over using what looks like a hierarchical reference because is is less re-usable as your testbench component hierarchy changes.

When you say it doesn'tt work, what is wrong? Compiler error? Randomize fails?, or you are not getting results you expect? I hope you realize this oddity of the SV LRM: when searching for identifiers in constraints, the object being randomized is searched first, then the local scope. It looks like you named your identifiers differently in the sequence and seq_item, but you did not show the req item definition. But when you write your constraints like `uvm_do_with(req,{req.aaddr == prev_aaddr;}) There is no need to write req.aaddr. just aaddr will work. if req also has a prev_aaddr member, it will use that first. If you want to force the prev_aaddr in the ud class. you should write the constraint as `uvm_do_with(req,{aaddr == local::prev_aaddr;})

getB2() is implicitly this.getB2(). Since B2 is a member of 'this', a change event to B2 is also change event to 'this'. So wait(this.getB2()) will call getB2 for evaluation whenever there is a change event on 'this' (as well as calling getB2() upon first executing the wait statement)

The issue with functions in wait expressions or event controls is that the LRM only defines a few conditions when the expression must be evaluated to see if the result has changed. And that is when any operand in the expression changes. That includes arguments to any function calls as well as any objects referenced directly in the expression. An object is considered changed when any of it members has changed. The problem is that a class member can be a reference to another child class object, but when the child object changes, the reference in the parent object does not. It is the same problem as shallow copy versus deep copy, except here it is shallow events versus deep events. If you have a parent-child hierarchy of class objects and you are waiting on a method that looks into the value of child object, it won't unblock until something in the parent changes, or some other operand in the expression changes and causes the whole expression to be re-evaluated. For example class A; bit B1; endclass class B; A a = new; bit B2; function bit getB1; return a.B1; endfunction function bit getB2; return B2; endfunction endclass task run; wait(getB2()); // evaluated when B2 changes wait(getB1()); // evaluated when B2 changes not when a.B1 changes endtask

Yes, the workaround is to update your Linux OS. Unfortunately, C++ compilers have limited compatibility compared with C compilers. With Questa 10.1, you need gcc 4.3.3 or gcc 4.5.1 You really should update your OS. Not only is Centos 4.6 unsupported by Questa, it is also past end-of-life support by the CentOS project. (7 years)

You don't need the -sv_lib switch when using the UVM package that comes with Questa.

Does the hello_world.sv have at the top `include "uvm_macros.svh" You need this because the UVM package is now a separate compilation form the hello_world.sv

See the instruction at the bottom of http://www.accellera.org/activities/committees/vip. Dave

You should be using the UVM DPI library that comes with Questa. See http://go.mentor.com/uvm1-0-questa

I believe it was supposed to say "Do not print the field if it is the same as its default value"

A virtual interface variable is used to reference an actual interface instance. Did you mean to ask how to access a configuration object from an interface instance? If so, then the answer is the same of any access of a configuration object outside of the UVM component hierarchy. You need to understand how the first two arguments to uvm_config_db#type)::get/set() are used to build a path name to select a configuration object. But before I spend more time explaining, it would help if you clarified your question. Also, what do you plan to do with this configuration object?

What doesn't work?

Unfortunately, there is no backward compatibility layer to mix OVM and UVM components in a single testbench hierarchy. This decision has kept more people stuck in OVM environments than most people realize. It is possible to loosely couple two separate environments, as long as you never import both UVM and OVM packages into the same scope. You will need to manage all communication between the two testbenches either through RTL/interfaces, or with adapter classes.

You should not be adding the component handles sub,seqr or the config handle cfg in the concrete_agent. They never get constructed. The concrete_class can provide factory overrides in its build_phase before calling super.build(). If the concrete_agent needs to provide additional components, like another subscriber, then you would add its handle and have it constructed in the concrete_agent's build_phase(). The abstract_agent should construct "base" concrete components, assuming that makes sense for your environment. Then the concrete_agent only needs to provide the necessary overrides that are different from the default, instead of requiring the concrete_agent to override everything.

before0_fifo is not a fifo; it is a class that contains a fifo. Did you construct it?

Because that is not the right syntax to wait for a delay. The wait statement in Verilog waits for the expression to become true, or in your case, non-zero which is always is. The correct syntax is #(wait_time). Because of timescale issues in Verilog, you should write this as #(wait_time * 1us), where wait_time is the delay in µs. Also, it is not a good practice to put delays in sequences. Delays are physical properties of an interface and should be handled in the driver.

This is something that could be added to the factory, but for now you can add this virtual method to your classes virtual function bit is_a(uvm_object_wrapper am_a); if (my_type::get_type() == am_a.get_object_type()) return 1; else return super.is_a(am_a); endfunctionThe base class returns false if no match.