FPGA Architectures from 'A' to 'Z' : Part 1

1) How to implement an open IP encryption flow
2) Alternative computing solutions, from single cores to arrays of 'things'
3) True DSP Synthesis for FPGAs
4) Graph-based physical synthesis for FPGA designs
5) Rounding Algorithms 101

In this article we introduce a plethora of architectural features. Certain options – such as using antifuse versus SRAM configuration cells – are mutually exclusive. Some FPGA vendors specialize in one or the other, while others may offer multiple device families bases on these different technologies. (Unless otherwise noted, the majority of these discussions assume SRAM-based devices.)

In the case of embedded blocks such as multipliers, adders, memory, and microprocessor cores, different vendors offer alternative "flavors" of these blocks with different "recipes" of ingredients. (Much like different brands of chocolate chip cookies featuring larger/smaller chocolate chips, for example, some FPGA families will have bigger/better/badder embedded RAM blocks, while others might feature more multipliers, or support more I/O standards, or ... the list goes on).

The problem is that the features supported by each vendor and each family change on an almost daily basis. This means that once you've decided what features you need, you then need to do a little research to see which vendor's offerings currently come closest to satisfying your requirements.

A little background information
Before hurling ourselves into the body of this chapter, there are a couple of things we need to define so as to ensure that we're all marching to the same drumbeat. For example, a term you're going to see used throughout this book is "fabric." In the context of a silicon chip, this is used to refer to the underlying structure of the device (sort of like the phrase "The fabric of civilized society").

The word "fabric" comes from the Middle English fabryke, meaning "something constructed."

When you first hear someone using fabric in this way, it might sound a little "snooty" or pretentious. Truth to tell, however, once you get used to it, this is quite a useful word.

When we talk about the "geometry" of an integrated circuit, we are referring to the size of the individual structures constructed on the chip – such as the portion of a field-effect transistor (FET) known as its "channel". These structures are incredibly small. In the early 1980s, devices were based on 3 µm geometries, which means that their smallest structures were 3 millionths of a meter in size. (In conversation, we would say: "This IC is based on a three micron technology.")

The 'µ' symbol stands for "micro" from the Greek micros, meaning "small" (hence the use of "µP" as an abbreviation for "microprocessor," meaning "small processor").

In the metric system, 'µ' stands for "one millionth part of," so 1 µm represents "one millionth of a meter."

Each new geometry is referred to as a "technology node". By the 1990s, devices based on 1 µm geometries were starting to appear, and feature sizes continued to plummet throughout the course of the decade. As we moved into the 21st Century, high-performance ICs had geometries as small as 0.18 µm. By 2002 this had shrunk to 0.1µ m, by 2003 devices at 0.09 µm were starting to appear, and – at the time of this writing – the latest FPGAs are being created at the 0.065 µm node.

Any geometry smaller than around 0.5 µm is referred to as deep submicron (DSM). At some point that is not well defined (or that has multiple definitions depending on whom one is talking to), we move into the ultra-deep submicron (UDSM) realm.

Things started to become a little awkward once geometries dropped below 1µm, not the least that it's a pain to keep on having to say things like "Zero point one three microns." For this reason, in conversation, it's now common to talk in terms of "nano", where one nano (short for nanometer) equates to a thousandth of a micron – that is, one thousandth of a millionth of a meter. Thus, instead of mumbling "0.09 µm" ("Point zero nine microns"), one can simply proclaim "90 nano" ("Ninety nano") and have done with it. Of course, these both mean exactly the same thing, but if you feel moved to regale your friends on these topics, it's best to use the vernacular of the day and present yourself as hip and trendy as opposed to an old fuddy-duddy from the last millennium.

SRAM-based devices
The majority of FPGAs are based on the use of SRAM configuration cells, which means that they can be configured (programmed) over and over again. The main advantages of this technique are that new design ideas can be quickly implemented and tested, while evolving standards and protocols can be accommodated relatively easily. Furthermore, when the system is first powered-up, the FPGA can initially be programmed to perform one function such as a self-test and/or board/system test, and it can then be reprogrammed to perform its main task.

Another big advantage of the SRAM-based approach is that these devices are at the forefront of technology. FPGA vendors can leverage the fact that many other companies specializing in memory devices expend tremendous resources on research and development (R&D) in this area. Furthermore, the SRAM cells are created using exactly the same CMOS technologies as the rest of the device, so no special processing steps are required in order to create these components.

In the past, memory devices were often used to qualify the manufacturing processes associated with a new technology node. More recently, the mixture of size, complexity, and regularity associated with the latest FPGA generations has resulted in these devices being used for this task. One advantage of using FPGAs over memory devices to qualify the manufacturing process is that, if there's a defect, the structure of FPGAs is such that it's easier to identify and locate the problem (that is, figure out "what" and "where" it is). As an example, when IBM and UMC were rolling out their 0.09 µm (90 nano) processes, FPGAs were the first devices to race out of the starting gate.

Unfortunately, there's no such thing as a free lunch. One downside of SRAM-based devices is that they have to be reconfigured every time the system is powered-up. This either requires the use of a special external memory device (which has an associated cost and consumes real estate on the board) or the use of an on-board microprocessor (or some variation on these techniques. [Editor's Note: These techniques are presented in Chapter 5 of the book.]

Security issues and solutions with SRAM-based devices
Another consideration with regard to SRAM based devices is that it can be difficult to protect your intellectual property (IP) in the form of your design. This is because the configuration file used to program the device is stored in some form of external memory. [Editor's Note: There's a very interesting paper entitled How to implement an open IP encryption flow that provides a great introduction to encryption in the context of EDA design flows in general and FPGA design flows in particular.]

Currently there are no commercially available tools that will read the contents of a configuration file and generate a corresponding schematic or netlist representation. Having said this, understanding and extracting the "logic" from the configuration file – while not a trivial task – would not be beyond the bounds of possibility given the combination of clever folks and computing horsepower available today.

Let's not forget that there are reverse engineering companies all over the world specializing in the recovery of "design IP". And there are also a number of countries whose governments turn a blind eye to IP theft so long as the money keeps on rolling in (you know who you are). So if a design is a high-profit item, you can bet that there are folks out there that are ready and eager to replicate it while you're not looking.

In reality, the real issue here is not related to someone stealing your IP by reverse-engineering the contents of the configuration file, but rather their ability to "clone" your design irrespective of whether or not they understand how it performs its magic. Using readily available technology, it is relatively easy for someone to take a circuit board, put it on a "bed of nails" tester, and quickly extract a complete netlist for the board. This netlist can subsequently be used to reproduce the board. Now the only task remaining for the nefarious scoundrels is to copy your FPGA configuration file from its boot PROM (or EPROM, E2PROM, or whatever) and they have a duplicate of the entire design.

Page 2: next page
Page 1 | 2 | 3 | 4