Automated VHDL testbench server? - Page 1
Forum section: electronics / general

author: betocool
author_rank: Regular Contributor
timestamp: August 12, 2025, 01:00:03 am
content: Hey all,A colleague and I are thinking about setting up a PC in order to run VHDL simulations overnight. We are using Vivado as our IDE.My colleague is a software engineer and has proposed that we run unit tests, and I agree. I guess initially our models will be quite simple, but get more complex over time.I'm looking for useful information about starting a testbench to run over a few hours or overnight. Instead of looking at digital signals, the focus will be more about expected results from a series of inputs. We've never done something like this on VHDL, but my guess is that we'll have to use some sort of makefile or perhaps TCL scripts to run and evaluate the results.If you could point me to some articles or examples to get started that would be appreciated. Any simple example of a scripted or automated setup would do.Cheers,Alberto

author: Tation
author_rank: Regular Contributor
timestamp: August 12, 2025, 06:14:55 am
content: In VHDL you have all what is needed to perform unit testing. The testbenches not only apply stimuli, but also check outputs and generate reports. Also doable in SystemVerilog (perhaps the "right way" these days) and, to a lesser extent, in Verilog.Basic unit testing is a day from you, but more advanced methodologies for this, like PSL and UVM/UVVM (for SystemVerilog and VDHL, respectively) have a more step learning curve, tough. UVM well worths the effort, IMHO, some colleagues are making a career with it.For big projects, simulation is (almost) the only way to ensure conformance to specifications. And is also required in certification.Note: never used the simulator built into Vivado, so not knowing what exactly does it support. Does it support PSL?

author: betocool
author_rank: Regular Contributor
timestamp: August 12, 2025, 02:46:27 pm
content: Thanks for your reply!I was not familiar with PSL or UVVM, I need to read into that. I'm not sure that Vivado supports them, a very quick Google search did not specify that. I will have a look at UVVM, maybe there are simple examples I can start with.Cheers,Alberto

author: zapta
author_rank: Super Contributor
timestamp: August 12, 2025, 08:45:05 pm
content: Quote from: betocool on August 12, 2025, 01:00:03 amYour friend is right.What desktop operating system do you use (e.g. Linux) and version control system do you use (e.g. Github)?

author: Tation
author_rank: Regular Contributor
timestamp: August 13, 2025, 11:26:06 am
content: UVM was developed over SystemVerilog. UVVM is an adaptation of it into VHDL, as OSVVM is. You will find much more materials about UVM than about UVVM...Edit: a quick search just done suggests that Xilinx simulator does not yet support neither UVVM nor OSVVM, so maybe it is time to think about embracing SystemVerilog... or switch to £$€¥ proprietary simulators, like QuestaSim, Active-HDL,...

author: laugensalm
author_rank: Regular Contributor
timestamp: August 13, 2025, 11:48:04 am
content: I've done such with ghdl and own extensions that can be found under keyword 'ghdlex' (various resources).That approach basically has one big executable (typically with an embedded CPU) and loads programs/RAM over a virtual debug port (JTAG) in order to execute HW tests. Some of those scenarios are found in this project (https://github.com/hackfin/MaSoCist), e.g. run the gcc regress tests for RISC-V to verify a proprietary implementation from within a Docker environment.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 13, 2025, 02:09:30 pm
content: GHDL works really well and I certainly recommend it. It's not as fast for complex designs as commercial simulators though, but it's easy to use and easy to automate, and you can always launch several testbenches in parallel (with several instances of GHDL) to make up for it (for those long simulations)GHDL can be used with two different modes: mcode or compiled. The former is slower to simulate but much faster to get ready to simulate (so beneficial for short simulations), while the compiled mode compiles your VHDL code to an executable (so this compilation phase takes more time) and then running the executable executes the simulation significantly faster than mcode. It also supports code coverage (via gcov).

author: hamster_nz
author_rank: Super Contributor
timestamp: August 13, 2025, 09:16:01 pm
content: Here's a TCL script I had for an old Vivado-based project:Code:# read all design filesread_vhdl ../src/cpu/sign_extender.vhdread_vhdl ../src/cpu/data_bus_mux_a.vhdread_vhdl ../src/cpu/decode.vhdread_vhdl ../src/cpu/data_bus_mux_b.vhdread_vhdl ../src/cpu/program_counter.vhdread_vhdl ../src/cpu/alu.vhdread_vhdl ../src/cpu/result_bus_mux.vhdread_vhdl ../src/cpu/riscv_cpu.vhdread_vhdl ../src/cpu/register_file.vhdread_vhdl ../src/cpu/branch_test.vhdread_vhdl ../src/cpu/shifter.vhd# Top level system design (CPU + Memories + Peripherals)read_vhdl ../src/systems/top_level.vhdread_vhdl ../src/systems/top_level_expanded.vhd# The memory containing test coderead_vhdl ../src/program_memory/program_memory.vhdread_vhdl ../src/program_memory/ram_memory.vhd# The CPU bus - bridge, RAM and Serial peripheralsread_vhdl ../src/bus/bus_bridge.vhdread_vhdl ../src/peripheral/peripheral_serial.vhdread_vhdl ../src/peripheral/peripheral_gpio.vhdread_vhdl ../src/peripheral/peripheral_ram.vhd# Test benchread_vhdl ../src/test_benches/tb_riscv.vhdsave_project_as sim -forceset_property top tb_riscv [get_fileset sim_1]launch_simulation -simset sim_1 -mode behavioralrun 5usquitIt was run with something like:Code:echo source sim.tcl | vivado -mode tclOf course you can use the "open_project" command to open an existing Vivado XPR, but I didn't for this project.

