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.

Rather than taking a traditional approach to assessing the tradeoffs, I’d suggest that we need to carefully consider the two most critical definitions:  What does “integration” mean and what does “risk” mean?

In board development discussions, integration usually means reducing the number of components on your board by bringing as much function as possible into as few components as possible.   Likewise, risk is commonly associated with the complexity of the board that you are bringing to market.

I propose that the most accurate definitions of risk and integration imply both a physical aspect and a process aspect.  That is to say, risk can be quantified not only from the physical complexity of a board, but also with the complexity of the process that brings the board to market.  In the same way, integration can mean not only a reduced BOM (bill of materials) but also a simplified development process.

Whether risk and integration complement each other or not depends on how they are combined.  Higher levels of power management integration can bring more risk if the new solution is unproven.  On the other hand, higher levels of integration can actually reduce risk if new parts actually simplify the processes that are required to bring the board to market. The right balance is achieved when we can find new power management solutions that not only increases integration, but also reduce the risk.

The mission of the ProcessorPM POWR605 is to do just this.  That is, to reduce complexity and risk not only in terms of the physical board itself, but also in the process that brings it to market.   The ProcessorPM reduces the physical complexity of a processor power solution by bringing voltage monitoring, processor reset and watchdog timer functionality all under one roof.  Higher integration and a reduced BOM translate into lower risk.

The ProcessorPM comes with a tested and pre-programmed, factory configuration. The factory configuration integrates voltage monitoring for 5V, 3.3V, 2.5V and 1.8V supply monitoring with a CPU reset and watchdog timer interrupt output generation.  Although the user can change the programming, there is no need to do so if the default functionality suits their needs.  All they need to do is include ProcessorPM into their schematics and select the appropriate strap values to set watchdog delays and reset pulse stretching.   This simplifies the development flow and reduces risk by eliminating the need to develop and test a new configuration.

Integration and risk will continue to be factors in the ever advancing pace of microprocessor based systems.  The savvy engineer will continue to look for ways to optimize both for their system power management.

With increasing frequency, automotive manufacturers regularly inquire about using FPGAs in high-reliability systems.  In this continuation posting, I will highlight solutions that mitigate potential SRAM corruption issues.

Part one of this blog posting discussed the unique benefits of using AEC-Q100 qualified LatticeXP2 Non-Volatile FPGAs to eliminate issues that surround SRAM-based devices.  These include: hard failure of the boot memory, memory retention issues, deliberate tampering, memory erasure, and electrical noise.

Soft Error Detection
Soft errors occur when high-energy charged particles alter the stored charge in a memory cell in an electronic circuit.  The phenomenon first became an issue in DRAM, requiring error detection and correction for large memory systems in high-reliability applications.  As device geometries continue to shrink, the probability of soft errors in SRAM has become significant for some systems. Designers are using a variety of approaches to minimize the effects of soft errors on system behavior.  The phenomenon is applicable to all devices that include SRAM cells, including: Microprocessors, DSP processors, SRAM devices and FPGAs including Antifuse devices that include memory.

SRAM-based FPGAs store logic configuration data in SRAM cells. As the number and density of SRAM cells in an FPGA increase, the probability that a soft error will alter the programmed logical behavior of the system increases.  A number of varying approaches have been taken to address this issue, most of which involve Intellectual Property (IP) cores that the user instantiates into the logic of the design, using valuable resources and possibly affecting design performance.  The LatticeXP2 devices have a hardware implemented soft error detector that does not affect performance or heat dissipation of the devices.

The SED hardware in the LatticeXP2 devices consists of an access point to the FPGA SRAM configuration memory, SED controller circuitry, and a 32-bit register to store the CRC for the current bitstream (see Figure).  Enabling the SED capabilities does require the use of several I/O pins.  Subtracted from the overall pin count are 4 dedicated input pins as well as 4 dedicated output pins.  These pins are used to enable and start the SED checking as well as providing the status of the SED operation. 

During SED operation, the control circuits read the serial data stream data from the FPGA’s SRAM configuration memory and calculates a CRC.  The calculated CRC result is then compared with the expected CRC that is stored in the 32-bit register.  If the two CRC values do not match, there is corruption of the configuration memory and an external signal is set to a high value to indicate the error.  The user has several options for using the error signal: ignore the error, log the error using an external processor or reload the SRAM configuration from the original load device.

The SED checking inside the LatticeXP2 SED offers security against SRAM corruption that does not impact the performance or operation of the user logic.  FPGA designs implemented with the four items listed in part 1 of this posting can be considered ultra-reliable for startup and initialization.  Designs that incorporate the SED circuitry complete the protection for normal operation and enable complete ultra-reliable FPGA designs.

