Jump to content

Search the Community

Showing results for tags 'APB'.

  • 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, CRAVE, FC4SC)
    • SystemC CCI (Configuration, Control & Inspection)
    • SystemC Datatypes
  • UVM (Universal Verification Methodology)
    • UVM (IEEE 1800.2) - Methodology and BCL Forum
    • UVM SystemVerilog Discussions
    • UVM Simulator Specific Issues
    • UVM Commercial Announcements
    • UVM (Pre-IEEE) Methodology and BCL Forum
  • Portable Stimulus
    • Portable Stimulus Discussion
    • Portable Stimulus 2.0 Public Review Feedback
  • IP Security
    • SA-EDI Standard Discussion
    • IP Security Assurance Whitepaper Discussion
    • IP-XACT Discussion
  • SystemRDL
    • SystemRDL Discussion
  • IEEE 1735/IP Encryption
    • IEEE 1735/IP Encryption Discussion
  • Commercial Announcements
    • Announcements


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

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL












Found 2 results

  1. Hello All, I have some doubts related to the relationship between PSEL and PENABLE signals in the APB Protocol. The specification informs that: The PENABLE signal is asserted the following clock after PSEL is asserted and de-asserted after a transfer takes place. I would like to understand about the following conditions: 1) Can PENABLE toggle while PSEL is de-asserted? 2) Can PENABLE be asserted in the IDLE and/or SETUP phase? 3) Can PSEL go log in to the SETUP phase? 4) What happens when PSEL is asserted high in the ACCESS phase and PENABLE is not de-asserted? Thanks
  2. In our DUT, we have two separate independent physical interfaces (APB & I2C) (active 1 at a time) through which all registers can can be accessed, Also in our register model, we created two reg_maps, one for each APB & I2C. Now through testcase, we want only one physical interface at a time, to be subjected to default uvm sequences (i.e. uvm_reg_access_seq, uvm_reg_bit_bash_seq,etc) but it is not possible as uvm_sequence will get all the maps using get_maps(); So without over-riding the default uvm_reg_access_seq, is it possible to achieve such type of configuration in testcase itself via using uvm_reg_map or some other methods. Kindly refer following pseudo code //Pseudo Code for Scenario class dut_reg_test extends base_test; `uvm_component_uti ls(dut_reg_test) //Handle of default uvm register access sequence uvm_reg_access_seq my_reg_seq; // Select Physical Interface rand bit APB_I2C; uvm_reg_map test_map; dut_reg_model regmodel; task buid_phase (uvm_phase phase); super.build_phase(phase); // Select PHY Interface via commandline if ($value$plusargs("APB_I2C=%b", APB_I2C)) else APB_I2C = $random; if (APB_I2C) test_map = regmodel.apb else test_map = regmodel.i2c endtask : build_phase task main_phase (uvm_phase phase); //Create method for sequence my_reg_seq=uvm_single_access_seq::type_id::create("my_reg_seq"); //Randomize with selected map my_reg_seq.randomize with { maps == test_map;}); // Start default sequence my_reg_seq.start(NULL); endtask : main_phase endclass : dut_reg_test The above strategy cannot be implemented because uvm_reg_access sequence doesn't contain uvm_reg_map it's only present in uvm_reg_single_access_seq, Similar kind of limitations persists will all uvm_reg_bit_bash_seq & reset sequences. Can we have some strategy to resolve this issue ? Thanks Nikunj Hinsu
  • Create New...