Application Hardware Modeling: Selective modeling for early prediction of subsystem performances through simulation

Ming-Hao Kuo, Florian Espalieu, Nathalie Dufayard
Dolphin Integration SA

ABSTRACT

The virtual validation of subsystem performances (Pop-up Noise, Signal-to-Noise Ratio, Power supply Noise, Power consumption...) requires the modeling and simulation of complete subsystems. Application Hardware Modeling (AHM) consists in addressing the risks of performance degradation while integrating a Silicon IP in its Integrated Circuit (IC) and this IC on its Printed Circuit Board (PCB). The selection of relevant models for a subsystem performance, along with the creation and validation of models through equivalence checking, are the basics of Application Hardware Modeling for right-on-first-pass subsystems!

INTRODUCTION

A subsystem is defined as a set of components dedicated to one function of the overall system and configured for a specific application (e.g. audio).

Each component of the subsystem can be provided by a different vendor. The subsystem is assembled through IC integration and application design.

However, the design of a subsystem is not just about assembling various components. Indeed, the intrinsic performance of each component is not sufficient to guarantee the performance of the final product. Issues such as Pop-up Noise (PuN), crosstalk, power noise, Signal to Noise Ratio (SNR) degradation… can be introduced during the integration process and can degrade the overall performance.

It is often considered possible to assess the performance of the subsystem only at the end of the integration process. However, the issues can in fact be managed earlier if treated globally at subsystem level. The performances of the final product then can be seen as a set of subsystem performances.

The traditional methodology for verifying the Silicon IP or chip performances at system-level is to create characterization boards. However, this step is performed late in the design process. Therefore, if the board reveals performance degradations, this leads to costly diagnostics after prototyping. The longer it takes to identify and fix sources of degradation, the longer it takes to get the product on the market!

The rising complexity of each component, as well as of the subsystem as a whole, makes complete SPICE-level simulations either unfeasible or untractable. Therefore, multi-level modeling and simulation has become a must for early prediction of subsystem performances.

This article will present a methodology called Application Hardware Modeling (AHM) based on selective modeling of subsystem components. A specific focus will be put on the challenges to create models and to check their relevance.

APPLICATION HARDWARE MODELING (AHM)

The AHM methodology consists in the selective modeling and simulation of a complete subsystem in order to manage earlier the risk of performance degradation while integrating a Silicon IP in its IC and the IC on its PCB.

In order to verify the impact of potential integration issues and the sources of degradation which can occur during the design process, simulations must be performed earlier in the design process. This requires the creation of Virtual Application Boards (VAB) to be simulated for each targeted performance.

The first step consists in identifying the subsystem. As the embedded components, as well as on-board devices (including peripherals and parasitics), have to be simulated, AHM goes beyond integrated circuit (IC) boundaries. The main challenge to successfully simulate a subsystem is to select which components are required for each specific system-level performance (e.g. PuN or SNR), then to create the adequate models of these components at the relevant abstraction levels with the appropriate accuracy.

MODELING IS THE CRUX

Subsystem simulation presupposes having suitable models with appropriate representation of performance both for behavior and for disturbance propagation. Unfortunately, this is generally not the case!

Before starting the development of a model from scratch, the natural reaction is to search for an existing one.

For instance, if the subsystem includes an operational amplifier, the designer often wants to use the model provided on the website of the supplier.

However, such a choice must be carefully assessed because models provided by the component suppliers are not necessarily representative of the performance which must be observed. The right questions to be addressed are: what is the targeted performance? Which performance of this component needs to be modeled? Is the model representative of the reality for this performance?

For example, to simulate the subsystem of a Pulse Width Modulated (PWM) Digital Analog Converter (DAC), the Application Schematic and the power supply noise rejection of its components are essential to represent the real SNR performance.

Figure 1: Bloc diagram of a PWM DAC and its application schematic

Since most of the models provided by component suppliers do not take disturbances into account but only model the overall functionality, such models will not be appropriate for the SNR simulation of the PWM DAC and its application schematics (see figure 1). In such a case, the suitable model has to be representative both for behavior and for disturbance propagation. As a consequence, models must either be improved or created from scratch.

The major difficulty when creating a model is to identify which behaviors and effects have to be modeled. The best models are the simplest ones which represent only the behaviors and effects for a specific performance in order to avoid unnecessary calculations during simulation. Specific know-how is generally required to be able to identify which behaviors and effects have to be modeled to create such behavioral models, so called Electrical Performance Logic and Analog Models (EPLAM).

For instance, in the case of a PWM DAC, the digital part of the design is not sensitive to power supply noise as the output signal is encoded as binary data. On the other hand, noise will occur as soon as this signal will be considered as an analog one, i.e. at the output buffer. Thus, the EPLAM of the PWM DAC can be a Verilog block generating a simple PWM bit stream (for the digital) which is connected to a SPICE buffer model (for the analog) as shown in figure 2.

Figure 2: Application schematic of an audio DAC

