Mirabilis Design - Designing a Cross Bar Switch using VisualSim- Similar to AXI, PCI-Express and Rapid IO

Home | Demonstrations | Semiconductors | Crossbar Switch Chipset

Crossbar Switch Chipset

VisualSim from Mirabilis Design is a graphical modeling and simulation environment for performance analysis, power exploration and architecture design of electronics and real-time software. VisualSim is used to design complex SoC, distrbuted computing systems, network of systems and FPGA during the product specification and design. Using VisualSim, a accurate model of your proposed system can be built, simulated and analyzed in as little as a few days.

This demonstrations shows the use of VisualSim to explore a complex SoC that is build around a crossbar switch. This model is built using statistical traffic stimulus and a generic switch model. For technology-specific models of PCI, PCIx, PCIe, AHB, APB, AXI, Core Connect PLB, OPB, Rapid IO, Switched Ethernet, VME, SPI etc., contact the Mirabilis Design representative by clicking here.

You can access the simulation model by clicking on any of the links below. From these windows, you can modify parameters of the model and run simulations. The analysis can also be viewed on the Web Page. The architecture of models cannot be modified from this Page and will require access to the VisualSim software license. To get a trial copy, click here.

Click here to view the interactive VisualSim Block Diagram and model - (Model - 1)

Click here to view the interactive VisualSim Block Diagram and model - (Model - 2)

Click here to view the interactive VisualSim Block Diagram and model - (Model - 3)

High-Performance and High-Reliability IO Sub-System

The model is a I/O agent with a set of N slots. The VisualSim model has been created using the block diagram in Figure 1. There are multiple input slots (defined by Traffic Generators), IO Agent-IOA (defined by aggregated link and processing element), port link that connects the IOA with the cloud (Task Issue, Scheduler and the MUX), cloud that connects all the devices (Task Issue, Scheduler, Processing element) and the individual devices like memory and CPU (Task Issue and Scheduler and processing element). The DMA is a special device as this could have multiple channels that have to also be taken into consideration.The analysis that can be performed with a model of this kind are:

Simplex vs. Dual-Simplex Operation
Capability: The interface from the cloud to the devices and from the IO Agent to the Cloud have been designed as a hierarchical block. A parameter specifies if the link is simplex or dual-simplex. Another parameter specified the transfer rate. The hierarchical block consists of If-then-else block that is sent to two Task Issues blocks. These are each sent to a Scheduler. The output of the Task Issue is connected to an OUT block. There are some additional blocks used for display of additional statistics. If simplex, then the total bandwidth is the sum of the bi-directional traffic. If dual-simplex, then there is dedicated bandwidth in each direction

Protocol overhead consumed per I/O transaction
Capability: The Task_Overhead field in the Data Structure (DS) is used to specify the amount of overhead bits. This is combined with the Expression block to compute statistics on the overhead. The overhead can be computed for individual packet types or for the entire system. The overhead can be computed in terms of additional utilization on the system.

Memory latency for DMA read/write operations
Capability: Each DS can be classified as a RD or WR operation using the Task_Type field. The latency for each DS can be computed at each device on the way or aggregated for the entire sample flow (Slot-to-Slot or memory only, DMA only etc.)

Latency across I/O agent ASIC, Bridge and within IO device
Capability: This would use the same statistics generator from the RD or WR but would include all the Task_Types in the criteria. The ASIC could be a single Scheduler and in this case the statistics would be generated by default. If more details of the ASIC are added, then the Display and Probes will can be used.

Number of pipeline read/write operations.
Capability: The number of pipeline read/write operations can be modulated based on the Task_Type and a compute block to determine the # of pipeline required to transfer the Task_Size data length. The data could be a small, medium, large or variable size.

Size of read/write operations
Capability: The mix of RD/WR can be modulated in the Traffic Generator at each slot. The mix can be based on a stochastic process, trace file or a XML-generated file.

Sample operation (a):

IOA to device (small write)
Device issues DMA read
Memory controller / IOA returns data (DMA read latency)
Device issues 1-N DMA pipelined read operations
Device issues 1 DMA write operation
Devices optionally issues pipelined DMA write operation

Capability: There are a number of ways the flow of data through the system can be specified. The verbose mode is to use a number of Task Issue blocks and connect in sequence. The decision between them can be made using the expression block and the If-then-else blocks. This could for demonstration purpose and is relevant for the sample supplied. If there are a large number of these instructions and operations, then the Model List is a better option. This specifies the flow through the system in a file and is evaluated at each stage. A stage can be the port link, IOA, cloud or device. A flow can look like Slot->IOA->Port Link -> Cloud ->CPU->Cloud->DMA->Cloud->Mem->DMA->Cloud->CPU->
Cloud->Mem->CPU->Port_Link->IOA->Slot.

Another way to approach the flow is to let the Dykstra algorithm determine the flow. As the sample provided is specific the first two are a better fit. If there are multiple paths through the system, then the algorithm approach would be better.

Sample operation (b):

Devices issues DMA read
Memory controller / IOA returns data (DMA read latency)
Device issues 1-N pipelined DMA write

Capability: The implementation is same as above but the focus will be on the transactions with Task_Type=WR..

Sample operation (c)

Interleave / mix of (a) and (b) in simultaneous flight

Capability: The specific mix of RD/WR is determined at the Traffic Generator. This is user-controlled and can be parameterized for experimenting with at simulation.