@Legerity, Inc.

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.

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.

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.

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.

Command Bus

Analog Signal Generator

Analog Signal Analyzer

DUT

Chip Level VHDL Mixed-Signal Test Bench Test Case

Digital Signal Generator

Digital Signal Analyzer

BFM

BFM

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.

Command Bus

VHDL-AMS Signal Generator

VHDL-AMS Signal Analyzer

DUT

Block Level Mixed-Signal Test Bench Test Case

VHDL Signal Generator

VHDL Signal Analyzer

AMS Interface Element

AMS Interface Element

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.

Command Bus

Signal Generator

Signal Analyzer

DUT

Text File Verilog Testcase VHDL Testcase Specman Testcase

Test Bench Application Layer

Transaction Layer

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.

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.

REQ

ACK

DATA

Figure 4 Command bus timing diagram

The transmission of the entire command line is text message based and may or may 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.

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; default_sample_size : natural := 1024; default_trig_type : trig_type_t := internal ); port( req : in std_logic; data : in std_logic_vector(7 downto 0); ext_trig : in std_logic; 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

Req Ack Data Signal_out Ext_trig Sig_gen

@Legerity, Inc.

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.

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; default_sample_period : time := 1 us; default_trig_type : trig_type_t := rise); port( req : in std_logic; data : in std_logic_vector(7 downto 0); ext_trig : in std_logic; ack : out std_logic := '0'; signal1_in : in real; signal2_in : in real; 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.

Req Ack Data Error_status Ext_trig Signal1_in Signal2_in Sig_ana

@Legerity, Inc.

use ieee.std_logic_1164.all; use work.conv_types.all;

entity real_to_digital is

generic ( conv_type : conv_type_t := smag; scale : real := 1.0; offset : real := 0.0; trig_type : trig_type_t := input_event; round_type : round_type_t := trunc);

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; Ts : time := 20 us); port ( req : in std_logic; data : in std_logic_vector(7 downto 0); ack : out std_logic := '0'; input : in real; 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.

Req Ack Data Output Input Filter

Clk I O Real_to_digital

@Legerity, Inc.

use ieee.std_logic_1164.all;

entity logic_monitor is

generic ( inst : string := “logic1”);

port ( req : in std_logic; data : in std_logic_vector(7 downto 0); ack : out std_logic := '0'; i : in real := 0.0; error_status : out boolean := false );

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 Generator

Sample Buffer

Design Under Test Mercury Device

Signal Analyzer

Sample Buffer A

Sample Buffer A

FFT A

FFT B

Check_ group_ delay

Rxa1 Vm1

Figure 5 Measuring group delay using virtual test equipment

Req Ack Data Error_status I Logic_monitor

@Legerity, Inc.

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, fb, is about 125Hz. After the signal generator Rxa1 is configured and cleared, two SINE wave tones (12*fb=1501Hz and 13*fb=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.

)1213(*1252_ 1213

−−

=π

θθdelaygroup

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.

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.

Supply PCM4 Supply

PCM4

Command Bus

Command Parser

Verification Testcase

Siganl Generator

DUT

Supply PCM4 Supply

PCM4 Singal Analyzer

Supply PCM4 Supply

PCM4

GPIB Bus

WinACIF

Validation Script (TCL)

Supply PCM4

DUT

Commlab

Supply PCM4 Supply

PCM4 Meter PCM4

Virtual Lab Translator

Application Layer

Transaction Layer

Figure 6 Unified verification and validation platform

@Legerity, Inc.

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