Presented byB. Koteswar Rao

08G71D7005

Under the Guidence ofMr.B. Naresh Reddy M.Tech

Abstract

Bus-based system-on-chip (SoC) design becomes the major integration methods for shortening design cycle and time-to-market, thus how to verify IP functionality on bus protocol is a challenge. Traditional simulation-based bus protocol monitors can check bus signals obey bus protocol or not, but they often lack of efficient debugging mechanisms .We propose a rule-based bus protocol checker, it contains related bus protocol rules to check bus signal behavior, and two corresponding debugging mechanism to shorten debugging times. Error reference table can summarize design under tests (DUTs) have been violated; Windowed trace buffer can capture multiple errors’ history data that helps designer debug efficiently.

In recent years, on-chip bus architecture becomes the major integration method for implementing a SoC. On-chip bus specification provide a standard interface that enables IP’s to communicate with each other. Designer just integrates his own IPs with third party IPs into the system to significantly reduce design cycles.

System-on-a-chip or system on chip (SoC or SOC) refers to integrating all components of a computer or other electronic system into a single integrated circuit(chip).

These IP’s functionality can be verified based on several formal verification methods. Formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain specification or property, using formal methods of mathematics.

AMBA

The Advanced Microcontroller Bus Architecture (AMBA) specification defines an on-chip communications standard for designing high-performance embedded microcontrollers. Three distinct buses are defined within the AMBA specification: •the Advanced High-performance Bus (AHB)•the Advanced System Bus (ASB)•the Advanced Peripheral Bus (APB).

The AMBA AHB is for high-performance, high clock frequency system modules. AHB supports the efficient connection of processors, on-chip memories and off-chip external memory interfaces. AHB is also specified to ensure ease of use in an efficient design flow using synthesis and automated test techniques.

The AMBA ASB is for high-performance system modules.AMBA ASB is an alternative system bus suitable for use where the high-performance features of AHB are not required. ASB also supports the efficient connection of processors, on-chip memories and off-chip external memory interfaces.

The AMBA APB is for low-power peripherals.AMBA APB is optimized for minimal power consumption and reduced interface complexity to support peripheral functions. APB can be used in conjunction with either version of the system bus.

AHB master : A bus master is able to initiate read and write operations by providing an address and control information. Only one bus master is allowed to actively use the bus at any one time.

AHB slave : A bus slave responds to a read or write operation within a given address-space range. The bus slave signals back to the active master the success, failure or waiting of the data transfer.

AHB arbiter : The bus arbiter ensures that only one bus master at a time is allowed to initiate data transfers. Even though the arbitration protocol is fixed, any arbitration algorithm, such as highest priority or fair access can be implemented depending on the application requirements. An AHB would include only one arbiter.

AHB decoder : The AHB decoder is used to decode the address of each transfer and provide a select signal for the slave that is involved in the Transfer. A single centralized decoder is required in all AHB implementations.

AHB PROTOCOL CHECKER ARCHITECTURE

Main function blocks: 1)Protocol Checker

2) Configuration Registers

3) ERROR Reference Table

4) Windowed Trace Buffer

Protocol Checker is the main core of High performance protocol, the inputs are all AHB bus signals, and the outputs are 73-bit ERROR signals and corresponding master and slave IDs.

Every rule has its own corresponded bit because every cycle maybe occur more than one error. If the i bit of ERROR is set, which indicates current bus signals violate i rule.

The Master/Slave ID is formed by the HMASTER signal. If an error occurs, the HPChecker will output the corresponded master ID number or slave ID number to indicate which master or slave violates the AHB protocol.

The configuration register can let the designer to set some parameters, including mask, protocol checker enable and max waiting cycle. The designer can base on the requirement of the system to mask some unnecessary rule checked.

The enable bit can enable or disable the HPChecker. For example, if we integrate one master IP into pre-verified AHB platform, we just need to check master-related rules and disable all other rules. If we modified an arbiter, we only need to check arbiter related rules.

The max waiting cycle is set by the designer to check the HREADY max waiting cycle.

Traditional protocol checkers will assert error signals or a printout error message for every error occurs, but this way is very inefficiently for early debugging in long simulation period.

In early debugging period, there may have many errors, especially when test bench or real case application has very long execution time. Such large amount of log messages or error signals waveform could help designer to debug limitedly, because that will be hard to read or analyze.

Moreover, we do not care about the timing information when error occurred in most case. Thus we provide an error reference table that can summarize what errors have been occurred.