Bitvis VIP RGMII

Quick Access



BFM

  • tx_ctl & rx_ctl only represent TXEN & RXEN respectively, the functionality of TXERR & RXERR is not implemented.

  • There is no support for RGMII-ID (use of Tsetup & Thold).

  • BFM functionality is implemented in rgmii_bfm_pkg.vhd

Signal Record

t_rgmii_tx_if

Record element

Type

Description

txc

std_logic

TX reference clock

txd

std_logic_vector(3 downto 0)

TX data lines (to DUT)

tx_ctl

std_logic

TX enable

t_rgmii_rx_if

Record element

Type

Description

rxc

std_logic

RX reference clock

rxd

std_logic_vector(3 downto 0)

RX data lines (from DUT)

rx_ctl

std_logic

RX enable

Configuration Record

t_rgmii_bfm_config

Default value for the record is C_RGMII_BFM_CONFIG_DEFAULT.

Record element

Type

Default

Description

max_wait_cycles

integer

10

The maximum number of clock cycles to wait for the DUT signals before reporting a timeout alert

max_wait_cycles_severity

t_alert_level

ERROR

The above timeout will have this severity

clock_period

time

-1 ns

Period of the clock signal

rx_clock_skew

time

-1 ns

Skew of the sampling of the data in connection to the RX clock edges. Suggested value is clock_period/4.

match_strictness

t_match_strictness

MATCH_EXACT

Matching strictness for std_logic values in check procedures.

MATCH_EXACT requires both values to be the same. Note that the expected value can contain the don’t care operator ‘-‘.

MATCH_STD allows comparisons between ‘H’ and ‘1’, ‘L’ and ‘0’ and ‘-’ in both values.

id_for_bfm

t_msg_id

ID_BFM

Message ID used for logging general messages in the BFM

data_valid_on_both_clock_edges

boolean

true

Switch for changing between double data rate and single data rate on RGMII interface

Methods

  • All signals are active high.

  • All parameters in brackets are optional.

  • For clarity, data_array is required to be ascending, e.g.

    variable v_data_array : t_byte_array(0 to C_MAX_BYTES - 1);
    

Note

The BFM configuration has to be defined and used when calling the RGMII BFM procedures. See Local BFM configuration for an example of how to define a local BFM config.

rgmii_write()

While config parameter data_valid_on_both_clock_edges = true (default):
  • Writes 4 bits of data on each clock edge. The bits [3:0] are written on the rising edge and the bits [7:4] on the falling edge.

While config parameter data_valid_on_both_clock_edges = false:
  • Writes 4 bits of data on each rising clock edge. The bits [3:0] are written on the first rising edge and the bits [7:4] on the following rising edge.

The length and data are defined by the “data_array” argument, which is a t_byte_array. data_array(0) is written first, while data_array(data_array’high) is written last.

rgmii_write(data_array, [action_when_transfer_is_done], msg, rgmii_tx_if, [scope, [msg_id_panel, [config]]])

Object

Name

Dir.

Type

Description

constant

data_array

in

t_byte_array

An array of bytes containing the data to be written

constant

action_when_transfer_is_done

in

t_action_when_transfer_is_done

Whether to release or hold the TXEN line after the procedure is finished. Useful when transmitting a packet of data through several procedures, e.g. from Ethernet HVVC. Default value is RELEASE_LINE_AFTER_TRANSFER.

constant

msg

in

string

A custom message to be appended in the log/alert

signal

rgmii_tx_if

inout

t_rgmii_tx_if

RGMII TX signal interface record

constant

scope

in

string

Describes the scope from which the log/alert originates. Default value is C_BFM_SCOPE (“RGMII BFM”).

constant

msg_id_panel

in

t_msg_id_panel

Controls verbosity within a specified scope. Default value is shared_msg_id_panel.

constant

config

in

t_rgmii_bfm_config

Configuration of BFM behavior and restrictions. Default value is C_RGMII_BFM_CONFIG_DEFAULT.