With increasing frequency, automotive manufacturers regularly inquire about using FPGAs in high-reliability systems.  There are several concerns that are raised during these discussions about corruption of the FPGA configuration used for initialization and SRAM corruption during operation.  In this entry, I will highlight several solutions to mitigate initialization configuration corruption using Lattice AEC-Q100 qualified devices.  Part 2 of this blog post will show solutions for dealing with potential SRAM corruption issues.

SRAM-based FPGAs download their configuration from an external source when the system powers up.  The boot source can be from a memory device such as a serial EEPROM or FLASH device.  Boot sources can also be an intelligent device like a microcontroller that can provide the correctly formatted bitstream.  All FPGAs have some type of CRC check of the initialization bitstream when the device starts.  If an error is found in the bitstream, then the FPGA will not start operating which prevents incorrect (and possibly dangerous) operation of the system.  Most FPGAs will then notify the system that the initialization failed and then start another initialization sequence that hopefully will be successful.

There are several scenarios that can cause the corruption of the initialization bitstream.  These include:

•     Hard failure of the boot memory
•     Memory retention issues
•     Deliberate tampering
•     Memory erasure
•     Electrical noise

There are four basic steps for using FPGAs when designing ultra-reliable systems, they are:

Step one is to move the primary boot device (contained in an external component) to a memory array that is internal to the FPGA.  This step eliminates many of the common initialization failure modes.  The integrated design also increases the initialization speed and allows the FPGA to be used in “Instant-On” systems.  The LatticeXP2 is the only non-volatile AEC-Q100 qualified SRAM/FLASH FPGA available.  Having on-die FLASH in devices like the XP2 allows extensive memory testing of the entire device at 125C.  This assures that even with continuous operation of the XP2 at the maximum temperature, there will be no losses in the FLASH memory content for a minimum of 10 years.

The second step for reliable systems is to add a redundant boot device.  This is accomplished by adding an external boot device that can be an automatic fallback device.  As the XP2 Flash Memory is field reprogrammable, it is possible for events to take place during an authorized download of new operating code during a dealer update.  By adding the secondary boot device, there is an assured backup or “limp home” operating image if necessary.  The typical use is to place a “golden” factory copy of the initialization code in the eternal memory device.  This allows the system to recover any problems with the image stored in the internal memory array.

Thirdly, secure the backup bitstream that is contained in the external memory device by using bitstream encryption to secure the boot image.  The XP2 and the LatticeECP2/M families support 128-bit AES bitstream encryption to prevent reverse engineering and unauthorized changes to the design.  An encrypted image is stored in the external boot device and during initialization; the image is unencrypted and moved into the SRAM cells.  This encryption mechanism can also be used to download a new image into the internal FLASH memory.

The last step is to “lock down” the FPGA to prevent unauthorized access to the stored configuration.   Several programmable registers internal to the XP2 control access to the configuration memory.  The possible combinations are:
    1. Unlocked
    2. Key Locked – Presenting the 128-bit key through the programming interface allows the device to be unlocked.
    3. Permanently Locked – The device is permanently locked.
To further complement the security of the device a One Time Programmable (OTP) mode is available. Once the device is set in this mode it is not possible to erase or re-program the Flash portion of the device.

FPGA designs implemented with these four steps can be considered Ultra-Reliable for startup and initialization with the ability to: start with a valid configuration, allow secure updates and prevent attempts to erase, download or modify the initialization configuration.

In the next entry, I will finish off this discussion with the monitoring and protection of the SRAM contents during operation.

Ernest Hemingway once wrote: "When people talk, listen completely. Most people never listen."  At Lattice, we're keenly aware of the importance of communications with our customers....  finding out their needs, thoughts and opinions.

To better serve the Lattice user community with enhanced communication between users and Lattice engineers, we're making some changes to our Forum area of the web.  This will be a three fold strategy: open forums, FAQ's, and Q&A.  Here's how they'll play out:

• Open Forum:  This is the newest section and it's a forum in the truest and most traditional sense of the word.  The purpose of the Open Forum is free form discussion between Lattice users. Please post here to share your experiences, questions, solutions and opinions.  Lattice engineers will also be active in this community, so please let us know what's on your mind!
• Q & A Forums: This is a set of forums where users can post questions directly to the Lattice applications engineering team. This forum is less about discussion and more about specific questions.
• FAQ's: This section is for fast answers.  A question gets promoted to an FAQ when we see the same question being repeated in the Q & A section, the Open Forum, or by direct contact with our tech support team (techsupport@latticesemi.com).  If you'd like to comment on an FAQ, please let us know your thoughts in the Open Forum.

We hope that this three pronged approach will provide open and dynamic communication between Lattice users and engineers. You can see the new forum organization at http://www.latticesemi.com/support/forums.cfm.  Please feel free to post your opinions on this new organization by posting in the Open Forum.  We're eager to hear what you think!

-dan

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.