This document describes a modular approach to constructing mixed-signal testbenches using virtual test equipment implemented in VHDL. The virtual equipment, such as signal generators and analyzers, encapsulate complexity and allow quick generation of testbenches and test cases with little effort. This modular structure can be used for both chip-level and block-level mixed-signal simulation and verification. The virtual equipment also provides a way to translate tests to real lab equipment for validation.

1. DesignCon East 2004
Simplifying Mixed-Signal Simulation
Using Modular Virtual Test
Equipment in VHDL
Zheng Xu, Legerity Inc.
Zheng.Xu@legerity.com
Jim Lear, Legerity, Inc.
Jim.Lear@legerity.com
@Legerity, Inc.

2. Abstract
Functional verification of a complicated mixed-signal chip or system can be a very challenging task.
Traditional verification environments are often cumbersome in generating stimulus and post-processing
data.
This paper describes a modular approach to construct a mixed-signal testbench environment utilizing a
reusable abstract layer of virtual test equipment implemented in VHDL for mixed-signal simulation.
This equipment includes the analog and digital signal generators, analyzers, filters and other devices
similar in concept to lab test equipment. Because the virtual test equipment encapsulates the signal
generation, measurement and analysis capability, with most complexity hidden from the user, chip level
testbenches and testcases can be quickly generated with little effort. Using mixed-signal simulators,
custom transistor- level circuit designers can also utilize these devices to easily create flexible design
testbenches. Furthermore, a unified verification and validation platform is achievable by translating the
commands to the virtual test equipment into commands for real lab equipment. This will potentially
significantly reduce the development cost of mixed-signal chip validation.
Author Biography
Zheng Xu is a Member of Technical Staff (MTS) design engineer at Legerity, Inc. in Austin, Texas. He
has worked on design and verification of voice/data communication and chipset Integrated Circuits. He
is also involved with mixed-signal system design, modeling and simulation. Prior to legerity, he worked
for AMD as a design engineer. Zheng holds a MSEE from Rensselaer Polytechnic Institute.
Jim Lear is a Member of Technical Staff (MTS) design engineer at Legerity, Inc. in Austin, Texas. He
has worked on custom digital circuit design and mixed-signal verification methodologies. Previously,
he worked for AMD and DEC. He holds an MSEE from the University of Texas, at Austin.
@Legerity, Inc.

3. Introduction
Chip level or system level simulation of a complex mixed-signal chip is very challenging because of the
many different operating modes and potential complex dynamic behavior involving various analog and
digital elements. Discrete time domain circuit modeling with VHDL has been used and proven to be an
effective approach to perform chip level mixed-signal simulation with fast throughput and reasonable
accuracy [1]. The analog design blocks are first modeled with VHDL and certified against the transistor
level simulation using a mixed-signal simulator. These discrete time domain analog models are then
combined with Verilog RTL design to generate the top- level VHDL/Verilog netlist. Finally, the VHDL
testbench, including signal generation, signal analysis and bus functional models, can be built to verify
the overall system.
In the past, monolithic chip-level VHDL testbenches were often built that combined signal generation,
signal analysis, and bus functional blocks into one or several large pieces of code. This approach is often
cumbersome in generating stimulus and post-processing data at the testbench level. It is also difficult to
maintain from project to project and reusability is poor. Furthermore, a chip level testbench built in this
way is of no use to analog or mixed-signal designers for their customized circuit design and behavior
model certification.
This paper presents a modular approach to construc t the mixed-signal testbench environment utilizing a
reusable abstract layer of virtual test equipment implemented in VHDL for mixed-signal simulation.
Section 2 describes how it can be applied to chip level system simulation as well as block level analog
circuit simulation. Section 3 outlines the programming interface used to control the virtual test
equipment. Section 4 illustrates the various building components of the virtual test equipment devices.
Section 5 describes an example of how the proposed modular testbench structure and virtual test
equipment have been applied successfully to achieve the mixed signal verification of Legerity’s
Mercury Project. Finally, Section 6 shows how a unified verification and validation platform can be
achieved by translating the commands to the virtual test equipment into commands for real lab
equipment.
Modular Mixed-Signal Testbench Structure
Chip Level Mixed-Signal Testbench Structure in VHDL
A typical chip level mixed-signal testbench includes various elements such as bus functional models,
stimulus generation, reference models and data checking etc. Historically, these testbench elements were
scattered at the testbench level or grouped according to these different categories under the testbench.
The input stimulus is stored in sample buffers after generation and the output result is captured in other
buffers for post processing and analysis. Both the buffers and analysis routines reside at the testbench
level. Over time, we realized that it is very cumbersome to modify the stimulus and deal with the buffers
and analysis routines directly. It is also very inconvenient to port and reuse the testbench from project to
project.
The signal generation, analysis and conditioning portions of the testbench could be better handled by
encapsulating the common data storage, analysis and filtering routines into a general purpose signal
generator, analyzer filter, and other devices. The generator, analyzer and filter serve as virtual test
equipment and can be instantiated and controlled in the testbench with different signal routing and
programmable parameters. An example chip level mixed signal testbench is shown in the Figure 1. The
@Legerity, Inc.

