FUTURE FPGA DEVELOPMENTS

One thing is certain—any predictions of the future that we might make are  probably going to be of interest only for the purposes of saying, “ Well, we  didn’t see that coming, did we? ” If you had told me back in 1980 when I started  my career in electronics that one day we’d be designing with devices containing hundreds of millions of logic gates and the devices would be reconfigurable  like today’s SRAM-based FPGAs, I’d have laughed my socks off. Xilinx now  has a family of 65-nm FPGA products on the market with over a billion transistors on one chip.   

Super-fast I/O   

When it comes to the gigabit transceivers discussed in Chapter 2, today’s highend FPGA chips typically sport one or more of these transceiver blocks, each  of which has multiple channels. Each channel can carry 2.5 Gbps of real data;  so four channels have to be combined to achieve 10 Gbps. Furthermore, an  external device has to be employed to convert an incoming optical signal into  the four channels of electrical data that are passed to the FPGA. Conversely,  this device will accept four channels of electrical data from the FPGA and convert them into a single outgoing optical signal. Some FPGAs today can accept  and generate these 10 Gbps optical signals internally.

Insider Info  

Another technology that may come our way at some stage in the future is FPGAto-FPGA and FPGA-to-ASIC wireless or wireless-like interchip communications.  With regard to my use of the term wireless-like, I’m referring to techniques such as  the experimental work currently being performed by Sun Microsystems on interchip communication based on extremely fast, low-powered capacitive coupling.  This requires the affected chips to be mounted very (VERY) close to each other on  the circuit board, but should offer interchip signal speeds 60 times higher than the  fastest board-level interconnect technologies available today.

Super-fast Confifi guration   

The vast majority of today’s FPGAs are configured using a serial bit-stream  or a parallel stream only 8 bits wide. This severely limits the way in which these devices can be used in reconfigurable computing-type applications.  Quite some time ago (somewhere around the mid-1990s), a team at Pilkington  Microelectronics (PMEL) in the United Kingdom came up with a novel FPGA  architecture in which the device’s primary I/O pins were also used to load the  configuration data. This provided a superwide bus (256 or more pins/bits) that  could program the device in a jiffy.   

As an example of where this sort of architecture might be applicable,  consider the fact that there is a wide variety of compressor/decompressor  (CODEC) algorithms that can be used to compress and decompress audio and  video data. If you have a system that needs to decompress different files that  were compressed using different algorithms, then you are going to need to support a variety of different CODECs.   

Assuming that you wished to perform this decompression in hardware using  an FPGA, then with traditional devices you would either have to implement  each CODEC in its own device or as a separate area in a larger device. You  wouldn’t wish to reprogram the FPGA to perform the different algorithms on  the fly because this would take from 1 to 2.5 seconds with a large component,  which is too long for an end user to wait (we demand instant gratification these  days). By comparison, in the case of the PMEL architecture, the reconfiguration data could be appended to the front of the file to be processed ( Figure 8-1 ).   

The idea was that the configuration data would flood through the wide bus,  program the device in a fraction of a second, and be immediately followed by  the main audio or video data file to be decompressed. If the next file to be  processed required a different CODEC, then the appropriate configuration file  could be used to reprogram the device.

This concept was applicable to a wide variety of applications. Unfortunately,  the original incarnation of this technology fell by the wayside, but it’s not beyond the bounds of possibility that something like this could reappear in the  not-so-distant future.   

More Hard IP   

In the case of technology nodes of 90 nm and below, it’s possible to squeeze  so many transistors onto a chip that we are almost certainly going to see an  increased amount of hard IP blocks for such things as communications functions,  special-purpose processing functions, microprocessor peripherals, and the like. 

Analog and Mixed-signal Devices   

Traditional digital FPGA vendors have a burning desire to grab as many of  the functions on a circuit board as possible and to suck these functions into  their devices. In the short term, this might mean that FPGAs start to include  hard IP blocks with analog content such as analog-to-digital (A/D) and digitalto-a nalog (D/A) converters. Such blocks would be programmable with regard  to such things as the number of quanta (width) and the dynamic range of the  analog signals they support. They might also include amplification and some  filtering and signal conditioning functions.   

