Frontier

WISHBONE Connectivity: Power without the Overhead

One of the most common questions that programmable logic designers face today is how to connect unique, disparate modules in their system.  That is to say, “Block A needs to talk to block B and vice versa. What bus should I choose?”  There are a plethora of choices that the designer can choose from, but what most designers really need is a proven, simple-to-connect bus interface without the overhead of many proprietary bus interfaces.  Enter WISHBONE.

In case you’ve not heard of WISHBONE, it’s a popular, open source hardware interface that is promoted by the OpenCores project (http://www.opencores.org).  Being open source offers several advantages for programmable logic designs:

Open source designs:  The OpenCores project is the web’s main proponent of the WISHBONE architecture.  In addition to its role as WISHBONE advocacy, the OpenCores website offers many grass-roots built RTL modules that are available for users in both Verilog and VHDL, many of which are of course, WISHBONE ready.  This means that a designer can attach their own WISHBONE design to one or several of these OpenCores designs, saving development time on both core functionality and bus connectivity.

Flexibility: Perhaps the most subtle advantage of WISHBONE is its flexibility.  Unlike most bus system, WISHBONE can be implemented as any one major bus types including hierarchical, point-to-point, or many-to-many.  In addition, a WISHBONE bus can be multi-master or single master and can be 8, 16, 32, or 64 bits wide.  The net effect of this flexibility is that WISHBONE is appropriate for programmable logic designs of almost any complexity.

Proven:  The WISHBONE interface is a well-defined standard, has been around for more than six years and has been implemented in hundreds, if not thousands of systems.  If you want a flexible, but low-risk bus architecture, WISHBONE fits the bill.

The Price: As stated on the Opencores website: “The WISHBONE standard is not copyrighted, and is in the public domain. It may be freely copied and distributed by any means. Furthermore, it may be used for the design and production of integrated circuit components without royalties or other financial obligations.”

Lattice and WISHBONE:

Lattice believes in the WISHBONE credo and has several resources for Lattice users:

LatticeMico32:  This is Lattice’s own 32-bit “soft” microprocessor.  It has a native WISHBONE interface and is free with an open IP core licensing agreement.  The power of the LatticeMico32 lies not only in the flexibility of the core itself (it’s synthesizable), but also that it can be connected to any WISHBONE peripherals including open source cores or your own, custom logic.

Reference Designs: Lattice offers several freely downloadable WISHBONE reference designs as a starting point for user designs.  These reference designs come complete with documentation, RTL, and testbenches.  WISHBONE modules include an I2C bus master, a SPI controller, and a LatticeMico8 WISHBONE adapter.  Again, since they are WISHBONE, these reference designs can be combined with OpenCores designs or a LatticeMico32.

System Examples:  Our successful MachXO Mini Evaluation Board comes with a native demo (“Mini SoC Demo”) that illustrates the WISHBONE bus in a working system. This demo includes our 8 bit LatticeMico8 soft processor, a UART, an I2C master, and a SPI memory controller, all connected on a WISHBONE bus.  A Lattice user can examine the WISHBONE bus connectivity by downloading the RTL and documentation for this demo at our MachXO Mini Development Kit website. At this website, find the “Demo Applications” button under “MachXO Mini Development Kit Resources” at the bottom of the page.  You can also view a video of the demo or experiment with it yourself by purchasing the board from the MachXO Mini Development Kit website.

Automotive Versions of Flash-based, Non-volatile FPGA Family

Lattice recently introduced AEC-Q100 qualified versions of its LatticeXP2 Instant-On FPGA family.  These are devices built using a process that includes SRAM Programmable Logic + FLASH Storage on a single-die.  Lattice has raised the capabilities of automotive FPGAs by offering new system-on-chip (SoC) features such as full-feature DSP blocks, pre-engineered source I/O blocks and its exclusive FlexiFLASH™ architecture.

The FlexiFLASH architecture integrates the configuration Flash on the same silicon die as the SRAM FPGA logic.  The non-volatile FlexiFLASH architecture enables Instant-On startup speed, FlashBAK capabilities as well as the additional benefits of fault tolerance and redundancy.  FlashBAK enables the contents of the Embedded Block RAM to be written back to the FLASH memory so that during subsequent device initializations, the EBR memory is loaded with the new values.

Automotive system designs are using a growing number of FPGA devices to add additional capabilities and flexibility.  The LA-XP2 provides designers the broadest offering for performance and features of any AEC-Q100 qualified FPGA.  The instant-on capability allows the LA-XP2 FPGA to be used for applications that cannot wait for a typical FPGAs to startup such as Engine Control Units, FlexRay and CAN interfaces, processor bus decoders, Power-on-Reset and low power designs using duty cycling.

Instant-On, Redundancy and FlashBAK, these are a few of the advanced features offered in the LA-XP2 that are enabling advanced automotive systems.

Power Awareness for Your FPGA Designs

When I am designing with FPGAs, I like being aware of their power consumption.

When FPGA power consumption is within your system power budget...

• Your system operates correctly
• You are not surprised during system power up
• Your system still functions well when you push the system speed and temperature

However, when FPGA power is over your system power budget...

• Your system can have functional problems under certain operating environments (note that advanced technology- 90nm or newer- FPGAs would have the highest power consumption at high temperature.)
• Peak power consumption could occur during power-up configuration from the external "boot" device (Flash or PROM).
  

To avoid potentially disastrous system issues, you need to be able to predict or be aware of your FPGA power consumption.  Lattice provides a FPGA power calculator either as part of the ispLEVER development software or a power calculator as a standalone software for the FPGA designer to estimate device power consumption.

Lattice's power calculator has two main options to calculate your FPGA power consumption:

1. Estimation mode: In an early stage of your FPGA design, you can simply enter the estimated number of functional blocks (PFU, EBR, I/O, etc.), operating frequency and device operating temperature (junction temperature).  Based on this information, the power calculator will provide an estimated FPGA device power consumption.  If your estimated numbers are close, you should be within approximately 20% of your final power requirements. 
2. Calculation mode: Once you have completed your FPGA design, your exact FPGA design netlist is loaded to the power calculator.  With this exact functional block utilization data along with the frequency and temperature of device operation, you should be able to predict FPGA power consumption within 10%.

Gone are the days when you can simply read the power numbers from the data sheet and use those numbers to budget for system power supply.  However, today's FPGA software tools can reasonably estimate power numbers that will work in your system environment. 

Microcontroller Obsolescence Solution

There are very few customers that enjoy receiving the statement: “Dear customer, the microcontroller in which you invested years of development time and money and planned to have in production for another 10 years is going End-Of-Life!” There have been several popular microcontrollers and microprocessors that have gone EOL over the last few years as semiconductor suppliers consolidate and prune their product portfolios.

Customers have the choice of performing a last-time purchase or re-designing the product. Last time purchases are problematic in the areas of up-front cash outlays and forecast quantities. As far as redesign, a simple board layout change to support a different part is easy, but software compatibility is the major hurdle when moving to a different microcontroller family. Most companies have a large investment in their target software; changing to a new architecture typically requires a complex and costly software port as well as verification.

Lattice to the Rescue
Lattice recently helped a customer in just this situation. The customer had a microcontroller in continuous production for more than 15 years. Not wanting to tie up capital in a last-time buy, the customer looked for other alternatives.

The customer required the replacement to be exactly the same fit and function as the original microcontroller. In addition, external and internal timing, processor functionality and even the same binary program had to run with no modifications. This compatibility included embedded software timing loops in the legacy processor code.

The final hardware solution is a small mezzanine board that contains an instant-on LatticeXP2 FPGA, an ADC device and clock generator. A PLCC connection allows direct interfacing with the manufacturer’s PCB and provides a pin-for-pin replacement for the original microcontroller. As the LatticeXP2 contains on-chip FLASH memory to configure the logic on startup, there is no need for an external boot memory which reduced the board device count and allowed for a smaller final solution.

The software solution used a third-party Intellectual Property (IP) core from Digital Core Design. DCD is a Lattice IP partner that offers a number of microcontroller and peripheral IP solutions. DCD modified an existing microcontroller core to match the exact execution and peripheral set found on the obsolete device.

The pin compatible solution allowed the customer design team to focus their efforts on validating the IP core instead of performing a full hardware and software design and validation. The solution enabled by Lattice and DCD ultimately saved the customer time and money by not having to perform a total system re-design.

Conclusion
Microcontroller and Microprocessor obsolescence will continue, but fortunately there are easy solutions to the problem using FPGAs coupled with microcontroller IP. The Instant-On LatticeXP2 FPGA provides a secure and small footprint solution that also meet customer’s very long life requirements. Microcontroller IP from partners like DCD allows a very quick and cost effective solution to replace existing microcontrollers while retaining exact software compatible with the original design.

Traits of the True Non-Volatile FPGA

Lattice has recently announced the industry's first true 90nm non-volatile FPGA, the LatticeXP2 family. The product announcement along with recent industry activities in non-volatile FPGAs has prompted me to clearly define the basic traits for a real non-volatile FPGA.

The key capabilities that FPGA designers should look for in a non-volatile FPGA device are:

1. "Instant-on" logic.
2. High security with enhanced security capabilities.
3. Small footprint and density migration options.

When you look at these capabilities, they may seem trivial. However, achieving these capabilities in a 90nm non-volatile technology is far from trivial.  Let's take these capabilities one at a time.

Instant-on logic: means the FPGA logic is active within 2ms of the last power supply reaching its minimum voltage.  If you compare this to a traditional SRAM-based FPGA or the recently announced hybrid or die-stack approach "non-volatile" FPGA, configuration times are typically an order of magnitude higher at >100ms.  This significant difference in configuration time allows FPGA designers to use the LatticeXP2 for power up reset and control logic. 

Security: a single-chip flash-based technology naturally gives the FPGA user enhanced security simply by having the configuration data transfer on-chip rather than off-chip from another non-volatile device.  If you choose to transfer from an off-chip device, the LatticeXP2 FPGA lets you encrypt the data transfer.  In addition, the LatticeXP2 device also comes with enhanced security capabilities such as a Flash Protect Key that locks the Flash programming, and an OTP fuse option that altogether disables any unwanted re-configuration of the FPGA.

Small footprint and density migration: because it is a one-chip solution, the LatticeXP2 devices will be offered in variety of packages, including the small foot-print 132csBGA, flexible QFP packages like 144TQFP and 208PQFP and high pin count packages such as 256fpBGA, 484fpBGA and 672fpBGA packages. 

The LatticeXP2 is Lattice's third-generation non-volatile programmable device, with a feature set carried over from many years of field experience in programmability.  You will find many other elegant programmability features such as FlashBAK or user Flash capability, Serial Tag memory, TransFR or Transparent Field Reprogrammability and Dual-boot capabilities.

To find out more about these features, please join our series of webcasts on these exciting topics on LatticeXP2 over the next few weeks.

FPGAs: Replacing ASICs?

It wasn't too long ago that common engineering wisdom dictated that FPGAs were only good for system prototype and initial production, and that ASIC/ASSP replacements would have to be up and running before commencing full production.

That may still be true for some systems that are ultra-low-cost, ultra-high-performance or ultra-high-volume. However, FPGAs are increasingly becoming a vehicle of choice for many systems.

The LatticeECP2M Family of FPGAs significantly lowers the price point for devices that provide advanced system-level connectivity (DDR/DDR2 DRAM interface, PCI-Express and Gigabit Ethernet etc.) with reasonable general purpose I/Os, programmable logic and memory resources.

What are your thoughts and experiences in using FPGAs for production volumes, rather than ASICs/ASSPs? We would like your feedback:

1. Have you considered FPGAs as ASIC/ASSP replacements in volume production?
2. Do you have an example of an FPGA attribute that "forced" you to go the ASIC/ASSP route?

Our goal is to provide the best Programmable Logic Devices for system development. So, we look forward to hearing potential improvements that would enable us to better meet your needs - at a lower overall cost and faster time to market.

What are your FPGA prototyping needs?

With every new FPGA product introduction, Lattice typically provides several evaluation boards to make your life a bit easier to prototype and test out the capabilities of our FPGA products.  Our Applications Engineering group has a significant influence on evaluation boards-- some of them are defined and built by our Applications Engineers.  With this blog posting, I would like to do an informal survey of what you would like to see in future evaluation boards.

Here is bit of background on the typical types of evaluation boards we build:

1) To demonstrate specialized features of our FPGAs.  In the past we have provided capabilities such as PCI, PCI Express, DDR1/DDR2, SPI4.2 and others as part of our Advanced Evaluation Boards. 