4. user programs the signal generator and analyzer virtual equipment by a centralized command bus and
can instruct the virtual test equipment to perform signal generation, data capture, and post processing
tasks in both time and frequency domain.
Chip Level VHDL
Command Bus Test Case Mixed-Signal Test Bench
Digital Digital
Signal BFM BFM Signal
Generator Analyzer
DUT
Analog Analog
Signal Signal
Generator Analyzer
Figure 1 Chip Level Mixed-Signal Test Bench
Analog signals such as current and voltage are represented as real scalars in VHDL[1]. The digital
versions of the generator and analyzer are similar to the analog, but have data converters placed on the
front end. The Bus Functional Model (BFM) is under the direct control of the command bus as well and
is used as the connection between the Design Under Test (DUT) and the digital generator and analyzers.
The analog signals are directly fed into the DUT from the sampling buffers within the signal generator
and are captured into the sampling buffers in the signal analyzer for analysis.
Block Level Analog Circuit Design Testbench Structure Using Mixed-Signal
Simulators
When designing block level analog circuitry within the context of complex mixed-signal system design,
it is very challenging to verify the functionality of the block design with signal control and processing
cross technology (domain) boundaries. Mixed-signal simulators have come to the rescue to combine the
continuous time transistor level differential equation solver with an event driven discrete time digital
simulation kernel. VHDL-AMS has the potential to encompass the S-Domain circuitry, Z domain
transfer as well as the software algorithms at the same time.
However, analog designers often face the challenge of building complex testbenches to fully utilize the
capability of the mixed-signal simulator. This task could be made simple by using the well defined,
documented and ready to use virtual test equipment. The signal generator and analyzer could be easily
plugged into the block level testbench as shown in Figure 2. The signal generators and signal analyzers
in VHDL could be used in conjunction with AMS interface elements in the simulation. Mixed signal
generators and analyzers in VHDL-AMS could also be built to directly interface with the transistor level
design. These virtual test equipment could be used for block level mixed signal system simulation as
well as measuring of the characteristics of the analog circuitry such as linearity, stability, I/O
impedances, etc.
@Legerity, Inc.

