Home » Newsletters » June 2010 » 2010-06-09-eete-analog-newsletterb

Print - Send - -

Analog EDA

Making the most of the system level in analog design

There is a disconnect in analog IC design. A separation between system level and implementation level design activities has crept up on us. The analog world seems to have evolved into two realms: equations and spreadsheets on one side; netlists, polygons and Spice on the other. It is like a split between the right brain and the left, leaving us struggling to combine technology with art.

From the circuit simulator point of view, the system level has been the poor relation – just think of all the highly optimised variants of SPICE that are out there. In particular, since system analysis is done at a high level of abstraction and runtimes are relatively short, runtime efficiency for analog system simulators is often neglected. Opportunities for deeper and more comprehensive analyses are missed.

Dealing with the separation of specification from implementation and the lack of optimization in analog system tools – results in significant benefits to the whole analog design flow, from specification through implementation to silicon test. As we show in this article, a small investment at the system level can result in huge overall benefits to analog/mixed‐signal/radio frequency (RF) projects.

What’s in the system?

For the purposes of this paper we consider analog IC systems to range from the size and complexity of analog intellectual property (IP) blocks – such as phase lock loops  (PLLs)  and analog to digital or digitial to analog converters (ADCs or DACs) to that of an RF receiver chain with associated filtering, translation to the baseband and conversion to a digital signal.  We are interested in modeling the functionality of such circuits and, most important, the wide range of non‐ideal behaviors that afflict them.

Our objective in modeling an analog circuit at the system level is to answer three important questions:

1. Am I building the right circuit?
We need to understand the system, to share that understanding with our collaborators, and hence to develop a detailed specification of how it must be implemented. In doing this, we provide the essential link between the initial requirements and the final implementation.

2. Am I building what I specified?
We need to capture the specification in such a way that it can guide the implementation and keep it on course. This capability should include the rapid debugging of unexpected behaviors – i.e. any inconsistencies between the specification and the implementation.

3. Am I on the best path?
We need to find the optimum implementation solution through an extensive exploration of the possible design space, including high quality, easy to understand feedback to the designer.

What does system level modeling, specification and architecture development consist of? A common scenario is to receive a specification for a system to be implemented as an IC block (an IP). Through the development of a model that corresponds to this specification we refine the latter and produce a system level architecture, with detailed specifications for sub‐blocks of the top level system. The output of the system level modeling activity is therefore a detailed architecture for the top level with a set of specifications for the sub-blocks.
 


If the system level modeling is accurate, the specifications fed to the implementation step of the flow are achievable and final results are achieved faster. If, on the other hand, one or more sub‐block specifications turns out to be infeasible, then difficult adjustments may have to be made. Either we go back to the system level and rework the top level architecture, finding new tradeoffs between the parameters of the sub‐blocks, else the problems are solved at the implementation/transistor level of abstraction. The latter approach requires transistor‐level simulations – a notoriously slow and painful way to explore architectural alternatives.

From this overview you may appreciate that system level analysis is a critical task in the analog design flow. Even though it may take less time than later steps, and although it takes place early in the project when time pressures are less severe than in when close to tapeout, the seeds sown by system modeling, specification refinement and architecture development have far‐reaching consequences.

Consequently, the key requirements for analog system level modeling are that it be:

• Comprehensive, to allow a full exploration of the solution space
• Accurate, to ensure that sub‐block specifications are feasible
• Implementation‐linked, to avoid errors in the interpretation of the developed architecture and sub‐block specifications

Current approaches

In an informal survey involving 34 European companies, working on a wide variety of analog/mixed‐signal/RF systems, we discovered a wide variety of approaches to analog system level modeling, many of them involving multiple tools. 56 percent of the respondants use general purpose numerical calculators to support system level calculations, and some use such an engine as the basis of internally developed tools. Others (about half of the 56 percent) use commercially available interface to facilitate the capture of circuit behavior in their particular numerical calculator.

