Jump to content

jadec

Members
  • Content Count

    129
  • Joined

  • Last visited

  • Days Won

    1

jadec last won the day on September 27 2014

jadec had the most liked content!

About jadec

  • Rank
    Senior Member

Profile Information

  • Gender
    Not Telling
  • Location
    San Jose
  1. I'd call it from the sequencer once and store the value to be retrieved whenever a sequence wants it. That does assume that you're setting some global parameter and not something that's applied to particular sequence instances.
  2. I was able to compile your code (with some minor additions). The message is very strange because the "formal type" is exactly what the "actual type" is extended from, so I don't see why this would fail. You should probably consult your simulator vendor.
  3. jadec

    Inherit uvm_root?

    Nash, you're probably better off creating your own question thread. But you should be able to register your own objection callback for this without modifying the component.
  4. The answer to the question is a question "How does your hardware determine the packet length?" Once you know that, you can implement the same logic in your monitor. It will be either so interface signaling the start and end of packet. Or some common header format. If it's the latter, you'll need a base class for your packet that can decode the common header (both for the length and to determine the actual packet type).
  5. uvm_config_db#()::get() is a rather expensive operation. You'll want to be careful about calling it frequently. For sequences, I generally recommend doing the get in the sequencer and just using "p_sequencer." to access it from your sequence.
  6. Take a look at Figure 1 in the UVM user guide. You should have 2 agents for your DUT. One for the input side (what you're calling your "driver") and one for the output side (which I think you're calling your "monitor"). Each of these agents contains a monitor. The input monitor should communicate to your scoreboard as will the output monitor. This allows you to check the functionality of the DUT (comparing what it saw on the inputs to what it generated on the outputs). If you want to check the functionality of the driver, you'll need to compare the input transactions in the driver against those observed by the input monitor (this is not generally automated).
  7. Since indexes to interface array need to be elab-time constants, you can do: duv_sigif fifo_vif[`PORTS_NUM] (clk, rst); // SystemVerilog Interface ... // outside of procedural block generate for (genvar i = 0; i < `PORTS_NUM; i++) begin initial uvm_config_db#(duv_vif)::set(uvm_root::get(), $sformatf("*.env.subenv[%0d].*", i), "tb_vif", fifo_vif); end endgenerate
  8. Generally, you wouldn't use uvm_resource_db directly. Instead you'd use uvm_config_db. You would identify the different instances by their instance path: uvm_config_db#(...)::set( this, "path.to.bfm1", "INTF", INTF1 ); uvm_config_db#(...)::set( this, "path.to.bfm2", "INTF", INTF2 ); Then in the "bfm" component: uvm_config_db#(...)::get( this, "", "INTF", my_intf ); Because each "bfm" will have a different fullname, the "this" will select the right interface.
  9. The uvm_queue::get_global_queue() function returns a shared queue of a particular type. You can create separate queues by using the uvm_queue::type_id::create(...) function. If your intention is to communicate data between 2 components, it's probably better to use tlm ports.
  10. These base classes are not intended to be directly instantiated.
  11. 1. You may set a default sequence for each run-time phase. This message is generated for each phase that didn't find one. 2. No, the message is an info only (you've probably set UVM_VERBOSITY too high for normal usage). 3. It is similar but there are some differences. For example, the sequencer sets "starting_phase" variable in the sequence if it starts it as a default_sequence.
  12. Perhaps you can post the code you are using to set and get the configuration (along with the context)? SystemVerilog tasks are not objects so they can't be passed directly via config. Normally, I'd expect the "wait for IRQ" function to be implemented in a component and for a handle to that component to be given to the virtual sequencer during the connect_phase (where the sequence can later access it). Config is generally not used for such connections.
  13. uvm_analysis_imp requires that the implementation be a component, but uvm_analysis_port can be instantiated outside of a component: uvm_analysis_port #( my_obj ) myport = new( "myport", null ); It might make debugging more difficult, but the port functionality doesn't require it.
  14. Where did you see this information? I don't find any reference to UVM_MUTE in the UVM 1.1c release at all.
  15. jadec

    Inherit uvm_root?

    You should be able to safely modify the global report server before calling run_test(). That should handle anything that happens within the UVM phasing (it's still possible for static initializers to run before that, but there's never going to be a way to control the order of that). It seems to me that any extension of uvm_root would suffer from the same timing problem you have now with extending the report server.
×