Jump to content

lisakb1963

Members
  • Content Count

    39
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by lisakb1963

  1. You have a real error -- from the printout. It looks like you have a mis-spelling somewhere, although the error is not indicative of what is wrong. 1. How have you defined your payload??? From the output it looks like you defined something payloadseqment. (seqment) NOT payloadsegment (segment). 2. The foreach look correct. I would further debug this and see how you defined payloadse?ment. Probably when you define the payload -- you spelled it as payloadseqment not payloadsegment and it is an array [] -- that is why you see the individual elements in the sequence. I am not sure -- why you did not receive a compile error.
  2. It depends on how your code was built. You can check the set_compare policy for a field by checking it: bit model.blk.reg.get_compare() 1. If it is set UVM_COMPARE, this will override the UVM_CHECK provided to the mirror. 2. The mirror() call will always use the register/field off of the default_map provided by context when you make the mirror call. 3. You can change your compare policy on the field right before you make the mirror call and see if that makes any difference. model.blk.reg.fld.set_compare(UVM_NO_COMPARE); // now that field should not be compared on mirror mirror(); //arguments to mirror will be different on R/W or check
  3. I updated your code. This is the quickest way of using the default printers classes: `uvm_info("REPORT", $sformatf("my_q[%0d]:\n%s", i, my_q[i].sprint(uvm_default_line_printer)), UVM_LOW) // the uvm_default_printer is the uvm_default_table_printer, you can change it globally or pass one these declared printer classes: uvm_default_table_printer uvm_default_line_printer uvm_default_tree_printer I updated your code with the uvm_default_line_printer call and it works.
  4. Chris, Here is an articleof "Why Macros Are Evil" & wait ... This wasn't the #1 article when I goggled "why macros are evil" (which I thought was pretty specific.) This was the 11th hit... http://verificationhorizons.verificationacademy.com/volume-7_issue-2/articles/stream/are-ovm-and-uvm-macros-evil-a-cost-benefit-analysis_vh-v7-i2.pdf
  5. You can use distributions, so that you can weight the corner cases to happen less than normal operations. x dist { 100:=1, 200:=2, 500:=5 } which gives the weights of 1-2-5. So 500 is weighted to happen more often. You can also use the range distribution: x dist {[100:102] :/ 1, 200:=2, 500:=5} which give the weights of 1/3, 1/3, 1/3, 2, and 5 You can't use distributions on randc variables. lkb
  6. 1. You need to instantiate the uvm_reg_hw_reset_seq. 2. Then you pass the instance model to your model. 3. Then you start the sequence. uvm_reg_hw_reset_seq reset_seq; reset_seq.model = my_model; reset_seq.start(null);
  7. Try this method instead. model.my_reg.read(status, value,.parent(this); The read_reg is a convenience method for not specifying .parent(this): Reads the given register rg using uvm_reg::read, supplying ‘this’ as the parent argument. Thus, read_reg(model.regA, status, value); is equivalent to model.regA.read(status, value, .parent(this)); Lisa
  8. Sorry for the late response, I don't seem to be getting emails from this site. Even though I signed up. Go to:http://www.verilab.com/resources/papers-and-presentations/ There is a good presentation and paper and code a page down: SNUG Europe 2012: I Spy with My VPI - Monitoring signals by name, for the UVM register package and more Lisa
  9. GG, If you have a Register Model for UVM_REG and an adapter, you are good to go for upfront things like reading and writing registers using the UVM_REG API calls. Now you have to decide on how to do prediction (this keeps the register model and the actual DUT synchronized.) Initially you can go with auto-prediction (by default it is off), but eventually you will want to create a predictor for your bus transactions (which tracks both actual bus transactions coming from the register model and other sources.) Turning on auto-predict will monitor your register transactions, but not all the transaction on the bus (outside of the register model.) This known as implicit prediction. Explicit prediction is done when you extend uvm_reg_predictor: Explicit Register Predictor The uvm_reg_predictor class defines a predictor component, which is used to update the register model’s mirror values based on transactions explicitly observed on a physical bus. More on this in 5.9.3 on in the User's Guide Lisa
  10. UVM_REG is a combination of VMM and OVM/UVM RGM. It is the register open standard. Tool generation is vendor specific (there are a lot of third party tools out there too -- which produce IP-XACT 1.5). For Cadence, iregGen takes in IP-XACT 1.5 xml. This makes use of the vendor Extensions. I think RAL has been expanded to produce the register model in SystemVerilog.
  11. This should work, but it may be something odd in your base class. I would look at protocol layering. This is very useful for OSCI or other protocols that have a high data layer over a physical data layer: TCP-IP USB 3.0 PCIe It involves using TLM 1.0, and reconstruction of data -- but it is useful. From what you describe, you aren't doing anything this complicated -- but this may be the way to solve your problem. This is described in the UVM User's Guide 6.5.2. It is also a usage model for UVM_REG (there are three) --- but unless you really have abstracted registers to the hardware -- you can't do anything like grab, lock, priority, ISR. But it is extremely useful for Layering of of data protocols.
  12. This will always work in a .log file or a directed file (based on a knob value) -- but it doesn't work when viewing transactions in the waveform windows. I also do not know if this works in the stripe chart window. I think we can't change the behavior in the GUI windows, but it will ALWAYS be displayed fully in the .log or other files. To redirect to other than the default simulator output file, you need to change .knobs.mcd to change the file pointer: mcd int mcd = UVM_STDOUT This is a file descriptor, or multi-channel descriptor, that specifies where the print output should be directed. By default, the output goes to the standard output of the simulator. I think currently, you can't change the transactions in the GUI windows (waveforms and Transaction strip chart) -- it will always default to 5 first and the 5 last. I'll try it and report back
  13. First, let me apologize -- markups does not seem to work anymore. Callbacks in the register model are really meant to extend the functionality of register if doesn't match one of the pre-defined registers already defined in UVM_REG. Also you can extend one of the pre-defined registers with unique behavior. If you are performing certain functions, say waiting for an interrupt -- you should use wait_for_change. Unfortunately, it needs backdoor access and isn't implemented in the model -- so you need to provide an implementation (and there really aren't UVM_REG specific guidelines for this). This involves DPI code if you want to wait based on a string name. Your simulator vendor may have something already. This is how it is defined: is_auto_updated virtual function bit is_auto_updated( uvm_reg_field field ) Indicates if wait_for_change() method is implemented Implement to return TRUE if and only if wait_for_change() is implemented to watch for changes in the HDL implementation of the specified field [B]wait_for_change [/B] virtual local task wait_for_change( uvm_object element ) Wait for a change in the value of the register or memory element in the DUT. When this method returns, the mirror value for the register corresponding to this instance of the backdoor class will be updated via a backdoor read operation. Section 5.6.6 Active Monitoring of the UVM User's Guide explains how to use this. If you don't mind having hard paths like the one in the example (this is a partial example): virtual task wait_for_change(); @($root.tb_top.dut.rf.f1 or $root.tb_top.dut.rf.f2); endtask Then you can implement it quite easily without the DPI. I've done this and it works. Hard paths don't work in packages. This is one reason you need the DPI. Also you can't wait_for_change on a string name. I found some free DPI code by goggling: wait_for_change + UVM_REG 1. There are white papers that explain it. 2. There are some free tools that give you the SV and C code you need. 3. Ask you vendor if they already have this code. I'd still look at some of the white papers. Hope that helps: LKB
  14. I don't know if you can force this behavior outside your patch. Using multiple sets() are fine, usually you do a single update to the hardware -- as if you were loading a packet/ppayload /memory in 0 time. I think your problem is in the auto_prediction logic (which may be affected by randomiztion). For the most part, most of the DUT type accesses (write, read, update, peek and poke) -- usually calls auto predict internally in the library. The library also has built-in (for efficiency) that it will not read/write a register on updates, peek, poke -- if it is the same value as the desired value in the model Check the Mantis database to see if this is "issue" -- it's not a bug, just optimization. I guess the best thing someone could ask for is similar to no_check (which is done automatically and causes prediction errors with volatile registers), this was fixed in 1.1c I'd look at Mantis an see if they are changing the behavior -- if not bring it up again here. Or you can continue with your path. The Accellera library (being built by multiple vendors -- where they are free) may not have all the optimizations that you want like older languages like 'c' - where you choice your level of optimization. All the mark-ups seem to be broken right now.
  15. Are scoreboard1 and scoreboard_fred different classes? You can always extend 1 of the 3 printers (uvm_table_printer, uvm_line_printer, uvm_tree_printer) in any class. That would be their local printer. You have to instantiate in a higher class but you can use it based on the class. The class should be a uvm_object not a component, so you probably want to do something in the object class based on which scoreboard. The uvm_object class allows you to reference data automation with the factory -- and all the Policy Based Classes use this information (Print, Clone, Record ...) You can also extend any default or defined printer with the do_print call back. This allows you to override or change the output. It will always be called, whereas -- if you define a new printer, it needs to be allocated and passed to obj.print or obj.sprint where obj is a data object class. mcd is in the knob class (associated with any defined printer). This allows you to redirect output to a file. The standard output is the simulator output file (like log files, etc).
  16. Hi Janick, How would I know I want to use batch updates? I am assuming based on comments --- that this is related to DUT changing registers. This would be part of the monitor activity of a variety of DUT changing registers (Counters, Interrupts, One register action reflecting another .... ). The documentation is a little skimpy on this in the UG (It only shows a hard-coded path). I always have to use a hard RTL path and I want to leverage the Register Model -- it does know the backdoor path. But I cannot pass it in to wait_for_change because it's a string , not an uvm_object. What I really want to know is the Accellera use model of dealing with DUT changing registers. Reading back on your answer. I am asking a separate question here -- unrelated to the use model of get/set -- Sorry.
  17. Experts, I understand basic Read and Write API (FRONTDOOR/BACKDOOR) I understand why we need update() and mirror() -- for the SV Randomize. Why would we want the get() and set() that just modifies the desired value. Under what circumstances is it desirable to use these?
  18. In the build_phase where you are building your model did you do a: model.lock(); This needs to be done before any usage
  19. Make sure you are using UVM 1.1a or higher (1.1b has been released) and 1.1c real be released around Labor day.
  20. Prior to calling the reset sequence, you need to pass the model to it: If it is in a phase call: virtual task run_phase(uvm_phase phase) phase.raise_object(this,"Running HW reset seq..."); uvm_reg_hw_reset_test = new("test_seq"); // you really should use create to put it in the database test_seq.model = your_reg_model_name; test_seq.start(null); phase.drop_objection(this, "End of HW Reset seq..."); endtask
  21. Hi You can get the latest release of uvm_rgm on the contribution site on the website : http://www.uvmworld.org/contributions-details.php?id=125&keywords=Cadence_UVM_RGM2.7.5_release Also, Cadence supports iregGen which will generate models for uvm_rgm, ovm_rgm, and uvm_reg (The Accellera standard) in System Verilog. This is not available in the contributions or in the IES release-yet You should ask your Cadence AE for the iregGen 1.05 parser/generator. It takes in IP-XACT xml.
  22. Depending on you <spirit:vendorExtensions> (I don't know what your generator does.) -- but you should be able to set a unique path per field as a vendor extension. The issue that I see with this is that typically you make an HDL hierarchy , and you seem to have a hard path. It really doesn't matter -- it just makes moving the fields around generically (and abstract) less usable. for instance you could do this: <spirit:field> .... spirit:vendorExtensions> <vendorExtensions:name>ctrl_reg</vendorExtensions:name> <vendorExtensions:type>ctrl_reg_t</vendorExtensions:type> <!-- You can add a hard coded a path per field --> <vendorExtensions:hdl_patht>top_dut.base_regs.ctrl_reg</vendorExtensions:hdl_path>
  23. 1.In your top tb you need to declare you need to use you interface name to be associated with a virtual interface interface core_if core_intf // is what you decleared 2. This is why you are getting an error around your set -- the compiler doesn't know what vmidmt_if is. 3. You configuration is wrong. The Path should be at the tb level not at the core_if (2nd argument) uvm_config_db #(virtual interface core_if)::set( null, "*.tb.vmidmt.*","core_vif", core_intf); // I a made up your tb path The 3rd argument should be reflective of a vif style name. This is for string look up purposes: Path Field Value "*tb.vmidmt.*" "core_vif" core_intf The arguments work like this: 1. The first is context -- which is null , top_tb.sv is the parent 2. The second is an instance call to all the UVC sub-components (both the agent's driver and monitor need to get the vif from the database) 3. The third is vif field name. 4. the fourth is the actual instance of the interface. lkb
  24. This is really old code. 1. All the phases should be declared xxx_phase (uvm_phase phase) 2. global_stop_request is no longer used The test is working though sort of. You just are running through all the phases and printing messages. Once run_test is called, the phasing system kicks off. All the phases except run_phase take 0 time. The run_phase in this example doesn't raise or drop objections, so your wait of #1000 doesn't happen. change your run to run_phase like this : virtual task run_phase (uvm_phase phase); phase.raise_objection(this); #1000; phase.drop_objection(this); endtask : run This is what the reporter says: ** Report counts by severity UVM_INFO : 58 UVM_WARNING : 0 UVM_ERROR : 0 UVM_FATAL : 0 ** Report counts by id [RNTST] 1 [uvm_test_top] 1 [uvm_test_top.t_env] 8 [uvm_test_top.t_env.ag1] 8 [uvm_test_top.t_env.ag1.drv] 8 [uvm_test_top.t_env.ag1.mon] 8 [uvm_test_top.t_env.ag2] 8 [uvm_test_top.t_env.ag2.drv] 8 [uvm_test_top.t_env.ag2.mon] 8 Old Message: Simulation complete via $finish(1) at time 0 FS + 186 New Message: Simulation complete via $finish(1) at time 1 US + 44
  25. When you see something like this. 1.Your objections are not being raised or dropped properly. 2. This is usually hidden in the sequence base class (that you create) pre-body and post-body. I'd have to look at the example and see where this is. If it's a simple test with no sequences, it can be placed in the run_phase of the test. In fact if you want to debug this in the run_phase do as the first item: phase.raise_objection phase.drop_objection as the last item. Since i don't have the example -- I don't know what they are doing. You might want to run a few of the example provided with the uvm1.1a release.
×
×
  • Create New...