uvvm / uvvm

UVVM (Universal VHDL Verification Methodology) is a free and Open Source Methodology and Library for very efficient VHDL verification of FPGA and ASIC – resulting also in significant quality improvement. Community forum: https://forum.uvvm.org/ UVVM.org: https://uvvm.org/

UVVM

UVVM (Universal VHDL Verification Methodology) is a free and Open Source Methodology and Library for making very structured VHDL-based testbenches.

Overview, Readability, Maintainability, Extensibility and Reuse are all vital for FPGA development efficiency and quality. UVVM VVC (VHDL Verification Component) Framework was released in 2016 to handle exactly these aspects.

Full documentation can be found on https://uvvm.github.io.

UVVM consists currently of the following elements:

• Utility Library
• VVC (VHDL Verification Component) Framework - Including Utility Library
• BFMs (Bus Functional Models) to be used with any part of UVVM (See below for currently supported interfaces for UVVM)
• VVCs to be used with UVVM VVC Framework and may be combined with BFMs (see overview below)
• Scoreboards to ber used as supplementary functionality at any level
• Enhanced randomisation - Included under the Utility library, automatically available when compiling Utility Library
• Functional Coverage - Included under the Utility library, automatically available when compiling Utility Library
• Specification Coverage - Aka Requirement Coverage og Requirement tracking - Includes a Requirements Traceability Matrix
• Error Injector
• more to come...

For starters

Please note that UVVM has two different complexity levels. The VVC Framework and VVCs for medium to advanced testbenches, and the Utility library and BFMs for simple usage - and as a basis for more advanced testbenches. Novice users are strongly recommended to first use UVVM Utility library and BFMs. This has a very low user threshold and you will be up and running in an hour. Please see Utility Library for an introduction. The VVC framework is slightly more complex, but it has been simplified as far as possible to allow efficient development of good quality testbenches. As a starter you may also want to include Enhanced Randomisation, Functional Coverage or Specification coverage

Note that a dedicated repository (UVVM_Light)](https://github.com/UVVM/UVVM_Light) has been provided to simplify getting started using Utility Library and BFMs. Here all the code and documentation have been collected in a single directory, and only a single VHDL library is used. The documentation and code are 100% the same as for the full UVVM.

Please also see Getting Started with UVVM.

For what do I need this VVC Framework?

UVVM is a verification component system that allows the implementation of a very structured testbench architecture to handle any verification complexity - from really simple to really complex. A key benefit of this system is the very simple software-like VHDL test sequencer that may control your complete testbench architecture with any number of verification components. This takes overview, readability and maintainability to a new level. As an example a simple command like uart_expect(UART_VVCT, my_data), or axilite_write(AXILITE_VVCT, my_addr, my_data, my_message) will automatically tell the respective VVC (for UART or AXI-Lite) to execute the uart_receive() or axilite_write() BFM respectively.

What are the main benefits of using this system?

The really great benefit here is the unique overview, readability, maintainability, extensibility and reuse you get from having the best testbench architecture possible - much in the same way as a good architecture is also critical for any complex FPGA design. Another major benefit here is that any number of commands may be issued at the same time from the test sequencer - thus allowing full control of when an access is to be performed, and the commands are understandable "even" for a software developer ;-) The commands may be queued, skewed, delayed, synchronised, etc. - and a super-set for applying constrained random or other sequences of data may of course also be applied. This yields an excellent control over your testbench and VVCs.

For debugging you can select logging of a command when it is issued from the sequencer, when it is received by the VVC, when it is initiated by the VVC and/or when it has been executed towards the DUT. This allows full overview of all actions in your complete testbench.

UVVM is free and open source and has standardised the way to build good testbench architectures and VVCs so that reuse is dead simple, and allows the FPGA community to share VVCs that will work together in a well-structured test harness. You may of course combine UVVM with any other legacy or 3rd party testbenches or verification models.

Main Features

• Very useful support for checking values, ranges, time aspects, and for waiting for events inside a given window
• An extremely low user threshold for the basic functionality - like logging, alert handling and checkers
• A very structured testbench architecture that allows LEGO-like testbench/harness implementation
• A very structured VHDL Verification Component (VVC) architecture that allows simultaneous activity (stimuli and checking) on multiple interfaces in a very easily understandable manner
• An easily understandable command syntax to control a complete testbench with multiple VVCs
• The structure and overview are easily kept even for a testbench with a large number of VVCs
• A VVC architecture that is almost exactly the same from one VVC to another - sometimes with only the BFM calls as the differentiator, thus allowing an extremely efficient reuse from one VVC to another
• A VVC architecture that easily allows multiple threads for e.g. simultaneous Avalon Command and Response
• A VVC architecture that allows simple encapsulation for ALL verification functionality for any given interface or protocol
• Allows VVCs to be included anywhere in the test harness - or even inside the design itself
• A logging and alert system that supports full verbosity control of functionality and hierarchy
• A logging system that lets you easily see how your commands propagate from your central test sequencer to your VVCs - through the execution queue - until it is executed and completed towards the DUT
• Includes randomisation and functional coverage to be included in the central test sequencer - or even better - inside the VVCs in the local sequencers for better control and encapsulation
• Simple integration with regression test tools like Jenkins and HDLRegression
• Quick references are available for UVVM Utility Library, VVC Framework and all the BFMs/VVCs/VIP
• May insert delay between commands – from sequencer, - and thus the only system to target cycle related corner cases
• Simple handling of split transactions and out of order protocols
• Common commands to control VVC behaviour
• Simple synchronization of interface actions – from sequencer
• May use Broadcast and Multicast

