Frontier

LUT by any other name...

When a problem or an issue gets too complex, I find it helpful to always get back to the basics. This is the case with estimating FPGA resource utilization or gate count.  It is natural for industry publications to discuss FPGA density in terms of gate count. After all, today's FPGAs are at gate densities that ASICs were at a few years ago. 

But what does gate count mean in the FPGA world? Gate counts do, sort of, give a rough estimate of complexity of function(s) that you are trying to implement into an FPGA. And depending on which marketing friend you talk to, the gate count has a large sliding scale.

Now, back to the basics.  FPGAs really only have certain basic functional blocks, as listed below in order of importance. You should be able to convert information given in an FPGA data sheet to these basic units:

1. The most basic logic block is a LUT and Register pair. The associated diagram on this posting shows a Slice that is 2 LUTs/2 Registers unit.
2. An I/O cell or pin.
3. Embedded Block RAM.
4. A DSP or Multiplier block.

The rest of the special functional blocks don't make it to my main list since they only consume a small portion of the device and/or only a limited number of designers will use them:

1. PLL/DLL
2. SERDES
3. Microprocessor
4. Analog

With the basic functional blocks, I can get to a fairly accurate FPGA device utilization, within 5% to 10% of the actual implementation.  The units of measure for each of the basic blocks are: LUT/Register count, I/O cell or pin count, Block RAM in raw bits (or number of blocks if you know the memory block size), and Multiplier Blocks (also pay attention to the multiplier width 9x9, 18x18, etc.).

Getting back to my thoughts on the title...

"LUT by any other name... is not an accurate measure of FPGA utilization"

FPGAs have used the 4 input look-up table (LUT4) structure as their basic logic block from the beginning. When I hear the utilization measure of a function taking 20K LUTs, it is clear in my mind what density FPGA device I am supposed to choose.

When I hear terms like 1.5 million gates, 16K logic cells, or 18K logic elements, those terms might as well be replaced by "widgets". My mind does not easily translate "widgets" into device utilization. 

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.

Open Source II

It is late Wednesday afternoon here in Silicon Valley and I should really be developing a new set of materials detailing our current and future products.  However, we had a great set of comments on my previous Open Source post and I thought it appropriate to take a few minutes to respond.

AS Assembler Support A couple of folks noted that the LatticeMico8 is supported by Alfred Arnold's AS Assembler.  I took some time yesterday to look around the AS Assembler site and learned a couple of things:

• Arnold has a great collection of computers.  You can check out the photos on Alfred's personal page.
• The AS Assembler looks like a decent tool and supports the LatticeMico8.

Based on this "extensive" research we went ahead and provided a link to the AS assembler on the LatticeMico8 page.  (That loud noise you can hear is the corporate machinery moving at faster than normal speed.)

Coding Style Some good feedback on coding style and the need for more commenting.  I have already shared this with the key developers.  Over time, we may be able to make some improvements here.  However, pragmatically I expect that the coding will continue to be somewhat Lattice oriented :-)

Development Teams Mood Regarding Open Source There were also some comments on our motivations/thoughts/feelings regarding open source.  As the Lattice team discussed releasing LatticeMico8 as open source, we clearly had in our minds that Lattice is somewhat smaller than our FPGA competitors and that open source would provide us with an opportunity to do something different.  In a way, this development (and hopefully others that follow) is making the FPGA space more "democratic"  with more choices.  This matches what we are doing with the silicon.  All this got me and many of my Lattice colleagues excited.

Lastly if anyone has any LatticeMico8 applications that they would like to share, then let me know.

Formal Verification Usage with FPGAs

In a recent survey of FPGA designers on EDA tools done by EE Times, I noticed a considerable drop (almost 50%) in the use of Formal Verification (FV) between 2005 and 2006.  At the same time, they predict their usage will increase in the future.  I attribute some of this drop to the design methodology change required to get the potential benefit from FV.