-- Examples:
rgmii_write((x"01", x"02", x"03", x"04"), "Write 4 bytes", rgmii_tx_if);
rgmii_write(v_data_array(0 to v_num_bytes - 1), HOLD_LINE_AFTER_TRANSFER , "Write v_num_bytes bytes", rgmii_tx_if, C_SCOPE, shared_msg_id_panel, rgmii_bfm_config);

rgmii_read()

While config parameter data_valid_on_both_clock_edges = true (default):
  • Reads 4 bits of data on each clock edge. The bits [3:0] are read on the rising edge and the bits [7:4] on the falling edge. To avoid having to delay the receiver’s clock, the config rx_clock_skew is used to set the sampling time of the data.

While config parameter data_valid_on_both_clock_edges = false:
  • Reads 4 bits of data on each rising clock edge. The bits [3:0] are read on the first rising edge and the bits [7:4] on the following rising edge.

The received data is stored in the data_array output, which is a t_byte_array. The number of valid bytes in the data_array is stored in data_len. data_array(0) is read first, while data_array(data_array’high) is read last.

rgmii_read(data_array, data_len, msg, rgmii_rx_if, [scope, [msg_id_panel, [config]]])

Object

Name

Dir.

Type

Description

variable

data_array

out

t_byte_array

An array of bytes containing the data to be read

variable

data_len

out

natural

The number of valid bytes in the data_array. Note that the data_array can be bigger and that is why the length is returned.

constant

msg

in

string

A custom message to be appended in the log/alert

signal

rgmii_rx_if

inout

t_rgmii_rx_if

RGMII RX signal interface record

constant

scope

in

string

Describes the scope from which the log/alert originates. Default value is C_BFM_SCOPE (“RGMII BFM”).

constant

msg_id_panel

in

t_msg_id_panel

Controls verbosity within a specified scope. Default value is shared_msg_id_panel.

constant

config

in

t_rgmii_bfm_config

Configuration of BFM behavior and restrictions. Default value is C_RGMII_BFM_CONFIG_DEFAULT.

-- Examples:
rgmii_read(v_data_array, v_num_bytes, "Read RGMII data", rgmii_rx_if);
rgmii_read(v_data_array, v_num_bytes, "Read RGMII data", rgmii_rx_if, C_SCOPE, shared_msg_id_panel, rgmii_bfm_config);

rgmii_expect()

Calls the rgmii_read() procedure, then compares the received data with data_exp.

rgmii_expect(data_exp, msg, rgmii_rx_if, [alert_level, [scope, [msg_id_panel, [config]]]])

Object

Name

Dir.

Type

Description

constant

data_exp

in

t_byte_array

An array of bytes containing the data to be expected

constant

msg

in

string

A custom message to be appended in the log/alert

signal

rgmii_rx_if

inout

t_rgmii_rx_if

RGMII RX signal interface record

constant

alert_level

in

t_alert_level

Sets the severity for the alert. Default value is ERROR.

constant

scope

in

string

Describes the scope from which the log/alert originates. Default value is C_BFM_SCOPE (“RGMII BFM”).

constant

msg_id_panel

in

t_msg_id_panel

Controls verbosity within a specified scope. Default value is shared_msg_id_panel.

constant

config

in

t_rgmii_bfm_config

Configuration of BFM behavior and restrictions. Default value is C_RGMII_BFM_CONFIG_DEFAULT.

-- Examples:
rgmii_expect((x"01", x"02", x"03", x"04"), "Expect 4 bytes", rgmii_rx_if);
rgmii_expect(v_data_array(0 to v_num_bytes - 1), "Expect v_num_bytes bytes", rgmii_rx_if, ERROR, C_SCOPE, shared_msg_id_panel, rgmii_bfm_config);

init_rgmii_if_signals()

Initializes the RGMII interface. All the BFM outputs are set to ‘0’, and BFM inputs are set to ‘Z’.

t_rgmii_rx_if := init_rgmii_if_signals
t_rgmii_tx_if := init_rgmii_if_signals
-- Examples:
rgmii_rx_if <= init_rgmii_if_signals;
rgmii_tx_if <= init_rgmii_if_signals;

