Jump to content

balasubramanian.g@pmcs.com

Members
  • Content Count

    13
  • Joined

  • Last visited

About balasubramanian.g@pmcs.com

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Location
    Bangalore, India

Recent Profile Visitors

325 profile views
  1. balasubramanian.g@pmcs.com

    Setting different hdlpaths to READ/WRITE access in UVM

    Hi Uwe Thanks for your reply. Very much appreciated. Let me work on the same and will get back to you with few more questions. Best regards Balasubramanian G
  2. Hi there A register can have different RTL implementation based on access_mode. ie., When a register REG_1 is read in backdoor, actual HDLPATH of the register would point to 'top.abc.dout'. When a register REG_1 is written in backdoor, actual HDLPATH of the register would point to 'top.abc.dout_temp' We want to program different hdlpaths to REG_1 based on access mode (READ or WRITE). Does UVM_REG provide ready-made hookups or methods like add_hdl_path_slice() methods to setup different hdlpaths to READ/WRITE backdoor access? (Inside the DPI based backdoor access itself?) I checked that write_backdoor and read_backdoor methods need to be overwritten to setup different HDLPATHs based on READ/WRITE access modes. But this involves overriding string based DPI backdoor access factory methods. I'm looking for an alternative here, if it really exists. Suggestions to this requirement, very much appreciated. Best regards Balasubramanian G
  3. balasubramanian.g@pmcs.com

    how do we sort the UVM_REG space based on address?

    Hi Uwe/Tudor I used the get_offset() method to iterate through the registers and sort it based on offset. Thanks for your timely responses. Best regards Balasubramanian G
  4. balasubramanian.g@pmcs.com

    Difference between configure and add_hdl_path() methods

    Euphemia, Thanks for your reply. My idea is to append newer paths at higher levels of reuse hierarchy. Somehow, configure() does not allow me to prepend() hdlpaths. As per my testing, add_hdl_path() method seems to work in same as well as different hierarchy. (I don't know what is the correct way to implement this)
  5. Hi there We want to traverse through all registers present in a UVM_REG_BLOCK based on increasing address. We have the following pseudocode: model.NTB_DB.get_registers(total_regs_ntb); foreach (total_regs_ntb) begin total_regs_btb.write(status, wdata, .parent(this)); end But, the above source code does not go through the registers space based on address. ie., When I have a 2-dimensional array of registers, array indices are chosen first(not addresses). Any help to workaround this problem is appreciated. Best regards Balasubramanian G
  6. balasubramanian.g@pmcs.com

    Array of registers

    Hi Rahul, This is how we modelled this scenario: <spirit:register> <spirit:name>REG_A</spirit:name> <spirit:addressOffset>0x0</spirit:addressOffset> <spirit:size>32</spirit:size> <spirit:field> <spirit:name>FIELD_A</spirit:name> <spirit:bitOffset>0</spirit:bitOffset> <spirit:bitWidth>32</spirit:bitWidth> <spirit:access>read-write</spirit:access> </spirit:field> <spirit:vendorExtensions> <vendorExtensions:array xmlns:vendorExtensions="http://www.spiritconsortium.org/XMLSchema/SPIRIT/1.5"> <vendorExtensions:x_from>0</vendorExtensions:x_from> <vendorExtensions:x_to>31</vendorExtensions:x_to> <vendorExtensions:offset_calc>0x0 + ( x * 16 )</vendorExtensions:offset_calc> </vendorExtensions:array> </spirit:vendorExtensions> </spirit:register> vendorExtensions helps us to capture the array of registers inside an existing address space or register file. This approach does not need a new register file inside your address_block.
  7. balasubramanian.g@pmcs.com

    Can we perform UVM_REG read/write access based on Address?

    Thanks Tudor/Uwe, get_reg_by_offset and get_reg_by_name methods aids in accessing registers based on address. We see benefit in accessing registers by name as well as address. Writing workaround source code to compute a register address using get_reg_by_offset and get_reg_by_name methods and exception handling cases manually looks tedious. This could well be handled inside UVM package itself. It would save user efforts to perform the calculation and manupulation in user environment. 'Register read using address' is an ease of use method/feature which can be easily enhanced in UVM package itself. (If this cannot be implemented, that's fine, a workaround exists, atleast) Best regards Balasubramanian G
  8. Hi there From the UVM users guide, a register read access can be executed as reg_model.BLK1.REG_FILE1.REG_1.read(status, rdata); But this mandates us to know the hierarchy of the register instantiation. ie., 'reg_model.BLK1.REG_FILE1' needs to be known to execute a read on register 'REG_1'. Is it possible to perform read/write access based on address instead of this hierarchy? Something like: generic_uvm_read (.address(0x0), rdata); In otherwords, we need not even know the register type or register instantiation hierarchy to issue a read access to that register. Can this be performed with UVM_REG? Requesting thoughts here. Best regards Balasubramanian G
  9. Hi there I couldn't find enough information about capturing whitebox information with respect to a register defined in IP-XACT standard. Could this be done somehow? The closest that could be found was WHITEBOX information with respect to models.(not registers) Though the register definition can be captured in IP-XACT XML, there isn't proper way to capture RTL implementation of a register in IP-XACT. Capturing RTL implementation of a register in IP-XACT XML would enable us to stitch UVM_REG backdoor access. (without vendorExtensions) We feel the urge/need to enhance IP-XACT standard regarding the same. Requesting thoughts regarding the same. Best regards Balasubramanian G
  10. balasubramanian.g@pmcs.com

    Complex register description

    We also found that SystemRDL is not supported by Cadence toolsets. Need for accellera to merge systemRDL into IP-XACT standard.
  11. balasubramanian.g@pmcs.com

    Capturing register array information inside IPXACT XML

    Hi Richard Thanks for your response. We have SoC designs where 2-dimensional arrays are implemented. The 2-dimensional arrays have two types of 'stride' values in them. 1st stride tries to increment address of the first dimension (consider this as COLUMN) 2nd stride tries to increment address of the second dimension (consider this as ROW) Example: REG_1[0][0]->0x0 REG_1[0][1]->0x4 REG_1[0][2]->0x8 REG_2[1][0]->0x10 REG_2[1][0]->0x14 REG_2[1][0]->0x18 COLUMN stride (=0x4) and ROW stride (=0x10) values make sure that each array element gets unique address. (Though there may be gaps introduced in between them). SystemVerilog arrays are our motivation to map this RTL implementation into arrays. (IEEE 1800-2012) Best regards Balasubramanian G
  12. Hi there IPXACT needs to capture array of registers properly in a design. Currently there is only one tag ''spirit:dim" to represent an array of registers. This does not enable us to capture an array of register effectively. Consider the following cases: 1. An array of registers can be one dimensional with each element offset by offset address 0x10. 2. An Array of multidimensional registers something like this: register_1[0][0] -> 0x0 register_1[0][1] -> 0x4 register_1[1][0] -> 0x10 register_1[1][1] -> 0x14 ... likewise Is there any way to capture just the address relationship to an array instance within IP-XACT XML tags? (Without using vendorExtensions tag?) We have not been able to capture the above said information inside IPXACT XML.(using only IP-XACT tags) Requesting thoughts regarding the same. Best regards Balasubramanian G
  13. Hi there What is the difference between using uvm_reg_block::configure() method and uvm_reg_block::add_hdl_path() methods? These two methods seem to perform the same function with different inputs. ie., They both try to add prefix to the backdoor hdl_path to a UVM_REG_BLOCK. My requirement: A register block has been defined as follows: class BLOCK extends UVM_REG_BLOCK; (1st level inheritance) ... end class SAMPLE_BLOCK extends BLOCK; ... end SAMPLE_BLOCK has 2nd level inheritance with UVM_REG_BLOCK. I wanted to reprogram SAMPLE_BLOCK at different levels of verification hierarchy. Example: SAMPLE_BLOCK instance may be present at "top.abc" in block level verification. SAMPLE_BLOCK has been reused at "top.xxx.abc" in Larger IP level verification. SAMPLE_BLOCK has been reused at "top.yyy.xxx.abc" in Device or Top level verification. Please note that at each higher level hierarchy, new prefix gets added to the hdlpath. ie., 'xxx' gets prefixed in Larger IP level verification and 'yyy' gets prefixed in Device level verification. When I use the add_hdl_path() method, the hdlpath gets linked hierarchically. When I use the configure() method on SAMPLE_BLOCK, the hdlpath doesnot get linked hierarchically. Am I missing something here? What's wrong here? Could this be a bug in UVM_REG? Best regards Balasubramanian G
×