5. Block Level Mixed-
Command Bus Test Case Signal Test Bench
VHDL AMS AMS VHDL
Signal Interface Interface Signal
Generator Element Element Analyzer
DUT
VHDL-AMS VHDL-AMS
Signal Signal
Generator Analyzer
Figure 2 Block Level Mixed-Signal Test Bench
Virtual Test Equipment Programming Interface
It is desirable to have a generic programming interface for these signal generators and analyzers to be
able to use them with different platforms or languages. A text based language independent command bus
is built to serve as an abstract application layer on top of the virtual test equipment as shown in Figure 3.
The application layer consists of the command bus, testbench and testcase specification and the
transaction layer includes the signal generator, signal analyzer, other virtual test equipment, and the
DUT. The testcase could be written in multiple languages such as VHDL, Verilog, Specman, or through
a direct text file of commands to be fed to the Command bus.
Text File Verilog Testcase VHDL Testcase Specman Testcase
Test Bench
Application Layer
Command Bus
Transaction Layer
Signal DUT Signal
Generator Analyzer
Figure 3 Mixed-signal testbench programming interface
The command bus is mainly used to control and configure the virtual test equipment and pass the
specification for analysis and data checking. The intelligence of stimulus generation and functional
checking is encapsulated in the transaction layer of the virtual test equipment so that the application
layer is very easy to construct.
The command bus is implemented as a simple unidirectional bus with simple handshaking as shown in
Figure 4.
@Legerity, Inc.

6. 1. When ACK is 0, a command character is broadcast to the bus and the request signal is driven high;
2. Each device receiving the character will drive a 1 on the ACK signal;
3. When ACK becomes 1 (all devices acknowledge), the request can be removed;
4. When each device detects the removal of the request, they will drive a 0 on the ACK signal.
5. Steps 1-4 are repeated until the entire command is transmitted. To signify the end of the command,
the null character (0) is sent. Upon receipt of the null character, the receivers are free to parse the
command and execute it, if necessary.
DATA
REQ
ACK
Figure 4 Command bus timing diagram
The transmission of the entire command line is text message based and may or ma y not consume any
time. The decision of when to acknowledge the null character, and hence control time consumption, is
up to each of the receiving devices.
Virtual Test Equipment Devices
There are several different types of virtual test equipment devices built in our environment including
signal generator, signal analyzer, digital/real converters, filters, logic monitor, impedance meters, etc.
One important aspect of the mixed signal system simulation is through spectrum analysis in the
frequency domain. The merits of interests may include the full path gain as well as signal to noise ratio,
power spectrum density, harmonic distortion etc. We have included a rich set of commands in the signal
generators and signal analyzers to carry out spectrum analysis as shown below. Fast Fourier Transform
and Inverse Fast Fourier Transform are provided to facilitate the data conversion between the time and
frequency domains conveniently.
All of the existing devices receive commands from the command bus with the following format:
<device> <inst_name> <command> [<data> …]
The <device> is the type of the device being used. For example, “sig_ana” is the device name for all
instances of the signal analyzer. The <inst_name> is the individual instance name with the
corresponding device type and generic parameters. The <command> is the action supported by the
device and is specified by the user in the testcase. And finally, <data> is the extra parameters associated
with the command. Each device has its own command set, described in the sections below, and each
command may or may not have data associated with it as illustrated in the following sections.
Signal Generator
The signal generator is designed as two processes sharing a sample buffer. One process interprets
commands from the command bus and creates the sample buffer. The second process feeds the sample
buffer to the output according to the chosen trigger. The signal generator has the following list of
features
n external/internal triggers;
n programmable number of samples;
n one output per signal generator with respect to inst_name;
@Legerity, Inc.

