Jump to content

lisakb1963

Members
  • Content Count

    39
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by lisakb1963

  1. set_compare function void set_compare( uvm_check_e check = UVM_CHECK ) Sets the compare policy during a mirror update. The field value is checked against its mirror only when both the check argument in uvm_reg_block::mirror, uvm_reg::mirror, or uvm_reg_field::mirror and the compare policy for the field is UVM_CHECK. The generator should have a vendor extension for this. But some don't so you manually have to set it: For a field: status_reg.fld0.set_compare(UVM_NO_CHECK); For a register: //this depends on the generator config_reg.data.set_compare(UVM_NO_CHECK); You have to extend the register file that contains these registers and create a derived class that call super.build(). Does the set_compare and then build(); Your generator may have an XML vendor extension for this.
  2. You can also add to your XML for the debug_status register, this: <vendorExtensions:name>NO_REG_HW_RESET_TEST</vendorExtensions:name> <vendorExtensions:name>NO_REG_TESTS</vendorExtensions:name> These commands can be for registers or blocks (register files). This may not be flexible if the generator doesn't know this vendorExtension.
  3. Kathleen has a new webinar for UVM_Reference_Flow_1 .1 here (It last about 1 hour): http://www.cadence.com/cadence/events/Pages/event.aspx?eventid=640 You can download the code here: http://www.uvmworld.org/contributions-details.php?id=105&keywords=UVM_Reference_Flow_Version_1.1
  4. You should contact your Cadence AE and ask for iregGen -- we don't post it, and it's not in the release yet. This is the current standard protocol. It takes in IP-XACT 1.5 XML and uses the IEEE 1685-2009 (I think that's the spec) for the schemas. From there you can create: UVM_REG -- which I use OVM_RGM UVM_RGM There are some difference in the vendor extensions in the README file. Even if you have other tools in place (a lot of people want to take a word document and generate IP-XACT with non-free tools -- you should still use iregGen -- it will create the vendor extensions for the outputted register model correctly. Callback hooks are generated for every register.
  5. All, I've using the Use Model 1 for most of my register sequences. Since my DUT does has counters, interrupts, and status registers (RO) - a lot of DUT action is done without frontdoor reads or writes. But for vertical re-use, I've been told the the more bus-independent Register Item (with a translator) is preferably. Actual it's a Layered sequence with the running on a downstream bus sequencer. The problem is with this use model I can't use the grab, ungrab, and is_relevant for the ISR that I want. Can we have 2 use models in 1 environment . Is it possible to set the default_map to a reg_seqr and if I want to use model 1. I can start a sequencer on the bus sequencer with an adapter in place. Is there a rule of thumb of when to use which use models. I could see configuration sequences being better as Model 3- Register Layering. Also reads and writes that don't have volatile side effects. But if your actually doing something that needs to be synchronized with the first model makes more sense.
  6. Here is what I did: It seems like you may not be setting the model correctly, in you req_seq From the calling test: //declaration of the sequence that does the built-in set_resets_seq rst_seq; // In the build_phase rst_seq = set_resets_seq::type_id::create("set_resets_seq", this); ... rst_seq.model = yapp_model; // you have to give the sequence a model to run on. Since I am re-using it, I using the start method at a test as a wrapper. //In the run_phase of the test: rst_seq.start(hbus_seqr); // this is the bus that I want to run the front door register sequence on. In my set_resets_seq: class set_resets_seq extends uvm_reg_sequence(); rdb_pkg::yapp_am model; logic [7:0] data; uvm_status_e status; uvm_reg_sequence rseq; `uvm_object_utils(set_resets_seq) function new (string name="set_resets_seq"); super.new(name); endfunction function connect_phase (uvm_phase phase); uvm_config_db#(rdb_pkg::yapp_am)::set(uvm_root::get(),"*set_resets_seq*", "*model*", model); endfunction virtual task body(); rseq = uvm_reg_hw_reset_seq::type_id::create("rseq"); rseq.model = model; `uvm_info("Calling Built in reset test","Starting Reset Test",UVM_LOW) rseq.start(null); endtask endclass I made a wrapper sequence -- just for my testing. Because I have a lot of experimental reg sequences You can probably just have the seq_reset_seq, But: 1) You have to give it a model from somewhere, you can always retrieve from the database. 2) You need to give it a front door bus sequencer to run on (if it's not in already defaulted) For a simple version of what you are doing: class smoke_test extends uvm_test smoke_env env; // assume your model is in here too task run_task(uvm_phase phase); uvm_reg_hw_reset_test reg_seq = new(); phaise.raise_objection(this, "Running hw reset_test"); reg_seq.model = env.model; reg_seq.start(null); // assuming the default sequencer has been set up for the frontdoor phase.drop_objection(this, "End of hw reset test"); endtask endclass
  7. I also had to use the genvar for assignment of the dynamic array of interfaces in the top_tb. This was VMM 1.1.1a code though and I didn't have the config database and I was using an older version of the Questa (the 6.6 series -- so it could be different now with 10). So this may be across compilers. We had to go through push-ups to get this to work. (Not the top_tb, but the assignment of physical interfaces to the vif -- because we didn't have a config_db). The other thing you can do to be more generic -- is don't paramterize your top. You can actually use the command line parameter set_config_int and then you can have a configuration knob to change the number of interfaces on the fly. This is really useful if you have your on internal library of IP and need to test across different configurations. IE a channel based environment that can support 3 to 10 channels depending on what product the IP is going into. It really depends on how flexible you need your knobs and configurations to be.
  8. Thank you for the clarification on what will be deprecated -- I have been under the false assumption that set_config_int and set_config_string would be supported. Since these are part of the Command Line Interface -- I would want an equivalent. Perhaps I had a mix with 124 channels or 256 -- I'd want to configure the VIF and go from there. Would this concept still be supported? An example is a put a VIF on the (let's say a mixer - with 256 channels) -- Of course we can set use the config_cb option -- but the command line doesn't support it. My whole point was to set the channels with the set_config_int and make a number of channels. I would then use the new[] to create VIFs and there on. This is pseudo code. My question is will we be support config_db sets and gets on the command lin?. It's very useful for generically configuring IP based on certain requirements Thanks, lisab@cadence.com.
  9. If you hard code logic[7:0] pixel_xxx[][], then you will not be able to 8, 10 and 12 bit pixels. The one dimension part comes from the user's guide: `uvm_field_array_int Implements the data operations for a one-dimensional dynamic array of integrals. `uvm_field_array_int(ARG,FLAG) ARG is a one-dimensional dynamic array of integrals, and FLAG is a bitwise OR of one or more flag settings as described in Field Macros above. `uvm_field_array_object Implements the data operations for a one-dimensional dynamic array of uvm_object-based objects. `uvm_field_array_object(ARG,FLAG) ARG is a one-dimensional dynamic array of uvm_object-based objects, and FLAG is a bitwise OR of one or more flag settings as described in Field Macros above. You could have a further refine your model by having a pixel class It would have properties, like size, color, etc (maybe something in post_randomize() like perform gamma to change a 12 bit pixel to 8 bit. Or some other type of transform. Then you can have an array of pixel objects , but it still seems like you have row/column 2 dimensional array issue. I am not sure you can slice off a dimension and register it with the field operations (this seems like a basic concept to me).
  10. This is pseudo code, but you can use dynamic arrays and set this pixel size on the command line with set_config_int or with the tb, or a test. This allows for flexible code. You could have a default_pixels_size and and a control knob for using it, versus making it random. The uvm_array_field macros are 1 dimensional, I've tried to work around it in pseudo code, but you can try to make multi-dimensional objects. class frame (type int HEIGHT, int WIDTH) extends uvm_sequence_item; int pixels[][][]; // R, G, B or you can make this easier with one dimension arrays or a struct and put those into a struct for manipulation. //one dimension version; // data rand int pixel_red[][] rand int pixel_green[][]; rand int pixel_blue[][]; //control knobs int use_default_pixel_size; rand int pixel_size; // this is actual pixel_size can be overriden from a higher source. // register with macros `uvm_object_utils_begin(frame) `uvm_field_int(pixel_size, UVM_ALL_ON); `uvm_field_array_int(pixel_red, UVM_ALL_ON); .... `uvm_object_utils_end; ` // Default Constraints constraint c_pixel_size{ pixel_size == 8; pixel_size== 10, pixel_size == 12 ; } constraint c_frame_width { WIDTH == frame[1].size(); } constraint c_frame_height {HEIGHT == frame[0].size();} get_config_int("use_default_pixel_size", use_default_pixel_size); if ( use_default_pixel_size == 1) get_config_int("default_pixel_size", pixel_size); if you want the pixels to be packed logic vectors, you can still use the uvm_field macros) -- it may be hard to put a bounds on the logic vector -- if you want flexibility. rand logic [7:0] pixel_red[][]; Now you need to paramaterize the size as well (and you might want to do that, and have the height and width in the configuration data base. class frame #(type int PIXEL_SIZE) extends uvm_sequence_item; or class frame #(type int PIXEL_SIZE, int HEIGHT, int WIDTH); You can play around a see what works best for you and what compiles with your compile and constraint solver get_ config_data
  11. I too have encountered this problem and tried all sorts of way to get rid of it. There is a Mantis Fix 3540, but I don't know if this will fix this or it's a separate Mantis Issue.
  12. This was a Mantis Bug : 3757 Fixed issue where uvm_component::check_config_usage did not use uvm reporting facilities to report, but used $display. This is fixed in 1.1a (you will not see the bizarre regular expression message). I haven't run the 1.1a code, but if it prints a message -- it should be done through the reporting facility. There still may be an issue with it not printing anything. I'd check the Mantis database.
  13. You need to have (N sets) of this tag: <vendorExtensions:hdl_path>my_dut_reg</vendorExtensions:hdl_path> In your case you would have one at the register level -- depending on how your design is working this can be the straight name of the register -- the top level path is defined at outside of the register blocks. For instance my register (you don't have to reserve fields that is the default, but you can do it -- you just will not use it in the rtl spirit:register> <spirit:name>my_reg</spirit:name> <spirit:addressOffset>0x01</spirit:addressOffset> <spirit:size>8</spirit:size> ... <spirit:field> <spirit:name>col_width</spirit:name> <spirit:bitOffset>2</spirit:bitOffset> <spirit:bitWidth>2</spirit:bitWidth> <spirit:vendorExtensions> <vendorExtensions:collect_coverage>cov_all</vendorExtensions:collect_coverage> <vendorExtensions:hdl_path>my_fld_col_width</vendorExtensions:hdl_path> </spirit:vendorExtensions> </spirit:field> .. the same for the row_width. After all the fields have been defined, you make all the vendorExtensions forthe register itself. This is where you would put the actually path to the 8 bit register name within the DUT. As far as the RTL, these must be exact names -- to create my_dut_reg you can use the hdl field names and bit concatenations. This way you can manipulate fields of registers and the register or vice versa --depends on your RTL decode.
  14. Jade, This is a great way to deal with muli-channel type items, though (like 256 for a mixer on a sound card). Also when you have programmable vip you can use a dynamic array to set the #channels for the vif and this code would appropriately deal with a multi-channel situation in the scoreboard. I think I'll re-write our yapp_router example for dealing with the channels this way.
×
×
  • Create New...