Cadence Emulation: Schirrmeister articulates Both Sides of the Equation

Frank Schirrmeister, Group Director of Product Marketing for the System and Software Realization Group at Cadence, had just returned from DATE in Grenoble when we spoke several weeks ago about the philosophy and technology behind Cadence’s emulation business unit. First, however, we spoke about Grenoble.

I asked Frank if DATE had been a success this year and he said, “Absolutely, yes. It was very interesting as it has transformed from a generic show into more of a technical conference. So the focus now is on the sessions.

“Particularly interesting for me, I was chair for a session about tools for the IoT. Jan Rabaay from U.C. Berkeley, always a good speaker, gave a great presentation on wearable trends. NXP also participated, talking about the connected car, and ARM spoke about their embed OS for the edge nodes. Also among those topics, we talked about debug. It was all very good.”

Having enjoyed DATE many times myself, I asked Frank what he thought distinguished the conference from DAC. He said, “First of all, DATE was in Grenoble, which is always a great destination. Then, of course, at DATE you see the European point for view.

“For instance, I had a presentation for my session regarding automotive issues, and included material of interest to our customers in Japan and Europe. The share of semiconductors in cars from those markets focuses more on the mission-critical pieces in the design. The focus is different for automotive customers in North America, where it centers more on mobile connectivity within the vehicle.”

All of this being very interesting, I turned the conversation to the real reason for our phone call: To allow Frank to clarify emulation at Cadence.

He started, “I’m Group Director for the Leading Product Management team for System Development, including virtual prototyping, links into RTL simulation, emulation and FPGA-based prototyping, and some of the software driven verification technologies. Because of all of this, I see in the industry that there are some misunderstandings around Cadence’s emulation technologies.

“For starters, we really have two different types of hardware assisted development technology. One – our Protium system – is about re-mapping the design into an array of FPGAs, similar to what Synopsys does with ZeBu and Mentor does with their custom FGPA-based emulator Veloce. These do have advantages on the speed side, because you can do some optimizations. Also, it’s very close to FPGA prototyping, like Synopsys’ HAPS, except it is automated.

“The alternative to the re-mapping of the user’s design into an array of FPGAs is what we are doing with Palladium, which is a processor-based emulator. I know the industry sometimes expresses concerns about scaling with this technology and its power consumption, but those concerns are unwarranted and in the case of power, a bit misleading.

“Cadence has made major advancements in being able to scale Palladium to larger designs, without suffering the speed degradation of FPGA-based systems. Scalability comes from millions of bit-level processors arranged as an array. As they execute all the time, you’re paying for the advantages of fast bring-up and simulation-like debug with higher intrinsic power consumption.

“With an FPGA emulation, only a modified version of the design is mapped onto the FPGA. With our Palladium technology, however, we measure capacity at an actual fully loaded dimension. If the design is a 256-million gate system, with Palladium you actually get a 256-million gate emulation. It’s 100 percent representative of the design.

“Again, with an FPGA emulation there are utilization issues. When you map to the FPGA emulation, you’re only getting 60-to-70 percent of the actual design. When it’s a 256-million gate system, in the FPGA emulator you are only getting 200 million gates, or less, as a nominal capacity. That is because a gate is not really a gate in an FPGA-based emulator.”

“The second thing that’s interesting and a keen distinction,” Frank continued, “is that using Palladium means compile is done using a single machine. You have a direct compile into the processor area. With capacity to compile up to 70 million gates per hour, you don’t need to do the layout onto the FPGA, which is time-consuming even when parallelized. With Palladium, the situation is such that we are very predictive.

“In an FPGA, first you have to do a partitioning of the design across FPGAs – that’s typically very fast – and then you lay out the design on the FPGA. You essentially have to deal with a longer turn-around time for getting the design into the box, which is the second big difference between FPGA-based emulation and Palladium.”

“The third big difference,” he said, “is on the debug side. We have a processor-based system, so a fair amount of resources are dedicated to debug in Palladium. It’s kind of like a debug plane which is dedicated to observing well all of the signals, all of the registers in the system. And it’s  less intrusive, which is very hard to do in an FPGA-based system where it requires dedicated hardware for placing probes into the design.

“The bottom line is, a gate in not a gate in an FPGA-based emulator, and Palladium scales very well. It also doesn’t require partitioning and layout into an array of FPGAs. As a result, bringing up the design is predictable and fast, and debug is like in simulation.”

Why then do critics in the industry still exist, I asked.

He responded, “Some of the critical commentary is about our higher power consumption and yes, it’s true. In fact, I just wrote a blog 3 weeks ago quoting some of our customers who are saying that they would be willing to consume even more power [in using Palladium], because that is not really an issue. Those customers are saying, ‘I have my design, I run it in Palladium, and I debug it, finding and eliminating defects fast. The turn-around in all of this is excellent.’

“So overall, we come out favorably in comparisons to FPGA-based emulation systems when power consumption concerns are looked at holistically, including compile, execution, download of debug data, and debug itself.

“Yes, we’re not an electric car. Palladium is more like a cross-over SUV, so to speak, where you can get from San Jose to Napa without three stops for recharging. Because our trace buffers are bigger, for the same amount of debug data Palladium created in one run, the closed FPGA-based system needs to run three times to create and make available to the user the same amount of debug information.

“And that’s due to our trace buffer size. When compared to other systems, for the same amount of debug data, customers would have to run the system three times as long, as a result actually consuming more power when considered holistically”

“It’s all about a trade-off in what the user really wants,” Frank said. “Yes, Palladium has higher power consumption, but it can bring the design up earlier, before the RTL is fully stable. And customers know full well that if they want to do a lot of debug on the hardware/software side of things, it always comes at a price.

“Overall, you have to look at the whole equation. Getting the design into the emulator, running it, and then doing the debug. Yes, an FPGA system may run faster, but it has less debug capabilities and it takes much longer to get the design up and running in an FPGA.”

Frank offered emulation-market distinctions between the Big Three EDA companies: “Synopsys and Cadence are actually close in our technologies with respect to emulation. We at Cadence both sell FPGA-based systems, Protium, that can be used adjacent to Palladium for faster bring-up, and then also allows for manual optimization as done in classic FPGA-based prototyping.

“In addition, with Palladium we have a processor-based system where the design can be brought up even earlier for simulation-like debug.”

He said this strategy works well with validation people: “We are always working with a diverse portfolio of engineers, all of whom believe doing early debug with a simulator offers advantages when you need higher speed, and then condone switching to an FPGA – a strategy whereby prototyping can happen much sooner.”

Driving home the point, Schirrmeister concluded, “We essentially offer a processor-based emulation with fast turnaround times to get the design up and running, and into the box. At a later point in the design flow, when the design is more stable and you have removed most of your bugs, that is when you want to bring up more of your software at higher speed. That’s when you want to turn to FPGA-based emulation and prototyping with Protium.

“Cadence has both sides of this equation covered.”

******************

Tags: Cadence, DATE, FPGA-based prototyping, Frank Schirrmeister, Mentor Graphics, Palladium, Protium, Synopsys

This entry was posted on Tuesday, April 7th, 2015 at 4:32 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.