Jump to content

sylvainb

Members
  • Content Count

    4
  • Joined

  • Last visited

  1. Hi Tudor, Thank you for your answer... I actually found in between a paper that mention this problem (section VII). They also suggest a work-around by using uvm_config_db#(int) instead of uvm_config_db#(hs_type_t), and this works perfectly for me to circumvent the issue!
  2. Hi All, It seems that there is a problem for automatically updating components fields registered with uvm_field_* macros. It works fine if the field is of type int, but it fails if the field is of type enum. Do I miss something? (I tested this code with both UVM 1.1-d and UVM 1.2) class hs_driver extends uvm_driver #(hs_packet); hs_type_t driver_type; int my_param = 10; `uvm_component_utils_begin (hs_driver) `uvm_field_enum (hs_type_t, driver_type, UVM_ALL_ON) `uvm_field_int (my_param, UVM_ALL_ON) `uvm_component_utils_end [...] endclass: hs_driver class test_bench extends uvm_component; `uvm_component_utils (test_bench) hs_driver host; hs_driver device; [...] virtual function void build_phase(uvm_phase phase); super.build_phase(phase); uvm_config_db#(hs_type_t)::set (null, "*.device", "driver_type", DEVICE); uvm_config_db#(int)::set (null, "*.host", "my_param", 888); host = hs_driver::type_id::create ("host", this); device = hs_driver::type_id::create ("device", this); endfunction: build_phase endclass: test_bench Printing test topology: ------------------------------------------------------------- Name Type Size Value ------------------------------------------------------------- uvm_test_top simple_test - @1863 mtb test_bench - @1939 device hs_driver - @2089 rsp_port uvm_analysis_port - @2162 recording_detail integral 32 'd1 seq_item_port uvm_seq_item_pull_port - @2130 recording_detail integral 32 'd1 driver_type hs_type_t 32 HOST -> should have been DEVICE! my_param integral 32 'ha recording_detail integral 32 'd1 host hs_driver - @2024 rsp_port uvm_analysis_port - @2095 recording_detail integral 32 'd1 seq_item_port uvm_seq_item_pull_port - @2058 recording_detail integral 32 'd1 driver_type hs_type_t 32 HOST my_param integral 32 'h378 -> In this case (for an integer) the field has been updated followin uvm_config_db recording_detail integral 32 'd1 recording_detail integral 32 'd1
  3. Hi Peter, Thank you for you answer. I had indeed a look within the "Linear PCM integrated example test bench". I think the idea of separating the UVC monitor and the coverage by encapsulating the coverage groups within a uvm_subscriber is neat, however I can foresee that the example of the coverage library (lpcm_cov_lib.sv), using only the size as a parameter (16,24 & 32bits), can become easily extremely verbose and clumsy when the numbers of parameters increase and the parameters interact with one another to determine how the cover group should look like. The best of course, would be to have a covergroup in the base class that can be extended and tweaked in a derived class, but I understand that this is not possible due to SystemVerilog language limitations... Regards Sylvain
  4. Coverage should sit along with protocol checkers within a UVC states the UVM user guide. In SystemVerilog, it is achieved using covergroup within the monitor, these covergroups are built within the monitor constructor using the 'new()' method - At least it's what is done within the UVC we purchased from a vIP vendor. As a consequence, if I want to make a new derived class for the UVC monitor I am reusing in order to tailor the verification environment to the special needs of my DUT, I am not able to override the initial covergroup within the monitor base class... Is there a better way to proceed? What is there the best practice for extending/modifying and existing covergroup? Regards Sylvain
×