Local BFM overloads

A good approach for better readability and maintainability is to make simple, local overloads for the BFM procedures in the TB process. This allows calling the BFM procedures with the key parameters only, e.g.

rgmii_write(v_data_array(0 to 1), "msg");

rather than

rgmii_write(v_data_array(0 to 1), "msg", rgmii_tx_if, C_SCOPE, shared_msg_id_panel, C_RGMII_BFM_CONFIG_DEFAULT);

By defining the local overload as e.g.

procedure rgmii_write(
  constant data_array : in t_byte_array;
  constant msg        : in string) is
begin
  rgmii_write(data_array,                -- Keep as is
              msg,                       -- Keep as is
              rgmii_tx_if,               -- Signal must be visible in local process scope
              C_SCOPE,                   -- Use the default
              shared_msg_id_panel,       -- Use global, shared msg_id_panel
              C_RGMII_BFM_CONFIG_LOCAL); -- Use locally defined configuration or C_RGMII_BFM_CONFIG_DEFAULT
end procedure;

Using a local overload like this also allows the following – if wanted:

  • Set up defaults for constants. May be different for two overloads of the same BFM

  • Apply dedicated message ID panel to allow dedicated verbosity control

Local BFM configuration

The RGMII BFM requires that a local configuration is declared in the testbench and used in the BFM procedure calls. The default BFM configuration is defined with a clock period of -1 ns so that the BFM can detect and alert the user that the configuration has not been set.

Defining a local RGMII BFM configuration::

constant C_RGMII_CONFIG_LOCAL : t_rgmii_bfm_config := (
  max_wait_cycles                => 10,
  max_wait_cycles_severity       => error,
  clock_period                   => 8 ns,
  rx_clock_skew                  => 2 ns,
  match_strictness               => MATCH_EXACT,
  id_for_bfm                     => ID_BFM,
  data_valid_on_both_clock_edges => false
);

Compilation

  • This BFM package may only be compiled with VHDL-2008 or newer. It is dependent on the Utility Library, which is only compatible with VHDL-2008 or newer.

  • After UVVM-Util has been compiled, the BFM package can be compiled into any desired library.

  • See Essential Mechanisms - Compile Scripts for information about compile scripts.

Simulator compatibility and setup

Additional Documentation

For more information see the specification “Reduced Gigabit Media Independent Interface (RGMII) Version 2.0”.

Important

  • This is a simplified Bus Functional Model (BFM) for RGMII.

  • The given BFM complies with the basic RGMII protocol and thus allows a normal access towards a RGMII interface.

  • This BFM is not a RGMII protocol checker.

  • For a more advanced BFM please contact UVVM support at info@uvvm.org



VVC

Entity

Generics

Name

Type

Default

Description

GC_INSTANCE_IDX

natural

N/A

Instance number to assign the VVC

GC_RGMII_BFM_CONFIG

t_rgmii_bfm_config

C_RGMII_BFM_CONFIG_DEFAULT

Configuration for the RGMII BFM

GC_CMD_QUEUE_COUNT_MAX

natural

C_CMD_QUEUE_COUNT_MAX

Absolute maximum number of commands in the VVC command queue

GC_CMD_QUEUE_COUNT_THRESHOLD

natural

C_CMD_QUEUE_COUNT_THRESHOLD

An alert will be generated when reaching this threshold to indicate that the command queue is almost full. The queue will still accept new commands until it reaches GC_CMD_QUEUE_COUNT_MAX.

GC_CMD_QUEUE_COUNT_THRESHOLD_SEVERITY

t_alert_level

C_CMD_QUEUE_COUNT_THRESHOLD_SEVERITY

Alert severity which will be used when command queue reaches GC_CMD_QUEUE_COUNT_THRESHOLD

GC_RESULT_QUEUE_COUNT_MAX

natural

C_RESULT_QUEUE_COUNT_MAX

Maximum number of unfetched results before result_queue is full

GC_RESULT_QUEUE_COUNT_THRESHOLD

natural

C_RESULT_QUEUE_COUNT_THRESHOLD

An alert will be issued if result queue exceeds this count. Used for early warning if result queue is almost full. Will be ignored if set to 0.

GC_RESULT_QUEUE_COUNT_THRESHOLD_SEVERITY

t_alert_level

C_RESULT_QUEUE _COUNT_THRESHOLD_SEVERITY

Severity of alert to be initiated if exceeding GC_RESULT_QUEUE_COUNT_THRESHOLD

Signals

Object

Name

Dir.

Type

Description

signal

rgmii_vvc_tx_if

inout

t_rgmii_tx_if

RGMII TX signal interface record

signal

rgmii_vvc_rx_if

inout

t_rgmii_rx_if

RGMII RX signal interface record

Configuration Record

vvc_config accessible via shared_rgmii_vvc_config

Record element

Type

Default

Description

inter_bfm_delay

t_inter_bfm_delay

C_RGMII_INTER_BFM_DELAY_DEFAULT

Delay between any requested BFM accesses towards the DUT.

TIME_START2START: Time from a BFM start to the next BFM start (a TB_WARNING will be issued if access takes longer than TIME_START2START).

TIME_FINISH2START: Time from a BFM end to the next BFM start.

Any insert_delay() command will add to the above minimum delays, giving for instance the ability to skew the BFM starting time.

cmd_queue_count_max

natural

C_CMD_QUEUE_COUNT_MAX

Maximum pending number in command queue before queue is full. Adding additional commands will result in an ERROR.

cmd_queue_count_threshold

natural

C_CMD_QUEUE_COUNT_THRESHOLD

An alert will be issued if command queue exceeds this count. Used for early warning if command queue is almost full. Will be ignored if set to 0.

cmd_queue_count_threshold_severity

t_alert_level

C_CMD_QUEUE_COUNT_THRESHOLD_SEERITY

Severity of alert to be initiated if exceeding cmd_queue_count_threshold

result_queue_count_max

natural

C_RESULT_QUEUE_COUNT_MAX

Maximum number of unfetched results before result_queue is full

result_queue_count_threshold

natural

C_RESULT_QUEUE_COUNT_THRESHOLD

An alert will be issued if result queue exceeds this count. Used for early warning if result queue is almost full. Will be ignored if set to 0.

result_queue_count_threshold_severity

t_alert_level

C_RESULT_QUEUE_COUNT_THRESHOLD_SEVERITY

Severity of alert to be initiated if exceeding result_queue_count_threshold

bfm_config

t_rgmii_bfm_config

C_RGMII_BFM_CONFIG_DEFAULT

Configuration for the RGMII BFM

msg_id_panel

t_msg_id_panel

C_VVC_MSG_ID_PANEL_DEFAULT

VVC dedicated message ID panel. See Scope of Verbosity Control for how to use verbosity control.

unwanted_activity_severity

t_alert_level

C_UNWANTED_ACTIVITY_SEVERITY

Severity of alert to be issued if unwanted activity on the DUT outputs is detected. It is enabled with ERROR severity by default.

Note

cmd/result queue parameters in the configuration record are unused and will be removed in v3.0, use instead the entity generic constants.

The configuration record can be accessed from the Central Testbench Sequencer through the shared variable array, e.g.

shared_rgmii_vvc_config(RX, C_VVC_IDX).inter_bfm_delay.delay_in_time := 50 ns;
shared_rgmii_vvc_config(TX, C_VVC_IDX).bfm_config.id_for_bfm := ID_BFM;

Status Record

vvc_status accessible via shared_rgmii_vvc_status

The current status of the VVC can be retrieved during simulation. This is achieved by reading from the shared variable from the test sequencer. The record contents can be seen below:

Record element

Type

Description

current_cmd_idx

natural

Command index currently running

previous_cmd_idx

natural

Previous command index to run

pending_cmd_idx

natural

Pending number of commands in the command queue

