Introduction
In a previous client engagement we needed to create a testbench for directed tests to prove part of the design against waveforms in the functional specification. We realised there was an opportunity to use the waveforms, and the need to document them, to create a simple directed testbench. One of our summer interns was tasked with developing a tool allowing blocks to be tested with minimal impact on development time.
Use cases
|
We now use the tool on a variety of projects:
Test cases can be written within the editor itself or they can be uploaded to the editor. Each file submitted will be treated as an individual test case, which can then be selected during simulation. As tests are modified, a timing diagram depicting the current test can be seen. To download the timing diagrams, simply right click the waveforms and select your preferred format. You can simply write test cases in JSON or YAML and we will email them to you along with an automatically generated testbench. Waveform diagrams for your test cases will be shown as you edit and can also be downloaded as images to aid in the documentation of your design. You're welcome to use the tool free of charge as often as you wish. Your waveforms and testbench will remain your property and will not be used either by ITDev or any third parties. |
For further information on how to write test cases, click here
For a detailed example of how to use the tool, including an example testbench, click here
Waveform Editor
How To Use The Tool
Test cases are written in WaveJSON, which is equivalent to JSON or YAML but with some additional restrictions. A tutorial for writing test cases can be found here, however there are several additional conditions which must be met for a testbench to be generated:-
- All signals must have a
nameandwaveattribute, as well as a direction (dir) attribute which can be eitherinoroutdepending on whether the signal is an input to or an output from the block being tested. - Multi-bit signals must also have a
widthin bits and an array ofdata. The data elements must be valid for the specifiedradix. This attribute is a 1 or 2 character string containingsif the data is signed, and one ofb,dorhto specify binary, decimal or hexadecimal data respectively. By default, data is assumed to be unsigned and in decimal format. - All signals in each test case must be the same length in cycles.
- The clock signal must be a series of edges of only one type, for example
p.......,p...PPpPandn....N..are all valid butp...n...and1p......are not. The type of edge must also be consistent across all test cases. - Edges must not be used by signals other than the clock signal.
- All signals belonging to the block being tested must be specified in every test case. Additionally, the name, direction and width of each signal must not differ between test cases.
- The period, phase and code features are not currently supported.
Test cases can be written within the editor itself or they can be uploaded to the editor. Each file submitted will be treated as an individual test case, which can then be selected during simulation. As tests are modified, a timing diagram depicting the current test can be seen.
Once the test cases have been written, the name of the module being tested must be specified, as well as the name of the clock signal and its period. After providing other details, a testbench will be generated and emailed to you, along with your test cases.
By default the tool contains a simple example, however a more complex example, including the resulting testbench, is available.