Furthermore, over the years a number of companies have promoted different flavors of field-programmable analog arrays (FPAAs). Thus, there is more  than a chance that predominantly digital FPGAs will start to include areas of  truly programmable analog functionality similar to that provided in pure FPAA  devices.   

ASMBL and Other Architectures   

In 2003, Xilinx announced their Application Specific Modular BLock  (ASMBL™) architecture. The idea here is that you have an underlying c olumnbased architecture, where the folks at Xilinx have put a lot of effort into designing different flavors of columns for such things as:   

General-purpose programmable logic   

Memory   

DSP-centric functions   

Processing functions   

High-speed I/O functions   

Hard IP functions   

Mixed-signal functions   

Xilinx provides a selection of off-the-shelf devices, each with different mixes  of column types targeted toward different application domains ( Figure 8-2 ).

Different Granularity   

As we discussed in Chapter 2, FPGA vendors and university students have  spent a lot of time researching the relative merits of 3-, 4-, 5-, and even 6-input LUTs. In the past, some devices were created using a mixture of different LUT  sizes, such as 3-input and 4-input LUTs, because this offered the promise of  optimal device utilization. For a variety of reasons, the vast majority of today’s  FPGAs contain only 4-input LUTs, but it’s not beyond the range of possibility  that future offerings will sport a mixture of different LUT sizes.   

Embedding FPGA Cores in ASIC Fabric   

The cost of developing a modern ASIC at the 90-nm technology node is horrendous. This problem is compounded by the fact that, once you’ve completed  a design and built the chip, your algorithms and functions are effectively “ frozen in silicon. ” This means that if you have to make any changes in the future,  you’re going to have to regenerate the design, create a new set of photo-masks  (costing around $1 million), and build a completely new chip.   

To address these issues, some users are interested in creating ASICs with  FPGA cores embedded into the fabric. Apart from anything else, this means  that you can use the same design for multiple end applications without having  to create new mask sets.   

I also think that we are going to see increased deployment of structured  ASICs and that these will lend themselves to sporting embedded FPGA cores  because their design styles and tools will exhibit a lot of commonality.   

MRAM-based Devices   

In Chapter 1, we introduced the concept of MRAM. MRAM cells have the  potential to combine the high speed of SRAM, the storage capacity of DRAM, and the nonvolatility of FLASH, all while consuming a miniscule amount of  power. MRAM-based memory chips are now available, and other devices, such  as MRAM-based FPGAs, will probably start to appear soon.   

Don’t Forget the Design Tools   

As we discussed above, some FPGAs now contain 1 billion transistors or  more. Existing HDL-based design flows in which designs are captured at the  RTL-level of abstraction are already starting to falter with the current generation of devices, and it won’t be long before they essentially grind to a halt.   

One useful step up the ladder will be increasing the level of design abstraction by using the pure C/C ++ -based flows introduced in Chapter 6. Really  required, however, are true system-level design environments that help users  explore the design space at an extremely high level of abstraction. In addition  to algorithmic modeling and verification, these environments will aid in partitioning the design into its hardware and software components.   

These system-level environments will also need to provide performance  analysis capabilities to aid users in evaluating which blocks are too slow when  realized in software and, thus, need to be implemented in hardware, and which  blocks realized in hardware should really be implemented in software so as to  optimize the use of the chip’s resources.   

People have been talking about this sort of thing for ages, and various  available environments and tools go some way toward addressing these issues.  In reality, however, such applications have a long way to go with regard to  their capabilities and ease of use.   

Expect the Unexpected   

Before closing, I’d just like to reiterate that anything you or I might guess at  for the future is likely to be a shallow reflection of what actually comes to pass.  There are device technologies and design tools that have yet to be conceived,  and when they eventually appear on the stage (and based on past experience,  this will be sooner than we think), we are all going to say, “ WOW! What a cool  idea! ” and “ Why didn’t I think of that? ” Good grief, I LOVE electronics!