It has long been recognized that the greatest obstacle to a System-on-Chip (SoC) design team’s success is verification. The verification challenge is getting exponentially worse as larger and more sophisticated analog circuits are now integrated with digital designs.

Verification of digital sub-systems is based on advanced techniques ensuring automation, reliability and predictability. To date the use of manually-verified hand-coded analog-block models within a digital verification environment has been sufficient. However, the move to greater levels of integration, advances in process node, and increasing market pressures now require an automated and metrics-driven verification methodology to provide confidence in a mixed-signal design to sign-off prior to submitting it for fabrication.

YOGITECH's approach combines digital and analog verification in the same environment. It provides engineers with a solution extending concepts and techniques widely used in state-of-art dynamic functional verification of a digital circuit into the analog domain.

In the last five years, functional verification has made great progress, driven by the increase in complexity of digital circuit in speed, functionalities and gate-count.

In dynamic verification, the traditional approach based on direct tests has been replaced or integrated by tools allowing random-constrained stimuli generation, self-checking mechanisms and functional coverage evaluation.
Using this technique increases the probability of covering nasty corner cases in the whole space of circuit states because it demands to a random approach. The result is a higher efficiency in bug discovery.

Moreover, this kind of approach also includes a methodology able to increase automation and re-use levels, improving verification process reliability. The verification engine, together with an object-oriented verification language, allows a relevant increase in verification productivity and quality.

In traditional approaches, digital and analog designs are normally completely separated but, in the end, the two parts must work together in silicon: the verification of their interface plays a significant role in top-level design validation.
On the digital side, coverage-driven functional verification based on object-oriented languages ensures a high level of reliability for digital circuits, but only behavioral models of analog blocks can be included. Without an automatic flow which defines and checks these models toward the actual implementation (i.e. transistor level), the confidence level in verification results of the combined circuit drops significantly.

FIG.1 Digital design / Functional verification




On the other hand, mixed-signal simulation tools, able to link and simulate analog and digital blocks in the same test-bench, are already available on the market, but they mainly address analog functionalities and have difficulty supporting complex digital blocks at the same time. Therefore, only digital sub-circuits are included in the simulation to simplify the process: this provides incomplete verification results. On top of that, in these scenarios, concepts like automation, functional coverage evaluation, self checking mechanisms and re-usability are still far from being used effectively.

FIG.2 Analog design / Mix-mode simulation




By comparing actual digital and analog mixed-signal verification flow, it becomes clear that the last is two steps behind, as illustrated in FIG.3
As a result, the overall verification coverage of a mixed-signal system is very often decreased and system bugs appear very late in the design process.
This is responsible for an expensive debugging phase, re-design and silicon re-spins with an escalation of costs and unpredictability in time to market.
Increasing the verification quality and its level of automation for mixed-signal circuit become more and more important.
The extension of verification methodology into AMS domain allows us to fill the gap improving the effectiveness of the whole development process and product quality.

FIG.3 Traditional verification flow for digital [A] and analog [B] mixed-signal circuit

The YOGITECH innovative approach unifies state-of-the-art verification tools, like Cadence Specman Elite, and mixed-signal simulators to create a common verification environment.
As illustrated in FIG.4, the verification environment surrounds the device under test (DUT) providing stimuli, collecting and elaborating simulation results according to a pre-defined verification plan. The environment is implemented using e (IEEE P1647 standard) as the object-oriented hardware verification language, which allows us to capture rules from specifications as well as to automatically generate random and pseudo-random coverage-driven tests.
Both analog and digital parts of the DUT can be handled in the same structure.

FIG.4 AMS vkit architecture

	DUT Device Under Test
	HVL BLOCKS Hardware Verification Language
	AHDL BLOCKS Analog/Digital Hardware Description Language

	HVL COMPONENTS
	AHDL COMPONENTS

The definition of the verification plan is the first and maybe the most critical step in the flow: design team (both analog and digital) has to seat together with verification team and they have to define parameters to be measured and procedures to perform such measurements, metrics to evaluate coverage and target results. Based on that, the verification environment will be developed as depicted in FIG.5