21 percent of respondants use spreadsheets as modelling tools. Typically, the behavior of each sub‐block of the system is modeled in a separate sheet and input/output cells are used to communicate signal values between sheets.

Less than a quarter of our contacts use purpose‐built system level design tools. In fact, 24 percent are in this category – exactly the same figure as for “home grown” solutions, based on C, C++ or grafted on numerical calculators, as mentioned.

Of course, these companies are able to produce first rate products using the systems that they have put in place. This is not to say that things cannot be improved, however. The engineers involved in this survey typically reported the following drawbacks in their existing flows:

1. A disconnect between the high‐level modeling and the implementation work
2. Problems with the accuracy of noise modeling at a high level, especially for complex modulation schemes
3. Simulation speed issues, particularly for time domain simulations of RF circuits and for statistical simulations requiring large numbers of data points

Implementation link

In both our opening discussion and the feedback from European companies, the importance of the link between the system level specification and the subsequent implementation is very apparent. In spite of this the majority of analog system level flows in use today have rather weak links between specification and implementation. Engineers survive, of course, but the situation is far from ideal. In particular, the lack of system level tools that plug into existing analog design environments is a major inconvenience for engineers focused on the implementation phase of the flow (as opposed to the system architects). Since the tools available in such environments are typically optimized for transistor‐level analysis (even though most of them also handle system level cells, such as gain blocks, ideal switches etc), they are very slow when working at the scale of the full system.

From the “top down” perspective, if the path from specification to implementation crosses a variety of tools, and each has its own database format, then the chances of consistency problems are high. If this problem were only encountered once per project, then the overall impact would not be serious. However, if there are iterations between the system and implementation levels, then the chances of some significant negative impact on the project are much higher.

To avoid these issues, a flow needs to support two simple concepts:

• Once‐only information capture
• Top‐down, pin‐accurate handoff of information from the system to the implementation level

To clarify, the first point means the avoidance of duplicate data entry in different data formats. We believe that the most natural way to achieve this is by capturing the system level behavior in the form of a schematic. This contrasts sharply with approaches based on describing this behavior in the form of equations and scripts, where the link between such descriptions and the implementation depends strongly on the correct and consistent interpretation of the equations and scripts by everyone concerned.



For the second point, we note that the system level view, while pin‐accurate, does not necessarily have to detail the complete pinout of sub‐blocks in the architecture. Pins that will exist in the final implementation may be omitted in the system level description if they do not have an influence on the function of a sub‐block, for example. This is a methodology choice. The minimum requirement is that the pin definitions made at the system level propagate in an unambiguous manner into the implementation.

Runtimes

As mentioned, simulators that were optimised for detailed transistor‐level simulations are also capable of running with less detailed models (eg. in VerilogA) and hence, to some extent, they can be used for system level modeling. When one compares the runtimes of the transistor‐level and system‐level views of the same circuit on such a simulator, the speed up at the system level is considerable. Hence it may at first seem that this approach to system level simulations is adequate.

However, the (SPICE or SPICE‐like) simulation engines used for transistor‐level work are usually based on iterative formulas such as Newton‐Raphson, and this is far from optimal for a system level simulator. Faster, more economical approaches are more appropriate.  Further, these approaches open up a range of analysis and optimisation possibilities that cannot easily be imagined when one is shackled to SPICE. Just as we did not miss having the internet or mobile telephones before they appeared on the scene, it is sometimes difficult for someone who is used to working with SPICE to appreciate what is possible once the constraints imposed by the SPICE simulation engine are removed.

The most problematic types of systems (with respect to simulation time) are the ones where time constants are widely spread. For example, oversampled data converters have sampling frequencies that are much higher than that of the signal of interest. Similarly, in radiofrequency transceivers, carrier frequencies are much higher than those of the data, and the number of simulator samples needed to compute, for example, a Signal Noise Ratio or Bit Error Rate is therefore is much higher than one would expect from a consideration of the symbols being processed. And, of course, simulation time also becomes critical when a large number of simulations is desired. This has become more important with recent, highly spread semiconductor processes, since the statistical analysis of circuit behavior now has to take into account many more process corners than in the past.

