IMPLEMENTATION OF LOW POWER INTERFACE FOR VERIFICATION IP (VIP) OF AXI4 PROTOCOL

e-issn 2455 1392 Volume 2 Issue 8, August 2016 pp. 1 8 Scientific Journal Impact Factor : 3.468 http://www.ijcter.com IMPLEMENTATION OF LOW POWER INTERFACE FOR VERIFICATION IP (VIP) OF AXI4 PROTOCOL Bhavana B M 1, Ajaykumar D 2 1,2 BMS College of Engineering Abstract The ARM AMBA protocols are an open standard, on-chip interconnect specification for the connection and management of functional blocks in a System-on-Chip (SoC). AMBA buses support the efficient connection of processors, on chip memories and off chip external memory interfaces. APB, AHB, AXI, ACE are few of the ARM AMBA protocols. As the number of protocols and their complexity has increased, the demands on verification engineers to achieve productive verification and debug has also increased. The verification of the SoC bus interconnects faces the challenge of verifying the correct routing of transactions as well as security and protection modes, power management features, virtual address space and bus protocol translations while still reaching project milestones. Verification IP (VIP) blocks are inserted into the testbench for a design to check the operation of protocols and interfaces. The role of Verification intellectual property (VIP) has become increasingly important over recent years as a vital component in achieving SoC verification productivity and is now established as an essential part of any verification solution. This paper is focused on implementation of low power interface for VIP of AXI4 protocol. The AXI low-power interface provides control signals for entry into and exit from a low-power state. It allows the supported peripherals to work either in the low power mode or active mode. Through simulation waveforms and assertions the entry and exit of the AXI slave into the low power state is verified. Keywords AMBA protocols, System on chip, AXI, APB, Low power interface I. INTRODUCTION A system on chip (SoC or SOC) is an integrated circuit (IC) that integrates all components of a computer or other electronic system into a single chip. It may contain digital, analog, mixed-signal, and often radio-frequency functions. SoCs are very common in the mobile electronics market because of their low power consumption. A typical application is in the area of embedded systems. A typical SoC consists of: A microcontroller, microprocessor or digital signal processor (DSP) core multiprocessor SoCs (MPSoC) having more than one processor core Memory blocks including a selection of ROM, RAM, EEPROM and flash memory Timing sources including oscillators and phase-locked loops Peripherals including counter-timers, real-time timers and power-on reset generators External interfaces, including industry standards such as USB, FireWire, Ethernet, USART, SPI Analog interfaces including ADCs and DACs Voltage regulators and power management circuits A bus either proprietary or industry-standard connects these blocks. The ARM AMBA protocols are an open standard, on-chip interconnect specification for the connection and management of functional blocks in a System-on-Chip (SoC). It facilitates right-first-time development of multiprocessor designs with large numbers of controllers and peripherals. APB, AHB, AXI, ACE are few @IJCTER-2016, All rights Reserved 1

of the ARM AMBA protocols. With its ACE, AXI, AHB and APB interface protocols, AMBA 4 has the flexibility to match every requirement. It is a standard interface specification that ensures compatibility between IP components from different design teams or vendors. The wide adoption of AMBA specifications throughout the semiconductor industry has driven a comprehensive market in third party IP products and tools to support the development of AMBA based systems. As the number of protocols and their complexity has increased, the demands on verification engineers to achieve productive verification and debug has also increased. Verification IP (VIP) blocks is inserted into the testbench for a design to check the operation of protocols and interfaces. The role of Verification intellectual property (VIP) has become increasingly important over recent years as a vital component in achieving SoC verification productivity and is now established as an essential part of any verification solution. Typical applications of SoC are consumer devices, networking communications and other segments of the electronic industry (microprocessor, media processor, GPS controllers, cellular phones, GSM phones, smart pager ASICs, digital television, video games, PC-on-a-chip). II. PROBLEM DEFINITION The SoC consists of one or more embedded processors, on-chip memory, off-chip memory, different IPs (USB, PCI, MAC etc) and interconnect which connects all these components using standard interfaces such as AXI, AHB etc. The designers integrate inhouse IPs with third party IPs into the SoC to significantly reduce design cycles. Since multiple IPs from various vendors is integrated into SoC, verification of this becomes a challenge. By using Verification IPs the system on chip designs can be verified faster, more thoroughly and with less effort. III. 3.1 Proposed Solution: METHODOLOGY AND IMPLEMENTATION Verification IP (VIP) is a verification component that is used to verify the industry standard protocols, such as USB, Ethernet, AMBA, etc. which are used in systems on chips (SoCs). VIP reduces verification cost and time for SoC verification which intern reduces the time to market. VIP typically includes monitors, checkers, coverage, test-plans, example tests, assertions and protocolcentric sequences. Reusable commercial VIP enables customers to focus their verification effort on verifying the design instead of creating, validating and supporting VIP; it also gives them a robust protocol model that has been used widely and proven across many designs. Verification IP saves months of effort from a verification project and instils confidence that the interfaces are working as expected. The aim of the paper is to develop the low power interface supported by the AXI protocol. The AXI low-power interface provides control during entry into and exit from a low-power state. It allows the supported peripherals to work either in the low power mode or active mode. The peripheral can enter low power state with the help of power down sequence. If the peripheral has no power down sequence then it can indicate the low power interface to turn off its clock. If the peripheral has a power down sequence it requires an indication from the low power interface to indicate when to initiate the power down sequence and the clock it turned off only after this request is acknowledged and the peripheral enters a low power state. 3.2 AXI Low-power interface: The low-power interface is an optional extension to the AXI protocol that targets two different classes of peripherals: @IJCTER-2016, All rights Reserved 2

