Interface and Buses / AMBA / AMBA_AHB
Block Name: AMBA_AHB

Code File Location: VisualSim/actor/arch/Buses/AMBA_AHB

Table of contents

    1. Block Overview

    2. Description

    3. Write Transaction

    4. Write Response

    5. Read  Transaction

    6. List of Models

    7. AMBA_AHB_Specification_and_Comparison_to_Model

    8. Model_Parameters, Data Structure Fields and Ports

    9. How to connect

    10. Statistics and Analysis

    11. Enabling plot output

    12. Errors and solutions

Block Overview

o  The Advanced High-speed Bus (AHB) library block conforms to the ARM Advanced Microcontroller Bus Architecture (AMBA) specification for read, write, Retry and Split operations. 

o  The Advanced Microcontroller Bus Architecture was introduced in 1996 and is widely used as the on-chip bus for ARM processors. The first generation of the AMBA buses was the Advanced System Bus (ASB) and Advanced Peripheral Bus (APB).

Description

The VisualSim AHB Bus emulates the AMBA 2.0 AHB Bus Protocol to match the functionality and timing.   

The AHB bus model has the following features:

- single edge clock protocol

- split transactions

- multiple bus masters and slaves

- burst transfers

- Retry transaction

- Wait states

- Single outstanding transaction

- pipelined address phase operations

- single-cycle bus master handover

- large bus-widths (64/128 bit)

Devices

The block contains 4 default Master and 4 default slave ports. 

Transaction

The most common transaction sent through the AHB Bus is the Processor_DS.  The bus uses the following fields of the Processor_DS:

• A_Command, A_Source, A_Destination, A_Hop, A_Bytes, A_Bytes_Sent, A_Bytes_Remaining, A_Task_Flag, A_Prefetch and A_Interrupt.

The fields of the Processor_DS data structure determines the type of Transaction – Read or a Write, transfer size in bytes, split, source and destination.

Masters and Slaves

The Master can be a standard block such as a DMA, Processor, traffic generator or a custom block that uses the DeviceInterface block as the protocol interface between the Block and the Bus.  Similarly, the slave can be a Cache and DRAM or any other custom block that is connected to the Bus using the DeviceInterface block as the protocol interface.  For the Slave side, the direction of the ports of the DeviceInterface block must be changed using the Right-click->Appearance->Flip Ports Horizontally.  

Every Master and Slave is associated with a FIFO Buffer. The size is determined by the FIFO_Buffer parameter.  The FIFO buffer is store the requesting or responding transaction that are waiting for the arbiter to allocate the bus.

Operation

On receiving a Processor_DS from the Bus Master, the transaction is placed in the FIFO Buffer and a request is sent to the Bus Controller. When the bus is available, the BusArbiter selects the master to grant access to the bus.  

The bus arbiter has two standard policies to select the next Master to transmit- First Come-First Serve (FCFS) and Round Robin.  The FCFS orders the incoming request in the order of arrival and based on the priority.  The transaction priority is the value in the A_Priority field.  Higher the value means higher the priority. The Round-Robin gives equal weightage to all Masters and selects a transaction from each Master in order.  The order of the Masters to transmit is listed in the parameter- "Round Robin Port Array" and allows transfer through the bus to the respective slave. Only one Master can be active on the bus at any time.  Until the bus completes the transaction ie the request and data transfer, no other Master can gain Bus access.  The lone exception is a Split transaction and is described below.

When the next Master is selected, the Bus generates a single cycle for the Address and Control phase.  The single cycle does not output any data structure.  It generates a delay internally and the timing diagram will display the address cycle.  The Bus Controller manages all commands and transfer on the Bus.    The Bus Controller handles the response from the slave (proceed, or Split Transaction) and processes till the transfer completes.  Only one outstanding transaction can be active on the Bus.  The only exception is when a split transaction occurs.  For more details on the split transaction, review the section below on Split Transaction.

Adding Wait Cycles

