Frontier

Must We Always Have Models?

Our industry has come to a point where engineers are expecting simulation models for everything we do.  Without a simulation model, we appear to be lost in even making some basic engineering judgement. 

Take for example, SSO (Simultanuous Switching Output) noise. This is not a new concept. We had dealt with this type of noise a while ago with 20-pin to 24-pin PDIP packages. In these PDIP packages, assigning the Vcc and GND pins to the corner pins gave us the largest lead inductance in the package that in turn caused significant SSO noise if we are not careful.

The basic concept of SSO noise is governed by the equation V=L*(di/dt).

• V is the SSO noise voltage generated by the simultanuousely switching outputs
• L is the combined inductance of the bond wire, lead frame and PCB connectivity components of the Vcc or GND path
• di/dt is the instantanuous switch current of each of the switching pins

No doubt, the industry has moved from simple PDIP packages to more complex packaging technologies with many combinations of I/O pins and drive settings that can switch simultanuously.  Don't get me wrong, I am your typical engineer who would love to have a simulation model, if an accurate one is available, without having to take out a second mortgage on my house to get it.

So, are we to stop designing systems with SSO conditions because we don't have access to a SSO simulator? There are a few practical things you can do to minimize the affect of the SSO noise.  This is based on understanding the principle and paying attention to pin assignments when you design your FPGA.   

1) Understanding that instantanuous switching current di/dt is one of the two contributing factors, paying attention not to use excessive drive current (ie. using the appropriate programmable drive at 4mA, 8mA, 12mA, 16mA and 20mA) and the appropriate slew rate setting can minimize the contribution.

2) You can also distribute your simultanuously switching outputs across multiple GND pins on a given package will effectively reduce the SSO noise as well.  This, again, is effectively reducing the di/dt. 

3) The other component is the L, the Vcc and GND inductance. You don't have much control of the device packaging component of the L.  You have to trust that the FPGA chip and package designer has taken care of providing you the most optimum L for a given package.  However, the PCB component of the L should be minimized through the proper Vcc and GND layout techniques. 

To give you a practical sense about how much SSO noise contribution you get in practice, our typical lab measurements of 16 contiguous outputs switching at 16mA, fast slew rate to a lumped 5pF load per pin can generate SSO noise in the order of 650mV for a >200 ball fpBGA package.  This is assuming you have also taken care of proper Vcc and GND PCB layout. 

Rest assured that we are working towards creating better simulation models, including SSO. It would be useful to have a model when we have to reliably design a DDR2 memory interface running at 400Mbps data rate with 64 I/O pins switching.  But when you are implementing a 16- or 32-bit data bus interface to a microcontroller that is running at 33MHz, careful pin assignment and drive setting will go a long way to avoid SSO noise, without simulation.

Who needs models?

Who Needs Models...

Models have always been important for electronic system design at all levels, whether at the component level (IC design), the board level or the system level. In this case, I am not referring to the attractive fashion models such as Kate Moss but, rather, the less evocative models that are important to verify the proper functionality of electronic circuits and systems.

My experience as an IC designer started with the need for only one fundamental model. I needed a SPICE model for each of my transistors in order to use a circuit simulator to verify the speed, power and functional characteristics of my design. I did not need a functional simulator (such as Verilog) because my first circuits were simple enough to "brain-sim" without the need for a computer-based logic simulator. I could do my entire job with a single circuit simulator.

Today, as a result of high levels of integration, we are truly integrating systems-on-a-chip. An IC designer must now perform sophisticated system-level modeling and simulation in order to verify the complex functionality of multi-million gate FPGAs. At the same time, the modeling and simulation requirements of FPGA customers have also grown substantially... and this is what I really want to talk about -- what are your needs as a end-user of FPGAs?

What models do you need...

Let's talk about the models and simulations that are now needed to support the application of FPGAs in today's electronic systems. In the final analysis, I want to know what you, the customer, believe to be the most important models that we can provide as a component supplier.

I will seed the conversation with a list of models that come to mind as important to our customers... please feel free to supplement this list with models that are missing or point out the models that are of particular importance to you.

TIMING MODELS

The timing model is used to determine performance-related characteristics such as FMAX and setup/hold timing violations. This model must comprehend pattern-dependent performance characteristics that comprehend the final P&R of the pattern with the FPGA. The model can be a very simple model or can extend to include the full PVT (process, voltage, temperature) variations of the FPGA.

FUNCTIONAL MODELS

Functional models (typically gate-level or behavioral) are important to allow board/system level functional simulations.

POWER MODELS

Lately, with deep sub-micron CMOS technology, the power levels of large FPGAs are very temperature dependent and power levels can increase dramatically at high temperature. Additionally, power is a strong function of application conditions such as supply voltage, pattern, clock frequency and output loading. Large FPGAs can easily exceed 5-10W power dissipation as a function of the foregoing variables. How important are Power Models to you? How do you verify that the Power Models accurately reflect the FPGA?

FAULT MODELS

Fault simulation is becoming more important as the functional integration levels grow. How does a system designer estimate the fault coverage for their test vectors? How does a system designer develop test patterns to fully test their board/system? Where does the FPGA fit into the overall Fault Simulation plan?

IBIS MODELS

The IBIS standard was developed by Intel many years ago in order to allow board-level signal integrity simulations to be performed without the need for a sophisticated SPICE simulation environment. Today, IBIS models are a common customer requirement. How important are IBIS models to you? How do you verify the accuracy of the IBIS models that vendors provide?

SPICE MODELS

In some cases, particularly Gbps I/Os, IBIS models are inadequate for board-level simulation needs. In these cases, the FPGA vendor will (begrudgingly) supply a more sophisticated I/O model in the form of an encrypted SPICE model. How important is this level of support for your designs?

BSDL FILES (IEEE-1149.1 & IEEE-1532)

This is another area of increasing need. Most modern systems include one or more 1149.1-compliant Boundary Scan chains. Many ATPG tools and ATE utilize the BSDL files to support the generation and application of board-level test patterns. Additionally, In-System Programmable parts (such as FPGAs) now use the IEEE-1532 extension to BSDL to support the generation and application of programming vectors to the programmable components on the board.

SOFT ERROR UPSET (SEU) MODELS

OK, now we arrive at a really esoteric model... Soft Error Upset (SEU) models. Today's large FPGAs have configuration bitstreams in excess of 50M bits -- now that's a lot of SRAM bits. The system-level MTBF due to SEU for FPGAs is becoming an important issue for certain customers and applications.

OTHER MODELS...

Now it is your turn to supplement and/or comment on the foregoing list of model requirements. Please share your perspective on the relative importance of the various models that you need. Please also share your views regarding which of the needs are being adequately addressed and which are being 'under-serviced' by your FPGA vendors. Feel free to rate and rank the various FPGA vendors in each of these areas. Your feedback will help shape Lattice priorities for model development and support in the future -- you can make a difference, so please share your views.

David Lee Rutledge, VP Product Development