Jump to content


  • Content Count

  • Joined

  • Last visited

  1. 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_regi
  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
  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
  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. 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
  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
  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 f
  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 iden
  • Create New...