It is possible to add Wait states at any time and to any transaction.  The User can add “AHB_Cycles” for any transaction entering the AHB Bus, and it will delay processing for this amount of Time.  The user must add this field and specify the value before entering the AHB Bus block.  If the field does not, exist, no additional Wait States are added.   This process can also be used to add additional Wait States for a Split operation, as well.  Standard time to generate the HReady after a Split is 2 cycles, if not specified externally.

Pipelined Address Operation

Address Pipelining provides increased throughput to the AHB Bus by hiding the Address phase of the next transaction during the Data phase of the previous transaction.  When there are multiple transaction to be sent out, the first transaction alone sends a Address Out.  The first transaction is determined when the transaction starts from an empty request queue.  When a new request is selected and there is an outstanding request, the transaction skips the address cycle and goes directly to sending the request.  

Determining the Availability of a Slave Device

AHB Bus automatically identifies the state of the DRAM and Cache block and generates a Retry sequence if they are busy.  Busy for these blocks is when the input Queue is full.  For all other devices and for custom user devices, status of the destination can be referenced in a memory related to the final destination.  If the value in the A_Destination field is “MyDevice”, then the status is checked at “MyDevice_Status”.  "MyDevice_Status" must be a global memory.  If true, the transaction would continue, else a retry would begin to execute.  If no global memory is found matching this name, the AHB Bus assumes the status to be true.

Split Operation

When a transfer occurs the slave can decide to issue a SPLIT response if it believes the transfer will take a large number of cycles to perform. This signals to the arbiter that the master which is attempting the transfer should not be granted access to the bus until the slave indicates it is ready to complete the transfer. Therefore the arbiter is responsible for observing the response signals and internally masking any requests from masters which have been SPLIT.  This is currently supported only for the Read operation.  This does not work for Write operations.

The basic stages of a SPLIT transaction are:

1. The master starts the transfer in an identical way to any other transfer and issues address and control information
2. If the slave is able to provide data immediately it may do so. If the slave decides that it may take a number of cycles to obtain the data it gives a SPLIT transfer response.  This is done by sending back to the AHB Bus the same transaction with the A_Command field modified to Read_Split or Write_Split.  The A_Destination and A_Source have been reversed.  The Arbiter notes the Master and Slave information.  The master cannot make any other requests to the same AHB unless this request has been completely full-filled.  If the same master has the ability to make multiple requests, then it needs to be conencted to multiple Master's on the same Bus.
3. The arbiter grants other masters use of the bus and the action of the SPLIT response allows bus master handover to occur. If all other masters have also received a SPLIT response then the default master is granted.  
4. There is a delay of two (2) cycles before the handover is complete and a HReady signal is enabled.  This is accomplished by setting a field called "AHB_Cycles" to 2.  Once the cycles are executed, the Bus continues to process normally.  If the user adds a field called AHB_Cycles, then these cycles will be used.
5. When the slave is ready to complete the transfer it sends the read or Write transaction to the Bus with the appropriate A_Destination and A_Slave.   The Command is now Read_Split_Done or Write_Split_Done.  The arbiter restores the priority of the appropriate master.  The arbiter will grant the master so it can re-attempt the transfer. This may not occur immediately if a higher priority master is using the bus.
6. When the transfer eventually takes place, the arbiter will allow the Master to arbitrate for a new transaction.

Retry Operation

The RETRY response works only for Read operations.  It currently does not support Write operations.  It provides a mechanism for slaves to release the bus when they are unable to supply data for a transfer immediately. The mechanism allows the transfer to finish on the bus and therefore allow a higher-priority master to get access to the bus.  

If the Cache or DRAM is used, the block uses the getBlockStatus RegEx to determine the status.  For any other Destination, the Bus will check the global memory called Destination Name + "_Status". If the value of the RegEx or this Global Memory is true, the normal transfer occurs.  If the value is false, then the Bus will generate a Retry.  When a Retry occurs, the arbiter will continue to use the normal priority scheme and therefore only masters having a higher priority will gain access to the bus. 

Adding Additional Masters and Slaves

Additional Master and Slave ports can be constructed by doing the following:

• Drag a new AHB block from the library
• Right-click to select Open Instance
• Drag a HardwareDevices->BusInterface 
• Enter unique names for each port in the Linear Port block by combining the Bus_Name + Port Number. 
• Select Graph->New Input/Output Multiport and add two instances
• Connect the input and output of each side of the Liner Port block to a single multi-port
• If using Round-Robin arbitration, add the Port names to the Round_Robin_Port_Array to the AHB block

Note:

AHB does not support “Custom” arbitration-mode.  A error will be reported if the Custom is selected for the AHB Block.

  Detailed Transaction Transfer Descriptions

Write Transactions- Master to Slave

A Write transaction proceeds as follows.

1. The transaction Arrives from Master and is saved in the respective Master FIFO Buffer.  All masters have the same size buffer and are set to FIFO Buffer. The source is set in the A_Source, destination is provided in A_Destination, transaction type is set in A_Command (Read, Write, Prefetch, Erase etc.) and transaction size is A_Bytes.  
2. The Port informs the Bus Controller of the transaction.  When the bus is available, the Controller selects a Master, based on the arbitration.
3. A single cycle address/control transaction (Write request) is transferred through the bus.  The control signal delayed internally but the signal is not sent out of the bus.  
4. After this control cycle, the transaction is delayed internally for all the bursts.  The burst is a parameter of the AHB block called Burst_Size_Bytes.
5. A transaction is sent to the slave port after the 1st burst or 1st word (bus width size), and the remaining transactions are delayed internally.  The A_Source, A_Destination, A_Bytes and A_Command will not be modified.  
6. The AHB Bus can operate in Buffered or Unbuffered mode. 
1. If the A_Task_Flag = true, AHB write is non-bufferable. In this case, the bus is held until the AHB slave interface provides a response to the master after the data is written into the memory.  In this case, a acknowledge message is sent back to the Master when the Slave has finished writing.  There is no delay across the Bus for this response message and does not affect the read/Write channels.
2. If the A_Task_Flag = false, AHB write is bufferable. The bus is released as soon as the AHB slave interface receives data without caring that the data is actually written into the slave or not.  No response is received by the Master.
7. Higher Priority requests or data transfers can preempt a lower priority transfer.  This is done between bursts only.
8. If the Slave decides to Split, the Slave responds with the same transaction and replacing Write with Write_Split.  This is for A_Task_Flag = true.  The Master cannot send a new transaction. When the Slave is ready to send a response, it sends the transaction with A_Command=Read_Done, indicating the response can be transferred.

   
Note: The write transaction takes two cycles to send the the packet out, 1 cycle for address/control and another cycle for 1st word transfer. The remaining values are delayed internally.

Figure 1. Timing Diagram – Write Transaction

Data Transfer – Write Transaction:

{A_Bytes, A_Command}

Address/Control Signal:

First fragment: {4, Write}     // sends address, 4 bytes (Bus Width), but A_Bytes will contain the original request size

    -- corresponds to Bus Control (BC) trace in red.

Data Transfer:

Write transfer: {64, Write}     // sends words, 64 bytes, output is sent at the 1st word transfer and the remaining bytes are delayed internally.

    -- corresponds to Bus Data (BD) trace in blue.

The following table shows an example of a Write activity:

 

List of Fields	Input from Master to Bus	Output to Slave (End of all bursts)
A_Bytes	Request Data Size	Value unchanged
A_Destination	Final Destination	No Change
A_Source	Original Source	No Change
A_Interrupt (Opt.)	FALSE	No Change
A_Prefetch (Opt.)	FALSE	No Change
A_Status	Used internally by Linear Bus. Set to Slave port name.	Set to Slave port name + Append "_"
A_Hop	Slave side port name	Next Bus, else Destination if direct connect
A_Command	Write	No Change

Table 1. Write Activity

Write Response

1. A write response will be sent back to the Master from the Slave.  This will release the Bus. 
2. All rules pertaining to the transaction fields remain the same as the Write Transaction.
3. When the response arrives at the Bus, it sent out immediately. Look at the Table 2 Output value.
4. A_Interrupt and A_Prefetch are used by the Processor and Cache for scheduling Prefetch.

Note: The write response takes 1 cycles to send the the packet out.

The following table shows an example of a Write Response:

List of Fields	Input from Slave	Output to Master
A_Bytes	Request Data Size	Value unchanged
A_Destination	Final Destination	No Change
A_Source	Original Source	No Change
A_Interrupt (Opt.)	FALSE	No Change
A_Prefetch (Opt.)	FALSE	No Change
A_Status	This is used internally by the Linear Bus.  This is set to Master port name	Append _ to_Name
A_Hop	Don’t Care	Next Bus or Destination if direct connect
A_Command	Read. Can have any suffix	Unchanged

Table 2. Write Response

Read Transaction

A Read transaction proceeds as follows.

1. The transaction arrives from Master and is saved in the respective Master FIFO Buffer.  All masters have the same size buffer and are set to FIFO Buffer. The source is set in the A_Source, destination is provided in A_Destination, transaction type is set in A_Command (Read, Write, Prefetch, Erase etc.) and transaction size is A_Bytes.
2. The Port informs the Bus Controller of the transaction.  When the bus is available, the Controller selects a Master, based on the arbitration.
3. When the transaction is accepted for transfer, the Data Structure is delayed by one cycle for the Address Control.  Then the Data Structure is output. Output value will be as shown in table 3.
4. The Bus is locked and waits for the response.  No other transfer or Read Request is possible during this period.  A Request can preempt a lower priority transfer. The slave responds by performing the data Read and returns the data fragments setting the A_Command as ‘Write’ so the bus would return the data to the master.
5. If the Slave decides to Split, the Slave responds with the same transaction and replacing Read with Read_Split.  The Master cannot send a new transaction but other Masters/Slave transfers can proceed.  When the Slave is ready to send a response, it sends the transaction with A_Command=Write_Done, indicating the response can be transferred.
6. The data fragments are transferred to the master through the bus taking several cycles, depending on the bus width, burst size, bus speed, bytes transferred etc.

Read Request Transaction:

        Note: The Read transaction takes one cycles to send the the packet out.

    The following table shows an example of a Read Request Transaction:

List of Fields	Input from Master	Output to Slave
A_Bytes	Request Data Size	Value unchanged
A_Destination	Final Destination	No Change
A_Source	Original Source	No Change
A_Interrupt (Opt.)	FALSE	No Change
A_Prefetch (Opt.)	FALSE	No Change
A_Status	This is used internally to set the Master port name	Append _ to Name
A_Hop	Don’t Care	Next Bus or Destination if direct connect
A_Command	Read. Can have any suffix	Unchanged

Table 3. Read Request Transaction

Read Transaction- Response:

    Note: The Read response takes two cycles to send the the packet out, 1 cycle for address/control and another cycle for 1st word transfer. The remaining values are delayed internally.

    The following table shows an example of a Read Transaction- Response:

List of Fields	Input from Slave	Output to Master (End of all Bursts)
A_Bytes	Request Data Size	Value unchanged
A_Destination	A_Source (Names flipped from Request. Can be an alternate destination also)	No Change
A_Source	A_Destination (Names flipped Request.)	No Change
A_Interrupt (Opt.)	FALSE	No Change
A_Prefetch (Opt.)	FALSE	No Change
A_Status	Used internally.  Set to Slave port name	Set to Master port name + Append "_"
A_Hop	Slave side port name	Next Bus or Destination if direct connect
A_Command	Write	No Change

Table 4. Read Transaction- Response

 

Figure 2: Timing Diagram – Read Transaction

Data Transfer – Read Transaction

{A_Bytes, A_Command}

Address/Control Signal:

First fragment: {64, Read}       //sends address, 4 bytes(Bus Width), but the A_Bytes maintain the original request size

    -- corresponds to Bus Control (BC) trace in red.

Data Transfer:

The slave DRAM reads and returns the read data, setting the A_Command as ‘Write’.

The 64 bytes to be transferred through the bus are sent from the Slave device.

Write transfer: {64, Write}    //sends words, 64 bytes, output is issued after the 1st word transfer, remaining bytes are delayed internally.

    -- corresponds to Bus Data (BD) trace in blue.

The Read response returning to the Master is sent when all of the data has been received. On receiving a Processor_DS from the Bus Master, the Bus Port places it on the FIFO Buffer and transfers control to the BusArbiter. The BusArbiter decides which master to grant access to the bus and allows transfer through the bus to the respective slave. The BusArbiter handles the response from the slave (proceed, or Split Transaction) and processes till the transfer completes.

List of models

Following are the list of demo models available in the tool. 

    VS_AR/doc/Training_Materials/Architecture/Bus/AHB_AXI:

            1. AHB_Buffered_Non_Buffered.xml

            2. AHB _MultiMaster_Fabric.xml

            3. All_AHB_Bus.xml

            4. AMBA_AHB_Bus_Model.xml

            5. AMBA_AHB_with_APB_Bus_Model.xml

            6. linear_Bus_AHB_Split2_Read_Test.xml

            7. Linear_Bus_AHB_Split2_Read_Write_Test.xml

            8. linear_Bus_AHB_Split2_Write_Test.xml

            9. AHB_AXI_Bus.xml

            10. AHB_APB_Bus.xml

            11. Smartfusion_test2.xml

            12. Three_level_Bus_Model.xml

AMBA AHB Specification and Comparison to Model

Before an AMBA AHB transfer can commence the bus master must be granted access to the bus. This process is started by the master asserting a request signal to the arbiter.  Then the arbiter indicates when the master will be granted use of the bus. A granted bus master starts an AMBA AHB transfer by driving the address and control signals. These signals provide information on the address, direction and width of the transfer, as well as an indication if the transfer forms part of a burst.  A write data bus is used to move data from the master to a slave, while a read data bus is used to move data from a slave to the master.  Every transfer consists of:

• an address and control cycle
• one or more cycles for the data

The address cannot be extended and therefore all slaves must sample the address during this time. The data, however, can be extended using the HREADY signal. When LOW this signal causes wait states to be inserted into the transfer and allows extra time for the slave to provide or sample data. During a transfer the slave shows the status using the response signals, HRESP[1:0]: 

OKAY     

The OKAY response is used to indicate that the transfer is progressing normally.

In the VisualSim model, normal progress does not require a response.

HREADY

HREADY goes HIGH this shows the transfer has completed successfully.  

In the VisualSim model this corresponds to the data structure returned, no interpretation is necessary.

ERROR

The ERROR response indicates that a transfer error has occurred and the transfer has been unsuccessful.  

In the VisualSim model, errors do not occur due to noise or hardware failure.

RETRY and SPLIT

Both the RETRY and SPLIT transfer responses indicate that the transfer cannot complete immediately, but the bus master should continue to attempt the transfer. In the VisualSim model, retry is detected by the arbiter, and it will perform the operation automatically, the user model does not need to take  any action.  Split can be signaled by the Slave Device, meaning the Slave will busy for a period of time and cedes the bus to any waiting transactions.  This is signaled by sending the incoming Slave transaction, back to the AHB Bus port and changing the field A_Command from “Read” to “Read_Split”, or from “Write” to “Write_Split”.  When the split condition clears, then the Slave needs to send “Read_Done” or “Write_Done”.  This can be sent everytime the Slave responds to a prior command, for example.

In normal operation a master is allowed to complete all the transfers in a particular burst before the arbiter grants another master access to the bus. However, in order to avoid excessive arbitration latencies it is possible for the arbiter to break up a burst and in such cases the master must re-arbitrate for the bus in order to complete the remaining transfers in the burst.

Setup

To Run the Model, the Model Parameters and the transaction data structure flowing into the respective channel of the AHB Bus Block (ex: Processor_DS) etc need to be setup.

Model Parameters, Data Structure Fields and Ports

General parameter

Parameter Name	Value (Data Type)	Explanation
Architecture_Name	“Architecture_1”(String)	It refers the Architecture_Setup name. Please keep both the names as same. It can be linked to top level parameter. Giving different names other than Architecture_Setup block's name will throw an error.
Bus_Name	“AHB” (String)	Unique name for this Bus. This name must be different from all architecture blocks, schedulers, smart_resources and global model memories.
Enable_Plots	false (check box)	This parameter is used for enabling the activity plotter for AHB. It will give the Timing diagram for each ports based on the control/Address and Data transaction within the bus
FIFO_Buffers	8(int)	It defines the input Buffer size of the bus. It can be linked to top level parameter. If the number of input request coming to the bus is higher than FIFO Buffer length, then some of the packets can be lost.
Key parameters for configuration
Bus_Speed_MHz	100.0 (Double)	Speed of the bus is specified in terms of Mega Hertz. This value is used for defining the clock cycle and internal timings. It can be linked to top level parameter.
Bus_Width_Bytes	8 (Int)	This parameter defines the width of the bus. The Bus can transfer only this much bytes in a single clock cycle.
Burst_Size_Bytes	16 (Int)	It defines the Maximum length of Bytes that the bus can send as burst transfer. Burst size should be greater than Bus_Width_Bytes. This parameter can be linked to top level parameter.  If A_Bytes that is equal to or smaller than this number will be sent as a single burst.  Any A_Bytes that is greater than this number will become two or more bursts.
Round_Robin_Port_Array	{Bus_Name+"_Port_1", Bus_Name+"_Port_2", Bus_Name+"_Port_3", Bus_Name+"_Port_4", Bus_Name+"_Port_5", Bus_Name+"_Port_6", Bus_Name+"_Port_7", Bus_Name+"_Port_8"} (Array of Strings)	This parameter can be used only when the bus operates on Round Robin mode. It determines the Round robin order for the ports.
Device_Attached_to_Slave_by_Port	{"Device_1"}, {"Device_2"}, {"Device_3"}, {"Device_4"}, {"Device_5"}, {"Device_6"}, {"Device_7"}, {"Device_8"}} (Array of Strings)	This parameter can be used for routing purpose when the hello messages are disabled. It will help the bus to transfer input data to a specific destination port.
Mode_Arbiter	FCFS (Pull-down) Available options: FCFS, RR, CUSTOM	This parameter defines mode of AHB Bus. FCFS defines the First Come First Serve mode and RR defines Round Robin mode of operation CUSTOM is the option used for implementing custom Scheduling algorithm for AHB Master and Slave ports. It can be achieved by using custom_out, custom_in ports in AHB.

Table 5: List of AHB Bus Block Parameters

 

Data Structure Field	Value (Data Type)	Explanation
A_Bytes                           (necessary)	100 (Int)	This is the total bytes to be transfered for this transaction.  All bursts of this transaction will have this value.
A_Bytes_Remaining	96 (Int)	The number of bytes remaining after the current transaction.
A_Bytes_Sent	4 (Int)	The number of bytes in this transaction.
A_Command                   (necessary)	"Read" or "Write" or "Read_Split" (String)	This determines the operation.
A_First_Word	true or false (Boolean)	Specifies whether this is the first word of the transfer
A_Priority	2 (Int)	This is priority of the transaction.  The transactions waiting for service are reordered based on this value.
A_Source                         (necessary)	"Processor"	This is unique name of the Source.  When the transaction returns from the Destination, the Source and Destination names are flipped.  So, the Source becomes the Destination and Destination becomes Source.
A_Destination                  (necessary)	“DRAM” (String)	Final Destination
A_Hop	“DRAM” (String)	Set to match A_Destination
A_Task_Flag	false (Boolean)	The default is false, which means that the Master does not require an acknowledge for a Write.  If set to true, the VisualSim standard blocks will send a acknowledgment back when all the data has been written to the Slave.  The DMA block uses this field to get a return from the Cache or DRAM block.

Table 6: List of Data Structure Fields used in the AHB Bus

Port Name	Type	Explanation
port1, port2, port3, port4, port5, port6, port7, port8	Multiport or input/output. Connection must be made in order- first input to this port and then output away from this port.	Each port is for a Master or Slave. Transaction Data Structure of type Processor_DS.

Table 7: List of AHB Bus Ports

Transaction Field Values – 100 Byte Read, Write Commands