2) To provide generic prototyping and evaluation capability with general prototyping area and very basic power supply and programming capability.  This is provided as our Standard Evaluation Board.

When I am working in the lab and want to take a quick look at something, there always seems to be a need to put an FPGA device in a socket with a very basic power supply and programming capability. For that I don't need a fancy connector to run multi-Gbps or fancy termination like DDR2. I just need basic functionality that can run at a reasonable speed (50MHz-100MHz). 

Hence, the reason for this blog post is to get your feedback. What are your FPGA prototyping needs?  For your answer please consider the following:

1) Does Lattice's current evaluation board offering satisfy your requirements?  If so, what features do you use? If not, what features would you like to see?

2) What is your price threshold for purchasing an FPGA evaluation board?

3) What is your operation speed requirement in MHz?

4) Would you like to see a very low cost FPGA prototype board? What capabilities do you need on this type of a board?

I look forward to your feedback on this.

Low-cost FPGA with SERDES

It's an exciting day at Lattice as we introduce the LatticeECP2M that:

1. enhances the amount of Embedded Block Ram (EBR) and
2. adds SERDES capability to the popular LatticeECP2 family.

The LatticeECP2M addresses the growing requirement for high-speed serial I/O interfaces in low-cost FPGAs.  Until now if you needed SERDES in an FPGA, your selection of FPGAs would be limited to high-end (i.e. relatively expensive) FPGAs.  In an continuing effort to bring premium features to affordable FPGAs, Lattice has added 4 to 16 SERDES channels (up to 3.125Gbps per channel) to the LatticeECP2M, a chip that already has a high EBR to LUT ratio, DSP blocks and DDR2 memory interface support.