7. n multiple signal sources
n samples loaded from file
n samples generated via IFFT from half spectrum file
n sum of exponential sine waves (DMT)
n triangle, ramping, and square waves
n noise
n DC value
n sample modification: min, max, abs;
n configured with generics or the command bus; and
n phase shift (skip samples).
The following is the entity code of the signal generator and its conceptual symbol. It uses the
std_logic_1164 and conv_types packages to define the types used in the entity. The generic inst_name
defines the instance name of the device. The default_sample_period and default_trig_type define how
the generator is clocked, by default. The trig_type can be internal, rise, fall, or risefall. If the trig_type
is internal, the internal clock generator is used and its period can be set with the default_sample_period.
If the trig_type is rise, fall, or risefall, then the signal is clocked by the appropriate edge of the ext_trig
pin. The default_sample_size is the default size of the sample buffer. Each of these defaults can be
overridden through commands.
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.conv_types.all;
entity signal_gen is
generic (
inst : string := "Vin1";
default_sample_period : time := 1 us; Req Ack
default_sample_size : natural := 1024;
default_trig_type : trig_type_t := internal Data Signal_out
);
port( Ext_trig
req : in std_logic;
data : in std_logic_vector(7 downto 0);
ext_trig : in std_logic; Sig_gen
ack : out std_logic := '0';
signal_out : out real := 0.0
);
end entity signal_gen;
The <command> for the signal generator can be one of the following: config, restart, skip, disable,
enable, load, load_spectrum, sine, complex_sines, exp, pwl, pulse, square, hanning, noise, clear, min,
max, abs, one_shot, continuous, or DC. Each command that creates a signal, e.g. sine, can replace the
existing contents of the buffer with the new signal, add the new signal to the buffer, or place the product
of the buffer contents and the new signal into the buffer. Hence, one can create modulated or
complicated composite signals.
Signal Analyzer
The signal analyzer will measure signals and check that the signals meet specifications. If the signals do
not meet the specifications, the signal analyzer will generate an error. The architecture is similar to the
signal generator except in the reverse direction. There is a sampling process that writes into a shared
sample buffer, and a command execution process that analyzes the buffer. In addition, there are two
@Legerity, Inc.

8. FFT buffers corresponding to two different channels. FFTs can be performed one time and the resulting
spectrum can be repeatedly analyzed with little overhead.
The signal analyzer has the following list of features:
n external/internal triggers;
n programmable number of samples;
n two inputs per signal analyzer with inst_name specified on generic;
n can be set for differential inputs for some measurements
n for other measurements (e.g. total harmonic distortion) one input may be the input to a
device and the other input may be the output of a device.
n spectrum analysis
n bin measurement,
n peak bin measurement,
n cutoff,
n ripple,
n PSD (power spectral density),
n Signal to noise ratio,
n Total Harmonic Distortion,
n Template comparison,
n group delay,
n four wire return loss
n phase difference,
n displaying or saving of spectrum;
n AC/DC analysis
n zero crossing (can generate trigger for other blocks)
n peak to peak
n rise/fall times
n DC level
n period,
n power,
n gain
n Units can be programmed to be absolute or dB.
n Can save samples or spectrum to a file
n global tolerances can be specified rather than specifying tolerance for all commands
The following are the entity code of the signal analyzer and its conceptual symbol. It uses the
std_logic_1164 and conv_types packages to define the types used in the entity. The generic inst_name
defines the instance name of the device. The default_sample_period, default_trig_type, and the
default_sample_size are similar to the like named signal generator generics. The output error_status will
be driven low by default, but if a check command finds the signals to be outside of the specifications,
the error_status will be driven high for the remainder of the simulation. This allows the testbench to
monitor the status of the simulation, if it so chooses.
@Legerity, Inc.