author: betocool
author_rank: Regular Contributor
timestamp: August 13, 2025, 11:37:57 pm
content: Thanks for your answers and help!My colleague ended up looking into TCL scripts for Vivado mainly because it's the tool we're using. Currently we're at the getting started stage. We're also considering a standalone Linux box so we can do things remote, perhaps a VM or a Docker environment... we just need some serious HDD space!We will look into some of the suggestions.Cheers,Alberto

author: laugensalm
author_rank: Regular Contributor
timestamp: August 14, 2025, 09:03:41 am
content: Are you sure you want to base your verification environment on Vivado/xsim?They haven't exactly been known for properly following the standard. Maybe they fixed their issues by now, but since isim, they had been carrying along some mutilations 'off standard' that had lead to simulation mismatches, especially when it came to arithmetics, led aside VHDL-08 issues.The Vivado solution may also not scale well due to licensing issues - on the other hand you have to be aware on the GHDL side that the libgrt infects your simulation with GPL, i.e. distributing an .exe forces you to actually release the source as well.For distributed Co-Simulation, the yosys CXXRTL back end is also an interesting option for functional verification, as you can legally distribute an .exe of your simulation w/o source and loop in external routines easily. You'll never want to mess with kludgy HDL verification methodologies again...

author: azer
author_rank: Regular Contributor
timestamp: August 18, 2025, 10:53:23 am
content: You could have a look athttps://github.com/HDLUtils/hdlregressionfor scripting your simulation.It will enable you to switch between running your simulations with vivad/ghdl/nvc/modelsim without changing your scripting and with minimal setup.For the regression server, you could install GitLab CE which has CI capability or you could use Jenkins.

author: fsasm
author_rank: Newbie
timestamp: August 20, 2025, 09:22:22 am
content: In my previous work, we used VUnit for testing and Vivado in Non-Project mode. Non-Project mode helps when you use version control like git, but it is cumbersome. Vivado just isn't made to be used with a version control system.I cannot recommand VUnit, as I often had trouble with the build system and sometimes with the test cases. Also, I started to hate Python to the core. Later I visited a training seminar for OSVVM and this was extremely helpful. Today I would recommend OSVVM with GHDL, but be careful that you don't have XPM or Unisim primitives in your entities, as they cannot be simulated with GHDL. For this you need a commercial simulator that support SystemVerilog and VHDL. The layout for the testharness and testcase for OSVVM is not so intuitive at first, that's why I would recommend getting training or getting someone who has experience with it, on board. Also OSVVM is just getting support for XSIM, as XSIM gets better support for VHDL-2008.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 20, 2025, 01:58:54 pm
content: Yes, apart from speed, be aware that commercial simulators (at least the ones shipping/compatible with your FPGA tools) will allow simulating vendor IPs, and also post-P&R timings, which GHDL can't.For the IPs, with GHDL you'll have to emulate them, can be from "trivial" (to emulate EBR or distributed RAM) to very hard.

author: laugensalm
author_rank: Regular Contributor
timestamp: August 23, 2025, 07:53:03 am
content: Quote from: SiliconWizard on August 20, 2025, 01:58:54 pmWhat you're referring to is probably the encrypted IP? This part could be solved, as Vivado actually delivers the encryption keys in clear binary, you just need to find the proper tool for it, and you couldn't share that knowledge widely (might be different now, I think I saw those tools on github again). With earlier ISE distributions, they used to ship/emit obfuscated VHDL for some stuff, that again violated the standard, so this had to be reverse-obfuscated again in a painful way. Nowadays the problem is that some primitive IP simply comes as Verilog only, requiring mixed language simulators again. I had no further issues in the past simulating Unisim entities with GHDL (for older architectures).Question is little what level you want to simulate on. In most cases when trying to not break stuff with code changes, you'll stick everything into CI/CD, and do the functional simulation only, where you might not necessarily need 'X', 'U', or 'Z' in the first place. That's where Verilator/CXXRTL and MLIR approaches perform fast for complex systems.Then on the small grains GHDL or Icarus are fantastic for OpenSource, but VHDL and basic Verilog methodologies are IMHO not up to par with modern software strategies. VUnit and alike don't really solve the core issues, just add unneeded complexity as 'alien' frameworks (i.e. not built-in to the HDL).