Experts At The Table: Rapid Prototyping
By Ed Sperling
System-Level Design sat down to talk about rapid prototyping with George Zafiropoulos, vice president of solutions marketing at Synopsys; Juergen Jaeger, senior product marketing manager at Cadence, and Howard Mao, senior product director at Springsoft. What follows are excerpts of that conversation.
SLD: What’s the current state of rapid prototyping?
Mao: There are two sides to that question. One involves the rapid prototyping itself. The other is being able to debug the rapid prototype rules. We focus on debugging the prototype.
Jaeger: If you look back at the beginning of FPGAs, they started as the base for doing ASIC prototyping. That’s where the name comes from. For many years, that promise had a lot of issues. For one, the capacity between the biggest FPGAs and even moderately sized ASICs and ASSPs was too big. Therefore, you ran into all the partition problems where you needed 20 to 50 FPGAs to implement that ASIC, which limited the usefulness. A second issue is that the software content in ASICs has dramatically increased, along with the associated costs. That has created a resurgence in FPGA-based prototyping. It’s a pre-silicon software development platform. That, in combination with multi-million gate FPGAs, has led most companies doing ASICs to do FPGA-based prototyping in one form or another. In many cases it is not for the whole SoC. It may be for subsystems. And that trend is accelerating.
Zafiropoulos: People have been doing FPGA-based prototyping for the past 20 years. It was seen as a perfect vehicle for prototyping, in addition to production use. The big change that’s happened over the past five years is that we’ve seen a maturation of the technology to the point where there are off-the-shelf commercial products as opposed to the user cobbling together their own solution. That’s the biggest change. From a commercial standpoint, you can buy a complete solution today whereas in the past you had to put together the pieces yourself. Prototyping has always been mainstream. What we’re seeing is higher-end FPGA prototyping is becoming mainstream itself because of the commercialization of those products.
SLD: One of the big pushes in this area came from LSI with its RapidChip platform, which failed for a variety of reasons. Now it’s gotten even more complex because we’ve got software to consider. So is it really rapid prototyping?
Zafiropoulos: The process to create the prototype is the rapid aspect.
Jaeger: But that’s also the area where today’s solutions fall way short of a customer solution. Everyone today can put together a board with FPGAs on it. That’s really not the problem anymore. The problem is how you get your ASIC design, which you want to use as the basis for software development, up and running on your FPGA. In the past, that’s where the industry in general has fallen short and pushed it off to the user. They said, ‘Here is a board, now do with it what you want.’ It often took three or four months to get the board up and running, but most users would do it again because they have no other choice. There’s a lot of room for improvement to make this bring-up and the debug easier for the user. That’s what’s needed to take FPGA-based prototyping out of this assembly-required and make it more of a productivity tool.
Mao: In the past, people used FPGA prototyping mainly for simulation. People tried to drive the performance of the FPGA prototyping board, which increased the set-up time. If they tuned the timing too high, it would create a delay. But if they can get it to connect to a virtual platform to do co-simulation then the situation is changed. One the other hand, even if you connect to a virtual solution you need to debug it. You have to think about different things. But it’s going to be hard for EDA companies to come in and fix that because much of the place and route is done in the Altera or Xilinx architecture.
SLD: Isn’t this the same problem we’ve been dealing with for a long time, though? The EDA companies want to charge money for tools and the FPGA companies give them away for free.
Jaeger: The FPGA vendors view their tools as an expense to sell silicon. FPGA-centric tools, whether they’re from the FPGA vendor or the EDA vendor, are really the wrong tools for rapid prototyping. You end up with FPGAs, but an FPGA synthesis tool forces you to modify your RTL. You cannot just take the ASIC RTL as it is and map it into FPGAs. That is one of the biggest challenges that users of FPGAs have today. They have an ASIC design, and then in parallel with that they have to co-develop the same design with the intent to map it into FPGAs. That’s unproductive. And then you validate in the prototype something different than what your original design is.
Zafiropoulos: I agree with that. Those tool chains are really intended to build a production single FPGA. They’re not intended to build an array of FPGAs with debugging functionality, rapid turn time and other features you really need in ASIC prototyping. It’s a different purpose, so they’re not optimized for prototyping.
Jaeger: On top of that, initially customers are transitioning from FPGA vendors and board vendors to using FPGA prototypes as a replacement for emulators. A prototype system really is not that. Debugging capabilities in an FPGA prototyping system are a key requirement. You need them. You don’t need the level of debug capability that you have in emulation systems. You have emulators for a purpose, simulators for a purpose and prototyping for a purpose.
Mao: But different customers have different problems. In the past, the FPGA prototype worked perfectly for one of our customers, but when they put up an operating system on that FPGA prototype it had a problem. It’s very difficult to use an emulator to replicate that problem because the performance is different. They run FPGA prototypes at 24MHz so they can put in the link to the operating system in one hour. When you move to an emulator it runs much, much slower. In the past people may or may not have needed that debug solution, but whenever they have a bug it’s always painful. If we can resolve that problem easier, maybe they can find a way to use the FPGA prototype to do the software co-verification much earlier in their design cycle.
Jaeger: I absolutely agree with that. I’m not sure the FPGA prototype is the right platform to do that debug, though.
Zafiropoulos: But you also allude to a bigger issue. There are multiple technologies because there are different problems you’re trying to solve, and not every technology is appropriate to solve all problems. Whether it’s a virtual model or an FPGA or an emulator or a simulator, they’re all great at something, they’re okay at something else, and they’re really bad at something else. The question is, with a problem of system-level validation or logic verification or software integration and testing, based on the need and the nature of the design, some combination of that stuff is going to be right. One size doesn’t fit all. That gets to the root problem of why there are so many different choices. It’s because there are so many different problems.
Jaeger: Where that leads to is early solutions such as simulation and emulation and virtual prototyping. It’s not a cohesive system that makes it easy for the user to go from one step to the next step, though. That is where the EDA industry is really challenged to pull these individual point tools together into something the user can put into their flow and solve their problem, whatever the problem might be.
Zafiropoulos: There are multiple tools and they have to play together—more so now than in the past, where they could be islands unto themselves.
Tags: Cadence, FPGA prototyping, rapid prototyping, Springsoft, Synopsys