9. library ieee;
use ieee.std_logic_1164.all;
library work;
use work.conv_types.all;
entity signal_ana is
generic (
inst : string := "Vout1";
default_sample_size : natural := 1024; Req Ack
default_sample_period : time := 1 us;
default_trig_type : trig_type_t := rise); Data Error_status
port( Ext_trig
req : in std_logic;
data : in std_logic_vector(7 downto 0); Signal1_in
ext_trig : in std_logic;
ack : out std_logic := '0';
signal1_in : in real; Signal2_in
signal2_in : in real; Sig_ana
error_status : out boolean := false
);
end entity signal_ana;
The <command> for the signal generator can be one of the following: config, restart, fft,
check_bin_mag, disp_peak_bin_mag, check_cutoff, check_ripple, check_psd, check_snr, check_thd,
check_group_delay, check_phase, check_gain, disp_spectrum, gen_zero_cross, check_peak2peak,
check_rise_time, check_fall_time, check_delay, check_dc_level, check_period, gen_templ, check_4wrl,
check_abs_delta, check_inl, check_dnl, check_inl_offset, check_inl_gain, check_fft_ratio_im,
check_fft_ratio_re, check_fft_ratio_mag, or check_fft_ratio_phase.
Real/Digital Converter
The real- to-digital converter and digital-to-real converter handle the data type conversion of analog and
digital signals for data generation and analysis purposes. An entity for the real_to_digital device is
shown below. The format of the digital value is determined by the conv_type generic. The value can be
smag, sfix, unsign, alaw, or ulaw. Smag indictes signed magnitude conversion, sfix indicates twos
compliment, unsign indicates an unsigned number and alaw and ulaw are the compressed PCM data
format. The input signal is first offset by the offset amount and then scaled by scale
(result=(input+offset)*scale). The result is then converted to an integer by using the trunc, floor, ceil, or
round functions, as defined by the round_type generic. The conversion can be triggered by the input
changing, or by one or both of the edges of the clk signal. This behavior is controlled by the trig_type
generic, and has the value of input_event (where the output is triggered by a change of the input signal),
rise, fall, risefall, or internal. The value of internal is treated the same as input_event. The digital to real
converter is similar to the real to digital converter except for the direction of the conversion. Also, there
is no need to round, since the inputs are integers.
@Legerity, Inc.

10. use ieee.std_logic_1164.all;
use work.conv_types.all;
entity real_to_digital is
generic ( Clk
conv_type : conv_type_t := smag;
scale : real := 1.0;
I O
offset : real := 0.0;
trig_type : trig_type_t := input_event;
round_type : round_type_t := trunc); Real_to_digital
port (
i : in real := 0.0;
clk : in std_logic := '0';
o : out std_logic_vector);
end real_to_digital;
Filter
The filter is a simple FIR or IIR filter device that can be used with the signal analyzers for signal
conditioning and filtering purposes. For example, in telephony applications, it is sometimes desirable to
generate a high frequency metering signal that is added to voice signals. The filter can be used to
remove the voice signals so that the metering signal envelope, frequency, and other characteristics can
be analyzed.
library ieee;
use ieee.std_logic_1164.all;
entity filter is
generic (
inst : string := "filt";
order : natural := 8; Req Ack
Ts : time := 20 us);
Data Output
port (
req : in std_logic;
data : in std_logic_vector(7 downto 0); Input
ack : out std_logic := '0';
input : in real; Filter
output : out real := 0.0);
end filter;
Logic Monitor
The logic monitor device is used to monitor the std_logic value of a simple signal. The logic monitor
keeps a scoreboard of the values that a signal has taken during a simulation. In this fashion, it can detect
if an event has ever taken place. For example, the logic monitor will record if an interrupt signal ever
became a ‘0’ during the simulation. In addition to keeping a historical scoreboard of values that a signal
has achieved, the logic monitor can be used to check the current value of a signal and to wait for a signal
to become a certain value. The possible logic values are ‘U’, ‘X’, ‘0’, ‘1’, ‘Z’, ‘W’, ‘L’, ‘H’, or ‘-‘. The
logic monitor accepts “check” commands to check the scoreboard or current value of the input. If these
check commands fail, the error_status signal is asserted.
@Legerity, Inc.

