It should be possible to have it analyse two sets of RTL and confirm they are equivalent. One other potential option that I've just discovered today but not yet had a chance to use is that Synopsys' formality tool can confirm that a netlist and some RTL implement the same design.
#CORNER CASE FOR FPGA SIMULATION CODE#
In which my first job would be to understand what the code does and to implement those decent tests and get them working with the original code before even attempting the redesign. This obviously falls down if the original designer didn't bother with testbenches or only added minimal ones. You should be able to just run those tests against your redesign and verify that they all still pass. The original designer should have added a tonne of high quality tests to verify the behaviour of the block and the system as a whole. UVM is basically built on the whole idea. System Verilog is great for constrained random stimuli generation. At work we have a lot of signal processing and digital filters where it’s often sufficient to have a text file with input data, apply it to the block and write the output to another text file, then check the output data with Matlab/Python etc. You could write your test bench (or part of it) in SystemC and use all the C++ functions/libraries you need. The big commercial simulators (Mentor ModelSim/Questasim, Cadence Xcelium, Synopsys VCS) also allow you to mix SystemC (which is basically C++ with some libraries for hardware description), System Verilog and VHDL. What do you need C++ for? If it’s about stimuli generation and/or output checking: System Verilog has a Direct Programming Interface which allows you to call C functions directly from your test bench. In an FPGA you can try to connect relevant signals to an on chip logic analyzer and see how they behave but it’s still tedious.ĭo you have any advice for librariers/projects for writing c++ tests for interacting with Verilator? Usually we try to reproduce the exact use case in simulation. It helps to have working test cases early because then, when they break you can just ask “what changed?“.ĭebugging on real hardware is much harder.
You can then think about the mostly likely (or most easy to check) reason why it doesn’t behave that way. When debugging it’s important to understand what the behavior should look like. It’s best to also combine them with constrained random stimuli.
#CORNER CASE FOR FPGA SIMULATION VERIFICATION#
Of course the important part about verification is automated checks. We try to include everything in top level tests: Analog models, digital interfaces, firmware etc. Here debugging is much harder and simulation is slower but all the blocks are already verified so usually you can focus on the connections between blocks. Then you have system level (also called top level) verification. Block level verification is important since it allows you to find bugs easily, early and quickly and also allows you to test lots of corner cases. So basically it comes down to a lot of verification. I am looking forward to hearing your thoughts!ĪSIC digital designer here, but should apply to FPGAs as well. However, since I am working on a Zynq system I could instead have an optional AXI slave port and expose the state to the CPU. Inspired by the zipCPU-blog I am considering making optional UART ports on all my modules to support dumping out the internal state. When it comes to HW Xilinx do offer the integrated logical analyzers, but that is SO tedious and inefficient. I think that a workflow using Verilator and C++ could be more efficient. When I do design I try to throw in as many unit tests and assertions in the code as possible. Debugging/Testing/Verifying on in FPGA logic.Debugging/Testing/Verifying with simulation tools like Verilator.My case is quite special since I neither know the design well or really understand what each part does well.īut I am still interested in hearing about your strategies for the following cases: It got me thinking about whether there are more productive ways of debugging and finding bugs. I have a few functional tests for the complete design and have spent hours staring at waveforms in GTKWave finding really minor bugs. I am currently working with porting someone else's design from one HDL to another. I am very interested to hear about other peoples debugging strategies.
0 kommentar(er)
