Jump to content


  • Content Count

  • Joined

  • Last visited

  1. nbjessen

    UVM Register Field Coverage

    I have the following: virtual function void build_phase(uvm_phase phase); uvm_reg_cvr_t cov_type_result; uvm_reg::include_coverage("*", UVM_CVR_ALL); my_reg_block = my_reg_block::type_id::create("my_reg_block"); cov_type_result = my_reg_block.set_coverage(UVM_CVR_ALL); $display("cov_type_result = %x", cov_type_result ); ... endfunction I believe this meets all of the requirements. My register code is below: I see 'cg_vals' get created. But sample_values is never called. class qsr_register_7 extends uvm_reg; `uvm_object_utils(qsr_register_7) uvm_reg_field RESERVED_QSR_07_31; // RESERVED rand uvm_reg_field ctl_pnld2_val; // PN31 seed for PN generator 2. // Function: coverage // covergroup cg_vals; ctl_pnld2_val : coverpoint ctl_pnld2_val.value[30:0]; endgroup // Function: new // function new(string name = "qsr_register_7"); super.new(name, 32, build_coverage(UVM_CVR_FIELD_VALS)); add_coverage(build_coverage(UVM_CVR_FIELD_VALS)); if(has_coverage(UVM_CVR_FIELD_VALS)) cg_vals = new(); endfunction // Function: sample_values // virtual function void sample_values(); super.sample_values(); if (get_coverage(UVM_CVR_FIELD_VALS)) cg_vals.sample(); endfunction // Function: build // virtual function void build(); RESERVED_QSR_07_31 = uvm_reg_field::type_id::create("RESERVED_QSR_07_31"); ctl_pnld2_val = uvm_reg_field::type_id::create("ctl_pnld2_val"); RESERVED_QSR_07_31.configure(this, 1, 31, "RO", 0, 1'b0, 1, 0, 0); ctl_pnld2_val.configure(this, 31, 0, "RW", 0, 31'b0000000000000000000000000000000, 1, 1, 0); endfunction endclass
  2. Hi, I've looked at the IP-XACT list of published busses (802.3, etc.). I have some questions: 1) they are for version 1.2; could they please be updated to the current IP-XACT standard? 2) there are number of missing busses; it would be very useful even if all that was present were port-names for the missing busses, so that at least in the future people would use the same naming for the same pins. Are there any plans for adding more busses? 3) Will they become officially released parts of IP-XACT, or just semi-official? 4) there is no documentation with them, so I don't know how complete or stable or accurate they are. Could this please be added? Thanks! Erik Jessen
  3. Uwe, Many thanks! #1: already working on it. #2: this is my plan once #1 is done. #3: We have multiple simulator licences and multiple vendor hardware accelerators. So a vendor-specific DB won't work. #4: this was discarded as the data-structures in the transactions are highly variable - much easier to output XML #5: Haven't looked at UVM1.2 yet, as company is still using UVM 1.0. Thanks for the tip! #6: thanks - I'll go take a look, but because we use multiple simulators, I'd need something that works on all simulators. #7: Yes, that is one of the things I've been mapping out; I've downloaded the OCP/IP to see what they have done for vendor-specific IP-XACT schema for busses. #8: Again - we use multiple simulators. Erik
  4. Uwe, You are quite sure that you know what I am saying and what technical problems I'm dealing with. However, I'm quite sure that you don't. So - are you open to the possibility that you don't yet understand what I am saying (and we should keep talking), or should we just end the discussion? Erik
  5. nbjessen

    Complex register description

    Hi, where could I find the plans to merge SystemRDL with IP-XACT?
  6. Uwe, my goal is to only do the post-processing if a failure occurs, so that the simulator licenses are available as much as possible. Also, we have a highly parallel processing architecture, so the problem is not "did we get an unexpected output", but being able to track backwards to watch the data propagate through the design. Also - while some corporate cultures are quite advanced on their uses of debug techniques and tools, not all are. Also there are times when the vendor tools are not stable. In my particular case, I pretty much could guarantee a core-dump if I did anything other than waveform dump and text processing - I was never able to identify in my very large design exactly what caused even turning on break points (but not even using them) to cause everything to crash. Even in post-processing, just source-code browsing caused the entire simulator GUI to crash. Also, in my case each sequence-item has 2 or 3 levels of linked-lists of objects in them, and some words have up to 8 possible interpretations. I can't even use the `uvm_fields for debug because the simulator crashes on me, reporting that I've exceeded the string-expansion limit. So I have both problems with UVM and with vendor tools. But I trust text output. And one the text output is in a standard format, I have a lot more options for post-processing. Erik
  7. David - yes, I was envisioning a single standard output for all transactions/sequence-items, so that things could be compared. Ideally we would have standard, reusable classes for various interface standards (XGMII, SPI, PCIe, etc.) Here's why I would like to use SQL up-front (if only for planning): it will force users to decide how they can track traffic - what will they use for keys to uniquely identify each transaction? I have observed lots of cases where one simply can't tell which output was generated by which input - there's just no way to tell. And in one case, it turned out that we had false-passes; the input just *happened* to align the stars so that two outputs looked like a pass, but really its because we had double-bugs cancelling each other out. It wasn't until system sim that we found we had inputs -> outputs swapping around in a corner case. If we'd changed the RTL to having a tracking tag, we could have easily caught the problem much earlier. And of course if this went into production it'd have been almost impossible to debug. I also like the SQL upfront - because it's a LOT easier upfront to ensure all that data can be tracked, than to go back later and realize that you could track the data in *almost* all of the time. But that *almost* meant that you had to do either incredibly complex analysis to get to 100%-sure, or you had to do 'best guess' after a lot of analysis. Both are extremely costly for what's really a trivial amount of upfront work.
  8. IP-XACT has a standard method for capturing register information. Including coping with having one field determine how to parse other fields in other registers. UVM seq-items have `uvm_fields, but these have some problems, including: 1) in large seq-items, hitting maximum macro length in chars - this requires removing fields or options or whitespace. 2) It appears that the `uvm fields consume runtime every time an object is created. 3) no way to go from human-readable documentation to a list of registers with clear pack/unpack. I would like to propose vendor extensions in IP-XACT for UVM seq-items, so that: 1) human-readable documentation can be generated. 2) source-code can be generated for packing/unpacking seq-items (C, SV, SV+UVM, Python, and lab-debug tools) 3) functional-coverage requirements could be captured in IP-XACT and functional-coverage code could be generated 4) requirements could be captured and then output could be generated into formats suitable for a) Formal verification simulation-based assertions c) post-processing and analyzing data collected in the lab. 5) UVM agents/monitors could be generated. Given that this is a 'green-fields' situation there is no reason why IP-XACT vendor extensions could not fully support all concepts in UVM in a user-friendly manner. This would also close a gap in IP-XACT, so that it is easier for IP-vendors to completely document how they generate (or expect) traffic, so users can verify pre-purchase if the IPs are compatible.
  9. Debug is extremely difficult to do in large, constrained-random simulations. 1) Even if there is large amounts of data available (such as UVM seq-item dumps), it is extremely slow to analyze the standard text outputs, and requires lots of script writing for each new bug 2) There are times when multiple streams of different sequence-items must be parsed in order to put the suspect sequence-item into context. I would like to propose adding another UVM output format: XML Then standard XML report-writers could be used to analyze the multiple output streams and generate statistics or identify possible failures or the failures themselves. I would then to also like to propose loading that data into SQL databases for more complicated analysis and creation of standard reports. Erik Jessen