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

636 profile views
  1. 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 ch
  3. 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. 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. 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
  7. 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 pac
  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.
  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
  10. We also found that SystemRDL is not supported by Cadence toolsets. Need for accellera to merge systemRDL into IP-XACT standard.
  11. 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 uniq
  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 jus
  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 verifica
×
×
  • Create New...