eRM (e language Reuse Methodology) compliance of vTerminals and vComponents ensures that the AMSvkit can be used with other verification components to build sophisticated verification scenarios. It is strongly recommended that the same approach be used in setting up one's own environment, in order to be able to easily re-use it for similar devices or to extend it in case of specification changes.

The act of verification means to extensively simulate the circuit under test in order to check its functionality according to the specifications in all the conditions in which it may work. The proper usage of the verification tool allows a deep process control: for example stimuli can be defined on-the-fly based on simulation results. Thanks to this feature, it is possible to define smart verification strategy, thus saving simulation time as well.

FIG.6 Verification flow

		Derived from the DUT specification
	•	Define the circuit parameters to measure.
	•	Define the circuit conditions and procedures for measurement.
	•	Define the functional coverage metric.

		According to the verification plan
	•	Select the vTerminals to be used.
	•	Synchronize the stimuli and checks.
	•	Define the structures for monitoring predetermined parameters.
	•	Implement the coverage items.

		Simulation run and result collection
	•	Evaluation coverage achieved.
	•	Reports are generated from the monitors.
	•	Log files generated.
	•	Signal waveforms generated.

YOGITECH's AMSvkit can be used to verify analog mixed-signal circuits at the module-level or at the top-level as illustrated in FIG.7
In fact, its components, as well as the module level environment developed in the proper way, can be instantiated to build a more complex verification scenario including big digital part, analog IPs/modules, software part and external circuits.
It operates through all levels of abstraction, from spice-level descriptions to high-level modeled DUT's and with all Specman Elite supported mixed-signal simulators. Simulator parameters like temperature and technology process model sets can be varied in multi-simulation runs, handling parallel regression tests with cumulative coverage evaluation.

FIG.7 Block level [A] and top level [B] verification environment



Often, to avoid an explosion in simulation time due to the increase in circuit complexity, it is necessary to create behavioral models for different blocks to be used at higher levels of the hierarchy (e.g. top-level SoC verification). The reliability of these models has to be evaluated with respect to the validation procedure of the circuit itself.
Referring to a well-implemented model in absolute terms makes no sense: the model is good if it behaves as the real circuit does under the conditions in which the circuit itself is validated.

The AMSvkit allows us to build an automatic flow checking the actual circuit implementation (transistor level description) and its model (analog high level description) in the same verification environment as shown in FIG.8
This is essential in order to gain enough confidence in the model and to be able to calibrate it appropriately versus transistor level behavior.

FIG.8 Self checking verification environment for behavioral models validation

YOGITECH's AMSvkit * basic provides all of the components necessary to build a verification environment for a mixed signal DUT.

The user can easily create and configure the verification environment through a graphical user interface and build different test scenarios. Alternatively, the environment can be script-driven from the command line to facilitate the creation of powerful mixed-signal circuit verification regression suites.

Due to the modular architecture of the AMSvkit * basic and the intuitive graphical user interface for building the Specman Elite verification environment, details of the analog DUT is not required by the verification engineer and deep knowledge of the hardware verification language is not required of the analog designer for the creation of an effective mixed-signal verification methodology.


KEY ELEMENTS

vTerminals set
More than 30 vSources and vProbes (i.e. configurable bridge between the e-based verification environment and analog domain) to generate and drive current//voltage signals (e.g. puse/sinusoidal/DC generator, ripple generator, noise generator) as well as to monitor and to process analog information (e.g. voltage/current sampling, time detectors, AC, linearity, monotonic detectors, etc).

vComponents set
Ready-to-use verification environments for bandgap cells, oscillators, comparators, close loop opamps and DC-DC converters including self-checking and coverage evaluation based on analog metrics that are easy to integrate in a complex mixed- signal environment and to extend to more complex functions.

Sequence database
A set of pre-defined sequences to drive vSources and vProbes to extract parameters by vProves.