Guest Blog: Max Maxfield on FPGAs becoming SoCs
Posted by Dave Orecchio on Sun, Mar 21, 2010 @ 08:43 AM
When I graduated college and commenced my career in 1980, my first job was as a member of a team designing CPUs for mainframe computers. At that time, only a limited number of digital implementation technologies were available to us: we could either use a bucketful of simple off-the-shelf "Jelly-Bean" integrated circuits each containing a handful of primitive logic gates, or we could create our own custom ASIC device (we were working at the 5 micron technology node in those days, and each ASIC contained only around 2,000 logic gates and registers).
We also had simple programmable logic devices (SPLDs), which we used for a variety of tasks such as implementing rudimentary state machines, acting as look-up tables, or gathering a bunch of "glue logic" functions together. These devices were invaluable when it came to fixing late-stage design errors without being obliged to re-spin the board.
I remember when the FPGAs first appeared on the market in the mid-1980s. The thing I remember the most was how unimpressed we all were. As far as we could see, although these components provided a little more capacity and flexibility than our existing SPLDs, they lacked the deterministic timing of their predecessors. And since we performed our board-level timing analysis using a pencil and paper, this was something of an issue.
So, my first impression was that FPGAs were of interest when it came to implementing glue logic and simple state machines ... but not much more. Over time, of course, FPGAs grew in terms of capacity and performance and became much more interesting. They also started to boast a variety of configurable input/output (I/O) capabilities, which made them of interest for interfacing between other components that supported different I/O standards.
Today, high-end FPGAs may feature hundreds of thousands of look-up tables, thousands of DSP functions, many hundreds of standard I/Os, large numbers of transceiver blocks providing gigabits-per-second of high-speed serial interface capability ... special communications and interface functions to the outside world (CAN, I2C, SATA, DDR2 and DRR3 memory interfaces, etc.) and the list goes on.
The term System-on-Chip (SoC) was originally associated with ASIC technologies. An SoC was an ASIC that included one or more microprocessor and/or microcontroller and/or DSP cores coupled with on-chip busses, on-chip memory, peripheral functions, communications functions, external interface functions, and the "secret sauce" functions that differentiated this device from the competition. The point is that we can do all of this with a high-end FPGA. For a vast range of applications, FPGAs are today's SoCs!
But with this trend comes a need for more robust design and verification tools. The ability to debug an FPGA design in a timely manner determines time-to-market (and time-to-profit) success; however, debugging one of today's multi-million gate FPGA designs is a non-trivial task. How can you ensure that the third-party RTL IP you are using for your software simulation is functionally identical to the gate-level IP you are loading into the FPGA? And how can you be sure that the optimizations being performed by the synthesis engine aren't introducing errors?
Of course it's no secret that I'm a big fan of GateRocket's RocketDrive, which was uniquely developed to solve debugging problems with the traditional FPGA design process. The RocketDrive bridges the gap between the RTL/abstract-level software simulation domain and the physical FPGA. As each new block is verified at the RTL (or behavioral) level in the context of your full-chip design, its synthesized/gate-level equivalent can be moved over into the physical FPGA in the RocketDrive.
As soon as a problem manifests itself, the verification run can be repeated with the RTL version of the suspect block resident in the simulation world running in parallel with the gate-level version realized in the physical FPGA. By means of a special software application, the signals from the peripheries of these blocks (along with any designated signals internal to the blocks) can be compared "on-the-fly."
Using this technology - combining conventional simulation with physical hardware and an appropriate debugging environment - it is possible to very quickly detect, isolate, identify, and resolve bugs, irrespective of where they originated in the FPGA design flow.
As I say, I'm a big fan ...I strongly recommend that you give a RocketDrive a whirl yourself, and then let me know what you think!
Clive (Max) Maxfield is the president of TechBites, which provides a unique mix of technical content, editorial content, and social networking. Max is the author and co author of a number of books, including Bebop to the Boolean Boogie (An Unconventional Guide to Electronics), The Design Warrior's Guide to FPGAs, and How Computers do Math, featuring the pedagogical and phantasmagorical virtual DIY Calculator. In addition to being a hero, trendsetter, and leader of fashion, Max is widely regarded as being an expert in all aspects of computing and electronics (at least by his mother). Max was once referred to as "an industry notable" and a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way.