Hi,
I am new to the UVVM VVC creation.
I am trying to convert my current verification platform to using VVC. I generated the templates by executing the python vvc_generator.py for my counter DUT.
Looked at the following link which has a simple counter and tried to follow same approach like they do to build the UVVM platform with VVC in place
https://www.edaplayground.com/x/2LhW
This simple counter design.vhd, testbench is not complete ie test sequencer process is missing calling the procedural commands etc
I am using a different counter as my DUT to this one just incrementing and reseting.
Used gen_pulse within my testbench to create an active high pulse for the reset. This works ok. Reset connects directly to the DUT (counter) within the test harness (ie it is not part of my counter_vvc). This reset pulse works fine.
Instantiated also within my testbech the bitvis clock_generator_vvc. This works fine too.
I created a BFM procedure counter_count_up and placed this within the counter_bfm_pkg
I called this counter_count_up procedure within my testbench Test Sequencer process and the counting up works fine right after reset (this is without the VVC framework in place).
The counter_count_up procedure just generates an active high enable signal (out) and counts up. It also does self checking of the counter at various points using the check_value uvvm utils procedure. Simulated this without the counter_vvc first in place and that was ok.
However, having problems at the moment when I added the BFM procedure call in the counter_vvc within the VVC dedicated operations. case v_cmd.operation COUNT_UP was used for this and within vvc_cmd_pkg.vhd I included COUNT_UP within the t_operation type list.
The clk is visible but the counter_vvc counter interface ‘in_enable’ and ‘out_counter’ interface signals do not perform as expected.
The template counter_vvc.vhd included a constructor, command interpreter, command executor and command termination handler. It is my understanding that the only things I need to add in this template file is to Insert BFM procedure calls within the case v_cmd.operation and update the top-level port of the counter_vvc to insert BFM interface signals. Isn’t this the case?
Do I need to create a Config initializer process (like the clock_generator_vvc does)?
I also noticed that the vvc_methods_pkg.vhd examples VVC procedure declarations inserted in this file just include example the following:
– <USER_INPUT> Please insert the VVC procedure declarations here
procedure counter_cnt_up (
signal VVCT : inout t_vvc_target_record;
constant vvc_instance_idx : in integer;
constant cycles : in natural;
constant msg : in string
);
ie it includes VVCT signal and not the original interface signals. Is this correct? Can someone explain here this matter too.
Within the package body of vcc_methods_pkg included the following which included the COUNT_UP:
procedure counter_count_up(
signal VVCT : inout t_vvc_target_record;
constant vvc_instance_idx : in integer;
constant cycles : in natural;
constant msg : in string
) is
use std.textio.side;
constant proc_name : string := “counter_count_up”;
constant proc_call : string := proc_name & “(” & to_string(VVCT, vvc_instance_idx) – First part common for all
& ", " & integer’image(cycles) & “)”;
begin
set_general_target_and_command_fields (VVCT, vvc_instance_idx, proc_call, msg, QUEUED, COUNT_UP);
shared_vvc_cmd.cycles := cycles;
send_command_to_vvc(VVCT);
end procedure;
The main issue I have is that the ‘in_enable’ is low at the beginning as expected BUT as soon as this signal tries to go to ‘1’ from the counter_count_up BFM procedure after executing the following command within the testbench:
counter_count_up(0, “Enable the counter to start counting up”, in_clock, in_enable, out_counter, C_SCOPE);**
the in_enable line is ‘X’ and stays 'X’
Initially had my in_enable signal declared as input port at the test harness level but had the following compilation error:
"Cannot assign to object ‘in_enable’ of mode IN
Changed it then top level test harness in_enable from input to output port. Then after running the simulation it shown this ‘X’ propagation issue on the ‘in_enable’ when the above command was executed from the testbench (test sequencer process).
in_enable is input to the DUT (counter). Test harness also instantiates the counter_vvc module and connected there the clock, reset, in_enable & out_counter.
This is URGENT. Prompt reply to this matter will be appreciated
Regards,
Kevin