5 Suggested methods for simulation
5.1 General
What is a satisfactory simulation is a matter of taste and working methods. Nevertheless, assumptions are always made in relation to a simulation. These assumptions include the expectation that specific functional elements work as expected. It is therefore pointless to examine these functional elements with a simulation. There can also be certain functional elements that would be beneficial to simulate, but doing so is too complex or time consuming.
This section suggests a few assumptions and limitations on the simulation process. An approach for the simulation of a system that involves the Xillybus IP core is also discussed. These guidelines are by their nature more open for discussion than those in the rest of this document.
The Xillybus IP core and its driver are a complex system, which has been tested extensively in various scenarios. It’s therefore unlikely to find bugs in the IP core itself with the help of a simulation: If a bug wasn’t found with terabytes of data transport and with a large range of usage patterns, a simulation is unlikely to reveal such a bug.
Moreover, the IP core’s behavior depends to a large extent on the response from the host: Both the driver and the application software respond in different ways and with different delays, which are nearly unpredictable. On top of that, the latency of the bus (PCIe, AXI or USB) is likewise random and hence unpredictable. A comprehensive simulation is therefore nearly impossible.
In light of this, it’s recommended to perform simulation of application logic up to the point where the FIFO connects with the Xillybus IP core. Accordingly, The IP core is simulated as a black box which drains this FIFO or fills it, depending on the data’s direction.
5.2 Simulating asynchronous streams
When a stream is configured to be asynchronous, the IP core transfers data from or to the FIFO (depending on the stream’s direction) so that the FIFO never reaches the state of overflow or underflow.
This holds true as long as the application software on the host performs I/O operations often enough, and Xillybus’ bandwidth capability is adequate for its mission. These two conditions are the result of a properly designed project. It can be beneficial to verify two aspects of the design by virtue of a simulation:
-
Whether the FIFO reaches overflow or underflow (depending on the direction).
-
Whether the application logic responds correctly to such faulty situation, e.g. as suggested in section 4.5.
To simulate proper operation, it can be assumed that the IP core transfers data to or from the FIFO at the maximal rate, as long as the related ’open’ signal is high (indicating that the file is opened by the host).
For a stream from the host to the FPGA, it’s beneficial to test what happens when the FIFO suffers from an underflow. It’s recommended to simulate this event by making the FIFO appear to become empty. For example, if the FIFO is part of the test bench, the test bench changes the ’empty’ signal (that is connected to the application logic) to high. Alternatively, the part of the test bench that simulates the data flow from the host may simply stop to push data into the FIFO for a period of time. The FIFO becomes empty as a result of this.
Likewise for a stream from FPGA to host: The ’full’ line can be changed to high, to test a FIFO’s overflow. Or, alternatively, the test bench can stop fetching data from the FIFO for a period of time, yielding the same effect.
One possible reason for breaking the continuity of the data stream is that the application logic attempts to exceed the bandwidth limitation of the stream (or the limitation on the IP core’s total bandwidth). If this possibility exists, it’s also recommended that the test bench simulates the bandwidth limitation. This can be done by making sure that the test bench (which acts as the IP core) fills or empties the FIFO with a data rate that is limited by the stream’s intended bandwidth.
However, note that in many applications a simulation of this sort is unnecessary, because the application logic isn’t capable of exceeding the bandwidth limitation.
5.3 Simulating synchronous streams
For the purpose of a simulation, the main difference of a synchronous stream is that the IP core’s data flow isn’t continuous: With a synchronous stream, the IP core transfers data to or from the FIFO only when there’s a pending function call on the host (read() or write() ).
The IP core’s behavior is therefore more dependent on the application software’s requests for I/O. Accordingly, the part of the test bench that simulates the IP core must be written with the application software’s access pattern in mind.
It may be irrelevant to simulate overflow or underflow for a synchronous stream, because a synchronous stream is the less preferred option when the purpose of the stream is to exchange large amounts of data. The methods for simulating these conditions is nevertheless the same as with asynchronous streams.
5.4 A simplified method for simulation
There is a simpler method for the simulation of the IP core if there is no interest in testing the response to an overflow and underflow. For example, in the host to FPGA direction: The FIFO can be implemented in the test bench simply by reading the data word from a file for each rising clock edge when the read enable signal is high. This simplified view of the FIFO relies on the assumption that the host prevents the FIFO from becoming empty by writing data to the relevant device file quickly enough.
In the opposite direction, the test bench writes the word to a file when the write enable signal is high. Similar to before, there is an assumption that the host always prevents the FIFO from becoming full, by reading data quickly enough.
This is approach doesn’t overlook the possibility that the continuity of the data flow can break. Rather, this approach recognizes that a broken data flow is most probably a result of something that is beyond the simulation’s scope: Too shallow DMA buffers, poor responsiveness of the application software, or a CPU deprivation resulting from an overall condition on the host. If such event happens for real, the application logic should make the host aware of that. As already suggested above, this mechanism can be simulated.
This approach does however disregard the possibility that the application logic attempts to exceed the bandwidth limitation of the stream. If such scenario is a realistic possibility, this simplified method for simulation may not be adequate.