Available VVCs and BFMs

These VVCs and BFMs could be used inside a typical UVVM testbench, but they could also be used stand-alone - e.g. as a BFM or VVC to handle just the AXI4-Lite interface with everything else being your proprietary testbench and methodology.

• AXI4
• AXI4-Lite
• AXI-Stream - master and slave
• Avalon MM
• Avalon ST - master and slave
• Ethernet
• SBI (Simple Bus Interface - A single cycle simple parallel bus interface)
• UART
• SPI - master and slave
• I2C - master and slave
• GPIO
• GMII - Transmit and receive
• RGMII - Transmit and receive
• Wishbone
• Clock Generator
• Error Injector
• More are coming

IMPORTANT The VIPs complies with respective protocols and thus allows a normal access towards the interface. The VIPs are not protocol checkers.

Prerequisites

UVVM is tool and library independent, but it must be compiled with VHDL 2008. UVVM has been tested with the following simulators:

• Modelsim
• Riviera-PRO
• Questa Sim
• GHDL

Note Questa Sim version 19.2 and Modelsim version 19.2 have known bugs that might prevent UVVM from working properly.

Python is required if you want to execute the VVC generation scripts

Introduction to VVC Framework - including manuals

All documents including powerpoint presentations are available in the doc (and uvvm_vvc_framework/doc) directory on GitHub. These are just fast access links to some interesting info:

• *'The critically missing VHDL testbench feature - Finally a structured approach'* - A brief introduction
• *'VVC Framework Manual'* - The user manual

License

Copyright 2022 UVVM Authors and Contributors List
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 and in the provided LICENSE.TXT.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

UVVM Maintainers

The UVVM steering group (currently Inventas and EmLogic, Norway) has released UVVM as open source and both EmLogic and Inventas are committed to develop this system further. We do however appreciate contributions and suggestions from users.

Please use Pull requests for contributions and we will evaluate them for inclusion in our release on the master branch.

uvvm's Issues

Declaring t_axilite_if signal

How does one declare the the t_axilite_if signal to connect to the vvc in the test harness. The unconstrained arrays need to be constrained I believe.

I tried this.
constant GC_ADDR_WIDTH : integer := 8;
constant GC_DATA_WIDTH : integer := 32;
constant GC_STRB_WIDTH : integer := GC_ADDR_WIDTH/8;

signal axi_ctrl :t_axilite_if(
write_address_channel.awaddr(GC_ADDR_WIDTH),
write_data_channel.wdata(GC_DATA_WIDTH),
write_data_channel.wstrb(GC_STRB_WIDTH),
read_address_channel.araddr(GC_ADDR_WIDTH),
read_data_channel.ardata(GC_DATA_WIDTH));

But get
(vcom-1356) Bad record element constraint (indexed name) for record type bitvis_vip_axilite.axilite_bfm_pkg.t_axilite_if

Is there an example AXI LITE Test Harness?

Vendor and tool independent compile order files

Hello,

it would be nice if UVVM would provide vendor and tool independent compile order files. Compile order files are simple text files containing one VHDL filename per line (ideally as a relative path to the root directory).

This would allow for instance PoC or GHDL to adapt it's UVVM pre-compile scripts faster to UVVM changes. All VIP pre-compilations would be independent of UVVM changes. Only new VIPs need to be added to a list of VIPs in such a pre-compile script.

Such compile order files could also be used in UVVMs TCL files and replace all calls to vcom by a generic solution. Changing files sets of a VIP would then be limited to changing the compile order file in stead of adjusting the TCL files.

Other users of such compile order files: Xilinx ISE, Xilinx Vivado

Wishbone BFM

It would be really nice to have a Wishbone BFM supporting either classic or pipelined mode.
I think that "basic" set of signals (DAT_O, DAT_I, WE, SEL, CYC, STB, STALL, ACK, ERR) would be sufficient for most users.

Incorrect behaviour of tvalid in AXI4-Stream BFM transmit procedure when using independent tready assertion

The AXI4-Stream BFM transmit procedure does not deassert tvalid correctly when the slave tready assertion is independent of the master tvalid signaling (as for example indicated by the third timing diagram on this page). This is imo covered by the AMBA specification.

A quick fix that worked for me is using rising_edge(clk) instead of config.clock_period when waiting for tready.

...
if v_wait_for_next_transfer_cycle then
    -- wait for config.clock_period;
    wait until rising_edge(clk);
    while axistream_if.tready = '0' loop
        wait for config.clock_period;
...

Let me hear your thoughts :).
Ben

IRQC demo compilation fails - bitvis sbi compile_bfm.do missing

I'm following the getting started instructions and the IRQC demo fails because compile_bfm.do for bitvis_vip_sbi is missing. To reconstruct the problem, fetch the master branch and then from ModelSim:

> pwd
/foo/bar/UVVM/bitvis_irqc/script
> do compile_and_sim_all.do
.. compile output ..
# ** Error: Cannot open macro file: ../../bitvis_irqc/..//bitvis_vip_sbi/script/compile_bfm.do
# Executing ONERROR command at macro ./../../bitvis_irqc/script/compile_tb_dep.do line 64

Compile script reference to sim

Hej

I'm not sure what the intention is: The compile tcl-scripts reference the sim directory for each part. This directory however is not in the repo in all cases.
I "fixed" that in some scripts by replacing "sim" with "scripts" (see scriptpath-branch in my fork).
But maybe you would prefer to have the sim-directory everywhere?

BR/emanuel

VIP BFM AXI4-Lite with ALDEC Active-HDL 9.2 simulator

Hi,
I'm trying to use the VIP BFM AXI4-Lite with a proprietary testbench and methodology for a custom application. I'm running the testbench in ALDEC Active-HDL 9.2 simulator.
When I try to compile axilite_bfm_pkg.vhd I get this error from Active-HDL:

# Compile Package "axilite_bfm_pkg"
# Compile Package Body "axilite_bfm_pkg"
# Error: DAGGEN_0007: axilite_bfm_pkg.vhd : (0, 0): Error during conversion C:\Users\ADMINI~1\AppData\Local\Temp\7512_349979928axilite_bfm_pkg_axilite_bfm_pkg.dag to C:\Users\ADMINI~1\AppData\Local\Temp\7512_349979928axilite_bfm_pkg_axilite_bfm_pkg._x86.bin
# Compile failure 1 Errors 0 Warnings  Analysis time :  78.0 [ms]

And when I try to simulate I get:

# ELAB2: Elaboration final pass...
# ELAB2: Fatal Error: ELAB2_0030 Error while reading binary code for unit "axilite_bfm_pkg".
# KERNEL: Error: E8005 : Kernel process initialization failed.
# Error: Fatal error occurred during simulation initialization.

I am sure there are no syntax error in the file. I am compiling with VHDL-2008. Can you help me? Is Active-HDL supported? If not, why it shouldn't?

Thanks, Andrea

t_slv_array vs t_byte_array

Hi

