Prototypical – Good [Book | PR | Reading]

I was at the DAC 2016 conference and exhibition in Austin, Texas, a few weeks ago. On the show floor, going by the S2C booth, I was roped in and got a paper copy of the book Prototypical. The copy was even signed by the authors Daniel Nenni and Don Dingee! Nice touch! The book is more than just marketing material – it provides a good overview of the origins and history of FPGA prototyping, and I found it nice and enjoyable to get more insights into this fairly important part of the EDA tools ecosystem.

Disclaimer: I work for Intel. I have no influence or contact with the selection of EDA tools. This blog is my personal reflections on the marketing, book, and general product category, and does not constitute an endorsement of any particular product.

Books as Marketing Materials

Overall, I must say I like the trend of giving out real books as giveaways rather than things like pens, USB power banks, and Angry Birds fluffy toys (actually, the Angry Birds were a hit with my kids, thanks Cadence!) I think it is a good way to provide something valuable that helps people understand what you do, and to engage for a longer time than just a white paper or thing. At last year’s DAC, I got a small version of “Hadoop for Dummies”, which was a nice little introduction to Hadoop and big data processing.

S2C is a vendor of FPGA prototyping solutions, and sponsored the book project from the look of it (rather unsurprisingly given the name of the book). The book project appeared to have been run out of the Semiwiki site, and the book is available for download after registration.

The book is really split in two parts: a fairly impartial journalistic take on the history of FPGA prototyping written by the named authors, and then a “Field Guide” written by the “Team at S2C”. The field guide is classic marketing materials, highlighting the value and capabilities of S2C products at the end of every section… just like I would have done it if I had been writing the text. I have no complaints about this, even though it is less generally interesting for someone not actively working on implementing FPGA prototyping.

FPGA Prototyping

It appears that FPGA prototyping got started commercially in 1994, after a few years of various academic prototypes (pun intended). Today, FPGA prototypes are pretty much mandatory in all hardware design flows, providing a way to quickly and comparatively cheaply run actual RTL (but synthesizing it for the FPGA rather than for the eventual ASIC). The other two techniques are software-driven simulation and emulation. Simulation is painfully slow but offers perfect insight, and an emulator is kind of a simulator in hardware – built to run the RTL as synthesized for an actual ASIC, and with great debug and trace support.

Emulators are cool – and also expensive. Before I had ever heard of FPGA prototypes, I had seen a few Cadence Quickturn boxes in various companies. They are the gold standard for ASIC design, but we are talking million-dollar-level investments. FPGAs are much less expensive per unit, but still fairly costly (I have heard numbers like 10k USD or more, depending on the size and number and nature of IO boards and other facilities). What surprised me a bit was to learn that FPGA prototypes are often faster than emulators – which kind of makes sense since an FPGA is mostly built to run fast, and less for features, inspection, and insight.

One aspect of FPGA prototypes that I find fascinating is the time it takes to actually set up for execution. Apparently, it can take a whole day to partition and synthesize and place and route a design to an FPGA prototyping solution. Once set up, you can run a lot of tests and software loads on the prototype though. In that respect, an FPGA prototype is really a prototype in the same sense as a prototype board.

The S2C Pitch and FPGA Prototyping

The S2C marketing part of the book was worth reading. It was unexpectedly technical and detailed, targeting people who are working on implementing FPGA prototypes. It goes into rather deep discussions on the particulars of how to build working setups from many separate FPGAs – which is the critical issue in modern FPGA prototyping for large designs. Along the way, it does give insight into the thinking in the world of FPGA prototypes, which is something I definitely appreciate.

The text was rather surprising in that it never mentioned transaction-level (TLM) virtual platforms and how they are used together with FPGA prototypes. The text does mention TLM in a few places, but only in the context of connecting the FPGA to a TLM testbench on a host, using the SCE-MI standard. I find the omission rather odd, since the combination of a fast virtual platform and an FPGA to run a piece of RTL is pretty common. The big EDA vendors have proposed and sold such solutions for many years – indeed, it seemed that a few years ago, the pitch for TLM VPs at the DAC had turned into “excellent tool to drive your FPGA prototype rig”. Maybe S2C has a customer base with different habits and product flows?

The text also strives to broaden the field of applicability of FPGA prototype rigs outside of the core hardware design and validation space. For example, they mention that FPGAs are good for enabling software development in automotive. Which is rather strange to me, since I thought most automotive software work was done by companies that buy standard parts. It seems odd that a chip vendor would hand over the RTL of a design along with an FPGA prototype to their customers… but then again, this is probably based on reality. Maybe they mean the internal software team at an automotive chip supplier, in which case it makes some more sense.

Another broadening is targeting FPGAs for architecture exploration work. The idea is to take pieces of RTL (the FPGA prototyping solution does require RTL-level implementation of all the blocks to work), and combine them in different ways. This offers a way to test different design ideas and ascertain their performance. I would expect most of this kind of design exploration to be done before starting on the RTL, but I guess if you are mostly combining existing blocks from IP vendors and internal reuse, this makes sense as long as rebuilding the chip is quick enough. But still… if you want to do high-level tradeoffs, using RTL for it seems awfully late and with little room to change fundamentals. It makes more sense to me to do this kind of work using more abstract architectural models and virtual platforms.

FPGAs are also touted as a good way to test your chip design with real-world IO at real-world speeds. Not sure how close you can get in terms of CPU performance, but IO units should be able to get reasonably close to real time.

When it comes to supporting debug, the paper mentioned some approaches. One is to use the debug facilities already present on the FPGA for standard FPGA developers, and to map them to the ASIC design with some additional tools. Another, complementary, approach is to modify the code that runs on the FPGA to insert additional probes and debug printouts. Basically equivalent to software tools that add logging and instrumentation to code in order to support debug and analysis. Indeed, it is interesting to see how FPGA prototyping technology contains several analogs to common software techniques.

There is also the issue of partitioning – how to break a large design across multiple FPGAs. While some of that can be done with tools automatically, it is very helpful if a design can be cut into multiple groups of functionality that operate with fairly narrow interfaces between them. This is mentioned both in the book, as well as in some talks I attended at the DAC. Indeed, a modern design that is comprised mostly of well-defined black-box blocks is rather amenable to such partitioning, since you do not have arbitrary connections from any part of the chip to any other part. The very fact that the chip is built from blocks forces a structure onto the communications that greatly help FPGA prototyping. This is similar to how we work with parallelism in virtual platforms – for the best performance, you want to break the design apart across cut-points with the lowest level of communication across the cut.

Summary

In summary, the Prototypical  book was a nice find at the DAC. It was good to learn a bit more about the fascinating field of FPGA prototyping, and I especially appreciated the look at the history of the field. Getting the book signed by the authors was a fun bonus, and kudos to S2C for inviting them on the floor.

My signed first page: