VME Bus Standard

Modeling the VME Bus

(Located demo/performance/VME)

Introduction

The first VME Bus standard was introduced in 1981, and the maximum theoretical backplane data rate was 40 Mbytes/sec. Subsequent VME bus standards increased the maximum theoretical backplane data rates as follows:

1984    VME64        80 MBytes/sec
1996    2eVME        160 MBytes/sec
1997     VME320    320 MBytes/sec

The VME Bus Model can support these different standards through the proper selection of parameters in the model. The VME_Clk_Time is set to 100ns, based on the protocol standard, which includes the address propagation, etc. The VME_Bus_Width determine how many bytes are transmitted in a single VME_Clk_Time. Based on the existing backplane data rates, one needs to set the VME_Bus_Width as follows for the different VME bus standards and data rates:

1981    VME        40 Mbytes/sec    VME_Bus_Width:    4 Bytes
1984    VME64        80 MBytes/sec    VME_Bus_Width:    8 Bytes
1996    2eVME        160 MBytes/sec VME_Bus_Width:    16 Bytes
1997    VME320       320 MBytes/sec VME_Bus_Width:    32 Bytes

Figure 1: VME Bus Model – Top Level

Model Support for Maximum Burst Size

The VME Bus Model also allows the user to set a maximum number of Burst Transactions, using the Max_Burst_Transactions parameter. This parameter will examine the incoming number of bytes of a new transaction, and then based on the VME_Bus_Width and Max_Burst_Transactions parameter, fragment the source transaction into individual transactions to be sent over the bus. The maximum bytes of a single Transaction can be calculated by the following equation:

Equation 1:

Maximum Bytes Single Transaction = Max_Burst_Transactions * VME_Bus_Width

This suggests that if the Max_Bust_Transactions is set to 16, VME_Bus_Width is set to
16, then 256 bytes can be sent as a single transaction over the VME bus, after winning the arbitration process.

VME Model Data Structure

The VME Bus Model contains a user-defined data structure that contains fields useful for transmission of data, and fields useful for collection other information about VME bus transactions passing through the model. Detail fields of the VME_Bus_DS include:

/*
      VME Bus Data Structure

*/

Source_Name         String Port_1   ; /* Source Name, used in routing       */
Destination_Name    String Port_N   ; /* Destination Name, used in routing */
Transaction_ID      int     1        ; /* Unique Transaction ID from Source */
Grant_OK            boolean false    ; /* Grant Flag                         */
Transaction_Bytes   int     4        ; /* Packet Size in Bytes (4 Min)       */
Transaction_Count   int     1        ; /* Bytes / Bus Width = Count          */
Last_Transaction    boolean false    ; /* Last Transaction (Fragment)        */

The Source and destination are string fields used in routing Data Structures through the model, using virtual connections. The Transaction_ID field can have a unique integer number to help identify a specific transaction passing through the model. The Grant_OK field is used in the arbitration process, in the VME controller. The Transaction_Bytes field is the number of bytes in the transaction, and the Transaction_Count is the number of 100 ns cycles, based on the Max_Burst_Transactions, VME_Bus_Width parameters. The Last_Transaction flag can be set to true for the last transaction in an application-level message.

In addition, there are standard header fields that contain information relating to the arrival of Transactions to the Bus Master, such as the TIME field. Users can modify the above Data Structure to add specific fields to collect, additional bus-related information, as the Data Structure passes through the bus topology.

VME Master/Slave Hierarchical Block

The Master/Slave hierarchical block operation is determined by the ‘Master’ parameter, where true sets the module to a bus Master. Figure 2, below shows the internal structure of this block.

Figure 2. VME Master/Slave Hierarchical Block.

Transactions enter the VME Master/Slave block on the left side and traverse through the single queue, to be sent to the destination Slave via the OUT_Fld_Mem block, a virtual connection block. Before a Transaction can be sent to the Slave destination, an arbitration process must be won by the Master, assuming there are other bus Masters in the bus topology. The first If_Else_K3 block determines if the VME bus is idle, and if yes, then initiates an arbitration request through the “Grant_Request” virtual connection, else the Transaction is stored in Queue_One.

Assuming the VME bus is currently idle, then the “Grant_Request” virtual connection initiates to copy the front Transaction in queue Queue_One, and sends this Data Structure to the VME_Controller hierarchical block via the ‘arb’ port on the right. The VME_Controller hierarchical block contains some simple logic to select the first Data Structure arriving, as the arbitration winner for access to the bus. The arbitration time can be set by model parameter, and the default is one VME bus cycle or 100 ns. Once a bus master has won the arbitration, then the Data Structures are sent to all of the Bus Masters, and only the Data Structure with the matching Source_Name Data Structure field and the Grant_OK field is set true, is accepted by the If_Else_K block. This process then selects the front queue Transaction of Queue_One and sends it to the Slave, based on the Data Structure Field, Destination_Name.

The IN block of the Slave port will then accept Data Structure, based on the name of the Port. This parameter of the VME Master/Slave is named: ‘Port_Name’. DS_Dly_2 block then delays the incoming Data Structure, based on the parameter named: ‘Port_Delay’. This delay could be thought of as a processor delay for the port.

Typical Results

Figure 3, below shows typical latency results from Port_1 to Port_3 in the example model. In addition, there is a latency histogram showing the frequency of different delays through the VME Bus. One will notice that the vertical bus delays fall on 100 ns increments consistent with the parameter settings of the model. The Bus delay Histogram also shows a somewhat uniform distribution of the Transaction delays, given the small sample size.

Figure 3. VME Bus Model Results.

The example results are based on a uniform random distribution for the size of transactions (20 to 100 Bytes), Bytes VME_Bus_Width set to 8 Bytes, and Max_Burst_Transactions set to 16. The 20 msec bus delay is based on the ‘Port_Delay’ parameter of Port_3 in the model. There is a 10 msec delay in the generation of the Transactions (Port_1), however, the Data Structure field TIME has been set after this delay, so it does not appear in the overall delay.

Other Model Considerations

The hierarchical block Gen_Traffic contains a While block that fragments Transactions if the incoming message size exceeds the value of Equation 1, and sends Data Structures to the bus Master in 100 ns increments. If a subsequent Data structure arrives before this fragmentation process is completed, then this could cause the model results to be somewhat distorted. If the user wishes to increase the VME data rate to the bus maximum level, then it is recommended the user add an additional queue before this fragmentation step to insure Data Structure integrity and consistent results.

Finally, the arbitration process of the VME_Controller hierarchical block is considered a timing-driven process, and if the user adds many Master nodes in the model, then it may be valuable to check the timing consistency of the VME_Controller under heavily-loaded conditions. In other words, one may see latency results that seem to potentially stop during the simulation, and one should observe the arbitration process to see if a bus Master is at fault.