Introduction

Purpose of this model is to demonstrate the ability to configure RapidIO models to match with Standard RapidIO Switches available in the market. The Rapid IO Block Set from VisualSim is a high performance RIO_Node that works in conjunction with the Serial Switch to create a Rapid IO bus that can be altered, according to specific arbitration algorithms, or other custom 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 port at the bottom of the Serial_Switch block to see if Doorbell, HW_Ack, Retry, NRead and NWrite 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.

VisualSim RapidIO library supports varities of Source Operations. The supported source operations are listed in the following text. All operations except Port-Write are enabled by default.

1. Read
2. Write
3. Streaming-Write
4. Write with Response
5. Data Message
6. Doorbell
7. Port-Write

  RapidIO Library supports sifferent flow control techniques specified in v 1.2, V 2.1 and V 3.0.

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.

RapidIO has four priority levels. Three non-zero watermarks are needed to progressively limit the packet priorities that may be transmitted as the effective number of free buffers decreases. Designate the three watermarks as WM0, WM1, and WM2 where WM0 > WM1 > WM2 > 0 and employ the following rules.

•          If free_buffer_count >= WM0, all priority packets may be transmitted.

•          If WM0 > free_buffer_count >= WM1, only priority 1, 2, and 3 packets may be transmitted.

•          If WM1 > free_buffer_count >= WM2, only priority 2 and 3 packets may be transmitted.

•          If WM2 > free_buffer_count, only priority 3 packets may be transmitted.

The default values for the Watermarks are:

•          WM0 = 4

•          WM1 = 3

•          WM2 = 2

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.

Modifying Flow Control Type

Flow Control Table allows user to change Flow Control  Type from V 1.2, V 2.1 or V 3.0 for RIO switches available in the model. Sample Flow Control Details are given below

ID	Switch	Flow Control Type	;
0	Switch1	V1.3	;
1	Switch2	V2.1	;
2	Switch3	V3.0	;
4	Switch4	V1.3	;

Routing Information

Routing information is maintained using "RIO_Routing_Table", RIO_Routing_Table is a  lookup table and user can enter Routing information of devices connected to each switches in this table. Sample table is given below
ID  Switch   Dest         Port     ;      
 0  Switch1  SDRAM        output   ;
 1  Switch1  Instrument   output13 ;
 2  Switch1  Comm         output24 ;
 2  Switch1  Multicast_1  lookup   ;
User can monitor the Rapid IO operation with a port at the bottom of the Serial_Switch block to see if Doorbell, HW_Ack, Retry, NRead and NWrite 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.