HAVEN

Our goal is to obtain the same time behaviour of verification runs in the non-accelerated and the accelerated version of the framework. The reason for this is clear: when a bug occurs in the accelerated version, it is possible to run the non-accelerated version with the same failing verification scenario and explore the origin of the failure in detail in the perfect debugging environment of a simulator. Simply placing the DUT in the FPGA is not an option, as the transfer of data through the system bus may be delayed, thus yielding behaviour different from the one obtained from the simulator. We solve this issue by placing the DUT into a separate clock domain and enabling/disabling the clock signal for this domain depending on the state of buffers for the input and output transactions. Thus the run of the DUT in the FPGA is guaranteed to result in the same waveform as the run in the simulator.

Unfortunately, this method is not always realisable, especially when a bug occurs after a huge number of transactions. In such a situation it is convenient to observe internal states directly from the verified hardware system placed in an FPGA in order to localise the source of the erroneous behaviour. Therefore, HAVEN provides Signal Observer, a component that monitors values of signals in the system during a verification run. The values are stored into the standardised Value Change Dump (VCD) format and can be inspected using any compliant waveform viewer, e.g., ModelSim or GTKWave (in the former case, the file with the dump needs to be converted into a ModelSim internal format by vcd2wlf, a tool provided in the ModelSim distribution). For common interfaces, it is easily possible to define specialised components derived from Signal Observer such that the output waveform contains correctly named and grouped signals.

The framework monitors two types of errors: assertion failures and conflicts in Scoreboard such as missing or corrupted data or incorrect order of received transactions. If a bug is detected, the framework provides a short report about the nature of the failure, the simulation time when it occurred and the number of the received transaction which caused the inconsistency in Scoreboard. An example of error detection is given in Appendix B in the technical report.