As part of the product introduction, we will be conducting a series of webcasts over next several weeks, highlighting the new device's capabilities such as digital video interfaces, detailed device architecture and SERDES features.

Speedy FPGA

It was very clear to my 4 year old when I read to him about speedy boats and speedy cars how fast they go. But how fast do FPGAs go?

I should give him credit for giving me the inspiration to write this piece: to try and explain FPGA speed to everyone so we can all have a similar baseline understanding on how to estimate FPGA operating speed.

The following functional areas determine the overall operating speed of the FPGA:

1. I/O interface
2. Logic implementation
3. Clock tree and PLL
4. Other functional blocks

The I/O speed is generally measured by input setup/hold time and output clock-to-out time. This will give us the raw speed in terms of frequency (MHz) or data rate (Mbps) of the individual I/O interface.  If an application requires multiple I/O pins, the skew between the pins will affect the I/O operation speed as well.

Logic implementation speed is generally determined by the internal register-to-register operation speed. The register-to-register speed is determined by the logic block and routing delays between the registers. The FPGA static timing analysis tool will report the register to register speed in MHz or point to point delay.

Clock tree delay skew and PLL (sysCLOCK PLL) speed also are part of the determining factor for the logic speed.  Clock tree delay skew will directly impact the logic register-to-register speed.  Again, the FPGA static timing analysis tool will report this as part of the register-to-register speed of operation in MHz. PLLs will generally be able to support the fastest speed that the registers and logic can operate.

Other functional blocks like Embedded Block RAM (EBR) and Multiplier (sysDSP) will also have their associated operating frequencies.  These operating frequencies are all taken into account into the overall speed of operation for the FPGA. 

The question "how fast do FPGAs go?" can be answered in terms of frequency in MHz.  But this simple frequency of operation is made up of all the components discussed above.  The following are the LatticeECP2 FPGA specifications for each component of speed. These specifications tell us how fast LatticeECP2 FPGAs go.

• I/O - 840Mbps generic LVDS
• Logic - 250MHz to 500MHz
• Clock tree/PLL - 420MHz
• EBR - 350MHz
• DSP - 325MHz

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.