Methods

  • All VVC procedures are defined in vvc_methods_pkg.vhd (dedicated to this VVC).

  • See Common VVC Methods for procedures which are common to all VVCs.

  • It is also possible to send a multicast to all instances of a VVC with ALL_INSTANCES as parameter for vvc_instance_idx.

  • All parameters in brackets are optional.

  • For clarity, data_array is required to be ascending, e.g.

    variable v_data_array : t_byte_array(0 to C_MAX_BYTES - 1);
    

rgmii_write()

Adds a write command to the RGMII VVC executor queue, which will run as soon as all preceding commands have completed. When the command is scheduled to run, the executor calls the BFM rgmii_write() procedure. data_array(0) is written first, while data_array(data_array’high) is written last.

rgmii_write(VVCT, vvc_instance_idx, channel, data_array, [action_when_transfer_is_done], msg, [scope])

Object

Name

Dir.

Type

Description

signal

VVCT

inout

t_vvc_target_record

VVC target type compiled into each VVC in order to differentiate between VVCs

constant

vvc_instance_idx

in

integer

Instance number of the VVC

constant

channel

in

t_channel

The VVC channel of the VVC instance

constant

data_array

in

t_byte_array

An array of bytes containing the data to be written

constant

action_when_transfer_is_done

in

t_action_when_transfer_is_done

Whether to release or hold the TXEN line after the procedure is finished. Useful when transmitting a packet of data through several procedures, e.g. from Ethernet HVVC. Default value is RELEASE_LINE_AFTER_TRANSFER.

constant

msg

in

string

A custom message to be appended in the log/alert

constant

scope

in

string

Describes the scope from which the log/alert originates. Default value is C_VVC_CMD_SCOPE_DEFAULT.

-- Examples:
rgmii_write(RGMII_VVCT, 0, TX, (x"01", x"02", x"03", x"04"), "Write 4 bytes");
rgmii_write(RGMII_VVCT, 0, TX, v_data_array(0 to v_num_bytes - 1), HOLD_LINE_AFTER_TRANSFER, "Write v_num_bytes bytes", C_SCOPE);

rgmii_read()

Adds a read command to the RGMII VVC executor queue, which will run as soon as all preceding commands have completed. When the command is scheduled to run, the executor calls the BFM rgmii_read() procedure.

The value read from DUT will not be returned in this procedure call since it is non-blocking for the sequencer/caller, but the read data will be stored in the VVC for a potential future fetch (see example with fetch_result below). If the data_routing is set to TO_SB, the read data will be sent to the RGMII VVC dedicated scoreboard where it will be checked against the expected value (provided by the testbench).

rgmii_read(VVCT, vvc_instance_idx, channel, [data_routing,] msg, [scope])

Object

Name

Dir.

Type

Description

signal

VVCT

inout

t_vvc_target_record

VVC target type compiled into each VVC in order to differentiate between VVCs

constant

vvc_instance_idx

in

integer

Instance number of the VVC

constant

channel

in

t_channel

The VVC channel of the VVC instance

constant

data_routing

in

t_data_routing

Selects the destination of the read data

constant

msg

in

string

A custom message to be appended in the log/alert

constant

scope

in

string

Describes the scope from which the log/alert originates. Default value is C_VVC_CMD_SCOPE_DEFAULT.

-- Examples:
rgmii_read(RGMII_VVCT, 0, RX, "Read data and store it in the VVC");
rgmii_read(RGMII_VVCT, 0, RX, TO_SB, "Read data and send to Scoreboard for checking");

-- Example with fetch_result() call: Result is placed in v_result
variable v_cmd_idx : natural;                       -- Command index for the last read
variable v_result  : work.vvc_cmd_pkg.t_vvc_result; -- Result from read.
...
rgmii_read(RGMII_VVCT, 0, RX, "Read data in VVC");
v_cmd_idx := get_last_received_cmd_idx(RGMII_VVCT, 0, RX);
await_completion(RGMII_VVCT, 0, RX, v_cmd_idx, 1 us, "Wait for read to finish");
fetch_result(RGMII_VVCT, 0, RX, v_cmd_idx, v_result, "Fetching result from read operation");