11. use ieee.std_logic_1164.all;
entity logic_monitor is
generic (
inst : string := “logic1”); Req Ack
port ( Data Error_status
req : in std_logic;
data : in std_logic_vector(7 downto 0);
ack : out std_logic := '0'; I
i : in real := 0.0;
error_status : out boolean := false Logic_monitor
);
end logic_monitor;
Mixed Signal Verification Example with Virtual Test Equipment
The proposed modular testbench structure and virtual test equipment have been applied successfully to
achieve the mixed signal verification of Legerity’s Mercury project. Mercury is Legerity’s next
generation low cost, high performance and software programmable line interface and audio processing
circuit for Voice Over Broadband (VOB) applications. It integrates various analog circuitries such as
line control, switcher, supervision and Sigma-Delta A/D converters etc. together with the highly
programmable digital filter and CODEC into a single chip. When combined with the low cost telephone
line driver, Mercury delivers a total voice path solution for multiple country applications worldwide and
bridges the gap directly between the phone line 2-wire interface and PCM highway.
One good example of the application of the virtual test equipment is to characterize the end-to-end group
delay for the receive path of the Mercury device as shown in Figure 5. The incoming signal is an
adjacent tone pair and is applied to the Rxa1 signal on the PCM highway. The signal is processed
through the Mercury device and data is collected at the two-wire interface signal metallic voltage, Vm1.
The signal ana lyzer first performs an FFT to convert the data samples into the frequency domain and
calculates the group delay directly with the command check_group_delay.
Signal Analyzer
Signal Sample Sample FFT A
Design Under Test
Generator Buffer Rxa1 Mercury Device Vm1 Buffer A
Check_
group_
Sample FFT B delay
Buffer A
Figure 5 Measuring group delay using virtual test equipment
@Legerity, Inc.

12. The procedure to characterize the RX path end-to-end group delay using the virtual test equipment is
shown step by step below.
First of all, we need to configure the signal generator and signal analyzers. The signal generator Rxa1 is
based on an external trigger. In this case, it is the rising edge of the Frame Sync (FS) on the PCM
highway. The period of the Frame Sync generated by the testbench is 124928ns. Using a sample count
of 64, the frequency width of each bin, f b , is about 125Hz. After the signal generator Rxa1 is configured
and cleared, two SINE wave tones (12*f b =1501Hz and 13*f b =1626Hz) were added to the generator
sampling buffer. Both signals have a magnitude of 2084 and a phase of 0°. On the other hand, the signal
analyzer has two channels of inputs including Rxa1 at the PCM highway on channel a, and Vm1 at two-
wire interface on channel b. The config command designates the signal analyzer “checks” will be
performed based on a minimum/maximum range (“min_max”). Alternatively, the signal analyzer could
check on relative or absolute tolerances. The “internal” keyword indicates that the signal analyzer is
capturing data based on the internal trigger with the sampling period of 244 ns. With a sampling period
of 244ns and 32768 samples in the sampling buffers, the minimum frequency, which is also the
frequency width of each bin, is the same as the generator (about 125Hz). The sampling buffers will
capture and hold 8ms worth of data for analysis.
sig_gen rxa1 config rise 64
sig_gen rxa1 sine 12.0 2084 0 add
sig_gen rxa1 sine 13.0 2084 0 add
sig_ana rxa1_vm1 config min_max 32768 internal 244.0 ns
The testcase has other setup commands to configure the external models and components as well as the
Mercury device itself. After the simulation is initialized and the Mercury device is put in the normal
active state, the testcase waits for 10ms to store enough data in the sampling buffers of the analyzer. An
FFT is then performed on sample buffers for both channels, a and b, to convert the data from the time
domain into frequency domain. A a simple check_group_delay command take the group_delay
measurement on bins 12 and 13, and checks whether the measurement is between the minimum group
delay of 350us and the maximum group delay of 360us.
sig_ana rxa1_vm1 fft a
sig_ana rxa1_vm1 fft b
sig_ana rxa1_vm1 check_group_delay a b 12 13 350e-6 360e-6
The check_group_delay routine examines the spectrum of the Rxa1 input channel and Vm1 output
channel at each tone (1500Hz and 1625Hz). It calculates the phase shift of each corresponding
frequency bin and in turn the group delay of the system using the derivative of the phase delay with
respect to frequency.
θ 13 − θ 12
group _ delay =
2π 125 * (13 − 12)
As you can see, the signal analyzer supplies the domain transfer and spectrum analysis routines and
hence significantly simplifies the testcase writing.
A Proposed Unified Verification and Validation Platform
Historically, chip verification and validation environment were built standalone. Chip verification
testcases were constructed with high- level languages such as VHDL, Verilog or Specman. The signal
@Legerity, Inc.

