Simulating Ethernet Traffic in a VaST Virtual System Prototype
It's often necessary to create a Virtual System Prototype (VSP) that includes an Ethernet network interface. For the simulation of this VSP to produce meaningful results, we also need to model the packet streams that this interface receives and sends. After all, what is the sound of one hand clapping?
There are a number of ways to achieve this, each with its own advantages and disadvantages. The most complete and timing-accurate way is for the Virtual System Prototype to contain platform models of all the communicating nodes, together with a timing-accurate behavioral model of the Ethernet network itself, as in the following diagram.
Click for a larger diagram
A real network may contain dozens of nodes, of many differing types, and so this approach may be impractical to implement. However, we are frequently interested in detailed modeling of just one of the node types on the network, namely the device we are currently designing.
A common case is where we have actual physical hardware for the other network nodes. In this case, we can connect the Virtual System Prototype to a real physical Ethernet port on the PC that is executing the simulation. This is implemented by adding a host-mapped peripheral device to the VSP, which communicates to another process running in the host OS, which drives the real Ethernet port hardware. This Ethernet port in turn is connected to the rest of the devices in the network as in the following diagram.
Click for a larger diagram
The main issue here is the timing accuracy of the complete system. The simulated Virtual System Prototype does not execute in real time – it may execute faster, or slower than real time depending on its complexity and the performance of the host PC. On the other hand, the real devices outside of the VSP are by definition, running in real time. If the VSP runs consistently faster, it's possible to insert delays so that it is synchronized with real time, but this isn't always possible. The good news is that most Ethernet protocols tolerate unpredictable time delays well. That's because they need to work in the presence of network congestion and collisions, and so these protocols have built-in timers, retry mechanisms, and the like. The total system simulation can be functionally accurate, but not necessarily timing accurate.
There is a third alternative, which is functionally accurate, and also preserves the timing accuracy of the complete system simulation. In this approach, the incoming Ethernet traffic is modeled by a file of packet data that includes timing information. A host-mapped peripheral model feeds the packets into the VSP at the correct moment in simulated time.
Click for a larger diagram
A commonly used format for this kind of file is the pcap (packet capture) format. Each packet of Ethernet data in a pcap file includes a time stamp accurate to the microsecond.
Click for a larger diagram
Files in pcap format can be created by packet sniffing tools such as:
- tcpdump, a tool for capturing and dumping packets for further analysis
- WinDump, the Windows port of tcpdump.
- Wireshark (formerly Ethereal), a graphical packet capture and protocol analysis tool
For further information, see http://www.tcpdump.org and http://www.winpcap.org.
These tools capture packet information from a real Ethernet port on the PC, and can save the data in a pcap format file. This file can then be replayed into a Virtual System Prototype simulation, with timing as specified by the packet timestamps. If the VSP wishes to transmit packets to the Ethernet port, the host-mapped peripheral timestamps the data and writes it to an output file on the host, also in pcap format. This file can later be analyzed and displayed by the tools.
This modeling technique works well when the device being modeled doesn't need to handshake over the network with the device supplying the data. The UDP (User Datagram Protocol) is such a protocol, and is often used for time-sensitive applications such as streaming media.
|