Hint

t_vvc_result is defined in the corresponding vvc_cmd_pkg.vhd for the VIP.

rgmii_expect()

Adds an expect command to the RGMII VVC executor queue, which will run as soon as all preceding commands have completed. When the command is scheduled to run, the executor calls the BFM rgmii_expect() procedure. The rgmii_expect() procedure will perform a read operation, then check if the read data is equal to the expected data in the data parameter. If the read data is not equal to the expected data parameter, an alert with severity ‘alert_level’ will be issued. The read data will not be stored in this procedure.

rgmii_expect(VVCT, vvc_instance_idx, channel, data_exp, msg, [alert_level, [scope]])

Object

Name

Dir.

Type

Description

signal

VVCT

inout

t_vvc_target_record

VVC target type compiled into each VVC in order to differentiate between VVCs

constant

vvc_instance_idx

in

integer

Instance number of the VVC

constant

channel

in

t_channel

The VVC channel of the VVC instance

constant

data_exp

in

t_byte_array

An array of bytes containing the data to be expected

constant

msg

in

string

A custom message to be appended in the log/alert

constant

alert_level

in

t_alert_level

Sets the severity for the alert. Default value is ERROR.

constant

scope

in

string

Describes the scope from which the log/alert originates. Default value is C_VVC_CMD_SCOPE_DEFAULT.

-- Examples:
rgmii_expect(RGMII_VVCT, 0, RX, (x"01", x"02", x"03", x"04"), "Expect 4 bytes from DUT");
rgmii_expect(RGMII_VVCT, 0, RX, v_data_array(0 to v_num_bytes - 1), "Expect v_num_bytes from DUT", ERROR, C_SCOPE);

Activity Watchdog

The VVCs support a centralized VVC activity register which the activity watchdog uses to monitor the VVC activities. The VVCs will register their presence to the VVC activity register at start-up, and report when ACTIVE and INACTIVE, using dedicated VVC activity register methods, and trigger the global_trigger_vvc_activity_register signal during simulations. The activity watchdog is continuously monitoring the VVC activity register for VVC inactivity and raises an alert if no VVC activity is registered within the specified timeout period.

Include activity_watchdog(num_exp_vvc, timeout, [alert_level, [msg]]) in the testbench to start using the activity watchdog. Note that setting the exact number of expected VVCs in the VVC activity register can be omitted by setting num_exp_vvc = 0.

More information can be found in Essential Mechanisms - Activity Watchdog.

Transaction Info

This VVC supports transaction info, a UVVM concept for distributing transaction information in a controlled manner within the complete testbench environment. The transaction info may be used in many different ways, but the main purpose is to share information directly from the VVC to a DUT model.

RGMII transaction info record fields. Transaction Type: t_base_transaction (BT) - accessible via shared_rgmii_vvc_transaction_info.bt

Info field

Type

Default

Description

operation

t_operation

NO_OPERATION

Current VVC operation, e.g. INSERT_DELAY, POLL_UNTIL, READ, WRITE

data_array

t_byte_array(0 to 2047)

0x0

Data for RGMII read or write transaction

vvc_meta

t_vvc_meta

C_VVC_META_DEFAULT

VVC meta data of the executing VVC command

-> msg

string

“”

Message of executing VVC command

-> cmd_idx

integer

-1

Command index of executing VVC command

transaction_status

t_transaction_status

INACTIVE

Set to INACTIVE, IN_PROGRESS, FAILED or SUCCEEDED during a transaction

More information can be found in Essential Mechanisms - Distribution of Transaction Info.

Scoreboard

This VVC has built in Scoreboard functionality where data can be routed by setting the TO_SB parameter in supported method calls, i.e. rgmii_read(). Note that the data is only stored in the scoreboard and not accessible with the fetch_result() method when the TO_SB parameter is applied. The RGMII scoreboard is accessible from the testbench as a shared variable RGMII_VVC_SB, located in the vvc_methods_pkg.vhd, e.g.

RGMII_VVC_SB.add_expected(C_RGMII_VVC_IDX, v_expected, "Adding expected");