We get ambiguity errors due to the added declaration of t_slv_array. Calls to axistream_transmit (for example) as proposed in the QuickRef with (x"00", x"00"...) are indeed not unambiguous anymore (correct me if I'm wrong here): A t_slv_array with 8-bit payload is exactly a t_byte_array.

How do you handle this collision?

Thanks and best regards,
emanuel

vvc_generator.py

There is a typo in vvc_generator.py for READ command calling old store_result procedure:

            file_handle.write("        --     work.td_vvc_entity_support_pkg.store_result(instance_idx  => GC_INSTANCE_IDX,\n")
            file_handle.write("        --                                       cmd_idx       => v_cmd.cmd_idx,\n")
            file_handle.write("        --                                       data          => v_read_data);\n")

should be:

            file_handle.write("        --     work.td_vvc_entity_support_pkg.store_result(result_queue => result_queue,\n")
            file_handle.write("        --                                       cmd_idx       => v_cmd.cmd_idx,\n")
            file_handle.write("        --                                       result        => v_read_data);\n")

Missing release tag

Hello,

the history of commits notes that the current master branch is at version 2.0.2 or higher, but no tag was released. Please correct this inconsistency.

Kind regards
Patrick

Common compile_src.do script bug

All compile_src.do have a common bug in the following code

} elseif {$argc >= 2} {
echo "\nUser specified source and target directory"
quietly set target_path "$2"
quietly set default_target 0

There is missing : quietly set source_path "$1"

So the code should be:

} elseif {$argc >= 2} {
echo "\nUser specified source and target directory"
quietly set source_path "$1"
quietly set target_path "$2"
quietly set default_target 0

Critical warnings from GHDL: Pure function "..." cannot call (impure) procedure "...".

I got further in integrating UVVM into one of our testbenches.

GHDL unveils more critical warnings:

uvvm_util\src\bfm_common_pkg.vhd:139:15:warning : pure function "normalize_and_check" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:142:15:warning : pure function "normalize_and_check" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:150:17:warning : pure function "normalize_and_check" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:153:17:warning : pure function "normalize_and_check" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:164:17:warning : pure function "normalize_and_check" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:202:15:warning : pure function "normalize_and_check" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:205:15:warning : pure function "normalize_and_check" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:213:17:warning : pure function "normalize_and_check" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:218:19:warning : pure function "normalize_and_check" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:223:21:warning : pure function "normalize_and_check" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:240:17:warning : pure function "normalize_and_check" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:265:14:warning : pure function "normalise" cannot call (impure) procedure "deprecate"
uvvm_util\src\methods_pkg.vhd:279:13:warning : (procedure "deprecate" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:268:15:warning : pure function "normalise" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:271:15:warning : pure function "normalise" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:279:17:warning : pure function "normalise" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:282:17:warning : pure function "normalise" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:293:17:warning : pure function "normalise" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:329:14:warning : pure function "normalise" cannot call (impure) procedure "deprecate"
uvvm_util\src\methods_pkg.vhd:279:13:warning : (procedure "deprecate" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:332:15:warning : pure function "normalise" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:335:15:warning : pure function "normalise" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:343:17:warning : pure function "normalise" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:348:19:warning : pure function "normalise" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:353:21:warning : pure function "normalise" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:370:17:warning : pure function "normalise" cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:121:12:warning : pure subprogram body cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:184:12:warning : pure subprogram body cannot call (impure) procedure "tb_error"
uvvm_util\src\methods_pkg.vhd:205:13:warning : (procedure "tb_error" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:249:12:warning : pure subprogram body cannot call (impure) procedure "deprecate"
uvvm_util\src\methods_pkg.vhd:279:13:warning : (procedure "deprecate" is defined here)
uvvm_util\src\bfm_common_pkg.vhd:313:12:warning : pure subprogram body cannot call (impure) procedure "deprecate"
uvvm_util\src\methods_pkg.vhd:279:13:warning : (procedure "deprecate" is defined here)

Procedures are always considered "impure", whereas functions are "pure" by default. So all the listed functions need to be marked as impure.

Finally I get this error message:

uvvm_vvc_framework\src_target_dependent\td_queue_pkg.vhd:21:9: body of package "td_queue_pkg" was never analyzed

I'll investigate in the next days if this error is caused by GHDL itself or by UVVM.

IRQC Testbench Simulation fails with GHDL due to XX's

The last days I was trying to compile and test run UVVM with GHDL V0.34dev. I started with the IRQC model and after figuring out the correct compilation sequence simulated the example. Unfortunately the simulation ended prematurely due to XX's coming out from dout signal.

Setup:

• I got the latest GHDL (c94da9d37438) and
• UVVM (103a0abc4b4b) (with git extension on Hg-mercurial).
• Compiled GHDL with MSYS2 and MinGW32-w64.
• Then using an MSYS2 window, I got to the folder of UVVM\bitvis_irqc\sim.
• Then run comp.bat (added .txt extension to attach here).

Problem:
Simulation stops with an error. The sim_fail.log.txt shows the error message. See the waveform below.

Resolution
It seems that changing the following line in the port definition of irqc_pif.vhd:
dout : out std_logic_vector(7 downto 0) := (others => '0');
to:
dout : out std_logic_vector(7 downto 0) := (others => 'L');

resolves the problem as seen from the log file and the waveform

Full simulation shown here:

Alternate Test
Trying to figure out if it was a glitch of GHDL I created a separate testbench, where the original code irqc_pif.vhd worked fine.

Here is the zip file with the simplified testbench.
TestGHDL.zip

Seems to me that there should be an issue with UVVM (maybe in combination with GHDL?).

sim_ok.log.txt
sim_fail.log.txt
test_comp.bat.txt

Version mismatch for OSVVM

This README.md shows the OSVVM version shipped with UVVM is 2016.11, but the version tag shows the latest version available on GitHub: 2018.04.

Use multiple instances of a VVC concurrently

Hi,
I have a design with multiple instances of the same interface.
The testbench has N instances of the same VVC (each one with a different GC_INSTANCE_IDX) and I can use each VVC from one single process, one VVC at time.
But if I try to use all the VVCs at the same time (one process doing VVC calls for each VVC) I get an error about missing resolution function for the *_VVCT (t_vvc_target_record) signal.
I think the problem is that the *_VVCT signal is defined in a package (vvc_methods_pkg) and hence it is shared across all the VVCs.
Have you encountered the same problem before?

Thanks,
Matteo

AXI stream VVC handles max wait cycles incorrectly

When you set up a AXI stream VVC transmitter and the tready signal will go on and off multiple times during a transfer, the max wait cycles error will occur when the accumulated wait cycles is more than max wait cycles. I assume the error should have been asserted only when a single wait period exceeds the max wait cycles.

bitvis_vip_scoreboard_pkg: check_queue_empty

procedure check_queue_empty(
      constant instance : in positive
    ) is
    begin
      check_value(not vr_sb_queue.is_empty(VOID), TB_ERROR, "The queue is empty", vr_scope, ID_NEVER);
    end procedure check_queue_empty;

I think VOID should be replaced with instance?

VVC Name to long

The max length of VVC name is 14. vcc_generator should display the max value.
C_LOG_SCOPE_WIDTH is 20 : 4 character for "_VVC" and 2 for ',' and number.
vr_scope : string (1 to 30) is to small if C_LOG_SCOPE_WIDTH is only changed , as the generator suggests
Suggestion: a new constant for the VVC_NAME length

adaptation_pkg.vhd
constant C_VVC_NAME_WIDTH : natural := 14;
constant C_LOG_SCOPE_WIDTH : natural := C_VVC_NAME_WIDTH+4+2; -- "_VVC" & ',' and number

ti_generic_queue_pkg.vhd
variable vr_scope : string(1 to C_LOG_SCOPE_WIDTH+13) := (others => NUL);

Questa strange vector width change

Hi

My TH has two axistream VVCs, one being 32 bits and one 64 bits. For one test, the TB first sends a frame to the 64 bit VVC, then a frame to the 32 bit VVC.
When I just add another test after this, the 64 bit command fails with questa complaining about bitwidth issues in axistream_transmit (axistream_bfm_pkg): It sees some lhs as 32 bit and rhs as 64 bits.

Keeping the transmits in bitwidth-order (i.e. breaking the test and first sending two frames to 64 bits, then two frames to 32 bits), everything works fine.

Replacing the axistream_if record in axistream_transmit from axistream_bfm_pkg (the core function that is used by all others) with individual signals, the error is gone.

I assume

• that questa somehow fixes the vector length in the vector internally (-> questa bug)
• that you cannot do much about it
• that signal records and function calls in VHDL are poorly supported by Questa (see other issues)

I hope that I find some time to file another SR at mentor...

Best regards
emanuel

function get_queue_is_full is not working properly

If "queue_size_in_bits" isn't divisible by "v_count" the below IF statement from ti_data_queue_pkg.vhd doesn't trigger.

The IF statement should rather be bigger than or equal, instead of only equal.

"if v_count(queue_idx) >= v_queue_size_in_bits(queue_idx) then"

//--- Code snippet from ti_data_queue_pkg.vhd ---//

-- get_queue_is_full

impure function get_queue_is_full(
queue_idx : natural
) return boolean is
begin
check_value(v_queue_initialized(queue_idx), TB_WARNING, "get_queue_is_full called, but queue " & to_string(queue_idx) & " not initialized.", v_scope.all, ID_NEVER);
if v_count(queue_idx) = v_queue_size_in_bits(queue_idx) then
return true;
else
return false;
end if;
end function;

How to check a single I²C address call with I2C_VVC?

I found 2 check procedures for a I²C slave: With one data byte and with 4 data bytes. How can I check a simple address issued by the master to test for a slave response?

Other questions:

• How do I distinguish read and write operations on the bus by enqueuing check commands?
• How How do I await restart conditions after n transferred bytes?

---

It's valid to the protocol to just address a slave, which even isn't required to acknowledge. This is sometimes called a quick command. It can carry up to 1 bit of information: The read/write bit. In addition to this this command can be used to discover the bus.

Register UVVM at 'awesome-vhdl' list

I created a new awesome list based on the awesome-python list.

It's available here: https://github.com/VHDL/awesome-vhdl

Please register UVVM as a verification framework (or propose another or new category) in that list via pull request.

---

I this list ist filled with some projects, I want to register it at the list of lists: awesome list

Issue with i2c_slave_receive procedure when I2C VIP used as Master and Slave in a Test Harness

Following instances are used in a Test Harness, no additional instantiations done. This plaform is created to check Master and Slave behaviors of the I2C VIP.
i1_i2c_vvc: entity bitvis_vip_i2c.i2c_vvc
generic map(
GC_MASTER_MODE => true,
GC_INSTANCE_IDX => 1,
GC_I2C_CONFIG => C_I2C_BFM_CONFIG_DEFAULT, -- Behavior specification for BFM
GC_CMD_QUEUE_COUNT_MAX => 1000,
GC_CMD_QUEUE_COUNT_THRESHOLD => 950,
GC_CMD_QUEUE_COUNT_THRESHOLD_SEVERITY => warning,
GC_RESULT_QUEUE_COUNT_MAX => 1000,
GC_RESULT_QUEUE_COUNT_THRESHOLD => 950,
GC_RESULT_QUEUE_COUNT_THRESHOLD_SEVERITY => warning
)
port map(
i2c_vvc_if => i2c_vvc_if
);

i2_i2c_vvc: entity bitvis_vip_i2c.i2c_vvc
generic map(
GC_MASTER_MODE => false,
GC_INSTANCE_IDX => 2,
GC_I2C_CONFIG => C_I2C_BFM_CONFIG_DEFAULT, -- Behavior specification for BFM
GC_CMD_QUEUE_COUNT_MAX => 1000,
GC_CMD_QUEUE_COUNT_THRESHOLD => 950,
GC_CMD_QUEUE_COUNT_THRESHOLD_SEVERITY => warning,
GC_RESULT_QUEUE_COUNT_MAX => 1000,
GC_RESULT_QUEUE_COUNT_THRESHOLD => 950,
GC_RESULT_QUEUE_COUNT_THRESHOLD_SEVERITY => warning
)
port map(
i2c_vvc_if => i2c_vvc_if
);

In a testbench used following two commands
i2c_slave_receive(I2C_VVCT, 2, 1, "One byte from master to slave");

i2c_master_transmit(I2C_VVCT,1,C_FPGA_DEVICE_ID, x"AA", "I2C TX", FALSE);

Following is the error GOT when the Master is about to generate stop condition. When debugged @ low level, found i2c_slave_receive procedure checking the timeout 20ns check before Master is able to assert STOP condition.
UVVM: *** FAILURE #1 ***
UVVM: 178240 ns I2C_VVC,2
UVVM: await_value(std_logic 1, 0 ns, 20 ns) => Failed. Timed out after 20 ns. 'One byte from master to slave' [1]

Let me know if there is any mistake in the usage.

axistream - Fatal Error

Hi everybody,

I'm using Sigasi with Riviera PRO and i ran into this error trying to simulate my design with a axistream interface:
Fatal Error: RUNTIME_0043 axistream_bfm_pkg.vhd (1228): Value -1823774432 out of range (0 to 2147483647)

Which refers to this code in axistream_receive() procedure in axistream_bfm_pkg.vhd:
constant c_num_strb_bits_per_word : natural := axistream_if.tstrb'length;

I'm using the axistream vvc in slave mode with a data width of 32 Bit, no user data, not using tdest, tkeep or tid.
tdest, tid, tkeep are running into this or similiar errors.

Code snippets:

---

Please help me, i dont know how to fix this issue.

regards,
Max

endianness of axistream

Hej

The current axistream VVC and BFM convert t_slv_array payloads with FIRST_BYTE_LEFT to t_byte_array. This corresponds to big endian.

I think this should be configurable. The axistream spec does not contain a remark about endianness at all, the full axi spec leaves that open on purpose.

Best regards,
emanuel

Change log is incomplete

Hello,

the change log doesn't list that version 2.x removed OSVVM [removed in commit ab7ac88].
It should either state where to find OSVVM on GitHub or note that OSVVM is no longer supported / required for UVVM.

Moreover the change log dropped items for already tagged and release versions.

Kind regards
Patrick

avalon_mm_bfm_pkg readdatavalid, wrong data

Hi,
there seems to be a problem in the avalon_mm_bfm if you configure it with use_readdatavalid => true.

If avalon_mm_if.readdatavalid is high the bfm waits another rising edge and a bit and then samples avalon_mm_if.readdata.

I fixed this by commenting out the waits....

@@ -581,8 +582,8 @@ package body avalon_mm_bfm_pkg is
       if timeout then
         alert(config.max_wait_cycles_severity, proc_call & "=> Failed. Timeout waiting for readdatavalid");
       else
-        wait until rising_edge(clk);
-        wait_until_given_time_after_rising_edge(clk, config.clock_period/4);
+        --wait until rising_edge(clk);
+        --wait_until_given_time_after_rising_edge(clk, config.clock_period/4);
       end if;
 
     else  -- not waitrequest or readdatavalid - issue read, wait num_wait_states before finishing the read

Could you check please?
kind regards
Frank

vvc_generator doesn't run

On Centos 7 (Python 2.7) attesting to run the vvc_generator does this.

python vvc_generator.py
File "vvc_generator.py", line 40
SyntaxError: Non-ASCII character '\xc2' in file vvc_generator.py on line 40, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details

Should the encoding be set in the file?

Configurable assertion time for AXI4Lite BREADY/RREADY signals

I would like to be able to configure when BREADY and RREADY signals are asserted, in similar way that *VALID signals (e.g. config.num_b_pipe_stages).
I've noticed that there is a field in configuration record, but there's no support in procedures.

UVVM Utility Library: shared_uvvm_status variable problem

Hello,
We use the variable: shared_uvvm_status.no_unexpected_simulation_errors_or_worse to return an error in modelsim for script based automation purpose.

Unfortunately this variable is '0' at startup and at the end without errors/warnings it still returns '0' instead of '1'...
For a workaround I put alert(WARNING, ...) at the beginning. That forces an initialization of the variable to '1'.
Thanks,
Jonas

license situation

Hi,

I have a question wrt the license situation. From the github project page "./README.md" and "./LICENSE" I had the impression that the whole package is covered by a MIT license.

I have found now the following files which indicate other licenses:

./uvvm_osvvm/LICENSE.TXT
./bitvis_uart/License.txt
./uvvm_util/LICENSE.txt
./uvvm_util/src/license_pkg.vhd
./LICENSE
./bitvis_vip_i2c/LICENSE.TXT
./bitvis_vip_axistream/License.txt
./bitvis_vip_sbi/License.txt
./bitvis_irqc/LICENSE.txt
./bitvis_vip_avalon_mm/LICENSE.TXT
./bitvis_vip_uart/License.txt
./uvvm_vvc_framework/LICENSE.txt
./bitvis_vip_axilite/LICENSE.TXT

So if I would now want to create a avalon_streaming component, based on the bitvis_vip_axistream component is it ok to do the following:

a) name it bitvis_vip_avalonstream
b) name it soundart_vip_avalonstream
c) publish my new component on github under MIT license
d) sell it to the highest bidder

