Reply To: Scripting dual-language testbench (VHDL / Verilog)

[Jim Lewis]

Hi Brad,
I have had on my todo list to come back to look at this example in further detail – I have just had a very busy year end for 2023.

Since I don’t have a copy of your testbench, we have only been able to talk in generalities. However, I think I see the issue in your statement here:

> When analyzing that TB file, since the generic has not been set to control the generate statement yet the simulation fails as it sees signals from the other DUT which is meant NOT to be generated and throws “unknown identifier” errors.

Generate statements differ from VHDL-2019’s conditional analysis in that everything in a generate statement must analyze – whether you intend to enable it or not. Hence, if that part of the testbench had pieces that will not analyze, then you will get analysis errors.

Now though, you probably have two separate working testbenches – you could merge them back together. However, I probably would not. I consider the cost of having two separate test harness very low.

OSVVM has a situation like this when testing the Axi4Manager.vhd and Axi4ManagerVti.vhd. The Axi4ManagerVti is a special version of the Axi4Manager that is used internal to a DUT where we have no ports that can be routed to the outside. Internally these two VC are identical (done by copying). Externally, Axi4Manager uses a port for the transaction interface and Axi4ManagerVti uses an internal signal for the transaction interface. The testbench/test harness connects to the Axi4Manager using port maps. The test bench connects to the Axi4ManagerVti using external names.

Even though I could handle these by a simple generic specified to the test harness when the test loads, I decided to do it by two separate test harnesses that are mirror images of each other (all signal names and instance names are the same) – the external name on the Vti component uses an identical name to the signal name for the port of the regular component.

Both VC will run the same test cases. Since the test harness and test ctrl from both versions use identical names, the same test case will run in either environment.

To run the tests, I created a RunAllTests that runs the regular component that does:

# RunAllTests.pro
include testbench
include TestCases

And I created a RunAllTestsVti that runs the internal signal + external name based component that does:

# RunAllTestsVti.pro
include testbenchVti
include TestCases

Had I used generics, then I would have needed to have a setting that passes the generic value down to the TestCases script. This is worth doing when necessary, but otherwise, I try to avoid it.

Best Regards,
Jim