Such a model is quite sufficient to have a realistic performance and is much easier to use in simulation compared to a full-SPICE description!

Once the relevant behaviors and effects have been identified, it is then easy to model with the most appropriate modeling language, whether a Hardware Description Language (HDL) or SPICE, depending on the required accuracy.

In some cases, a black-box model can be used as an EPLAM, if correctly parameterized. Indeed, a model is a set of parameterized equations which can be adapted with the values of parameters deduced from specifications, datasheets or measurement data.

For instance, the EPLAM of a power supply source can be a simple SMASH™ noise source with parameters deduced from specification, datasheet or measurement data as shown in figure 3:

Figure 3: Parameterization of a model

The Power Spectral Density (PSD) of such a source may be described as (f being the frequency):

Once the model has been created, the next step is to validate that it is equivalent to the specification or to the corresponding SPICE implementation so that simulation results can be trusted.

EQUIVALENCE CHECKING

Models can only be representative of a specific subset of the specification or of the SPICE implementation. Therefore, it is mandatory to check their equivalence and accuracy before trusting them in simulation.

The accuracy can only be proven by a comparison to a reference, which can be the specification, datasheet parameters, measurement results or simulation results.

Figure 4: An EPLAM represents only the relevant subset of the SPICE implementation

As an EPLAM does not model all the behaviors and effects of the component (see figure 4), it is necessary to define a class of equivalence, i.e. the simulation patterns and the list of performances with their min and max admissible values as acceptance criteria. The templates thus defined are the references against which the equivalence has to be assessed!

Such verification can be automated by using specific features of EDA solutions. The aim is to automatically detect template violations through visual display as well as on-line error reporting. The SMASH™ single-kernel simulator enables quick verification of SNR, THD, Jitter, power supply noise using the .measure directive for analog signals as well as of timing and signal shapes through VEC files for logic signals.

For instance, in the following example, a top-down equivalence check is performed on an HDL-AMS EPLAM of an amplifier by comparison to the datasheet.

The template is defined by the datasheet transfer function of the amplifier on which a ±10dB margin has been applied.

Figure 5: The EPLAM is not equivalent to the datasheet

As shown in figure 5, the template is violated and the EPLAM cannot be considered as equivalent to the datasheet: either the EPLAM must be improved or the specification requirements must be relaxed if they are too strict!

A less constrained template can be defined with the same datasheet transfer function of the amplifier but with only a ±30dB margin.

Figure 6: The EPLAM is equivalent to the datasheet

As shown in figure 6, no violation is detected which means that the EPLAM is equivalent to the datasheet with respect to the selected class of equivalence (here, the amplifier transfer function).

After all the models of the subsystem are validated through simulation and once a characterization board is available, the simulation results can be validated on silicon. Thus, the characterization ensures the final assessment of equivalence between the simulation results of the subsystem and measurements performed in the laboratory.

The concrete example of an audio subsystem is expressed below:

• AHM methodology has been applied on an audio DAC to create an EPLAM (in VHDL-AMS) representing the PuN level.
• This EPLAM is proven as equivalent to the SPICE model within a ±5 dBVp template.
• The simulation of the EPLAM of the audio DAC with its application schematics gave a PuN level of -49 dBVp during power-up and -76 dBVp during power-down.
• The measurement performed with an oscilloscope on the test board gave a PuN level of -52 dBVp during power-up and -77 dBVp during power-down.

Finally, the equivalence between simulation and silicon results has been proven within a ±5dB template.

APPLICATION: IMPACT OF JITTER ON SNR

For audio subsystems, jitter on the audio converter (be it an ADC - analog to digital converter - or DAC - digital to analog converter) can degrade system-level audio performances.

Indeed, adding jitter on clocks will impact the audio converter’s output noise spectrum, thus impacting its SNR and DR (Dynamic Range).

While the majority of engineers in audio applications are aware of the impact of jitter on SNR or even suffer from it, only few can concretely characterize the type of clock jitter and quantify its impact on SNR.

The impact of jitter on SNR can be forecasted using the AHM methodology to determine through simulation the transfer function between the jitter on clock and audio output SNR performance.

Definition of Jitter Tolerance Template

The transfer function between the jitter on clock and audio output SNR performance can be used to define the Jitter Tolerance Template (JT2). This template is defined as the jitter on MCLK which causes a 1 dB degradation on SNR and DR performances.

The JT2 is defined as the long term jitter (over 10 ms) in the frequency spectrum, at least up to 1 MHz or half of the Master Clock (MCLK/2).

It is determined through simulation with the EPLAM of the audio converter, together with the model of its clock and application schematics on PCB.

In practice, the JT2, as shown in figure 7, indicates the maximal amount (RMS - Root Mean Square - power) of Jitter allowed in a given frequency band, without degrading SNR and DR. It represents the specification.

Figure 7: Example of band dependant Jitter

