Embedded

March 8, 2011

Passing the Prototyping Torch

Tribal Knowledge from Synopsys and Xilinx

by Kevin Morris

You might think FPGA companies wouldn’t care much about people doing FPGA-based prototypes.  After all, these aren’t the people that design an FPGA into their product and then buy a bazillion for manufacturing use.  They buy a single-digit number of big parts, and they’re set. 

You might also think that EDA companies wouldn’t be all fired up to support FPGA-based prototypers either.  After all, aside from a few prototyping boards, and maybe some partitioning software, what do they stand to gain by making the prototyper successful? 

Most design teams working on big system-on-chip projects have only one prototyper.  There are several hardware design engineers, a passel of programmers, and one poor prototyper caught in the middle.  It hardly seems like a “market.”  The prototyper is often exiled to the back of the cube farm, given a couple of boards to play with, and told, “Make it work.”

Nonetheless, last week I moderated a panel hosted by Synopsys where they, in cooperation with Xilinx, rolled out a new book published by Synopsys Press - the FPGA Prototyping Methodology Manual (FPMM).  The book was written by prototyping experts from Synopsys and Xilinx with help from engineers at a number of large system and semiconductor houses, and it documents best practices for success in prototyping.  The authors, Doug Amos and Rene Richter of Synopsys and Austin Lesea of Xilinx have been working with and supporting FPGA-based prototypers for years.  The best practices documented in this manual have heretofore been passed down within groups and companies as tribal knowledge, from elder prototyper to new cub (probably with a significant gleam in the eye of the retiring elder).  Now, that knowledge has been captured, organized, and shared with the world - and the (prototyping) world will be a much better place as a result.

This is not a small amount of information.  The FPMM is about 500 pages, and it seems as if significant editing was required to pare it down to that.  As tribal knowledge goes - the prototyping tribe apparently has collected a lot of it over the years.  This is because prototyping is deceptively hard.  While it may seem like a simple matter to take a bunch of HDL that describes a complex hardware system and get it up and running on an FPGA board so that the team can test what they’re doing, the subtle nuances of putting generic designs into programmable logic quickly humble even the most experienced designer.  Did you use third-party IP?  Does it work in FPGAs as well as your target technology?  Did you use latches?  You did, didn’t you?  No? Shame on you!  Does your design easily partition between multiple devices?  How tight are your timing constraints?  Do you have more clock domains than a typical FPGA can handle?  The list goes on and on.

It is worth noting that the manual doesn’t address just the prototyper.  The manual explains best practices in organizational terms too – and a good portion of the manual should be read by engineering management.  There is sound advice about when and how in the product life cycle prototypers should work with the rest of the development team, with software developers, and so forth.  While the deep “style guide” parts of the manual might put management to sleep, the organizational sections should definitely be highlighted and passed through management.  Even though software developers are probably the biggest beneficiaries of the FPMM, the manual does not address them directly.  They’ll just see the benefits in earlier, more robust prototypes for their development work. 

Prototypers typically start with a design they did not create - a mish-mash of new blocks from their design team, re-used stuff from previous projects, and third-party IP blocks with varying levels of “cleanness” when it comes to FPGA use.  The design team often doesn’t have a big stake in getting the prototpye up and running quickly - after all, that’s why they have a prototyper.  The software team, however, is generally pretty anxious to get their hands on some actual hardware to see how things will behave.  In today’s multi-core, multi-process, asynchronous applications, the actual timing of concurrent events in hardware is a source of many unanticipated headaches.  The sooner the software is running on a cycle-accurate hardware platform - hopefully at or near actual speed - the sooner those ghosts in the machine can be exorcised.

It is worth pointing out here that FPGA-based prototyping is not a substitute for emulation.  Emulators still play a critical role in the design and verification of complex systems, and FPGA-based prototypes co-exist in that world quite nicely.  While your emulator gives you super-fast verification capability with deep visibility into the workings of your design – perfect for ferreting out those last few bugs you couldn’t find with simulation, your FPGA-based prototype is made to be replicated and distributed to your software team – with full speed (or near full speed) performance, much less visibility into the workings of the hardware, and much lower cost.

