Reply To: Verification with SystemVerilog or VHDL

[Jim Lewis]

Hi Oliver,
> Above all, there is no SystemVHDL as a complement to the SystemVerilog
Renaming Verilog to SystemVerilog is simply marketing. Just asking that question demonstrates the brilliance it.

OSVVM provides VHDL with “SystemVerilog + UVM” verification capabilities including Transaction Level Modeling, Constrained Random, Functional Coverage, Scoreboards, Memory Models, Error and Message handling, and Test Reporting (HTML and JUnit) that are simple to use and work similar to built-in language features.

I think it is important to understand that when comparing “SV + UVM” vs “VHDL + OSVVM” one needs to look at verification capabilities (and not language features) and that the VHDL side needs to be represented by someone skilled in OSVVM – otherwise, it is just a one sided marketing rant full of FUD (fear, uncertainty, and doubt).

It is likely that at this point, OSVVM’s test reporting capabilities go beyond what SystemVerilog provides. OSVVM’s Intelligent Coverage randomization which does randomization across a functional coverage model is a feature that is missing in SystemVerilog, so for randomization SystemVerilog is reliant on their Constrained Random capability.

> Simulation speed is a big problem in this project
No one has done a speed comparison of a SystemVerilog vs OSVVM testbench doing randomized test generation. If there is a vendor that wants to do this, I am open to working on the VHDL side.

I expect that OSVVM doing Intelligent Coverage randomization (randomization across the functional coverage model) would compare favorably to SystemVerilog doing constrained random. With SystemVerilog there is solver overhead plus uniform randomization creates extra stimulus. Randomization theory tells that to generate n test cases using uniform randomization (what the solver uses) that it takes O(n * log n) randomizations / test cases applied. Here n is the number of unique test cases you need to generate. So if you need to generate 64 test cases, log n = 4.16, and hence, constrained random will generate more than 256 test cases to cover this. With OSVVM, all the overhead is in the functional coverage data structure and no extra stimulus is generated – so even if VHDL is slower, it would have to be more than 4X slower for SystemVerilog to have an advantage.

> The problem he sees is that Xilinx provides the cores in Verilog and …
Some how FPGA vendors did not get the repeated message revealed by the Wilson Verification survey – FPGA designers prefer VHDL.

If your simulator supports dual language simulations, there is no problem using their Verilog design core with your VHDL design and VHDL verification environment.

> The problem he sees is that Xilinx provides … the test framework in System-VL
In OSVVM, the test framework/test harness is nothing more than structural VHDL code, so this is done just like for RTL code and does not consume significant time (fraction of a day). OTOH, the SystemVerilog framework is a revisualization of how to create a netlist by using OO techniques that has significant complexity and subtilty.

What that leaves then is the verification component (VC, aka testbench model/BFM) used to test the design. OSVVM verification component library currently has VC for Axi4Manager (full and lite), Axi4Memory (full and lite), AxiStream (Tx and Rx), UART (Tx and Rx), DpRam, and Ethernet GMII/MII/RGMII/RMII – and I have plans to work on additional VC.

To simplify writing verification components, OSVVM provides an Address Bus and Stream Model Independent Transaction (MIT) library. Using this library allows you to focus on the signal wiggling that needs to be done by the verification component – the transaction interface and API is defined by OSVVM. In addition to simplifying VC development, using MIT simplifies writing tests since two streaming VC (such as AxiStream and Avalon ST) use the same transaction API.

May I ask what Xilinx demo you are looking at?

Best Regards,
Jim