Any peripheral that has no power-down sequence and that can indicate when its clocks can be turned off. Any peripheral that requires a power-down sequence, and can have its clocks turned off only after it enters a low-power state. The peripheral requires an indication from a system clock controller to indicate when to initiate the power-down sequence, and must then signal when it has entered its low-power state. The low-power clock control interface consists of the following signals: A signal from the peripheral indicating when its clocks can be enabled or disabled Two handshake signals for the system clock controller to request exit or entry into a lowpower state. The CACTIVE signal indicates whether the peripheral requires a clock signal. The peripheral asserts CACTIVE HIGH when it requires the clock to be enabled, and the system clock controller must enable the clock immediately. The peripheral deasserts CACTIVE to indicate that it does not require the clock. The system clock controller can then disable the clock, but is not required to do so. CSYSREQ: The system clock controller uses the CSYSREQ signal to request: The peripheral enters a low-power state. The system clock controller drives the CSYSREQ signal LOW to initiate the request. The peripheral exits a low-power state. The system clock controller drives the CSYSREQ signal HIGH to initiate the request. CSYSACK: The peripheral uses the CSYSACK signal to acknowledge: The request to enter the low-power state. It drives CSYSACK LOW when it recognizes this request. The request to exit from low-power state. It drives CSYSACK HIGH when it recognizes this request. 3.2.1 Acceptance of low-power request: Figure 1: Acceptance of low-power request At T1 the system clock controller drives CSYSREQ LOW to request the peripheral to enter lowpower state. After the peripheral recognizes the request, it performs its power-down sequence and at T2 it drives CACTIVE LOW, to signal that the clock can be removed. Then at T3, the peripheral drives CSYSACK LOW to signal that it has completed its entry into low-power state. The peripheral must not drive CSYSACK LOW until at least one cycle after it drives CACTIVE LOW. 3.2.2 Denial of low-power request: @IJCTER-2016, All rights Reserved 3

Figure 2: Denial of low-power request At T1 the system clock controller drives CSYSREQ LOW to request the peripheral to enter lowpower state. At T2, the peripheral acknowledges the low-power request by driving CSYSACK LOW but denies the request by holding CACTIVE HIGH. The system clock controller must maintain the clock, and must go through the low-power state exit sequence before it can initiate another lowpower request. At T3, the system clock controller begins the low-power state exit sequence by driving CSYSREQ HIGH. At T4 the peripheral completes the exit sequence by driving CSYSACK HIGH. 3.2.3 Exiting a low-power state: Either the system clock controller or the peripheral can request exit from a low-power state. The protocol requires both CACTIVE and CSYSREQ are LOW during the low-power state, and driving either of these signals HIGH initiates the exit sequence. Figure 3: system clock controller initiated exit from low-power state Figure 4: Peripheral initiated exit from low-power state @IJCTER-2016, All rights Reserved 4

3.3 Testbench Architecture: Figure 5: Testbench It contains AXI master, DUT, APB master and power controller. The AXI master is implemented in UVM. It issues the read and write instructions to the DUT (AXI slave) through the AXI interface. The APB master is implemented using UVM register layer classes and power controller is APB slave. When a value 32'h00000001 is written into a low power register of APB slave from APB master environment, APB slave drives the AXI slave into low power state by turning off its clock. When any other value is written into the APB register, the APB slave drives the AXI slave out of the low power state by turning on its clock. 3.3.1 AXI master and slave: Top module: The top module instantiates the DUT, test class and interface. Clock and reset signals are generated. The interface is configured using the uvm_config_db::set() macro. Run_test() method is called to initiate the run_phase of test class. AXI Test: The test class instantiates the AXI environment and creates them using the new() method in the build phase. In the run phase, the stimulus is applied by invoking the sequences to the DUT. AXI environment: The environment class instantiates the AXI agent and creates it using UVM factory. In the start of simulation phase uvm_top.print_topology is used to print the components of the testbench. AXI agent: The AXI agent class instantiates the AXI driver and AXI sequencer and creates them using UVM factory. In the connect phase the seq_item_port of the driver is connected to the seq_item_export of the sequencer. AXI Sequencer: The sequencer controls the flow of sequence items generated by sequences. AXI Transaction: The AXI signals such as rw, id, addr, len, size, data etc are declared as rand bits and constraints are applied. AXI Sequence: The required stimulus is generated and sent to the sequencer. Sequences for read and write, fixed burst transactions are written. @IJCTER-2016, All rights Reserved 5