Prototyping really comes into its own in designs where stimulus for verification are difficult to create: when the test of success is something esoteric like the quality of video – rather than a bunch of bits matching a particular pattern, or when five applications are running simultaneously – each accessing capabilities of built-in hardware asynchronously through layers of APIs, OS, middleware, drivers, and so forth. 

One might expect that a manual written by Synopsys and Xilinx would be heavily biased toward methods or activities that favor those companies’ products.  WIth FPMM, this does not appear to be the case.  One could be just as successful following the advice in the FPMM using Altera FPGAs, or Dini boards, as with Synopsys (HARDI) boards and Xilinx FPGAs.  The manual does, however, tread a little lightly on the important build-versus-buy decision on FPGA prototype boards. 

Most companies today create their own prototyping boards.  It’s an easy trap to fall into.  How hard could it be to throw a few FPGAs on a board, add a few peripherals that are specific to your company’s typical products, and pop out a few boards that could be used throughout your company, division, or product team for years to come?  Actually, it’s much harder than it sounds.  Getting all the FPGAs arranged so that they’ll communicate well together with no timing issues and with the right pins connected to the right other pins and the power every place it’s supposed to be is complicated stuff.  Having the right version of the right peripherals on there so that you have room for future expansion is a crap shoot, and making a general-purpose connector/socketing system where you can add your own future daughter cards is an exercise in engineering fortune telling.  In fact, this prototype-board-building project is complicated enough that companies make their whole living doing it.  Maybe that thought should give you pause... 

Knowledge does not stand still - even tribal knowledge.  With the notion that prototyping best practices will evolve, the companies that put together the FPMM also built an online community where the methodology can evolve and improve with input from the prototyping public.  This evolutionary approach has worked well with other methodology projects that Synopsys has spearheaded.

With all these apparent reasons for a lack of motivation and the decidedly underwhelming direct revenue impact, why have Synopsys and Xilinx gone to the effort and expense to create the FPMM?  Perhaps the key is in the critical role prototyping plays in making design projects successful.  More successful projects mean more money and more technology flowing out of companies like Xilinx and Synopsys.  

Comments:

You must be logged in to leave a reply. Login »

Related Articles

From Cradle to Cloud

Education Meets High Tech

by Amelia Dalton

Who Controls the Power?

Open Power Foundation Aims to Make PowerPC More Plentiful

by Jim Turley

Once upon a time, there were many little RISC processors frolicking in the deep green microprocessor forest. There was the jaunty little ARM. The bright little SPARC. The mighty little MIPS. The aristocratic little PowerPC. And so many others. They all played and laughed and had ever such a good time.

Then, one by one, the happy little RISC processors started disappearing. Were they gobbled up by the big, bad CISC processor that lurked in the woods? Did they cross over the Wheatstone Bridge and into another land? Or did they just get lost in the tall grass, wandering aimlessly until their mommies and daddies forgot about them? ...

iWatch, You Speculate Incessantly

by Bruce Kleinman, FSVadvisors

I held out as long possible before writing anything iWatch related. The irony is that I am iFatigued with everyone iGuessing about an iUnnanounced product, and yet here I am contributing to the noise. iCaramba! The proverbial last straw: I read a piece comparing Microsofts unannounced wearable to Apples unannounced wearable. OMG.

And AFTER deciding to write this piecebut before I could startanother piece appeared with the declarative headline Heres Everything We Know About the iWatch. And because I cannot make up stuff this good, apparently the things we KNOW include:...

FPGA-Prototyping Simplified

Cadence Rolls New Protium Platform

by Kevin Morris

System on Chip (SoC) design today is an incredibly complicated collaborative endeavor. By applying the label System to the chips we design, we enter a...

Dont Pass Me By

Project Ara Dev Boards and the Internet of Moving Things

by Amelia Dalton

The pedal is to the metal, our motor is running, and Fish Fry is hitting the open road. At the wheel this week is mCube...

  • Feature Articles RSS
  • Comment on this article
  • Print this article

Login Required

In order to view this resource, you must log in to our site. Please sign in now.

If you don't already have an acount with us, registering is free and quick. Register now.

Sign In    Register