Jump to content

mastrick

Members
  • Content count

    43
  • Joined

  • Last visited

  • Days Won

    1

mastrick last won the day on April 5 2016

mastrick had the most liked content!

About mastrick

  • Rank
    Junior Member
  1. When you set the default_sequence in uvm_config_db, you specify the phase in which the driver will start the sequence. Just with that specification, you can run the sequence in any phase. get_starting_phase() and set_starting_phase() refer to a phase that will be objected to by the automatic phase objection feature of uvm_sequence. The default value for that starting_phase is the phase in which the sequence gets started (what you specified to the uvm_config_db).
  2. Strangely enough, we have just encountered this issue for the first time today. Thanks Robert for posting! In our case, the nested class does not use the field macros but rather calls uvm_report_info directly. We use nested class in this case because this class is used as a replacement class in the test, and to allow us to compile all tests in one executable without conflict, we require such classes to be nested within the test class that uses it. Guess I'll file a mantis to see if the implementation can tolerate such usage.
  3. I believe you want your test sequence to object to main_phase so that you will not have the physical sequence ended before the test sequence ends.
  4. randomize() with inside syntax

    Also, you might want to keep your randomize() call outside the assert(). Otherwise, simulators may not call the randomize at all if you disable assertions (e.g. to temporarily work around a problem). You can assign the return from randomize() to a variable and then assert that variable.
  5. Hi Dave, If you just had "c.a = 10; p.c = c;", you would certainly expect c.a (and p.c.a) to be 10 afterwards. I think the question is why p.randomize(c. does not mean that c.a is a state variable, so it is still 10 after the randomize. Mark
  6. I would expect that is an expected usage model and I have filed Mantis 5529 https://accellera.mantishub.com/view.php?id=5529 againstthe current IEEE standardization effort.
  7. You are correct. That is Mantis 4427, whose fix did not get into the UVM 1.2 release.
  8. initialization sequence question

    If you are using run-time phasing, you simply need to have your environment start the init sequence in some phase before main (perhaps the configure phase), holding the objection until that sequence completes, and then tell test developers that they must run their sequences in main phase (which is the intent of main phase).
  9. I have created a Mantis item to clarify the description of uvm_component_name_check_visitor.
  10. Can you describe in more detail what you mean by "pre_reset_phase entering twice"? What are the signs?
  11. Thanks for the suggestion, David. The situation that caused us to consider this question was that we had a verification component modeling an external interface to our ASIC, so it had its own clock, not shared with the rest of the design. There is a possibility that clock is not running, which we wanted to model, but when the clock did not run, our drive through the clocking block never happened. In real circuitry, even though the clock is not running, the asynchronous reset (applied to the external component also) would ensure that the external data was driven to a known value. This made us consider that often our verification components act as if they are synchronously reset but they may not be in real life, and one can imagine scenarios where a bug could escape. So your example implies that a non-blockjng assignment to DATA would change the value on DATA and not be treated as another driver to be resolved on DATA. If so, can you say why the internal assignment behaves differently from a non-blocking assignment from outside the interface of the form m_if_instance.DATA <= value?
  12. Our uvm_driver derivatives push values into the RTL via clocking blocks in interfaces. This updates the signals synchronously as we typically want, but is there a recommended way to add an asynchronous update of the signal to model a change that could occur when asynchronous reset is applied? We see that if we just assign to the signal at the interface level (not the clocking block level), we get a conflict between both assignments.
  13. The +uvm_set_default_sequence is applied at the time that +uvm_set_config_int is applied, which seems consistent. This is before run_phase, which is why your code overrides the command line value. What do you think about making your code check whether there is an existing setting first? task run_phase(uvm_phase phase); if (!uvm_config_db #(uvm_object_wrapper)::exists(null, "uvm_test_top.my_sequencer.main_phase", "default_sequence")) uvm_config_db #(uvm_object_wrapper)::set(null, "uvm_test_top.my_sequencer.main_phase", "default_sequence", seq_b::type_id::get()); sequencer.start_phase_sequence(phase); endtask: run_phase
  14. sequencer and sequence driver

    It might make a difference which context you saw "sequence driver" in, but the eRM (Specman) concept of "sequence driver" is the same as the UVM sequencer.
  15. UVM Phase issue

    Can you show some of the code you have for the base test pre_configure phase, including the raising of the objection?
×