Jim Lewis

Hi Richard,
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]

Hi Richard,
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]

Hi Tim,
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]

Hi Tim,
> 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]

Hi Chengshan,

>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]

Hi Chengshan,

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]

Hi Chengshan,

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]

Hi Chengshan,

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]

Hi Chengshan,
First, thanks for the feedback.

Are you using this with a particular design?

You have four questions, so I will give 4 separate answers.

Best Regards,
Jim