In the cases just described, simulation algorithms based on time‐domain deterministic descriptions (such as general‐purpose Ordinary Differential Equation solvers, with or without timestep adaptive control) are grossly inefficient. They require a number of simulation sampling points and a number of iterations per point that is far too high considering the fundamental problem that is to be solved.

For architectures without feedback significant speed improvements can be obtained by vector processing of samples. However, many interesting systems do not fall into this – eg. PLLs and gain‐control architectures – and in these cases a sample‐by‐sample computation is mandatory.

Harmonic balance uses a frequency formulation as a starting point and, as a result, it is relatively immune to scattered time constants. Nonlinearities can be computed in the time-domain and referred back to the frequency domain using Fourier transforms. This method, in its simplest form, is accurate for weakly non‐linear systems, with periodic signals described by a small number of tones. It cannot, however, be used for digitally modulated signals. The latter can be simulated with extensions of harmonic balance, such as circuit envelope or envelope transient analysis. To achieve their ends, however they add a transient term to the core algorithm, thereby inheriting the drawbacks of transient simulation.

Hence we see that there are already a number of algorithmic approaches to speed computation at the analog system level, even though they do not apply in all cases. Not all avenues of improvement have been investigated, however. Among promising new approaches are those which make a smart choice of what actually needs to be computed.

This is done on the basis of:

• The specific information and accuracy that the user requires. For example, if he wishes to see a spectral density, then the computation of many time samples can be avoided. Adapting the computation method to the requested output leads to many such runtime savings.
• Knowledge of the system characteristics. For example, if a tool “knows” that a system is sampled‐ or continuous‐time, linear or non‐linear, which events are expected, etc. then it can dynamically select the most suitable algorithm for the job in hand. By doing so the tool is mimicking the human thought process, using a general classifications to guide it to an adequate (fit for purpose) solution in a reasonable time.

These are just some ideas on the opportunities to improve simulation runtimes at the analog system level. While the field is not unexplored, it is not completely charted either, and many interesting possibilities remain.


Diagnosis and exploration

To link with the previous section, one of the major benefits of any improvement in simulation runtimes is that it allows a more extensive exploration of the design space in the time available. In addition, extreme speedups (three orders of magnitude compared to SPICE, say) make it possible to architect simulation tools in a completely different way.
The most common use model for a simulator is to first setup the input netlist and configuration data, then run one simulation or perhaps a batch of simulations using a command. An alternative paradigm, closer to the type of experimentation that can be done with a prototype board and an oscilloscope for example, is:

1. Initialize the simulation tool
   a. Read in the circuit
   b. Display the key parameters describing the circuit
   c. Obtain the response curves for the default parameter settings
2. Modify a parameter (through a GUI)
   a. Immediately see the effect on the response curves
   b. Loop on this step, modifying parameters and seeing the effect

This alternative approach (which supplements, rather than replaces, the traditional one) allows new insights into circuit behavior and easier understanding of how specific components and non‐ideal phenomena affect the response. It also makes it easier for one engineer to explain to another how the design works.

Improved runtimes – as mentioned, we are considering improvements of several orders of magnitude compared to SPICE – also unlock new possibilities for statistical analysis. Design centering (at the system level) and reliability analysis become far less time consuming. Of course, the condition for this to be useful is that the system level models are sufficiently accurate, especially with respect to non‐deal effects.