A good presentation from Harry Foster, ex-Jasper, current Mentor, describes why methodology is important.  Use in the FPGA design flow will continue to creep up as previous ASIC designers move to FPGA design (and bring their FV experience with them), and design complexity continues to expand while schedules don’t.

As design complexity increases, the percentage of total design time spent on verification increases.  Common estimates are that design verification exceeds 50% of the design time. 

Traditional ASIC verification has relied heavily on simulation where test stimuli are fed to the design, and the output is checked for correct results.  Simulation has become much more common in the FPGA verification flow as well, although because of the re-programmable fabric, the FPGA designer has more chip-level options – for example using an internal FPGA logic analyzer such as Xilinx’s ChipScope™ or Lattice’s ispTRACY™ products.

All verification techniques have their pros and cons.  As more time is spent in simulation, the coverage improves at a slower rate.  Moreover, the best that simulation can tell a designer is that, “no bugs have been found yet”, rather than the much more useful, “this design is correct”.

Formal verification is a technique that takes a very different approach to verifying a design.  It also has its pros and cons, but the consensus is that that Simulation and Formal Verification are very complementary.  Together, they have the potential of giving the highest verification coverage in the fastest time (lowest cost).

Formal verification relies on “rules” that have been defined by the user that characterize how the design should behave – the so-called design intent.  For example, in a bus protocol, if bus signal A should never be high two cycles after bus signal B goes low, this can be captured as a rule.  These rules can be checked in two fundamental ways:

• Dynamic or Simulation Based: while the design is running in simulation, the rules are checked for any violations.
• Static: through formal analysis of the netlist, counter-examples are created which show how a rule can be violated.  If this counter-example was run through a simulator, the violation could be observed.

Both dynamic and static FV approaches are used in Assertion Based Verification (ABV).  Like a simulation testbench, the FV rules have to be created by the design or verification engineer.  Two rule languages have emerged:

• SystemVerilog Assertions (SVA) are part of the SystemVerilog language, and can be a powerful method for designers to capture and formally document their design intent during design entry.
• PSL is more HDL language neutral, and has additional support for more advanced formal verification techniques.

A paper comparing the two languages can be found at: http://www.pslsugar.org/papers/pslandsva.pdf

Formal verification is not new, and its general adoption has been slow.  Certain designs that have high concurrency and lower sequential depth (e.g. processors), are ideal for formal verification and the technique is commonly used.  A few rules can accomplish much more than many simulation test vectors.

However, the fact that simulation and formal verification are complementary requires the user to know how they are going to apply the two techniques.  This requires much more upfront planning, expertise in rule generation, and basically adopting a new design methodology.  That kind of thing doesn’t happen overnight.

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

Open Source

One Sunday morning during July 2005, I sat at my kitchen table drafting the Lattice Open IP Cores license agreement while my young daughter attempted to sit on my head.  Was it worth the effort?  As to being a human jungle gym, definitely.  With regards to Open Source IP for FPGAs, the jury is still out....   Shortly after crafting the license agreement, we released the LatticeMico8 microcontroller as open source.  I have heard of many examples of customers using this LatticeMico8, which is great.  However, I have not heard much feedback on the Open Source nature of this IP.  I would be interested in reading comments from users on this topic.  Does it make sense to have Open Source IPs for FPGAs?  Should Lattice be doing more of this? 

Slow Inputs Acceptable For FPGA?

This is a common question I get when you have system requirements to drive relatively slow input signals into fast FPGA inputs.  "How can I prevent the inputs from causing output oscillation?"

The theory behind this FPGA input or any fast CMOS device input behavior is simple.  As the input rise time gets slower, the signal stays in the input transition point a longer period of time.  This combined with any signal noise associated with the transition causes the input translator to detect false transitions which in turn get translated to the output.  The end result usually is output oscillation.

You can effectively use an input series resistor with the FPGA's internal input bus-hold latches to improve the slow input ramp time tolerance.  It's been demonstrated in our lab that the input ramp time improves from hundreds of nanoseconds to microseconds. More details can be found in the technote posted on Lattice web site.