Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


amitshere last won the day on January 12 2016

amitshere had the most liked content!

About amitshere

  • Rank
    Junior Member
  1. Are you generating your register Model from RALF using ralgen? Have you provided the 'hdl paths' in the RALF specification? If not , you would have to do that. The user documentation in VCS "UVM Register Abstraction Layer Generator User Guide" has the details in the chapter: "Generated Backdoors"
  2. given that the backdoor access is anyways completed in zero time, and it updates/gives you the values of only the specific field depending on whether you are doing a field.write()/field.read(), you don't need an explicit individual field access
  3. You can't have a UVM_NO_CHECK for a 'RO' field.. You would want to check that a WRITE to the field actually doesn't take effect.. This can be validated when you do a READ,
  4. I am sure there are multiple tools by different vendors which help to generate UVM REG SV models from IPXACT... ralgen which ships with VCS also would help you generate UVM REG models from IPXACt
  5. you can lookup up the AXI UVM RAL examples at https://solvnet.synopsys.com/retrieve/033407.html if you have Synopsys Solvnet access
  6. if you are using RALF, you can add the constraints in the Input specifications (RALF itself), add constraints for the 'value' of different fields.. IPXACT1.5 also allows you to add constraints You can also add inline constraints while randomizing individual fields, registers.. eg:model.regname.randomize() with ...
  7. Sean, If a field occupies 2 byte lanes, you can perform a halfword access through a fld.write().. Otherwise, you will have to do a register.write()/update() but manually override the byte_enable property in the adapter.. for the adapter to understand when to override, it can query the extension argument.. see http://www.uvmworld.org/forums/showthread.php?489-uvm_reg-read()-and-write()-documentation
  8. You need to set the "supports_byte_enable" in extensions of uvm_reg_adapter if the bus protocol supports byte enables.
  9. This is how you can code this: pseudo code: Then in your TB code, In the Adapter
  10. In your virtual sequence, you will need to create the sequence using uvm_create() then make the appropriate regmodel assignment and then start the sequence using seq.start()
  11. You can do a get_item() in the adapter to get bus-independent read/write information (uvm_reg_item) that corresponds to the generic bus transaction currently translated to a bus-specific transaction.. The 'extension' will be available via that reference and then you can use that information to be used appropriately in the adapter
  12. The adapter should translate it to a burst-write protocol-specific transaction whenever it sees a UVM_BURST_READ/WRITE If the protocol does not support burst operations, you would have to use the layering approach and execute it in terms of individual transactions.
  13. Yes, I guess it should have gone to the documentation; But again I wouldn't think that the adapter would need to do anything different for a UVM_BURST_WRITE vis-a-vis a UVM_WRITE.. I Whenever you have a mem.burst_write(), the base class infrastructure ensures that as many regular writes that are required are scheduled.. The Adapter would know that the current transaction would be part of a memory burst.. It might addtionally want to set specific properties in the host transaction item..
  14. Are you sure you didn't call a mem.burst_write(...) anywhere in the code
  • Create New...