kind regards
Frank

Use Avalon_mm as a slave ?

Hi,
I wanted to use Avalon MM bfm as a slave in my projet but I just figured out that it seems to be only available as a master. Is there any way to use it as a slave ?

To be more precise, I have a component which needs to perform reads and writes in my FPGA DDR through the DSP which is using Avalon protocol to communicate. I want to test my component with an interface that could act as a Avalon BFM slave. If it's not possible with UVVM VVCs is there any other possibility to achieve this easily ?

Best regards

#23 Reopen: Issue with i2c_slave_receive procedure when I2C VIP used as Master and Slave in a Test Harness

Hi Marius,

I am reopening the thread again. This thread is in continuation to the old thread #23.

Please consider adding additional command as given below after the i2c_master_transmit command. Still it fails. Use the same setup what you have described.

i2c_slave_receive(I2C_VVCT, 2, 1, "One byte from master to slave");
i2c_master_transmit(I2C_VVCT, 1, C_FPGA_DEVICE_ID, x"AA", "I2C TX"); -- CHANGED by Marius
await_completion(I2C_VVCT,1,100 * 10*C_BIT_PERIOD); -- ADDED by AHHarish

Regards,
AHHarish

What is the recommended value for max-delta-cycles to use UVVM?

UVVM needs a lot of iterations in a time step. So what is the recommended value for max-delta-cycles?

