RIO_Node

Block Name: SRIO_Node                                                                                                                                                                                                    

Library location: Hardware Modeling  -->Emerging Bus Standards --> Serial Rapid IO
Code File location:  $VS/VisualSim/actor/arch/Buses/SRIO

Table Of Contents

1. Block Overview
2. Description
    1 Block diagram of Flow
    2. Flow Sequence
    3. Additional Signals
    4. Fragmentation
    5. Delays
    6. Queues
    7. Acknowledge
    8. Retry
3. Logical layer messages
4. Queue Depth
5. Block Ports
6. Statistics
7.Parameters
8. Additional Information
9. Example Models

1. Block Overview

This library emulates all the components of the SRIO system.  These include the Device interface, fragmentation, ingress queue, egress queue and the switch. The library contains three major blocks- RIO_Node, Serial_Switch and the RIO_Delay blocks. For these blocks to operate correctly, the model must contain three items as a prerequisite- Architecture_Setup, Power_Manager and Digital.

5. Configuration
To include the PCIe block in a model, the following steps must be followed:

• SRIO_Node is available in Hardware->Emerging Bus Standards->SRIO->SRIO_Node. One SRIO_Node is required for each connected device.  A SRIO_NOde conencted to another SRIO_Node is possible for connecting to the next Serial Switch.
• Drag the block and place it in your model. To construct a Serial Switch, drag the Hardware Modeling->Bus_Switch_Ctrl->Serial_Switch.
• Now connect the input and outport of all the SRIO_Nodes to the multiport (single port contains both input and output) of the respective Serial_Switch.
• Now connect all the Source and Destination devices to the respective SRIO_Nodes
• If the wire delay must be considered, then introduce the SRIO_Delay block between the SRIO_Node and the Serial_Switch.
• Set the block parameters to match your block diagram. Refer to the Parameter selection for the possible parameter values.

2. Description

The Rapid IO Block Set is a high performance RIO_Node that works in conjunction with the Serial Switch to create a Serial Rapid IO that can be altered, according to specific arbitration algorithms and configurations. The RIO_Node provides the logic for master and slave node message processing, while the Serial Switch provides the channels and timing needed by the Rapid IO protocol.

In addition, one can monitor the Rapid IO operation with a Text_Display at the bottom of the Serial_Switch block to see if data and messages are being sent in the expected order. One can also turn off the monitoring, once the messages have been validated using a parameter of the RIO_Node block called Enable_Status_Messages to false.

The RIO_Node takes transactions, or transaction fragments, at a master RIO_Node and sends messages to the designated slave Rapid_IO_Node, based on an internal routing table. This routing table is assembled in the Serial Switch and utilizes fields in the Processor_DS called A_Source and A_Destination to route through the Rapid IO bus. The Serial Switch has a parameter for the Bus_Width that will determine the latency through the switch based on the field A_Bytes_Sent in the Processor_DS.

2.1 Block Diagram of Flow

2.2 Flow Sequence

Traffic Input->Master Queue->Fragmentation->Read_Request ot Write_Data Request out->Ingress Node Queue->Switch->Egress Node Queue->Device
Hardware_Ack from Egress to Ingress- Remove from Ingress_Queue
No Hardware_Ack and receives Ack for the next sequence number- Retry the unacknowledged packets prior to this sequence number
If flow_Control at Egress device, Egress port checks availability of Device before transmitting.  
At Egress port, generate Random number.  If below BER, then drop. If above BER, then send Hardware_Ack to Ingresss.
Sequence number is unique using a combination of fields- RIO_Dest_Node and RIO_Seq_ID.  The Sequence number will be checked for each Node-Node combination at the Ingress Port.
A_Bytes_Out field of the output transaction from Egress port = 0

2.3 Additional Signals

Logical: Global Read and Write Ack Destination Egress to Source Ingress.
Physical: Read and Write between Egress and Ingress within a switch. 

2.4 Fragmentation

Fragmentation is done at the Ingress Node. Defragmentation is done at the Egress of each Switch. There is a flow control between the Fragmenter and the Ingress Queue. There is a 1 bit delta T between each fragment. If the previous fragment is accepted, the next fragment is attempted to be sent to the Ingress Queue.  When all the fragments of a transaction are accepted at the Ingress Queue, a flow control message is sent to the Traffic Source.

Fragment delay = Interface_Speed * fragment size

2.5 Delays

Fragmentor
    1. To generate fragments, there is a delay of fragment_Size /Interface_Speed.
    2. There is a one bit time between fragments.
    3. Wait time for the flow control Ack from Ingress Queue

Ingress Queue
    1. Delay in queue waiting for prior packets to be transmitted.
    2. Retry packet delay time

Switch
    1. Delay in queue waiting for the switch link
    2. Link transfer time
    3. There is one Queue for each combination of Source+Destination

Egress Queue
    1. Queue delay waiting for Flow Control from Defragmentor
    2. Waiting for the last packet in the transaction to arrive before sending the request out to the Defragmentor.
    3. All packets until the last packet will be stored in the Queue, consuming FIFO position

Defragmentor
    1. 1 bit time Delay before sending out the transaction
    2. Wait for EVENT from next Node or Destination

