feature article
Subscribe Now

Passing the Prototyping Torch

Tribal Knowledge from Synopsys and Xilinx

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.  

Leave a Reply

featured blogs
Jul 28, 2021
The System Analysis Knowledge Bytes blog series will explore the capabilities and potential of the System Analysis tools offered by Cadence®. In addition to providing insight into the useful... [[ Click on the title to access the full blog on the Cadence Community site....
Jul 28, 2021
Here's a sticky problem. What if the entire Earth was instantaneously replaced with an equal volume of closely packed, but uncompressed blueberries?...
Jul 28, 2021
Hyperscale data centers are driving demand for high-bandwidth Ethernet protocols at speeds up to 800G to support HPC, AI, video streaming, and cloud computing. The post What's Driving the Demand for 200G, 400G, and 800G Ethernet? appeared first on From Silicon To Software....
Jul 9, 2021
Do you have questions about using the Linux OS with FPGAs? Intel is holding another 'Ask an Expert' session and the topic is 'Using Linux with Intel® SoC FPGAs.' Come and ask our experts about the various Linux OS options available to use with the integrated Arm Cortex proc...

featured video

Breakthrough FPGA news from Intel

Sponsored by Intel

As part of the numerous portfolio announcements associated with the launch of the 3rd Gen Intel® Xeon® Scalable processor, Intel also disclosed some breakthrough FPGA news: Intel® Agilex™ FPGAs now deliver industry-leading power efficiency and performance.

Click here for more information about Intel® Agilex™ FPGAs.

featured paper

Hyperconnectivity and You: A Roadmap for the Consumer Experience

Sponsored by Cadence Design Systems

Will people’s views about hyperconnectivity and hyperscale computing affect requirements for your next system or IC design? Download the latest Cadence report for how consumers view hyperscale computing’s impact on cars, mobile devices, and health.

Click to read more

featured chalk talk

Using the Graphical PMSM FOC Component in Harmony3

Sponsored by Mouser Electronics and Microchip

Developing embedded software, and particularly configuring your embedded system can be a major pain for development engineers. Getting all the drivers, middleware, and libraries you need set up and in the right place and working is a constant source of frustration. In this episode of Chak Talk, Amelia Dalton chats with Brett Novak of Microchip about Microchip’s MPLAB Harmony 3, with the MPLAB Harmony Configurator - an embedded development framework with a drag-and-drop GUI that makes configuration a snap.

Click here for more information about Microchip Technology MPLAB® X Integrated Development Environment (IDE)