08-09-2016, 11:57 AM
[attachment=70732]
INTRODUCTION
The On-Chip bus is an important system-on-chip (SoC) infrastructure that connects major hardware components. Monitoring the on-chip bus signals is crucial to the SoC debugging and performance analysis/optimization. Unfortunately, such signals are difficult to observe since they are deeply embedded in a SoC and there are often no sufficient I/O pins to access these signals. Therefore, a straightforward approach is to embed a bus tracer in SoC to capture the bus signal trace and store the trace in an on-chip storage such as the trace memory which could then be off loaded to outside world (the trace analyzer software) for analysis.
Unfortunately, the size of the bus trace grows rapidly. For example, to capture AMBA AHB 2.0 bus signals running at 200 MHz, the trace grows at 2 to 3 GB/s. Therefore, it is highly desirable to compress the trace on the fly in order to reduce the trace size. However, simply capturing / compressing bus signals is not sufficient for SoC debugging and analysis, since the debugging / analysis needs are versatile: some designers need all signals at cycle-level, while some others only care about the transactions. For the latter case, tracing all signals at cycle-level wastes a lot of trace memory. Thus, there must be a way to capture traces at different abstraction levels based on the specific debugging/analysis need.
1.1 Introduction to the AMBA Buses:
1.1.1 Overview of the AMBA specification:
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).
A test methodology is included with the AMBA specification which provides an infrastructure for modular macro-cell test and diagnostic access.
1.1.2 Advanced High-performance Bus (AHB):
The AMBA AHB is for high-performance, high clock frequency system modules. The AHB acts as the high-performance system backbone bus. AHB supports the efficient connection of processors, on-chip memories and off-chip external memory interfaces with low-power peripheral macro-cell functions. AHB is also specified to ensure ease of use in an efficient design flow using synthesis and automated test techniques.
1.1.3 Advanced System Bus (ASB):
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 with low-power peripheral macro-cell functions.
1.1.4 Advanced Peripheral Bus (APB):
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.
1.1.5 Objectives of the AMBA specification:
The AMBA specification has been derived to satisfy four key requirements:
• to facilitate the right-first-time development of embedded microcontroller
products with one or more CPUs or signal processors
• to be technology-independent and ensure that highly reusable peripheral and
system macro-cells can be migrated across a diverse range of IC processes and
be appropriate for full-custom, standard cell and gate array technologies
• to encourage modular system design to improve processor independence,
providing a development road-map for advanced cached CPU cores and the
development of peripheral libraries
• to minimize the silicon infrastructure required to support efficient on-chip and
off-chip communication for both operation and manufacturing test.
1.2 A Typical AMBA-Based Microcontroller:
An AMBA-based microcontroller typically consists of a high-performance system backbone bus (AMBA AHB or AMBA ASB), able to sustain the external memory bandwidth, on which the CPU, on-chip memory and other Direct Memory Access (DMA) devices reside. This bus provides a high-bandwidth interface between the elements that are involved in the majority of transfers. Also located on the high-performance bus is a bridge to the lower bandwidth APB, where most of the peripheral devices in the system are located.
AMBA APB provides the basic peripheral macro-cell communications infrastructure as a secondary bus from the higher bandwidth pipelined main system bus. Such peripherals typically:
• have interfaces which are memory-mapped registers
• have no high-bandwidth interfaces
• are accessed under programmed control.
The external memory interface is application-specific and may only have a narrow data path, but may also support a test access mode which allows the internal AMBA AHB, ASB and APB modules to be tested in isolation with system-independent test sets.
1.3 Terminology:
The following terms are used throughout this specification.
1.3.1 Bus cycle :
A bus cycle is a basic unit of one bus clock period and for the purpose of AMBA AHB or APB protocol descriptions is defined from rising-edge to rising-edge transitions. An ASB bus cycle is defined from falling-edge to falling-edge transitions. Bus signal timing is referenced to the bus cycle clock.
1.3.2 Bus transfer:
An AMBA ASB or AHB bus transfer is a read or write operation of a data object, which may take one or more bus cycles. The bus transfer is terminated by a completion response from the addressed slave.
1.3.3 Burst operation:
A burst operation is defined as one or more data transactions, initiated by a bus master, which have a consistent width of transaction to an incremental region of address space. The increment step per transaction is determined by the width of transfer (byte, half-word, word). No burst operation is supported
on the APB.
A typical AMBA AHB system design contains the following components:
1.3.4 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.
1.3.5 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.
1.3.6 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.
1.3.7 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.
1.4 AMBA Signal Names:
All AMBA signals are named such that the first letter of the name indicates which bus the signal is associated with. A lower case n in the signal name indicates that the signal is active LOW, otherwise signal names are always all upper case.
1.4.1 AHB signal prefixes:
H indicates an AHB signal. For example, HREADY is the signal used to indicate that the data portion of an AHB transfer can complete. It is active HIGH.
1.4.2 ASB signal prefixes:
A - is a unidirectional signal between ASB bus masters and the arbiter
B - is an ASB signal
D - is a unidirectional ASB decoder signal.
For example, BnRES is the ASB reset signal. It is active LOW.
1.4.3 APB signal prefixes:
P indicates an APB signal.
For example, PCLK is the main clock used by the APB.
1.5 AMBA AHB signal list:
All signals are prefixed with the letter H, ensuring that the AHB signals are differentiated from other similarly named signals in a system design.
1.6.3 Transfer response:
A typical slave will use the HREADY signal to insert the appropriate number of wait states into the transfer and then the transfer will complete with HREADY HIGH and an OKAY response, which indicates the successful completion of the transfer.
The ERROR response is used by a slave to indicate some form of error condition with the associated transfer. Typically this is used for a protection error, such as an attempt to write to a read-only memory location.
The SPLIT and RETRY response combinations allow slaves to delay the completion of a transfer, but free up the bus for use by other masters. These response combinations are usually only required by slaves that have a high access latency and can make use of these response codes to ensure that other masters are not prevented from accessing the bus for long periods of time.
A full description of the SPLIT and RETRY operations can be found in Split and retry on page 3-24.
The encoding of HRESP[1:0], the transfer response signals, and a description of each response are shown in Table 3-5.
LITERATURE SURVEY
Since the huge trace size limits the trace depth in a trace memory, there are hardware approaches to compress the traces. The approaches can be divided into lossy and lossless trace compression.
The lossy trace compression approach achieves high compression ratio by sacrificing the accuracy; the original signals cannot be reconstructed from the trace. The purpose of this approach is to identify if a problem occurs. Anis and Nicolici [2] use the multiple input signature register (MISR) to perform lossy compression. The results are stored in a trace memory and compared with the golden patterns to locate the range of the erroneous signals. The locating needs rerunning the system several times with finer and finer resolution until the size of the search range can fit in the trace memory. Such approach is suitable for deterministic and repeatable system behaviors. However, for a complex SoC with multiple independent IPs, the on-chip bus activities are usually not deterministic and repeatable. Therefore, lossless compression approaches are more appropriate for real-time on-chip bus tracing.
2.1 AHB Trace Macro-cell (HTM):
The HTM provides address and data trace information about AHB buses. The information from an HTM can be used with the debugger to enable easy, accurate debugging on AHB-based embedded systems. The HTM provides extensive resources for event recognition to generate trigger events. The HTM generates trace data for output through the AMBA Trace Bus (ATB). The trace debug function is non-intrusive and HTM can be controlled using an APB (AMBA v3) interface.
The trace operation indicates the data transfers that have taken place to defined memory locations or regions. Other AMBA control information can also be included. However, other operations like IDLE cycles and BUSY cycles in AHB are not traced.
The HTM is an Advanced Microcontroller Bus Architecture (AMBA) compliant System-on-Chip (SoC) debug component.
INTRODUCTION
The On-Chip bus is an important system-on-chip (SoC) infrastructure that connects major hardware components. Monitoring the on-chip bus signals is crucial to the SoC debugging and performance analysis/optimization. Unfortunately, such signals are difficult to observe since they are deeply embedded in a SoC and there are often no sufficient I/O pins to access these signals. Therefore, a straightforward approach is to embed a bus tracer in SoC to capture the bus signal trace and store the trace in an on-chip storage such as the trace memory which could then be off loaded to outside world (the trace analyzer software) for analysis.
Unfortunately, the size of the bus trace grows rapidly. For example, to capture AMBA AHB 2.0 bus signals running at 200 MHz, the trace grows at 2 to 3 GB/s. Therefore, it is highly desirable to compress the trace on the fly in order to reduce the trace size. However, simply capturing / compressing bus signals is not sufficient for SoC debugging and analysis, since the debugging / analysis needs are versatile: some designers need all signals at cycle-level, while some others only care about the transactions. For the latter case, tracing all signals at cycle-level wastes a lot of trace memory. Thus, there must be a way to capture traces at different abstraction levels based on the specific debugging/analysis need.
1.1 Introduction to the AMBA Buses:
1.1.1 Overview of the AMBA specification:
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).
A test methodology is included with the AMBA specification which provides an infrastructure for modular macro-cell test and diagnostic access.
1.1.2 Advanced High-performance Bus (AHB):
The AMBA AHB is for high-performance, high clock frequency system modules. The AHB acts as the high-performance system backbone bus. AHB supports the efficient connection of processors, on-chip memories and off-chip external memory interfaces with low-power peripheral macro-cell functions. AHB is also specified to ensure ease of use in an efficient design flow using synthesis and automated test techniques.
1.1.3 Advanced System Bus (ASB):
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 with low-power peripheral macro-cell functions.
1.1.4 Advanced Peripheral Bus (APB):
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.
1.1.5 Objectives of the AMBA specification:
The AMBA specification has been derived to satisfy four key requirements:
• to facilitate the right-first-time development of embedded microcontroller
products with one or more CPUs or signal processors
• to be technology-independent and ensure that highly reusable peripheral and
system macro-cells can be migrated across a diverse range of IC processes and
be appropriate for full-custom, standard cell and gate array technologies
• to encourage modular system design to improve processor independence,
providing a development road-map for advanced cached CPU cores and the
development of peripheral libraries
• to minimize the silicon infrastructure required to support efficient on-chip and
off-chip communication for both operation and manufacturing test.
1.2 A Typical AMBA-Based Microcontroller:
An AMBA-based microcontroller typically consists of a high-performance system backbone bus (AMBA AHB or AMBA ASB), able to sustain the external memory bandwidth, on which the CPU, on-chip memory and other Direct Memory Access (DMA) devices reside. This bus provides a high-bandwidth interface between the elements that are involved in the majority of transfers. Also located on the high-performance bus is a bridge to the lower bandwidth APB, where most of the peripheral devices in the system are located.
AMBA APB provides the basic peripheral macro-cell communications infrastructure as a secondary bus from the higher bandwidth pipelined main system bus. Such peripherals typically:
• have interfaces which are memory-mapped registers
• have no high-bandwidth interfaces
• are accessed under programmed control.
The external memory interface is application-specific and may only have a narrow data path, but may also support a test access mode which allows the internal AMBA AHB, ASB and APB modules to be tested in isolation with system-independent test sets.
1.3 Terminology:
The following terms are used throughout this specification.
1.3.1 Bus cycle :
A bus cycle is a basic unit of one bus clock period and for the purpose of AMBA AHB or APB protocol descriptions is defined from rising-edge to rising-edge transitions. An ASB bus cycle is defined from falling-edge to falling-edge transitions. Bus signal timing is referenced to the bus cycle clock.
1.3.2 Bus transfer:
An AMBA ASB or AHB bus transfer is a read or write operation of a data object, which may take one or more bus cycles. The bus transfer is terminated by a completion response from the addressed slave.
1.3.3 Burst operation:
A burst operation is defined as one or more data transactions, initiated by a bus master, which have a consistent width of transaction to an incremental region of address space. The increment step per transaction is determined by the width of transfer (byte, half-word, word). No burst operation is supported
on the APB.
A typical AMBA AHB system design contains the following components:
1.3.4 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.
1.3.5 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.
1.3.6 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.
1.3.7 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.
1.4 AMBA Signal Names:
All AMBA signals are named such that the first letter of the name indicates which bus the signal is associated with. A lower case n in the signal name indicates that the signal is active LOW, otherwise signal names are always all upper case.
1.4.1 AHB signal prefixes:
H indicates an AHB signal. For example, HREADY is the signal used to indicate that the data portion of an AHB transfer can complete. It is active HIGH.
1.4.2 ASB signal prefixes:
A - is a unidirectional signal between ASB bus masters and the arbiter
B - is an ASB signal
D - is a unidirectional ASB decoder signal.
For example, BnRES is the ASB reset signal. It is active LOW.
1.4.3 APB signal prefixes:
P indicates an APB signal.
For example, PCLK is the main clock used by the APB.
1.5 AMBA AHB signal list:
All signals are prefixed with the letter H, ensuring that the AHB signals are differentiated from other similarly named signals in a system design.
1.6.3 Transfer response:
A typical slave will use the HREADY signal to insert the appropriate number of wait states into the transfer and then the transfer will complete with HREADY HIGH and an OKAY response, which indicates the successful completion of the transfer.
The ERROR response is used by a slave to indicate some form of error condition with the associated transfer. Typically this is used for a protection error, such as an attempt to write to a read-only memory location.
The SPLIT and RETRY response combinations allow slaves to delay the completion of a transfer, but free up the bus for use by other masters. These response combinations are usually only required by slaves that have a high access latency and can make use of these response codes to ensure that other masters are not prevented from accessing the bus for long periods of time.
A full description of the SPLIT and RETRY operations can be found in Split and retry on page 3-24.
The encoding of HRESP[1:0], the transfer response signals, and a description of each response are shown in Table 3-5.
LITERATURE SURVEY
Since the huge trace size limits the trace depth in a trace memory, there are hardware approaches to compress the traces. The approaches can be divided into lossy and lossless trace compression.
The lossy trace compression approach achieves high compression ratio by sacrificing the accuracy; the original signals cannot be reconstructed from the trace. The purpose of this approach is to identify if a problem occurs. Anis and Nicolici [2] use the multiple input signature register (MISR) to perform lossy compression. The results are stored in a trace memory and compared with the golden patterns to locate the range of the erroneous signals. The locating needs rerunning the system several times with finer and finer resolution until the size of the search range can fit in the trace memory. Such approach is suitable for deterministic and repeatable system behaviors. However, for a complex SoC with multiple independent IPs, the on-chip bus activities are usually not deterministic and repeatable. Therefore, lossless compression approaches are more appropriate for real-time on-chip bus tracing.
2.1 AHB Trace Macro-cell (HTM):
The HTM provides address and data trace information about AHB buses. The information from an HTM can be used with the debugger to enable easy, accurate debugging on AHB-based embedded systems. The HTM provides extensive resources for event recognition to generate trigger events. The HTM generates trace data for output through the AMBA Trace Bus (ATB). The trace debug function is non-intrusive and HTM can be controlled using an APB (AMBA v3) interface.
The trace operation indicates the data transfers that have taken place to defined memory locations or regions. Other AMBA control information can also be included. However, other operations like IDLE cycles and BUSY cycles in AHB are not traced.
The HTM is an Advanced Microcontroller Bus Architecture (AMBA) compliant System-on-Chip (SoC) debug component.