Any plan to support bursting in the avalon MM VIP?

I have a need for that functionality and if there were plans for it to appear in the next release or near future, I might work on another area of the design rather than making a bursting VIP myself.

Simulation log flooded by "readdatavalid was active after <N> clocks"

When using the avalon_mm_bfm_package, I get "readdatavalid was active after <N> clocks" for every read since message ID is set to 'config.id_for_bfm'. In my opinion, info about readdatavalid is only relevant if it fails, so may I suggest you change message ID to, let's say, ID_POS_ACK instead?

With regards,
Alf

axistream_transmit procedure sending data even when vready is un-initialised

Hi,

I have been using axistream and axilite BFMs for a while in my self checking simulations and have found out that the axistream_transmit procedure keeps sending the data to slave when vready signal un-initialised is. In general the ready signal from slaves must be in defined state, but since the purpose is verification of designs, I would like the developers to have a look into this procedure

on line : 367 in axistream_bfm_pkg.vhd

(while v_tready = '0' loop) could be changed with (while v_tready /= '1' loop).

Accessing the VVCT from a subprogram

Can the vvct be accessed from a procedure or function so that one could make the test sequence more hierarchical. for instance doing something like this?

procedure reg_test is
begin
axilite_write(AXILITE_VVCT,1,x"0008",x"5a5a", "Writing to reg");
end procedure reg_test ;

