Jump to content

Bart

Members
  • Content count

    35
  • Joined

  • Last visited

  1. Bart

    Problems with starting_phase

    Duh - thanks Alan - you're right. However that raises a much more serious question. I thought that using get_starting_phase() was optional in UVM1.2. However since the method call is redundant in the example above, it shows that the UVM1.1 starting phase mechanism fails with no warning or error in UVM1.2. Thats a big backwards compatibility issue!
  2. Bart

    Problems with starting_phase

    OK attach file doesn't seem to work - heres the simple test case example: module top; import uvm_pkg::*; `include "uvm_macros.svh" class base_seq extends uvm_sequence; `uvm_object_utils(base_seq) function new(string name="base_seq"); super.new(name); endfunction task pre_body(); uvm_phase phase = get_starting_phase(); // add for UVM1.2 if (starting_phase != null) begin starting_phase.raise_objection(this, get_type_name()); `uvm_info(get_type_name(), "raise objection", UVM_MEDIUM) end endtask : pre_body task body(); #20ns; endtask task post_body(); uvm_phase phase = get_starting_phase(); // add for UVM1.2 if (starting_phase != null) begin starting_phase.drop_objection(this, get_type_name()); `uvm_info(get_type_name(), "raise objection", UVM_MEDIUM) end endtask : post_body endclass : base_seq class test extends uvm_test; `uvm_component_utils(test) uvm_sequencer sequencer; function new (string name, uvm_component parent); super.new(name, parent); endfunction : new function void build_phase(uvm_phase phase); super.build_phase(phase); sequencer = uvm_sequencer::type_id::create("sequencer", this); uvm_config_wrapper::set(this, "sequencer.run_phase", "default_sequence", base_seq::type_id::get()); endfunction endclass initial begin run_test("test"); end endmodule : top
  3. I'm trying to use the new get_starting_phase() mechanism in UVM1.2, but it's not working for me. For UVM1.1, I have the following working fine: task pre_body(); if (starting_phase != null) starting_phase.raise_objection( this, get_type_name() ); endtask In UVM1.2 RC8, I add: task pre_body(); uvm_phase phase = get_starting_phase(); if (starting_phase != null) starting_phase.raise_objection( this, get_type_name() ); endtask This just doesn't work. get_starting_phase() returns null everytime and the objection is never raised so the simulation immediately ends. Attached is a simple testcase - in UVM1.1 the sequence successfully waits for 20ns, but after adding get_starting_phase(), in UVM1.2 RC8 the simulation ends immediately. Have I misunderstood how get_starting_phase is suposed to work?
  4. Yeah OK that's a tougher one.. You can avoid string typos in type overrides by using the set_type_override_by_type variant instead of the set_type_override_by_string. In our experience this reduces override problems considerably.. and any problems you do see are usually to do with incorrect factory registration (wrong name in utility macro) rather than an incorrect type override
  5. Forgot to add - in UVM1.0 & above, you should call check_config_usage() from check_phase() or any of the post-run phases. Reason is that if you are using the configuration mechanism to set run_phase default_sequence properties of sequencers, these are only resolved during the run phase itself. Therefore checking config usage in a pre-run phase (like start_of_simulation) may incorrectly report unmatched default_sequence settings.
  6. In UVM1.0 and later, you can print the factory settings, from e.g. a test class, with : factory.print(); From the documentation:- function void print ( int all_types = 1 ) Prints the state of the uvm_factory, including registered types, instance overrides, and type overrides. When all_types is 0, only type and instance overrides are displayed. When all_types is 1 (default), all registered user-defined types are printed as well, provided they have names associated with them. When all_types is 2, the UVM types (prefixed with uvm_) are included in the list of registered types. In UVM1.0EA, check_config_usage() was called automatically. In UVM1.0 & later, you have to call it explicitly..
  7. The original reason why sequence libraries were not documented in the UVM1.0 release was that the libraries were a late additional to the release and so missed the documentation deadline. However this doesn't explain why they didn't make the UVM1.1 documentation. Since large chunks of the implementation code is still labelled as "prototype" or "subject to change", I'd be inclined to avoid sequence libraries until their status as a library feature is clarified.
  8. In UVM1.0EA, the method check_config_usage() is automatically called at the end of the simulation. This prints out any configuration settings which are not matched by pathname or fieldname. It could be that an problem in one of your config settings is missed during simulation (because it is not matched) but causes an error at the end when check_config_usage() is called. You could get a null pointer warning if you're using objects as configuration containers. Try commenting out your configs & seeing if that fixes that problem.
  9. Hi uwe Attached is a simple test case with incorrect config database set call on property config_item in the path uvm_test_top.env. The check_phase method of the test class contains a check_config_usage() call to confirm the incorrect configuration and a call to uvm_config_db_options::is_tracing() to check if the configuration tracing is enabled. Adding +UVM_CONFIG_DB_TRACE adds no extra output to the log, but is_tracing() returns 1. With +UVM_RESOURCE_DB_TRACE option, I get additional output like this:- UVM_INFO ***uvm-1.1/src/base/uvm_resource_db.svh(130) @ 0: reporter [CFGDB/SET] Configuration 'uvm_top.env.config_item' (type unknown) set by = ? UVM_INFO ***uvm-1.1/src/base/uvm_resource_db.svh(130) @ 0: reporter [CFGDB/GET] Configuration 'uvm_test_top.recording_detail' (type unknown) read by uvm_test_top = null (failed lookup) UVM_INFO ***uvm-1.1/src/base/uvm_resource_db.svh(130) @ 0: reporter [CFGDB/GET] Configuration 'uvm_test_top.recording_detail' (type unknown) read by uvm_test_top = null (failed lookup) UVM_INFO top.sv(39) @ 0: uvm_test_top [test1] Config tracing = 0 i.e. correct ID of the failed configuration of config_item, plus the extra recording_detail overhead, and confirmation that configuration tracing is disabled. So it looks like +UVM_CONFIG_DB_TRACE is not aliased to resource coverage, but just doesn't work. Simulation run on IUS9.3s37 with UVM1-1
  10. Hi Uwe Not sure if that bug description is correct:- >>>A bug in uvm_config_db.svh causes the UVM_CONFIG_DB_TRACE option to be ignored and use UVM_RESOURCE_DB_TRACE instead. In my experience the UVM_CONFIG_DB_TRACE option is ignored full stop. Not replaced by the resource trace as implied by the description..
  11. You can connect virtual interfaces in either the build_phase() or the connect_phase() so its a matter of preference & philosophy. Strictly speaking you're not making a connection - you are assigning a value to the local vif property through the configuration mechanism. Static configuration settings are updated during the build_phase(), so traditionally this is the phase to handle this. If you were connecting component TLM ports or references, you would do this in the connect_phase() to make sure the start & end points of the connection exist.
  12. Anyone tried the new +UVM_CONFIG_DB_TRACE option in UVM1.1? Is it broken? I'm using set & get calls on uvm_config_db and adding the +UVM_CONFIG_DB_TRACE option does not generate any new output. Whereas using the +UVM_RESOURCE_DB_TRACE option reports get calls for every sodding property in my testbench, including default_sequence for every UVC in every run phase; recording_detail for every component; etc etc. Is this the expected behavior? Are there no filtering options? I'm resorting to the old check_config_usage() call, the output of which is significantly worse than in UVM1.0EA.. Config debugging seems to be going backwards in UVM1.0/1.1. Given some of my users like the regexp options in config sets, this is getting painful.. Anyone have any good options for config debug in UVM1.0/1 besides the above?
  13. Hi Pratta Like I said, returning a response via item_done() may not be suitable for your application. Section 4.5.4 of UVM1.0.1 User Guide - Sending Processed Data back to the Sequencer - actually identifies 3 options for passing a response to the sequencer: 1) Argument to item_done() 2) Explicit put_response() call 3) Using the built-in analysis port of the driver We use option 1 for simple transfers where the response is obtained in the same transaction as the request. For responses outside the original request transaction, we've always used a fourth option: 4) Connect the sequencer to the analysis port of the UVC monitor. Of course this has the disadvantage of not having access to the transaction id of the request for matching, but our applications don't have non-deterministic out-of-order responses. Your Mileage May Vary
  14. item_done() may not be suitable for your application, but item_done() does actually call put_response() and can deal with out-of-order responses.. In the driver, when you send a response via item_done(), you can set the transaction id of the response to match the request: task run(); forever begin seq_item_port.get_next_item(req); send_to_dut(req, rsp); seq_item_port.item_done(rsp); end endtask : run task send_to_dut(input packet reqp, output packet rspp); rspp = packet::type_id::create("rspp",this); rspp.set_id_info(reqp); ... Then in the sequence, you can get the response based on the transaction id: virtual task body(); `uvm_do_with(req, {req.data_in == 2'b00;}) get_response(rsp, req.get_transaction_id()); ... There's a response queue (default length 8) between the sequence and driver to store responses. Writing responses to a full queue loses the response and generates an error. Note if you call get_response() without a response id, it returns the next response in the queue. Get_response is blocking, so if there is no response with a matching id or the response queue is empty, the get_response will block until a response is received.
  15. The process class is part of the SystemVerilog language. You're unlikely to find source code for the implementation. It's probably vendor-specific anyway. The SV LRM should provide enough description of the methods of the process class for you to use it.
×