On Design Productivity And Cost of Ownership …

By Frank Schirrmeister
Last weekend I spent time with my 7 ½-year-old daughter (the ½ is crucially important at that age) on our tree house project. Well, it is more a tree “deck” so far, which is quite respectable though given that we just started building it in one weekend (as the book I quickly downloaded that evening on the iPad actually recommended). A project like this gives endless opportunities to teach children things, from safety around power tools to setting up the project, cleaning up, and optimization of the actual steps when doing repeatable tasks like screwing down deck planks. I realized on Monday that all of this is applicable to electronic design as well 😉

If you have ever had a 7 ½-year-old design partner building anything, you will know that patience is not necessarily a strong suit of theirs. So you want to get to it fast, whatever “it” is. This weekend Sydney had chosen a color and was painting the four base poles. Prep was easy: Wear clothes we don’t care about anymore, find paper to put the bucket and brushes on, etc. Then we worked on the deck planks—there is a sub-floor like structure on the four newly painted poles installed around the tree—and we had bought deck planks earlier. Prep? Out comes the table saw, measuring tape, power drill, various drill bits, deck screws, etc. As you can imagine the process of setting everything up, measuring, debugging why we had cut one of the planks to the wrong length (classic diagonal misalignment bug) and re-cutting took much longer than actually installing the about 30 square feet of deck planks that day. Once we were on it the main thing was about speed of getting the next plank up, how many we could carry at the same time and how fast we could drill and screw—loading time, capacity and performance so to speak.

Before clean-up I realized over home-made lemonade (sugar is my daughter’s secret ingredient) that this was actually quite instructive for my day to day job during the week, as well. In the four engines of the System Development Suite the main three characteristics we are typically looking at when executing hardware/software designs are speed, accuracy (TLM vs. RTL) and capacity. In articles like “Combining Prototyping Solutions to Solve Hardware/Software Integration Challenges” I have outlined  other characteristics, such as turnaround time, time of availability, and debug efficiency, but it seems we are getting back to speed, accuracy and capacity far too fast.

What works as comparison between the actual engines—Virtual Prototyping, RTL Simulation, Acceleration/Emulation and FPGA Based Prototyping—works just as well to compare the different options users have on the market. Our acceleration/emulation business is running on all cylinders and we are clearly the market leader. In customer meetings I often hear the question, “So how do I compare productivity, really?”

Well, as my daughter would tell you about our deck planks (while selling you some lemonade), it is simply all about the setup and turn-around time! There is a reason why we are calling our engine the Palladium XP “Verification Computing Platform.” It has been conceived as a verification computer with a specialized processor to which we compile the RTL to be executed and for which we enable specialized hardware debug similar to what users are used to in RTL simulation. This is pretty unique. Other platforms for hardware acceleration out there are based on FPGAs, either commercial or custom. As a result there is no need for Palladium XP to do the layout within FPGAs or do partitioning between them, which is a complicated, time consuming process. Bottom line: The setup and compile time, i.e. how to get to “it” in my daughter’s language, is significantly faster, as is the debug cycle as the debug insight is great. The Figure associated with this post shows a typical example for a 128 million gate design.

Design Productivity in an Acceleration/Emulation Environment

Our customers see three times faster compile times, as well as significantly faster debug loops, and as a result get to up to six design turns per day—at least three times as many as they see in FPGA-based systems. This provides real advantages for design engineers, as well. My daughter’s attention span is naturally limited at 7 ½ years, but even for trained professionals their concentration will suffer after 12 hours of hard work, so squeezing in 2 to 3 runs in the first 10 hours is key to real productivity.

The other question we often hear in customer meetings is about “cost of ownership.” This deserves its own post, but suffice it to say that my daughter had motivated a friend of ours to come over to “play” and help. It turned out he was very helpful (as he was taller than 40 in) in helping to hold up studs. But if I had had more power drills we could have parallelized the preparation of the deck planks as well. While this may have helped with the set-up time, there is a cost associated with that—just like in the compile farms needed for compiles to FPGA-based hardware acceleration.

You see where I am going with that:)

And by the way,  just to be crystal clear, this is not to bash FPGAs. We do see a clear need for FPGA-based hardware acceleration, as well, and in fact offer those systems called Rapid Prototyping Platform RPP as part of the System Development Suite. Both have their use in customer’s project as I had described in previous articles. The above commentary simply applies to FPGA-based systems playing in the Acceleration/Emulation market.

Bottom line: This was a productive weekend for the tree house project…and my daughter now knows about what questions to ask to get the best design productivity for acceleration/emulation, as well.

—Frank Schirrmeister is group director for product marketing of the System Development Suite at Cadence.