Jump to content

Search the Community

Showing results for tags 'BACKDOOR'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Accellera Systems Initiative
    • Information
    • Announcements
    • In the News
  • SystemC
    • SystemC Language
    • SystemC AMS (Analog/Mixed-Signal)
    • SystemC TLM (Transaction-level Modeling)
    • SystemC Verification (UVM-SystemC, SCV)
    • SystemC CCI Public Review
  • UVM (Universal Verification Methodology)
    • Methodology and BCL Forum
    • UVM SystemVerilog Discussions
    • Simulator Specific Issues
    • UVM Commercial Announcements
    • UVM 1.2 Public Review
  • Portable Stimulus
    • Portable Stimulus Discussion
    • IP-XACT Discussion
  • IEEE 1735/IP Encryption
    • IEEE 1735/IP Encryption Discussion
  • OCP (Open Core Protocol)
  • UCIS (Unified Coverage Interoperability Standard)
  • Commercial Announcements
    • Announcements


  • SystemC
  • UVM
  • UCIS
  • IEEE 1735/IP Encryption


  • Community Calendar

Found 7 results

  1. Hi, I'm trying to perform backdoor access to uvm_mem. For some reason, the Xcheck_accessX function in uvm_mem, override my map with pseudo map. From this function: rw.map = uvm_reg_map::backdoor(); From uvm_reg_map: // Function: backdoor // Return the backdoor pseudo-map singleton // // This pseudo-map is used to specify or configure the backdoor // instead of a real address map. // I need an important data from my map (the uvm_mem base address). why to override it? How can I overcome this? Thanks, Dror
  2. 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
  3. 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
  4. Hi Guys, I am using UVM Register model to mimmick RTL's register implementation. Some registers are not implemented in RTL which are going to be connected to output port of some other module. I have got a HDL path of register as an output port declaration of some module. Something like: The HDL path is: "tb_top.dut_u.interrupt_module_u.o_ext_interrupt" o_ext_interrupt is declared as output port inside interrupt_module, which is not connected to any other wire or register. Can this output port's value be changed by writing to it via UVM BACKDOOR ? I am using following API: register_name.write(status,data,UVM_BACKDOOR,default_map); I dont see any change in value in the register. I think it is happening because the destination (o_ext_interrupt) is output of the module. I am using Cadence's simulator: irun. Please help if anyone is aware of such issue. Regards, Vismay.
  5. Hi all, There is one register model such as this: class R_r extends uvm_reg; uvm_reg_field vaule; ... endclass : R_r class A_R_file extends uvm_reg_file; R_r R; ... endclass : A_R_file class R_model extends uvm_reg_block; A_R_file R_f; ... endclass : R_model class my_r_seq extends uvm_reg_sequence; R_model regmodel; ... write_reg(regmodel.R_f.R, status, wdata); peek_reg (regmodel.R_f.R, status, rdata); ... endclass : my_r_seq R_r is write-only, when reading R_r via backdoor as above, VCS reports such an error. UVM_ERROR /EDA_Tools/synopsys/vcs1209/etc/uvm-1.1/uvm-1.1d/src/reg/uvm_reg_block.svh(2049) @ 406000: reporter [RegModel] Block does not have hdl path defined for abstraction 'RTL' UVM_ERROR: get: unable to locate hdl path R_f.R Either the name is incorrect, or you may not have PLI/ACC visibility to that name The VCS reports that "unable to locate hdl path", but I have used configure() function to configure the hdl path in class A_R_file and class R_model. Did anybody meet the issue?
  6. The issue I have is the register model has multiple registers of different names but the fields within the registers are named the same. The register model is generated by a tool so getting changes made will take some time and I need a work around. I have a lot of registers so this is a big problem. class reg_0 extends uvm_reg; rand uvm_reg_field x; rand uvm_reg_field y; ...... endclass class reg_1 extends uvm_reg; rand uvm_reg_field x; rand uvm_reg_field y; ...... endclass I need to be able to access the fields in my scoreboard. The problem is the field is not associated to the register so I can't simply call peek on x without associating it with the correct register. Is there a way to associate the register name with the field name and then call peek without hard coding the call to peek? I am using get_registers() and get_fields() to load my queues. Is there a way to get the registers and the fields for that register instead of one or the other? Perhaps I have missed something in the reference manual. reg_fields.peek(status,reg_field_data);
  7. Hi, Please help with an issue about backdoor read\write to a register. Is it going to be fixed? When doing backdoor write\read to a register – the code (uvm_reg) uses the default map instead of the map the user gave in the write\read register operation: A. do_write gets rw with the correct map that the user wanted – rw.map. B. When doing backdoor write (1 below) , XpredictX (3 below) is called with rw.local_map (=null). get_access with null map is actually default map. C. Even If XpredictX was called with rw.map – it should make many warnings no matter what is the default map\which map we gave the write. This is because in the do_write, Xcheck_accessX (2 below) is changing rw.map to “Backdoor” – empty map which doesn’t contain any regs. ------------------------------------------------------------------------------------------------------------------------- 1. task uvm_reg::do_write (uvm_reg_item rw); -> with the user specified map - rw.map … if (!Xcheck_accessX(rw,map_info,"write()")) (see Xcheck_accessX below ) return; … // EXECUTE WRITE... case (rw.path) // ...VIA USER BACKDOOR UVM_BACKDOOR: begin .. begin foreach (m_fields) begin uvm_reg_data_t field_val; int lsb = m_fields.get_lsb_pos(); int sz = m_fields.get_n_bits(); field_val = m_fields.XpredictX((rw.value[0] >> lsb) & ((1<<sz)-1), (value >> lsb) & ((1<<sz)-1), rw.local_map); -> local map is null – see XpredictX below …. endtask: do_write ------------------------------------------------------------------------------------------------------------------------------------ 2. function bit uvm_reg::Xcheck_accessX (input uvm_reg_item rw, ->with the user specified map output uvm_reg_map_info map_info, input string caller); … if (rw.path == UVM_BACKDOOR) begin if (get_backdoor() == null && !has_hdl_path()) begin `uvm_warning("RegModel", {"No backdoor access available for register '",get_full_name(), "' . Using frontdoor instead."}) rw.path = UVM_FRONTDOOR; end else rw.map = uvm_reg_map::backdoor(); -> rw map is changed to “Backdoor”, local map is not calculated (for FRONTDOOR it is – below) end if (rw.path != UVM_BACKDOOR) begin rw.local_map = get_local_map(rw.map,caller); … return 1; endfunction ------------------------------------------------------------------------------------------------------------- 3. function uvm_reg_data_t uvm_reg_field::XpredictX (uvm_reg_data_t cur_val, uvm_reg_data_t wr_val, uvm_reg_map map); -> map is null uvm_reg_data_t mask = ('b1 << m_size)-1; case (get_access(map)) -> get access is performed with null map = get access is performed without giving a map and it is using the default map instead of the map that the user specified in the write operation "RO": return cur_val; "RW": return wr_val; … -------------------------------------------------------------------------------------------------------------