As a consequence, the use of JT2 is essential for estimating whether the jitter on the clock of an audio converter will degrade its SNR performance, especially for pure digital audio design (e.g. PWM modulator or Class-D amplifier), as it is well known that they are more sensitive to clock jitter than mixed-signal audio converters.

JT2 shall be used, at early stage of IC design-in, to select a suitable audio PLL or clock generator for the audio converter.

Extraction of Jitter Profile

The jitter profile (JP) in frequency domain (or the jitter density spectrum) of the clock source shall be determined for comparison to the JT2.

The JP can be either determined by simulation if the PLL is self-designed or if the clock source pattern is provided, or by measurement with an oscilloscope.

Jitter Profile vs. Tolerance Template

Once the JT2 and the JP are obtained, the profile must be compared to the template. This comparison can be broken down into three steps (see figure 8):

• The first step consists in measuring the clock characteristics (frequency and period variation) with a scope measurement or SMASH™ transient jitter simulation.
• In a second step, using the specific jitter function of SMASH™, the characteristics of the clock (frequency and period variation, cycle to cycle, cycle jitter) can be extracted.
• Once the signal of interest is extracted, e.g. the time domain long term jitter (over 10 ms), SMASH™ can compute the spectrum thanks to its FFT functionality.

The JP can then be superposed to the JT2 after carrying out an FFT normalization, using the formula below:

Figure 8: Comparison of the Jitter profile to the Jitter Tolerance Template

If the JP is in the immune zone (see green zone of figure 9) of the JT2, the audio performance will not be degraded by the clock jitter.

Figure 9: Template composition

However, if the JP is out of the immune zone of JT2 (as shown on figure 10), the audio performance cannot be guaranteed due to jitter impact. Further analysis must be performed to evaluate the impact of the jitter on SNR.

The only way to find out what will be the SNR degradation in advance without fabricating the IC is to perform system-level simulation.

Example of simulation results

Figure 10 shows a JP (red waveform) which is out of the immune zone of the JT2.

Simulation results of the EPLAM of the audio DAC together with the jittered clock and the application schematic (e.g. filters) show an SNR of 73 dB at the output of the subsystem instead of 95 dB as specified for the audio DAC.

This represents a degradation of more than 20 dB! If a 90 dB SNR at system-level is a must, then a clean clock generation is needed to prevent the SNR degradation.

One can select another clock generator or add a clock jitter cleaner, and perform the simulation to verify if the performance of 90 dB can be achieved.

Figure 10: Example Jitter profile out of immune zone of Jitter Tolerance Template

Simulation results vs. measurements

The EPLAM of audio converter for determining the impact of jitter on SNR has been created thanks to the technical expertise of the designer by selecting the critical sub-blocks of the audio converters which are sensitive to clock jitter, and by using specific models of these sub-blocks (e.g. capacitor loading equation or filter equation). The equivalence between the EPLAM of the audio converter has been verified against the SPICE implementation.

Then, the JT2 of the audio converter is verified and validated with measurement results. The validation of the JT2 is done in the laboratory with a jitter generation module and the testboard of audio converter (see Figure 11).

The jitter generation module uses two different techniques to create jitter: dynamic edge filtering and dynamic offset addition. Once the jitter is generated on MCLK, this jittered clock is fed to the clock input of the audio converter.

Several jittered clocks with their JP in the immune zone are generated, and measurement results confirm that there is no SNR degradation. The JT2 is thus validated.

Figure 11: Validation on measurement of the JT2

By using the jitter generation module with the audio converter testboard, different clock jitter can be generated and their profiles can be extracted with SMASH™. Therefore, the equivalence checking of simulation results and SNR measurements can be performed easily, including of course the example illustrated in Figure 10.

OUTLOOK

This article has demonstrated the interest of applying the AHM methodology for early prediction of subsystem performances.

But it is important to mention that this methodology can also be used to define optimized application schematics for each of the market segments targeted for the product. Indeed, a wise combination of SPICE and behavioral models allows to drastically reduce the simulation time of the subsystem and therefore to explore all necessary design cases and optimizations.

Finally, if not applied before the prototyping stage, the AHM methodology can also be used for diagnostic purposes as it allows reproducing sources of degradation and integration issues through simulation in order to verify corrections before re-spins.

We have chosen the example of the impact of clock jitter on SNR to illustrate the benefits of the methodology but it can be applied to other performances, such as pop-up noise, power supply noise, sound power, crosstalk… on components of other subsystems.

CONCLUSION

This article explains and demonstrates a proven methodology targeting the virtual verification of subsystem performances before prototyping in order to anticipate and solve performance degradations.

Selective modeling of the subsystem is necessary in order to treat the issues globally. The designer plays an important role in:

• selectively identifying the blocks of the subsystem,
• choosing the adequate models at the relevant abstraction levels in order to set-up multi-level simulations at the required accuracy,
• checking that the models are representative of the reality.

In the end, the result is well worth the need: simulations are now tractable and can be trusted!