13. generator, analyzer, and bus functional model were built without the information of possible forward
compatibility with the validation effort. On the other hand, the lab validation environment could be built
upon a hardware abstraction layer to control various lab equipment through the GPIB bus. An interactive
GUI interface could be constructed on top of the hardware abstraction layer to facilitate easy test script
writing. Legerity’s validation platform includes a Commlab hardware abstraction layer and Tcl is the
language of choice to build the Windows based Advanced Computer Interface (WinACIF) program as
the platform for validation script development. Unfortunately, a lot of effort was duplicated between the
verification and validation teams to achieve similar functional testing and coverage.
The modular virtual test equipment is designed to mimic the real lab equipment. The virtual test
equipment’s programming interface through the Command bus is somewhat similar to the programming
concepts via the GPIB bus used in the lab validation environment as shown in Figure 6. As you can see,
the corresponding components match naturally between the setup of these two different platforms.
However, a link to bridge the gap between the verification testcase and the TCL validation script is
missing. The virtual test equipment could be built with tags or parameters, which identify themselves
corresponding to the real lab equipment for a target lab test bench setup. The verification testcase can
then be translated into the validation script through a Virtual Lab Translator implemented in TCL. In
most of the cases, this process is unidirectional from verification to validation. Occasionally, the
validation script could be translated into the verification testcase as well if the feature checking routine
is proven to be mature and reliable. This way, we can streamline and reuse the development effort
between the verification and validation teams and we can also save significantly on the development
cost of mixed-signal chip validation.. This methodology maintains the backward compatibility of all the
TCL scripts already developed for feature validation of the legacy mixed-signal chip.
Verification Virtual Lab Validation
Testcase Translator Script (TCL)
Command WinACIF
Parser
Commlab
Application Layer
Command Bus GPIB Bus
Transaction Layer
Supply Supply Supply Supply
Supply
Siganl Supply
Singal Supply
PCM4 Supply
PCM4
PCM4 PCM4 Supply Meter
PCM4
Generator Analyzer4
PCM PCM4 PCM4
PCM4 PCM4
DUT DUT
Figure 6 Unified verification and validation platform
@Legerity, Inc.

14. Conclusions
This paper describes a modular approach to construct the mixed-signal testbench environment for mixed
signal simulation. A reusable abstract transaction layer of virtual test equipment implemented in VHDL
for mixed-signal simulation was introduced to improve the verification environment efficiency and
reusability. These virtual test equipment includes the analog and digital signal generators, analyzers,
filters and logic monitors etc. and they are similar in concept to the lab test equipment. Many of these
virtual devices are capable of performing complicated post-processing tasks in both the time and
frequency domains. While the lab devices may be controlled through the GPIB bus, the virtual lab
equipment is controlled through a simple text message based unidirectional command bus. These virtual
test equipment offers the following benefits for the functional verification of complex mixed signal
chips.
• The virtual test equipment offers the separation of the application layer and transaction layer of the
traditional testbench structure. With most of the verification intelligence encapsulated within the
virtual test equipment in the transaction layer, chip level testbenches and testcases can be generated
easily.
• The virtual test equipment offers easy reusability and portability from project to project
• The virtual test equipment can be used for block level cross domain simulation and characterization
within a mixed signal simulator environment and improve the analog circuitry design efficiency.
• The virtual test equipment is built with forward validation compatibility so that a unified verification
and validation platform can be achieved by translating the commands to these virtual test equipment
into commands for real lab equipment.
These virtual test equipment, when used properly, could significantly speed up the functional
verification of mixed signal chip development and decrease the development cost of mixed-signal chip
validation.
References
[1] J. Lear, Z. Xu, “High Throughput Mixed Signal Verification Techniques in VHDL”, DVCon 2004,
Mar.2004
[2] Peter Ashenden, “The Designer's Guide to VHDL, 2nd Edition”, Morgan Kaufmann, 2001
@Legerity, Inc.