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.
