Jim Lewis
Forum Replies Created
-
AuthorPosts
-
April 25, 2024 at 07:48 #2377Jim LewisMember
Hi Jeremy
Currently OSVVM is doing quit -sim when a simulation ends in error. This unfortunately is necessary to close the transcript file.A change is coming to not do this when running interactive
Jim
April 24, 2024 at 21:03 #2375Jim LewisMemberHi Mahmoud,
Please see test case OsvvmLibraries/AXI4/Axi4/TestCases/TbAxi4_ReleaseAcquireManager1.vhdBest Regards,
JimMarch 23, 2024 at 18:36 #2363Jim LewisMemberFor the next release of OSVVM, I have added an AlertLogID input to SafeResize and all of the OSVVM VC specify the ID on the call to SafeResize. I also updated the error message to be of the following form:
Alert ERROR in AxiManager_1, SafeResize: value changed on resize. Original value: 01AF, Resized value: AF
Hopefully this will clear up the source of the issue in the future.
March 17, 2024 at 16:28 #2362Jim LewisMemberStep 1: If you have complex clock domain crossings, you probably need a clock domain crossing tool. Especially to find anything that might loop back.
Step 2: Use your directed cases to explore the relationships you understand.
Step 3: Add jitter to your clock (or clocks depending on the number of clock domains you have) so that your simulation explores more than interactions caused my the differences in frequency.March 11, 2024 at 18:27 #2352Jim LewisMemberHi Joseph,
This is coming from the call to SafeResize that is inside of OSVVM verification components. What it is telling you is that the testbench put a value with more one’s on the left hand side of it in the call to a transaction, such as Write, Read, or Send, than is used by the verification component.The error will happen when you call Send(StreamRec, X”1FF”) and the VC only uses 8 bits of data internally. Hence, the ‘1’ value on the left hand side of the test case supplied value is thrown away. Instead call Send(StreamRec, X”FF”) and everything is fine. Even calling Send(StreamRec, X”00FF”) is ok as it would be throwing away ‘0’ and the value is not modified.
For a test that has this sort of ERROR, the test case that uses a value of X”1FF”, but expects it to be interpreted as X”FF” is at a minimum obfuscating the intent of the test – as a result OSVVM counts this as an ERROR. VHDL+OSVVM is intended to be able to be used in safety critical environments where this sort of thing is important.
Best Regards,
JimFebruary 16, 2024 at 01:10 #2346Jim LewisMemberHi Jake,
Just checked the Questa command reference manual. Good catch. It is an easy fix.
In the file, VendorScripts_Siemens.tcl, all of the specialization is done. In there
the analyze for Verilog/SystemVerilog is:
`tcl
proc vendor_analyze_verilog {LibraryName FileName args} {
set AnalyzeOptions [concat [CreateVerilogLibraryParams “-l “] -work ${LibraryName} {*}${args} ${FileName}]
# puts “vlog $AnalyzeOptions”
eval $::osvvm::shell vlog {*}$AnalyzeOptions
}
`
Change it to (the change follows the text CreateVerilogLibraryParams):
`tcl
proc vendor_analyze_verilog {LibraryName FileName args} {
set AnalyzeOptions [concat [CreateVerilogLibraryParams “-L “] -work ${LibraryName} {*}${args} ${FileName}]
# puts “vlog $AnalyzeOptions”
eval $::osvvm::shell vlog {*}$AnalyzeOptions
}
`
Let me know how it goes.Best Regards,
JimFebruary 1, 2024 at 21:31 #2341Jim LewisMemberHi Jake,
This is something that one of the Siemens AEs has talked to me about and has worked on. I will have to see if he has something ready to submit for OSVVM. The plan is that Visualizer will simply use a separate VendorScripts_Visualizer.tcl. With that it should be fairly easy to do whatever visualizer needs done as all the hooks are already there.If for some reason the Siemens AE does not share, we can talk and get this updated.
Best Regards,
JimJanuary 1, 2024 at 21:08 #2333Jim LewisMemberHi 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,
JimNovember 27, 2023 at 21:47 #2326Jim LewisMemberHi Lukas,
Do you have the output of LinkLibraryDirectory? If it is working ok, it should be something like the following:LinkLibraryDirectory C:/tools/VHDL_LIBS/QuestaSim-2022.01 # set CurrentSimulationDirectory C:/tools/sim/questa # vmap defaultlib C:/tools/VHDL_LIBS/QuestaSim-2022.01/defaultlib # vmap osvvm C:/tools/VHDL_LIBS/QuestaSim-2022.01/osvvm # vmap osvvm_axi4 C:/tools/VHDL_LIBS/QuestaSim-2022.01/osvvm_axi4 # vmap osvvm_common C:/tools/VHDL_LIBS/QuestaSim-2022.01/osvvm_common # vmap osvvm_cosim C:/tools/VHDL_LIBS/QuestaSim-2022.01/osvvm_cosim # vmap osvvm_dpram C:/tools/VHDL_LIBS/QuestaSim-2022.01/osvvm_dpram # vmap osvvm_dpram_pt C:/tools/VHDL_LIBS/QuestaSim-2022.01/osvvm_dpram_pt # vmap osvvm_ethernet C:/tools/VHDL_LIBS/QuestaSim-2022.01/osvvm_ethernet # vmap osvvm_uart C:/tools/VHDL_LIBS/QuestaSim-2022.01/osvvm_uart
If the precompiled altera libraries are not all in the same directory, you may have to do several LinkLibraryDirectory.
You probably also need to look into which libraries does it find and which ones are missing and where are they located.
Best Regards,
JimP.S. With ModelSim/QuestaSim, watch out for spaces in the library path. You can work around issues if you can compose a relative path to the libraries without the space, but otherwise, you may be out of luck – that is one tool bug that I cannot find a good work around for.
November 6, 2023 at 12:48 #2315Jim LewisMemberIf you look at the OSVVM *.pro compile scripts you will note there are a number of places where we do not compile certain things – because of a bug in a particular tool.
Note these ports are not OPEN. but instead they have a null range, which is a valid range. Please submit a bug against Xcelium for this issue.
I will make a note to update OSVVM’s scripts not to compile this capability for Cadence at this time. Maybe the solution is to add an additional file that builds this with a small range (0 to 0) for Cadence rather than a NULL range.
October 27, 2023 at 09:51 #2312Jim LewisMemberHi Rishi,
The issue with 10.5b looks like a bug in that version of the tool. I don’t test with versions that old.Best Regards,
JimOctober 27, 2023 at 09:49 #2311Jim LewisMemberHi Rishi,
The issue with 2022.4 (quarter or release in 2022 not sure) / 2022.10 (10 probably is month) that says:# ** Error: vhdl_src/std/standard.vhd: (vcom-1576) expecting IDENTIFIER or BODY.
Is a tool install issue. OSVVM does not analyze (compile) the standard package.
Most recently I had been testing with Questa release 2022.1. It worked well without the issues you saw in 2022.4. I am installing 2023.4 soon and will start testing with that.
Best Regards,
JimOctober 6, 2023 at 00:54 #2300Jim LewisMemberHi Adam,
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?
Jim
October 5, 2023 at 04:53 #2297Jim LewisMemberIn 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,
-gname=value
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:
-g/top/UUT/DISPB_4_OMUX/TimingChecksOn=false
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 4, 2023 at 01:13 #2295Jim LewisMemberHave 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 ...
-
AuthorPosts