AXI driver: In the build phase, the AXI interface is obtained using uvm_config_db::get() macro. In the run phase, the tasks reset, get and drive, sent_addr_write_trx(), sent_data_write_trx(), received_resp_write_trx(), sent_addr_read_trx(), received_data_read_trx() have been called simultaneously using fork join statement.in the reset task all the interface signals are set to 0. In get and drive task the transaction is obtained from the sequencer and depending on rw signal the transaction is put into a write queue or read queue. This process is repeated inside a forever loop.the sent_addr_write_trx(), sent_data_write_trx(), received_resp_write_trx(), sent_addr_read_trx(), received_data_read_trx() tasks are coded according to the AXI protocol and are executed forever. Interface: It contains all the signals and connects the DUT and testbench. DUT AXI slave: The slave receives the signals from the interface. It contains two state machines to implement the read and write transactions. It returns back the response to the interface. 3.3.2 APB RAL (register access layer) model: It is a power controller. It contains the APB master and slave. Top module: The top module instantiates the DUT, test class and interface. The interface is configured using the uvm_config_db::set() macro. Run_test() method is called to initiate the run_phase of test class. APB test: The reg block, sequencer and driver are created in build phase. In the connect phase the driver and sequencer are connected through seq_item_port.connect(), adapter is created and it is connected to sequencer using default address map defined in the reg block. In the run phase sequence is created and sequence is started on bus sequencer. APB registers: Fields of the registers are created and configured for read write field access policy. Each of the registers is assigned with a fixed address. APB register block: Two registers are built and configured. These registers are added to the default address map using add_reg() function. APB adapter: It has two inbuilt functions: bus2reg and reg2us. The reg2bus function copies the transactions from the registers to the bus and sends it to the sequencer using address map. The bus2reg copies the transactions from bus to registers. APB sequences: Read and write tasks on the registers of the register block are instantiated. APB Sequencer: The sequencer controls the flow of sequence items generated by sequences. APB Driver: Receives transactions from sequencer through seq_item_port.get() and applies it to DUT interface. Response received from the DUT interface is sent back to sequence using seq_item_port.put(). The signals are applied to the interface according to the protocol. Interface: It connects the DUT and the testbench DUT(APB slave): It is coded according to the protocol. The data is written into the registers for write operation and data is read from the registers for read operation. 3.3.3 Low power operation: The power controller is connected to AXI slave using the low power interface. Register R1 of the APB slave is considered as a low power register. When written with a value 32'h00000001 it sends a request to AXI slave to enter the low power states by driving the CSYSREQ signal low. The slave then acknowledges the request by driving the CSYSACK signal low. AXI slave also desserts CACTIVE signal to indicate that it does not require the clock. The power controller then disables the clock to the AXI slave. When a value other than 32'h00000001 is written into the register R1, the power controller requests the AXI slave to exit the low power states by driving CSYSREQ signal high. The slave @IJCTER-2016, All rights Reserved 6

acknowledges it by asserting CSYSACK signal. It also asserts CACTIVE signal to indicate that it requires clock to perform its operations. The power controller then enables the clock to AXI slave module. IV. RESULTS In the test class the AXI sequence and APB sequences are called simultaneously using fork and join statements. 1. Request to enter low-power state at 130ns Figure 6: Request to enter low-power 2. Request to exit low-power state at 360ns Figure 7: Request to exit low-power @IJCTER-2016, All rights Reserved 7

V. CONCLUSION The verification environment was developed in UVM. AXI master and slave for basic read-write transactions were implemented. It was tested for it s functionality through simulations. The power controller was designed. By writing into one of the register of power controller with the help of APB master, the DUT was controlled to enter and exit the low power state. The DUT here has no power down sequence and will always respond to the request sent from the power controller. Simulations and assertions were used to verify the low power operation of the DUT. REFERENCES [1] Pradeep SR; Lakshmi C, Design and verification environment for AMBA AXI protocol for SOC integration, International journal of research in engineering and technology.eissn 2319-1163. [2] MayankRai Nigam; Mrs.ShivangiBande, AXI interconnect with four masters and four slaves, International journal of engineering research and general science,volume 2 issue 4, June-July 2014 ISSN 2091-2730 [3] Shaila S math; Manjula B R, Design of AMBA AXI protocol for system on chip communication, International journal of communication network and security, volume 1 issue 3, ISSN: 2231-1882. [4] Golla Mahesh; Sakthivel.S.M, Verification IP for an AMBA-AXI Protocol using System Verilog, International journal of Engineering Research and General Science, volume 3, issue 1, January-February 2015, ISSN 2091-2730 [5] AMBA AXI protocol specifications, ARM, Version IHI 0022B [6] AMBA APB protocol specifications, ARM, Version IHI 0024B [7] Universal Verification Methodology (UVM) 1.2 User's guide, Accellera, October 8, 2015. @IJCTER-2016, All rights Reserved 8