This document discusses the use of the OVM (Open Verification Methodology) and AVM (Accelerated Verification Methodology) for verifying IP cores. It provides an overview of the timeline of OVM and AVM releases used for verification. It also describes some example test environments developed using OVM, including testbenches created for an Ethernet core and a CPRI core. Specific components like an I/Q module within the CPRI core are also discussed. The document emphasizes that a functional verification methodology is important but which specific one is used is not as important as applying best practices. It concludes by asking if there are any questions.

1. The AVM and OVM in IP Core
Verification – Experiences and
Observations
Gareth Edwards
IP Solutions
April 22, 2009

2. Topics
 What is a methodology? What is it not?
 The timeline
 Some example OVM test environments
Page 2 © Copyright 2009 Xilinx

3. What is methodology?
methodology
1. A collection of methods, practices,
procedures and rules used by those who
work in some field.
2. The study of such methods etc.
3. The implementation of such methods etc.
Page 3 © Copyright 2009 Xilinx

4. Methodology is only part of the overall strategy
Compliance
Hardware Testing
Validation
Functional
Verification
CDC Linting
Analysis
Formal
Proving
Page 4 © Copyright 2009 Xilinx

5. The Timeline
Various Ethernet testbenches
Wrote our own extensions
 AVM 2.0 (July 2006) (primarily component removal)
 AVM 3.0 (May 2007)
– ovm_object.clone() Started CPRI testbench
– Multiple environments development, November
– Component Removal
2007
 OVM 1.0 (January 2008)
– Factories
– Configuration Ported CPRI testbench in-
– Sequences/scenarios
– Backward compatible with AVM 3.0
flight
 OVM 1.1 (May 2008)
– Singletop top
– Refined test phasing Ported CPRI testbench
– Backward compatible with OVM 1.0 again…
 OVM 2.0 (Sep 2008)
– Unified sequences
– User Guide!
– Backward compatible with OVM 1.1 CPRI I/Q Module
testbenches
Page 5 © Copyright 2009 Xilinx

6. The CPRI core – the DUT
Page 6 © Copyright 2009 Xilinx

7. The main CPRI Test suite (transmit)
comparators
Cpri_model
HDLC
tx_monitors
Eth
tx_drivers DUT monitor DeMux
IQ
Startup Sync Vendor
SM SM
= tlm_fifo
byte_codeword_transaction
serial or
model_codeword_transaction
2 byte parallel i/f
Page 7 © Copyright 2009 Xilinx

8. The main CPRI Test suite (receive)
= tlm_fifo
comparators
model
HDLC rx_stim
Eth rx_stim
rx_monitors DUT driver
IQ rx_stim
sync Vendor rx_stim
byte_codeword_transaction
serial or model_codeword_transaction
2 byte parallel i/f
Page 8 © Copyright 2009 Xilinx

9. The I/Q Module
entity iq_module is
generic (
C_TX_WIDTH_1 : natural := 10;
C_TX_START_1 : natural := 0;
C_RX_WIDTH_1 : natural := 10;
C_RX_START_1 : natural := 0;
C_TX_WIDTH_2 : natural := 10;
C_TX_START_2 : natural := 20;
C_RX_WIDTH_2 : natural := 10;
C_RX_START_2 : natural := 20;
C_TX_WIDTH_3 : natural := 10;
C_TX_START_3 : natural := 40;
C_RX_WIDTH_3 : natural := 10;
C_RX_START_3 : natural := 40;
…
Page 9 © Copyright 2009 Xilinx

10. Testing the I/Q Module – parameterisation (1)
class dut_param extends ovm_object; entity iq_module is
generic (
rand CpriSpeedType min_speed; C_TX_WIDTH_1 : natural := 10;
C_TX_START_1 : natural := 0;
rand int n_tx_channels; C_RX_WIDTH_1 : natural := 10;
int tx_width[1:24]; C_RX_START_1 : natural := 0;
int tx_start[1:24];
C_TX_WIDTH_2 : natural := 10;
rand int n_rx_channels; C_TX_START_2 : natural := 20;
int rx_width[1:24]; C_RX_WIDTH_2 : natural := 10;
int rx_start[1:24]; C_RX_START_2 : natural := 20;
function void pre_randomize(); C_TX_WIDTH_3 : natural := 10;
int status; C_TX_START_3 : natural := 40;
status = std::randomize(tx_width, rx_width) C_RX_WIDTH_3 : natural := 10;
with { C_RX_START_3 : natural := 40;
foreach (tx_width[i]) {
…
tx_width[i] inside {[4:20]};
}
foreach (rx_width[i]) {
rx_width[i] inside {[4:20]};
}
};
endfunction : pre_randomize
Page 10 © Copyright 2009 Xilinx

11. Testing the I/Q Module – parameterisation (2)
class dut_param extends ovm_object;
rand CpriSpeedType min_speed; Stub program creates
rand int n_tx_channels; dut_param object,
int tx_width[1:24]; randomizes and saves
int tx_start[1:24];
generics to storage
rand int n_rx_channels;
int rx_width[1:24];
int rx_start[1:24];
function void pre_randomize();
int status;
status = std::randomize(tx_width, rx_width)
with {
foreach (tx_width[i]) {
tx_width[i] inside {[4:20]};
Simulator reads generics,
} elaborates testbench
foreach (rx_width[i]) {
rx_width[i] inside {[4:20]};
and reconstructs dut_param
} object
};
endfunction : pre_randomize
Page 11 © Copyright 2009 Xilinx

12. Functional Coverage Tracking
Page 12 © Copyright 2009 Xilinx

13. Conclusions
 Using a Functional Verification Methodology can improve the
quality of your verification effort
 We’ve used OVM; other verification methodologies are
available
 It’s not that important which one you use
 Don’t forget the rest of your verification strategy
Page 13 © Copyright 2009 Xilinx

14. Questions?
?
Page 14 © Copyright 2009 Xilinx