See the Bitvis VIP Scoreboard for a complete list of available commands and additional information. All of the listed Generic Scoreboard commands are available for the RGMII VVC scoreboard using the RGMII_VVC_SB.

Unwanted Activity Detection

This VVC supports detection of unwanted activity from the DUT. This mechanism will give an alert if the DUT generates any unexpected bus activity. It assures that no data is output from the DUT when it is not expected, i.e. read/receive/check/expect VVC methods are not called. Once the VVC is inactive, it starts to monitor continuously on the DUT outputs. When unwanted activity is detected, the VVC issues an alert.

The unwanted activity detection can be configured from the central testbench sequencer, where the severity of alert can be changed to a different value. To disable this feature in the testbench, e.g.

shared_rgmii_vvc_config(RX, C_VVC_INDEX).unwanted_activity_severity := NO_ALERT;

The unwanted activity detection is ignored when the rx_ctl signal goes low within one clock period after the VVC becomes inactive. This is to handle the situation when the read command exits before the next rising edge, causing signal transitions during the first clock cycle after the VVC is inactive.

For RGMII VVC, the unwanted activity detection is enabled by default with severity ERROR.

Note

This feature is only implemented on rgmii_rx_vvc.

More information can be found in Essential Mechanisms - Unwanted Activity Detection.

Compilation

The RGMII VVC must be compiled with VHDL-2008 or newer. It is dependent on the following libraries:

  • UVVM Utility Library (UVVM-Util)

  • UVVM VVC Framework

  • Bitvis VIP Scoreboard

  • RGMII BFM

Before compiling the RGMII VVC, assure that uvvm_util, uvvm_vvc_framework and bitvis_vip_scoreboard have been compiled.

See Essential Mechanisms - Compile Scripts for information about compile scripts.

Compile order for the RGMII VVC

Compile to library

File

Comment

bitvis_vip_rgmii

rgmii_bfm_pkg.vhd

RGMII BFM

bitvis_vip_rgmii

transaction_pkg.vhd

RGMII transaction package with DTT types, constants, etc.

bitvis_vip_rgmii

vvc_cmd_pkg.vhd

RGMII VVC command types and operations

bitvis_vip_rgmii

../uvvm_vvc_framework/src_target_dependent/td_target_support_pkg.vhd

UVVM VVC target support package, compiled into this VVC library

bitvis_vip_rgmii

../uvvm_vvc_framework/src_target_dependent/td_vvc_framework_common_methods_pkg.vhd

Common UVVM framework methods compiled into the this VVC library

bitvis_vip_rgmii

vvc_sb_pkg.vhd

RGMII VVC scoreboard

bitvis_vip_rgmii

vvc_methods_pkg.vhd

RGMII VVC methods

bitvis_vip_rgmii

../uvvm_vvc_framework/src_target_dependent/td_queue_pkg.vhd

UVVM queue package for this VVC

bitvis_vip_rgmii

../uvvm_vvc_framework/src_target_dependent/td_vvc_entity_support_pkg.vhd

UVVM VVC entity support compiled into this VVC library

bitvis_vip_rgmii

rgmii_tx_vvc.vhd

RGMII TX VVC

bitvis_vip_rgmii

rgmii_rx_vvc.vhd

RGMII RX VVC

bitvis_vip_rgmii

rgmii_vvc.vhd

RGMII VVC wrapper for the TX and RX VVCs

bitvis_vip_rgmii

vvc_context.vhd

RGMII VVC context file

Simulator compatibility and setup

Additional Documentation

For more information see the specification “Reduced Gigabit Media Independent Interface (RGMII) Version 2.0”.

Important

  • This is a simplified Verification IP (VIP) for RGMII.

  • The given VIP complies with the basic RGMII protocol and thus allows a normal access towards a RGMII interface.

  • This VIP is not a RGMII protocol checker.

  • For a more advanced VIP please contact UVVM support at info@uvvm.org

Note

Disclaimer: This IP and any part thereof are provided “as is”, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and non-infringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with this IP.