In addition to the new possibilities for design exploration made possible through runtime improvements, there are important algorithmic improvements that can be introduced in system‐level simulation. A further limitation of most of today’s simulation methods (especially when we consider the large “market share” taken by general purpose tools and ad‐hoc methods) is their lack of insight in the relationship between the signal components of a system and the waveforms that it produces. Even where a breakdown of an output signal into its component contributions is possible, the calculation is often a blind mix of contributions (wanted signal, sometimes noise, non‐linearity products altogether) combined in a way that does not reflect the reality of the circuit (ie. sampling and mixing details).

To sum up this section, the dream of any circuit designer would be not only to get waveforms as quickly as in the lab, but also to be able to track which causes produce which effects by:

1. Getting the instantaneous, visual feedback of a parameter change
2. Identifying which are the contributors to the waveforms currently observed.

Wish list

Let us crystallise the above discussion into a “wish list”. As analog system designers we are looking for:

• A solution integrated with the designer’s environment
    o Single database, interface and use model
    o Focus the mind on the problem, not on the tools

• Fast interactivity
    o Quick looping to rapidly understand results
    o The tool must go faster than the mind

• Maintain cause and effect relationship
    o Ability to backtrack from a phenomena to its source
    o Simple and rapid sensitivity analysis

• No concessions
    o High Precision
    o Interface based on Established Concepts
    o Underlying tool mechanisms must be hidden

The benefit of the above improvements in tools and methods would vary according to the designer and the design activity.

For designers concerned mainly with implementation activities at the transistor level, but who still need a good understanding of the system level architecture, the availability of a true system level tool fully integrated into the design environment would be immense.  While they are unlikely to reuse a system model handed down in the form of a spreadsheet, for example, they could certainly reuse a schematic‐based system level architecture.  Further, they would be very comfortable producing such a schematic from a written specification, for example.

The active use of a system level tool during the implementation phase of a project naturally keeps the system level model alive, as updates in circuit parameters can be made as the sub-block implementation gradually matures. As a result the system level model can plan an important role right through to silicon test, allowing engineers to quickly investigate system-level scenarios as they try to understand the measured behavior of the silicon.

For system architects – that is, engineers whose deliverable output is in the form of a specification – fulfillment of our wish list would give them not only the ability to explore the design space more thoroughly, it could greatly facilitate specification handoff and the interaction with the design implementation team or company.


Fig 3: The ultimate goal is to leverage the system model right through to silicon test

Conclusion

We are convinced that a small investment at the system level of an analog design can result in huge overall benefits to a project. Further, an integrated, pin‐accurate, top‐down approach to analog system design has clear benefits and cannot be implemented using the tools most commonly employed at the system level today.

Finally, we note that the runtimes of analog system‐level tools could and should be better optimised. Such optimisation allows a much higher level of interactivity with the design, increasing the coverage of the design exploration space as well as allowing better communication between collaborating engineers.

Anyone working on analog systems, from the complexity of a PLL upwards, should seriously look at what can be gained by improving their system level tools and flow.


Andrew Betts (andrew.betts@asygn.com) is Consultant Director of Sales and Field Operations at Asygn SAS, based near Grenoble, France (www.asygn.com). Betts has a PhD in Analog IC Design over 20 years experience of the microelectronics field.

Nicolas Delorme is Chief Technical Officer of Asygn SAS. Delorme has a PhD in Analog IC Design and is a specialist in the field of sensor and actuator microsystems. A founder of Asygn, Delorme has been responsible for the implementation of the company’s analog simulator products.

Mixed-signal

 

Austriamicrosystems

 

Fairchild Semiconductor

 

Battery

 

FPGA

 

NXP Semiconductors

 

SoC

 

MEMS

 

National Semiconductor

 

Cypress Semiconductor

 

Intersil

 

Linear Technology

 

Maxim Integrated Products

 

Sensor

 

STMicroelectronics

 

Analog

 

ADCs

 

Analog Devices

 

Lattice Semiconductor

 

Microcontroller

 

Audio

 

CMOS

 

ADC

 

DAC

 

Microcontrollers

 

Sensors

 

Texas Instruments

 

Power Management

 

Atmel

 

Power