axialite read data

Hello,

I can get axialite_read to function. It appears that the data read is not available to the test bench though. Is this intentional? I am guessing a new axilite_read function is required for this.

Enhancement: adaptations_pkg.vhd as parameter in compile script

Hello,
In uvvm_util the compile_src.do uses a fix location of the adaptations_pkg.vhd.
It would be nice, if an own adaptations_pkg.vhd can be passed as a parameter to compile_src.do. I think it would make sense regarding that this package might be project specific and located somewhere else.

For example, we integrated UVVM as a submodule in our git structure. In our project we have the custom adaptations_pkg.vhd saved. So, now we need to copy first our specific package to uvvm_util/src location and then run the compile script.

Thanks,
Jonas

axistream usage help

I am trying to use an axistream BFM in my own testbench. The testbench uses axilite BFM successfully.
I have to drive a number of axistream interface (N = number of possible channels). So I declare:
type t_axistream_array is array (0 to 63) of t_axistream_if (tdata(31 downto 0),
tkeep(3 downto 0),
tuser(0 downto 0),
tstrb(3 downto 0),
tid(7 downto 0),
tdest(3 downto 0));
signal axistream_if : t_axistream_array;

Then I initualize signals:
for i in 0 to 63 loop
axistream_if(i) <= init_axistream_if_signals(true,axistream_if(i).tdata'length,
axistream_if(i).tuser'length,
axistream_if(i).tid'length,
axistream_if(i).tdest'length);

    end loop;

Then I try to drive a master axistream interface in this way:

axistream_transmit_bytes( v_data_array , "Send", s_in_data_axis_aclk, axistream_if(0));
where v_data_array is
variable v_data_array : t_byte_array(0 to 3) := (x"00", x"01", x"02", x"03");

Then I get the following message when I run the simulation:

UVVM: *** TB_ERROR #1 ***

UVVM: 512.5 ns AXISTREAM_BFM

UVVM: axistream_transmit(4B) => Failed. Boolean was false. 'Sanity check: Check that bfm_config.clock_period is set'

Do I need to set clock period? Why?

AXILite BFM error: Timeout waiting for WREADY

Hello,

I have an error in axilite_write(). The procedure doesnt receive WREADY and I dont know why...

This is a simple example: https://pastebin.com/tHkMxzh2

I have the error:

UVVM: =========================================================================================================================================================================
UVVM: ***  TB_FAILURE #1  ***
UVVM:           190 ns   AXILITE BFM
UVVM:                    axilite_write(A:x"00000000", x"00000002") => Failed. Boolean was false. ': Timeout waiting for WREADY'
UVVM: 
UVVM: Simulator has been paused as requested after 1 TB_FAILURE
UVVM: *** To find the root cause of this alert, step out the HDL calling stack in your simulator. ***
UVVM: *** For example, step out until you reach the call from the test sequencer. ***
UVVM: =========================================================================================================================================================================

How to handle your alerts?

Hi.

I just discovered that you changed the handling of if stop-limit is reached from a assert failure to std.env.stop (line 2356):
assert false report "This single Failure line has been provoked to stop the simulation. See alert-message above" severity failure;
to
std.env.stop;

I have used qustasims: exit -code [expr {[coverage attribute -name TESTSTATUS -concise] > 1}] to get a correct exit code for our tests but now it can't tell the difference anymore.

/Ronny

Broken README in the OSVVM directory

This is a followup on #53.

With PR #55, several issues where introduced in this README.md:

• broken headline + typo in the headline
• missing forced linebreak before **License**
• broken link to the PAL 2.0 license

See PR #55 for further details.

Aldec Active-HDL $version variable

Hello,

The variable $version is pre-defined and used for the version number.
All the build scripts (compile_src.do, ...) need to be updated in order to avoid trouble.

Just adding an underscore avoid the variable collision in Active-HDL.

<--->

Detect simulator

if {[catch {eval "vsim -version"} message] == 0} {
quietly set _version [eval "vsim -version"]

puts "Version is: $_version"

if {[regexp -nocase {modelsim} $_version]} {
quietly set simulator "modelsim"
} elseif {[regexp -nocase {aldec} $_version]} {
quietly set simulator "rivierapro"
} else {
puts "Unknown simulator. Attempting to use Modelsim commands."
quietly set simulator "modelsim"
}
} else {
puts "vsim -version failed with the following message:\n $message"
abort all
}
<--->

Regards,
Cédric

await_any_completion

Hi,

In my sequencer I do this to wait for either channel to complete:

await_any_completion(MY_VVCT, 0, TX, v_tx_cmd_idx, NOT_LAST, 200 us, "Await tx-transactions");
await_any_completion(MY_VVCT, 0, RX, v_rx_cmd_idx, LAST, 200 us, "Await rx-transactions");
after the await_any_completion is completed I would expect:

my_vvc_lib.vvc_methods_pkg.shared_my_vvc_status(TX, 0).previous_cmd_idx = v_tx_cmd_idx
or
my_vvci_lib.vvc_methods_pkg.shared_my_vvc_status(RX, 0).previous_cmd_idx = v_rx_cmd_idx

but neither of them has changed.

Is there any other way of telling me which channel triggered the completion of the await_any_completion?

Regards,
Ronny

Why is the new version naming scheme not compliant to semantic versioning?

May I ask why UVVM is changing its version naming scheme?

The new naming scheme is not compliant to the semantic versioning standard. A date naming schema is violating §6, §7 and §8 of that standard.

6. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
7. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.
8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.

If you fear that customers might not see when a "release" was released, please have a look at one of your older v2.4.1 releases. There is a date shown. More over you can use annotated tags to give more information about your release (like a release date).

I consider it a big drawback to jump onto the Aldec and Xilinx versioning naming scheme train just for marking reasons.

From developers stand point: The new version names are almost useless to derive the impact of UVVM changes to the own projects.

Kind regards
Patrick

UVVM 2.3.0 contains invalid VHDL code

Hello,

@andresdemski reported an issue (#343 - Compiling UVVM with compile-uvvm.sh failed) in GHDL's pre-compile scripts for UVVM. A part of that issue was discussed in a separate issue report (#345 - Reading out parameters in procedures is not supported), but by reading the VHDL-2008 LRM again, we figured out, that the problem is not on the GHDL side.

Packages like methods_pkg.vhd contain invalid VHDL code e.g. at line 5151. According to the compilation log file provided by @andresdemski, this issue occurs several times in that file and possibly also in other files of UVVM.

Subprogram parameters of kind signal and mode out can not be read.

Kind regards
Patrick

---

Here is a quote from VHDL-2008 LRM proving that reading signal parameters is not valid:

LRM 6.5.2 Interface object declarations
...
An interface object has one of the following modes:

• in ...
• out. The value of the interface object is allowed to be updated and, provided it is not a signal parameter, read. Reading the attributes of the interface object is allowed, unless the interface object is a signal parameter and the attribute is one of 'STABLE, 'QUIET, 'DELAYED, 'TRANSACTION, 'EVENT, 'ACTIVE, 'LAST_EVENT, 'LAST_ACTIVE, or 'LAST_VALUE.
• inout or buffer ...
• linkage ...

Modelsim/Questa workaround in axistream_vvc.vhd

Hi

In axistream_vvc.vhd, the commit with tag v2.1.0 replaced the record-port version of the axistream_transmit-call with a discrete call version in the TRANSMIT case. The reason is that SIGSEGV mentioned in the comment above.

I guess the cases RECEIVE and EXPECT require the same fix. I currently comment those cases, because they trigger the same SIGSEGV. I tried this with Questa 10.3d and 10.5c

Thanks for the library!
Best regards,
emanuel

spi_master_receive_only seems not to work

Hello,
I'm using spi_master_receive_only procedure to get some data from my SPI slave. I noticed that when this function is executed, there are no clock cycles transmitted to the slave. So I did a little bit of investigating:
It looks to me that spi_master_receive_only(..) never sets the shared_vvc_cmd.num_words value. So when the command executor process runs, it sees v_num_words as 0 in the MASTER_RECEIVE_ONLY case around spi_vvc.vhd:352. That causes it to call the multi word version of the BFM's spi_master_receive function.

Then the multi word spi_master_receive procedure exits immediately at line spi_bfm_pkg.vhd:814 since the rx_data'length -1 is 0.

Can someone confirm this? I think the correct solution is to add a check to the executor in MASTER_RECEIVE_ONLY around spi_vvc.vhd:349 that checks for both v_word_length and v_num_words being zero and changes them.

    when MASTER_RECEIVE_ONLY =>
      if GC_MASTER_MODE then
        -- fix the word length and number of words if they're zero
        if v_word_length = 0 then
            v_word_length := GC_DATA_WIDTH;
        end if;
        if v_num_words = 0 then
            v_num_words := 1;
        end if;

Thanks