Flow Control:
There are multiple flow controls in SRIO
1. Between Traffic Source and Fragmentor- This is an optional action that is enabled when Input_Flow_Control parameter is true.  When the Fragmentor has completed fragmenting and transferring all the segments of a transaction to the Ingress Queue, then an EVENT is sent to the Traffic Source to Pop the next transaction. If this is not enabled, the transactions are sentto the fragmentor immediately.
2. Between Fragmentor and Ingress Queue- There is an EVENT for accepting each packet in the Queue.  When the EVENT for the previous packet is received the next packet is sent.
3. Between Egress Queue and Ingress Queue- When the Egress Queue is full. Requires a Ack to remove a packet from the Ingress Queue.
4. Between Egress Queue and the Destination.  This is an optional item. If the Output_Flow_Control parameter is true, then the Egress Queue waits for the previous packet to be Ack using an EVENT. If this is no true, then the packets are immediately sent out from the Egress Queue.

2.6: Queues

• Ingress- Single Queue at each Node which stores the transaction for all destinations
• Egress- One queue for each Node that stores transactions arriving from all destinations
• Switch- One queue for each combination of Source+Destination

2.7: Acknowledge

• Hardware: This is a positive Ack between Egress and Ingress Queue.  There is NACK.  A negative Ack is assumed when the later sequence number is Ack at the Source.
• Logical: This is not used within SRIO Node blocks. A port is provided on the RIO_Node block where this Ack is received. It is up to the user to create additional operation around these Acks. There is a separate Read and Write Ack. There is a local Ack between the Egress and Ingress of a Switch.  This is done one per transaction.  There is a Global Ack between the Destination Egress and the Source Ingress.
• All Ack consume bandwidth on the link. The Size of the Ack is listed as a parameter.

2.8: Retry

• BER: Every time a segment arrives at the Egress Queue, a random number is generated.  If the number is less than the BER, then the packet is dropped.
• When the Egress Queue is full, the packet is dropped.

3. Logical Layer Messages

At the logical layer, the VisualSim library block will cover three functionality- Doorbell, Retry, mailboxes and Rd/Wr Ack. There is a top-level parameter at each Node that defines the Bytes associated with these header-only packets. There is a separate output port at the Node block that receives the Doorbell, Retry request, and the Ack messages.  The RIO blocks do not process the Type 11 messages.  It simply provides it on the output port.

The Doorbells message is sent by the user with the RIO_Message field=”Doorbell”. This is sent to the Destination node and it returns a “DB_Ack” message.
The Read and Write data sends back an Ack when received at the Destination.  In addition, the Read and Write send a local Ack at each Egress port of a Router. This is for use in guarantee delivery.

Five Mailboxes are provided at Each Sender and Receiver Nodes.  The first Mailbox is exclusive for Doorbells. Each of the Mailboxes can have up to 4 messages outstanding to each Sender Mailbox for a total of 16 outstanding messages.  The queue consumed for the Mailbox is separate from the Ingress/Egress Queues. The user sets the Sender and Receiver mailboxes numbers in the RIO_SENDER_MAILBOX and RIO_RECEIVER_MAILBOX fields. The addresses are not managed by the RIO Node.  It is the responsibility of the user to set those in the model at the Requester.

The Mailbox 0 has the highest priority and Mailbox 4 has the lowest priority. The Mailbox content will be reordered at the Destination Receiver Mailbox.

4. Queue Depth

• When the Ingress Queue is full, the fragmentor must wait.
• When the Switch Queue is full, the packet is dropped. 
• When the Egress Queue is full, the incoming packet is dropped.

5. Block Ports

• RIO_Node- To Device- Input and Output; Logical Ack port, Input and Output to Switch
• RIO_Delay- To Device- Input and Output; Logical Ack port, Input and Output to Switch
• Serial Switch- Has 24 input/output ports. This is one per connected Node.

6. Statistics for RIO_Node

• Number of Packets Entered From Source
• Number of Packets Entered From Switch
• Latency
• Buffer
• Throughput

7. Parameters

8. Additional Information

• Source or Traffic Generator- Block generating traffic that is sent into the RIO Node
• Packet or Segment- Fragmented portion of a transaction with maximum size of the Maximum_Payload_Size parameter
• Transaction- The request or data arriving from the Source or the previous Switch; And the unit sent out to the Destination device
• Queue- A FIFO with a fixed number of packet locations
• Switch- Crossbar with point-to-point connections
• Retry- When a packet does not receive a Ack and a future packet has received a Ack, the packet must be retransmitted from Ingress to Egress.
• Ack- Two types- logical and hardware.
• BER- Bit Error Rate is a number used to statistically create error
• Flow Control- Control that packets are not dropped through the system
• EVENT- A VisualSim virtual connection that triggers a block to pop a transaction

9. Example Models

1. SRIO with Single Master and Single Slave devices Read Operation

2. SRIO with Single Master and Single Slave devices Write Operation

3. SRIO with Two Master and Single Slave devices Read/Write Operation

4. SRIO with Two Mster and Two Slave devices Read Operation

5. SRIO with Two Master and Two Slave devices Write Operation

6. SRIO with Two Master and Two Slave devices Read/Write Operation

7. SRIO with Four Masters and Two Slave devices Read/Write Operation

8. SRIO with DMA operation

9. SRIO with Processor and SDRAM

10. SRIO with Virtual Machine as Master device and SDRAM Read Operation

Created with the Personal Edition of HelpNDoc: Benefits of a Help Authoring Tool