Scripting dual-language testbench (VHDL / Verilog)
October 2, 2023 at 21:32 #2292
I’m wondering if there has been any documentation made for using some script functions with a dual-language testbench. Looking through past articles I’ve found discussion of topics that come close to what I am trying to do but none of which speak to .pro (or since I’m simulating in Riviera .do) considerations.
The core of what I am trying to do is use ‘SetExtendedSimulateOptions’ to set some top level testbench generics from my .do script. I’ve done this plenty of times with VHDL only DUTs and it works great but I’ve found that if the DUT uses both VHDL and Verilog I am unable to set those generics.
I believe the main issue is that I needed to use commands like vsim instead of ‘simulate’ or ‘RunTest’ for the testbench to run but these commands don’t have the necessary hooks to read in the values being passed by ‘SetExtendedSimulateOptions’.
As an example a the .do script would look something like this:
source ../dir/hdl/OsvvmLibraries/Scripts/StartUp.tcl SetExtendedSimulateOptions "-gC_EXAMPLE_PARAM=1" build ../dir/OsvvmLibraries/OsvvmLibraries.pro build ../dir/example.pro analyze ../dir/test_cases/DUT_test.vhd vsim work.DUT_test work.glbl -L unisim run -all
Is there some consideration I am missing in OSVVM that would allow me to change the vsim command to an equivalent osvvm command and still run both the VHDL DUT_test file and the Verilog glbl file?October 4, 2023 at 01:13 #2295
Have you tried:
simulate DUT_test glbl -L unisim [generic C_EXAMPLE_PARAM 1]
What library is glbl in? If it were VHDL and glbl is in the unisim library, the glbl would be referenced as unisim.glbl.
If all of your simulations use glbl and unisim library, you can do:
SetExtendedSimulateOptions "-L unisim" SetSecondSimulationTopLevel glbl simulate DUT_test [generic C_EXAMPLE_PARAM 1] simulate ...October 4, 2023 at 19:43 #2296
glbl is a verilog file referenced by an IP from a third party vendor.
Is it possible to set a generic for a file that is analyzed before simulation? Looking at the script users guide I would think that SetExtendedAnalyzeOptions is meant to accomplish this but I could be using the command incorrectly. Is it possible to use SetExtendedAnalyzeOptions to set the value of a generic in a specific analyzed file?
In this case DUT_test would be a configuration of the main DUT_TB entity defined in a separate file, so I’m trying to set a generic set in DUT_TB which is analyzed before simulating DUT_test.
Thanks!October 5, 2023 at 04:53 #2297
In OsvvmLibraries/Ethernet/TestStandAlone/TestStandAlone.pro, I set the generics for the top level test by doing:
simulate Tb_xMii1 [generic MII_INTERFACE RGMII] [generic MII_BPS BPS_1G]
Here Tb_xMii1 is the name of the configuration for the testharness (named TbStandAlone).
So if you have not already, add top level generics to the testharness that are then mapped to lower level blocks. Looking at the example above may help some.
From the RiveraPRO command reference on asim/vsim,
Assigns values to VHDL generics, Verilog and SystemVerilog parameters, and SystemC generics that are not assigned values in VHDL generic maps or through the Verilog/SystemVerilog defparam statement. Has no effect on SystemVerilog parameterized classes.
The name part of the argument can include a relative or hierarchical path (without the dataset logical name, i.e. without string sim: at the beginning). For example:
So if you have mapped a lower level generic, it does not look like you can override it with this. So instead, have a top level generic that is not mapped, and connect it to the lower level examples – just like done in the Ethernet testharness.October 5, 2023 at 21:02 #2299
Okay, this is very helpful information and from this I believe the answer to what I am trying to do is probably no.
Looking at TestStandAlone.vhd assume there is a generate statement that decides if xMiiPhy gets created or not.
phy_gen : if C_PHY_GEN_TRUE = 1 generate xMiiPhy_1 : xMiiPhy generic map ( MII_INTERFACE => MII_INTERFACE, MII_BPS => MII_BPS, DEFAULT_DELAY => tpd ) port map ( -- xMii Transmitter Functional Interface GTx_Clk => GTx_Clk , Tx_Clk => Tx_Clk , TxD => TxD , Tx_En => Tx_En , Tx_Er => Tx_Er , Tx_Ctl => Tx_Ctl , -- xMii Receiver Interface Rx_Clk => Rx_Clk , RxD => RxD , Rx_Dv => Rx_Dv , Rx_Er => Rx_Er , Rx_Ctl => Rx_Ctl , Crs => Crs , Col => Col , -- Testbench Transaction Interface PhyTxRec => PhyTxRec , PhyRxRec => PhyRxRec ) ; end generate phy_gen;
In the above code passing something like MII_INTERFACE into the xMiiPhy using the simulate commands makes total sense, those generics will not be needed before simulation begins. However, C_PHY_GEN_TRUE is needed before simulation of a testcase occurs.
Does OSVVM assume that generics will not be used in this way? If this is not recommended for OSVVM I will restructure my testbenches going forward but I wanted to be sure I wasn’t missing something simple that would allow me to control a generate statement in the TB before running a dependent testcase.October 6, 2023 at 00:54 #2300
If C_PHY_GEN_TRUE is a top level generic, OSVVM will allow you to specify it for either simulate or RunTest. As long as your simulator supports that, it should work just fine. Generate is resolved at elaboration time – which is the first step of simulation.
Have you tried something like this and it failed to work?
JimOctober 6, 2023 at 17:14 #2301
Yes, this fails before the simulation phase is ever reached because I have two testbenches that are testing two versions of a DUT which has a different port list in each testbench but use the same TB file. These two testbenches have separate .pro files and test cases but they share the TB file. 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.
I’m fairly certain that in the OSVVM Ethernet example, if for whatever reason two versions of ethernet were using TestStandAlone.vhd with generate statements to create one version of the DUT or the other, it would encounter the same issue.
“analyze TestStandAlone.vhd” would fail because the generic that controls which version of the DUT is created would not be set until the next line, “RunTest Tb_xMii1.vhd”.
Luckily its pretty easy to just split the TB file into two, one for each version of the DUT. I just thought I must be missing something because during initial testing I was using a constant variable to generate the correct DUT during analyze just fine but when I pulled that constant to the top level as a generic it broke the testbench.
BradOctober 6, 2023 at 17:23 #2302
- You must be logged in to reply to this topic.