Verification with SystemVerilog or VHDL
Why OSVVM™? › Forums › OSVVM › Verification with SystemVerilog or VHDL
Tagged: SystemVerilog OSVVM VHDL Xilinx cores test framework high-level language behaviour simulation speed
- This topic has 4 replies, 2 voices, and was last updated 4 months, 1 week ago by Oliver.
December 2, 2022 at 09:49 #2109
regarding OSVVM for verification of FPGA design I have a question.
My colleague told me, that we need to use SystemVerilog instead of VHDL for a new project. The problem he sees is that Xilinx provides the cores in Verilog and the test framework in System-VL. Only this is automatically built and provided by the demo. If we wanted to take this into VHDL, we would have to translate everything ourselves and reproduce it, which he doesn’t see the point of. That probably won’t be any faster either. Simulation speed is a big problem in this project.
Not all cores from all manufacturers are available in VHDL. Above all, there is no SystemVHDL as a complement to the SystemVerilog, which brings precisely this high-level language-based emulation of behaviour.
What is your idea about this? Thanks!December 2, 2022 at 17:05 #2110Jim LewisMember
> 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?
JimDecember 5, 2022 at 14:11 #2114
thank you for the detailed answers!
Actually I’m looking at the PCIe test framework from Xilinx. The AXI I’m planning to verify is already included in OSVVM, as I could see. For QSPI as another task I will probably need to write my own.
OliverDecember 5, 2022 at 14:36 #2115Jim LewisMember
There is an OSVVM SPI model at: https://github.com/noasic/SPI
My long term plan is to clone it. It is a candidate for inclusion in OSVVM.
JimJanuary 26, 2023 at 10:11 #2144
thanks for the link. Now that I finally got my tools working I will have a look at it soon. The OSVVM demo tests look good and run well (not when following the old user’s guide in the OSVVM Examples zip archive on this site though). Unfortunately the simulation of Xilinx PCIe-demo-design with Vivado will not run when the language is set to VHDL ([XSIM 43-3322] Static elaboration of top level Verilog design unit(s) in library work failed.). There are problems with generics. Only in Verilog it will run.
- You must be logged in to reply to this topic.