Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by dave_59

  1. It is not possible to have a class object with both a member variable from B and member variable from C simultaneously; it is one or the other. So you can never randomize an object with both member variables. Perhaps you can show some example code of what you are thinking.
  2. Of course @(func(signal)) is going to cost more in performance than just plain @(signal).
  3. This does not work, This is exactly the problem described in the original post.
  4. I think defparam is partly to blame here. Before introducing the inline parameter override syntax using #(param1,...) in Verilog-2001, it was very difficult to predict when a parameter had received its final elaborated value relative the the module referencing it. Adding generate constructs makes that process even harder when you start allowing hierarchical references to parameters outside you instance, before the instance hierarchy has been fully elaborated. So the "no hierarchical names" rule is a broad hammer. In your particular example, you can get around this rule by using typedef instead of parameter references. SystemVerilog allows referencing a type from an interface port because there is a strict relationship between the interface instance and the port it is connected to. interface bus #(N = 8) (); typedef logic [N-1:0] adr_t; logic [N-1:0] adr; endinterface module m #(M = 8) (bus intf0, input [M-1:0] adr_pure1 ); typedef intf0.adr_t adr_t; // bring interface type into local scope if (M != $bits(adr_t)) $error("unequal parameters"); endmodule module top; bus b(); m m1(b,'0); // no error m #(10) m2(b,'0); // error endmodule
  5. This is a open issue with the LRM. https://accellera.mantishub.io/view.php?id=7190
  6. It's not legal to dynamically select an instance of a module or interface. Elaboration flattens out all hierarchy. Arrays of instances are not true arrays like a variable. Each element could have different characteristices because of defparam, bind, and port connections. The BNF does not allow the syntax.
  7. Hi Linc, Section 4.4 Stratified event scheduler of the 1800-2017 LRM defines a time slot as A time slot is clearly a single point of time encompassing all the regions (active, inactive, nba,...) and the iteration of all the region without advancing time. A time step has a looser definition, and there is already a request to use it more consistently in the LRM. There are many uses of time step that really should be time slot. IMHO, a time step should be used to refer to a particular point in time, or the advancement from one particular time to the next nonexempt time slot.
  8. Hi Linc, Your code works correctly on three other EDAPlayground simulators.
  9. @ljepson74, All you have to do is import uvm_pkg::uvm_enum_wrapper; and you've got this handy little class to use, you don't even need to have a class based testbench.
  10. The UVM field macros do not handle OOP very well, and is one of the many reason we do not recommend using them. It would be much simpler and more efficient to use the streaming operator exactly as you wrote it in a do_pack method.
  11. The link answers the question on how to apply a distribution to any set of constraints. The dist construct only works with explicit values.
  12. https://verificationacademy.com/forums/systemverilog/distributed-weightage-constraint#reply-46525
  13. You always incur overhead for automation. Performance rapidly deteriorates as you introduce dependencies with other random variables. For example, suppose you need 8 unique values between 10 and 20. You are going be calling $urandom_range many extra times throwing away values that don't meet the constraints. And it becomes very difficult to know when there are no solutions, and you end up in infinite loops looking for solutions that are very hard to find or don't exist. This is what a constraint solver does for you. Since constraints are tied to the class inheritance system, they provide another key benefit: you can add to or override them easily. It's very difficult to override constraints embedded within procedural code (this includes using in-line constraints).
  14. Give your error message a unique ID. Use set_report_severity_id_override to change the severity of that ID from UVM_ERROR to UVM_INFO. Then call get_id_count at the end of your test to make sure it's non-zero.
  15. The return code usually indicates successful completion of the tool and is unrelated to completion of the test. Non-zero return codes would be OS specific error codes. The SystemVerilog standard way of indicating pass/fail status is using the $info/$warning/$error/$fatal messages. Most tools are essentially catch the UVM reports and convert them to one of the SystemVerilog messages. They also have a way of detecting the most severe message issued during a run and you can use that information for determining pass/fail status.
  16. This was recently discussed here. The assertion should fail because disable_assert is false at the start of the attempt.
  17. Works for me in Questa, and in the VCS on edaplayground.com. I mean I get no compilation errors, did not check the functionality of your code. Maybe you are using an older version, Also, I suggest using *.SystemVerilog as file extension of using *.v and -sverilog switch. That helps keep legacy Verilog files working.
  18. It is the name of a class typedef added by the `umm_object_utils or `umm_component_utils factory macros and you are using type_it::create() to access a static method in that class. I explain the macro in this blog post. I explain how the UVM implements the factory in more detail in my SystemVerilog OOP for UVM course.
  19. You could extend your class from uvm_report_object. But this also creates a uvm_report_handler object which has a lot of overhead. A few other options are Avoid using a nested class. What is it doing for you in this situation? Define the class bar at the same level as foo. Avoid using the `uvm_field macros - also a lot of overhead.
  20. You might want to see http://forums.accellera.org/topic/1967-problems-with-starting-phase/
  21. The original intent of the phases in the OVM was to help with the initialization and shutdown of a simulation. The OVM phases mimic what happens in other environments like SystemC. end_of_elaboration is after all the elements of your testbench are constructed, and start_of_simulation is the initialization of your testbench. The phases make good breaking points for debug and checkpoints for restoring. The problem with phases in general is that unless you get everyone to universally agree on what goes in each phase, they lose their effectiveness.
  • Create New...