Figure out how to write unit tests for the sim.v files.

[mithro]

We want a structured way to write unit tests for the sim.v files (and a way to run them).

We want the unit tests to be compatible with at a minimum;

• Yosys
• Verilator
• Icarus Verilog

But making it compatible with commercial simulators would be good too.

I think we want to use Cocotb but I have never used it myself.

[mcmasterg]

I don't have a whole lot to say on this / no strong opinion.

But I can add:

• UVM is way overkill for this type of application. Don't even consider it
• For Skybox I rolled my own framework that loosely resembled JUnit
• I've never used Cocotb. I'd need to try it out before having an opinion on it. I'm up to exploring it / seeing a demo

[mithro]

@cliffordwolf - Do you have an opinion on how we should be writing unit tests for these models? I'm guessing you are going to say we should be using formal verification? :-P

[mithro]

@awygle - FYI.

[elms]

I've started to look at demonstrating a simple test using cocotb and VUnit.

I have a branch with a simple test using cocotb (think I found an bug in mux2.sim.v).

VUnit doesn't currently support Icarus Verilog, but people are working on it (see vunit/vunit#188). I haven't had success running this branch yet (getting a segfault during compilation).

Other thoughts:

VUnit is a good choice to drive tesbtenches on an existing codebase. Each testbench needs a few lines added to integrate with VUnit. Running VUnit the output is very similar to many unit test frameworks. It looks like it can be extended to report details to other processes (eg octave) and do additional checks.

cocotb takes a different approach and borrows from UVM. The test cases are written in python which opens all the flexibility of python to how to drive DUTs. It also has a built-in concept for generating tests, but I haven't looked at that yet.

Both support GHDL and integration with Jenkins (which hopefully means easily with travis-ci).

[mithro]

By UVM you mean;

UVM is a methodology for the functional verification of digital hardware, primarily using simulation. The hardware or system to be verified would typically be described using Verilog, SystemVerilog, VHDL or SystemC at any appropriate abstraction level.

?

[elms]

Yes.

Cocotb encourages the same philosophy of design re-use and randomised testing as UVM [link]

They also use the scoreboard, driver, and monitor patterns which I believe is terminology shared with/borrowed from UVM. These are available but not required.