OSVVM’s 2020.12 release introduces Virtual Transaction Interfaces (VTIs). VTIs allow us to connect to verification components (VCs) without using any ports or signals in the testbench framework. This cap […]
Testing for OSVVM 2020.12 release was done on RivieraPro 2020.10 and ModelSim 2020.01. Unfortunately I did not test with QuestaSim 2020.04 (my licenses are for a machine that I just finished setting up today).
There appears to be a subtle bug in QuestaSim that causes a SEGV Fatal when doing Burst Transfers (such as TbAxi4_MemoryBurst1). I…[Read more]
2020 was quite a year.
While everything else was quite dark, OSVVM had a great 2020. Normally I travel for work around 75K air miles. 2020 none. This saved a lot of time. All of that time (and more) […]
Ouch. Did you report the tool bug to Synopsys? Did they respond?
I would have to think about a work around. Maybe if generics were
added to the package to constrain the size of DataToModel, DataFromModel,
ParamToModel, and ParamFromModel – and they were sized to match the largest
item in the system, it should be ok – maybe after…[Read more]
Jim Lewis wrote a new post, VHDL: Shared Variables, Protected Types, and Memory Modeling 1 month ago
VHDL-93 (IEEE 1076-1993) created shared variables of an ordinary type as a temporary solution – which was noted in the standard document (aka LRM). VHDL-2000 (IEEE 1076-2000) created protected types as the onl […]
Verification components have become an essential part of a structured VHDL environment. In OSVVM we implement verification components as an entity and architecture. This provides RTL engineers with a fam […]
What we find is that users have more influence over vendors than I do. To be fair to them though, OSVVM has had numerous updates through COVID. One benefit of teaching on-line and not traveling is that I have had more time to work on OSVVM.
One of my goals is to get the OSVVM compile scripts working under Cadence Xcelium. If you…[Read more]
The OSVVM 2020.10 release is finally out.
Yes I realize it is now late November. So why 2020.10? In late October, the code was done and marked as 2020.10 with the expectation that the […]
One of the main things what OSVVM models differentiate from other available solutions is the extensive documentation. I like that very much.
I remember closed source models which only have very little documentation and second, were written very poor. I used an FPGA-vendors eMMC model some years ago which was created in addition to the MMC controller unit we use. The model was only very basic and without doc, only the controller had some basic docs. After digging through the (Verilog) code I added some fundamental things like an associative array to allow data write/read checks coverage and assertions. Even with my little knowledge of (System) Verilog I was able to do that better.
I have been thinking about package that would have some global signaling events – such as
signal TestDone : integer_barrier;
signal ResetDone : integer_barrier;
We could add something like:
signal TestErrorCount : integer ;
The idea is that if all tests had access to something like this, then it could be picked up automatically by…[Read more]
This is definitely in scope of a good discussion.
In 2020.08, OSVVM upgraded our scripting. Currently everything is TCL based, but the intent is to also have a BASH based executor of the scripting environment. One of the goals of the current approach is to create a simulation execution environment that is tool independent – ie:…[Read more]
Your Script has a couple of things out of order. Specifically
VendorCovApiPkg.vhd must be compiled before CoveragePkg.vhd,
OsvvmContext.vhd must be compiled last (or almost last),
RandomPkg.vhd must be compiled before CoveragePkg.vhd,
ScoreboardGenericPkg.vhd must be compiled before ScoreboardPkg_int.vhd and ScoreboardPkg_slv.vhd.
Our compile…[Read more]
Sorry I missed your additional discussion.
This warning is ok. The code is legal VHDL code. It would be more obvious if they would print the message as:
Warning: NULL_RANGE_TYPE has a null range, Range 0 downto 1
Null ranges are legal. Often people end with them unintentionally, so the vendors decided to issue a warning.…[Read more]
> Is OSVVM supported by the latest Synopsys VCS-MX?
It is my understanding that it is, however, I have not done any testing with it – yet. Hopefully toward the end of the year, that will be changing.
> I didn’t notice any scripts in the OsvvmLibaries/Scripts repository.
It is on my todo list. Does VCS-MX have a tcl interface or do y…[Read more]
#2 Did you run the testbench examples before modifying them? The test TbAxi4_MemoryBurst (which runs when you do
build ../OsvvmLibraries/AXI4/Axi4/testbench) does bursts. The first burst in the test is 3 32 bit words – IE 12 bytes and the address is word aligned.
What is 1 wider? Did you mean 64 bits? AXI data supports a power of 2…[Read more]
#1 I use “run all” to run my tests. std.env.stop will stop the test. However, stop works much like a breakpoint, so the simulation can be continued. I am ok with this.
If you wanted to prohibit the testbench from running further after it stops, use std.env.finish instead. It also allows an integer parameter, so you can call it…[Read more]
>1. Could the test bench be stopped gracefully by stopping all clocks?
Do you have a method to gracefully stop clocks? Everything I have seen
has overhead incurred at least once per clock cycle (or some multiple of
the clock cycle).
OTOH, I really like std.env.stop. It only incurs overhead when
it is actually stopping the…[Read more]
3. Correct. The 2020.08 Axi4Responder_Transactor.vhd is intended to be a register access model and does not support bursting. As you noted, Axi4Memory.vhd, implements memory models and does support bursting. This is noted in the README.md at: https://github.com/osvvm/AXI4.
Do you need a transactor that supports bursting? It…[Read more]
2. The test sequencer interface to AXI verification component burst FIFO is 8 bits. The AXI verification component assembling this into the size of the data bus. So you will always push bytes into the FIFO – even if you make the data bus bigger or smaller. It was tested with a 32 bit AXI data bus, however, it is intended to…[Read more]
4. Typo! You are correct, AxRegion should be 4 bits. I will fix that
in the next release. Anything else like that is an issue?
What do you mean you had to change the width to make it compile? Is this to
connect it to your design? It compiles and runs fine with the OSVVM models
which all use the same incorrectly sized…[Read more]
First, thanks for the feedback.
Are you using this with a particular design?
You have four questions, so I will give 4 separate answers.
- Load More