Jump to content

lisakb1963

Members
  • Content Count

    39
  • Joined

  • Last visited

  • Days Won

    4

lisakb1963 last won the day on February 10 2015

lisakb1963 had the most liked content!

About lisakb1963

  • Rank
    Junior Member
  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. lisakb1963

    OVM RGM Porting to UVM

    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. lisakb1963

    OVM RGM Porting to UVM

    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).
×