The ultimate future goal is to create a generic Automated Test Bench that can be used with any of our IO cores. Of course the test vectors testing each core has to be different. However, since all our cores use wishbone bus this simplifies creating a generic solution. In this final post, I’ll list down the possible problems with creating a generic test bench and propose a solution for each one of them.
1. The cores I/O pins have different names specific to each core.
SOL: Use a wrapper and wire the ports to general names that are not device dependent.
2- Each core have different number of I/O ports
SOL: It is possible to just include a big number of ports with generic names in the tester and top module and use a parameter to tie their output to X if they are not being used.
3- Cores have different parameter names
SOL: Use Wrapper like with the first problem to tie the names to generic ones.
4- Cores have different number of parameters
SOL: The same solution like problem number 2 can be used except this time the unused parameters don’t have to be tied to anything just supply them with a zero by default if they are not needed
5- For each core it’s parameters have a specific number of possibilities. For example the size of the GPIO can range from 1 to 64 but the modes of SPI are 4 modes only.
SOL: Pass command line arguments to your shell script that decide the first value of a parameter and the final value to iterate to.
6- Some devices like I2C have sophisticated hand shaking mechanisms between master and slave every transaction
SOL: Test the master and the slave together or use an already verified device to communicate with either of them.
Those are the problems I have noted when creating the test benches for each device separately. I am sure better solutions will emerge when actually coding for the generic test bench.
0 Comments