Description	A_Command	A_Bytes	A_Bytes_Remaining (optional)	A_Bytes_Sent (optional)
100 Byte Read at Slave. Bus Width = 4	Read	100	96	4
100 Byte Read Return at Master	Write	100	0	100
100 Byte Write at Slave	Write	100	0	100

Table 8: Transation Field Values

How to connect

The following image shows the right way to connect the AHB in the Architecture. Source like Processor and DMA can be connected directly to the AHB port, but if the Master device is designed with simple library block(as logic) then user has to include Device Interface block to provide the interface with master. Similarly for Slave. Slave like RAM, Integrated cache and display can be  connected directly to the slave port.

   

The Bridge block plays important role in connecting the different buses in the architecture. Two buses can not be connected directly, user has to use Bridge block.

Statistics and Analysis

The Key statistics for the AHB bus are:

    1. Delay
        The maximum and minimum delay that is handled by the AHB during the simulation.

   2. IO operations per second
         The total number of input and output operations happened during the simulation

    3. Input Buffer Occupancy
          Whenever the bus is occupied the input requests will be waiting in the buffer.

    4. Preempt Buffer Occupancy
          The request that are preempted by the higher priority request are

    5. Throughput
          Throughput of the bus in terms of Mega bytes per second are observed.

     6. Utilization
          Percentage of utilization for this bus is observed for the entire simulation time.

These are analyzed as max, min, mean and standard deviation of it.

The following image shows the statistics that can be observed and analyzed in AHB bus.

Analysis:

AHB Delay:
    Bus Width bytes will determine the number of cycles of delay other than control/address cycle in the internal process. User can check whether the uniform transaction is happening or not based on the model construction.

IO operations per second:
    Number of IO operations in the consecutive blocks should be same. if there are mismatching amount of transactions is displayed then the block is not receiving the exact transactions from the neighboring blocks.

Input Buffer Occupancy in words:
    The buffer occupancy(number of words based on bus width) of the bus during the simulation are observed, it will help the user to determine the buffer length of the design during the actual design integration.

Preempt Buffer Occupancy:
    This will help the user to analyze the number of request that is buffered in the queue because of the preemption of higher priority request.

Throughput:
    This will help the user to check whether the designed speed and bytes are working properly or not. Throughput can be compared with the neighbor blocks to check whether the requests are processed by the bus during the simulation or not.
    If the throughput is not same as the neighbor blocks then check the connectivity or the previous block to see the data is routed properly. Some ports may not be connected and the data are not getting processed.

Utilization:
    This will help the user to see how good the resources are utilized in the design. Based on the percentage of utilization user can improve the system configuration to get efficient outcomes.

Enabling plots

    There are two methods for enabling and analysing the plots in the AHB bus.

    1. Adding Timing daiagram to the model (Hardware Setup - > TimingDiagram) and modify the bus name in the configuration window. This will shows the overall transaction in the bus along with the other blocks in the model.

 

    2. Enabling the "Enable_plot" parameter in AHB configuration window. This will show the data transaction at each port.

    

      

Errors and solutions

    1.
    Explanation    :  if (port_token.A_Command == "Write") false, expression plus 4, else plus 1., Check argument types, argument values, field names, and variables.

    Exception        :  VisualSim.kernel.util.IllegalActionException: No method found matching {A_Bytes = int, A_Destination = string, A_Hop = string, A_Instruction = arrayType(string), A_Source = string, BLOCK = string, DELTA = double, DS_NAME = string, ID = int, INDEX = int, TIME = double}.A_Command()

Make sure all the necessary fields are available at the input of AHB, if not please add the fields using expression list.

    2. 

    VisualSim.kernel.util.IllegalActionException: .AHB_Testing.AMBA_AHB.AMBA_Port @ 0.0 ps -->

    java.lang.NullPointerException

Try the following scenarios 

                1. Add the list of fields in input Data Structure in case some fields are not available.
           2. Add Architecture setup block if not available in the model.
           3. Make sure the  data type of each field  is correct.

 

 

Created with the Personal Edition of HelpNDoc: Free Kindle producer