By Ed Sperling
You would have to be hiding in a cave without WiFi to miss the Synopsys acquisition of Virage Logic, which is due to go through in Synopsys’ fiscal Q4. This should turn Synopsys into an IP powerhouse and push it further into adjacent markets. And Synopsys still has a pile of cash remaining, so don’t think this is the end of the acquisition spree.

Case in point: At least some of the money leftover went to purchasing Synfora’s high-level synthesis technology. Considering Synopsys didn’t really have a play in the HLS market until last year, it has gained expertise in this area rather quickly. Synopsys’ push into software prototyping followed a similar pattern. There are three other big players in HLS, Mentor, Cadence and Forte. Synopsys doesn’t have enough cash to buy Mentor or Cadence, but there are plenty of rumors floating around about what company it can buy.

Mentor, meanwhile, is working on drumming up interest in HLS, which has been slow on the uptake for the better part of a decade. It introduced a high-level synthesis reference book, known as the HLS Blue Book. It’s everything you wanted to know about HLS–and it’s free.

Cadence is raising some big bucks on the side in a note-swapping deal that will provide millions to the company’s general fund. So far it hasn’t said what it’s going to do with that money, but given EDA stock prices these days Cadence may be gearing up to do some acquisitions of its own.

Mentor rolled out yet another addition to its Calibre DFM suite, this one aimed at fast and accurate extraction using 3D field solver technology. Translation: Calibre is a cash cow for Mentor and the company is making sure it stays that way.

All the big EDA companies seem to have some sort of announcement with TSMC this week. It might have something to do with the new flows that TSMC has introduced, including its analog/mixed signal reference flow 1.0. Synopsys validated its custom design solution with that flow and is working to validate Galaxy at 28nm for TSMC’s interoperable process design kit. Cadence likewise threw its support behind TSMC’s AMS 1.0 for 28nm. TSMC also included Apache Design Solutions’ power and noise solutions in two of its flows, including the AMS 1.0. And Mentor is working with TSMC on waivers for its design rule checks so previously waived IP doesn’t slow verification.

On the processor front, ARM introduced a virtual debug interface called VSTREAM that allows developers to stop the processor, view and change the value of registers and system memory. The tool works with both Mentor’s and Cadence’s emulation platforms, as well.

Actel is offering a free IP cores bundle and RTL package options with its standard software bundle. Until now most of the FPGA vendor giveaways were basic tools. This ups the ante by quite a bit.

By Ed Sperling
System-Level Design sat down to discuss the future of synthesis with Shawn McCloud, product line director for Catapult C Synthesis as Mentor Graphics; Chris Eddington, director of marketing for system-level products at Synopsys; Bret Cline, vice president of marketing and sales at Forte Design Systems; Sanjiv Kaul, executive chairman at Oasys; and Andy Biddle, director of business development at Magma. What follows are excerpts of that conversation.

SLD: Why is high-level synthesis, which has been around for awhile, suddenly so necessary?
Kaul: In the typical chip there are multiple physical partitions. It can take a typical design team 15 hours to get through the logic synthesis portion and a week to two weeks to get through physical implementation—per block. And it can take multiple iterations through that loop. Some design teams go through that loop seven to 10 times. They’re looking for ways to get timing closure much faster, and the only way to do that is to bring physical information up earlier in the process.
Cline: That’s not the only way. High-level synthesis guys can make much better tradeoffs into the RTL schedule before it even hits a logic synthesis tool, which can eliminate a huge class of timing problems.
Kaul: You’re still dealing with RTL after that.
Cline: I agree, but we own the schedule. So if the schedule gets filled up and you go through synthesis place and route and don’t meet the timing, you can go back through the high-level synthesis tool and change the schedule. You just can’t do that in RTL. We can make the flow smoother by allowing people to not make stupid decisions in the creation of that RTL.
Eddington: That’s one of the big advantages of high-level synthesis. You iterate quickly at the architectural level and you minimize the iterations that you have to do for back-end place and route.
Cline: You should never miss timing with high-level synthesis.
Kaul: It’s not so much a question of missing timing closure. It’s how long it takes you to get there.
McCloud: High-level synthesis allows you to get to timing closure more quickly. Let’s say you’ve hand-coded an architecture that completely misses timing. The time it takes to re-code , especially if it’s a significant architectural change, could be weeks to months depending on the complexity of the design. With high-level synthesis it’s easy to adjust the percentage that you’re reserving for placement and reschedule the design. And what happens when you have a spec change late in the design? That’s a nightmare to deal with in hand-coding, but it can be dealt with relatively quickly with high-level synthesis.
Cline: In addition, the tools that are coming out at the RTL level are doing smarter things with these designs. It does make it easier for us in the long run. The things that people are happiest with using high-level synthesis, which you would never expect, are the verification improvement and the predictable timing closure. You’d expect them to say productivity.

SLD: Is there a cost for that timing closure?
Biddle: And do you see more flip-flops?
Cline: You certainly can. We have a timing address knob. You can overfill the time schedule or you can underfill it. On average, we beat a hand-coded design between 10% and 20% in terms of area and still meet timing. Generally people would worry we are larger. We’re just a compiler. We can shrink down without a penalty.
McCloud: It’s a question of how much time you want to spend on a design. We’re typically within 10%. Sometimes we’re a lot smaller. Sometimes we’re bigger. If someone wanted to spend enough time they might be able to do a better job.
Kaul: It’s not an ‘either-or’ issue. It’s an ‘and’ issue. High-level synthesis can do certain things. If you want to add a pipeline to your design or you want to change your architecture, high-level synthesis is very well suited. If you want to go from RTL to GDSII in a 28nm design, then you have to have technologies that understand what’s going on downstream.
Cline: I agree. The better the logic synthesis tools get, the better the overall results.

SLD: How accurate does synthesis have to be?
Cline: It’s different for different abstractions.
Eddington: For architectural decisions you’re leveraging the capabilities of the logic synthesis tools. The decisions you’re making aren’t exactly where you’re going to put a register but roughly how many you need and roughly where they need to go. You let the logic tool do the fine-tuning.
Kaul: It’s very design-dependent. Some designs are pushing the performance. Logic synthesis has to get you very close to where you’re going to be at the end of place and route. Otherwise you can have a lot of iterations. If your design is not pushing performance, then I think you have a lot more give.
Eddington: Logic synthesis has to be pretty accurate. You need to make better decisions at the logic level. Integration with placement is still an ongoing area of innovation and improvement. The high-level synthesis, in terms of logic accuracy in the architecture and placement of registers and so forth, doesn’t have to be quite as accurate as the RTL logic synthesis.
Cline: Our customers get a number for a baseline, run that through logic synthesis and then correlate the two. You want them to be as close as possible. After that, one of the nice things about a high-level synthesis flow is the turn is really quick—literally minutes. We don’t hear people running things for four days. If it’s running for four hours, we wonder what’s going on. That’s a curse from a licensing standpoint because you don’t run this stuff for that long. But at the end of the day, they’ll run a number 100 times and then track a number. If that number correlates with what logic synthesis would have looked like, had they run it every single time, then I think they’re generally pretty happy. It doesn’t have to be 100% correlation, but we’re not going to run logic synthesis every time because it’s fairly expensive.
McCloud: It needs to be able to give you relative comparisons. All of these tools eventually take a candidate design down through RTL synthesis to give you some accurate estimates. Once you have that, you’re comparing the candidate architecture to new ones you can create in a matter of minutes. If your candidate architecture has 150,000 gates and you have another one that has 200,000 gates, is that relative comparison correct? Our number is accurate enough to do exploration. Typically you’ve got a high-level design model that’s technology independent. You take that into an FPGA and prototype it. When you take it to ASIC, almost always you do multiple architectures. We estimate the timing and where potential timing issues will occur. The next step is to take those through RTL synthesis, and that’s when you’ll know for sure. Did it meet timing or not. The architectural exploration benefits are really the big win, along with the verification benefits—being able to do those transformations without having to change your high-level model verification.

SLD: What determines who wins in high-level synthesis?
Cline: The technology takes a bit of time to mature. It’s quite easy to synthesize a C algorithm into some RTL. That’s not a hard problem and it makes the barrier to entry look fairly low. But getting a C algorithm into RTL that’s actually manufacturable is actually quite a hard problem.
McCloud: It is centered around completeness of flow. But I would say the most important aspect is the tool that addresses the verification side of things. When you look at the RTL design flow today, 60% to 70% of the design cycle is consumed by verification. A high-level synthesis tool needs to address the verification side of that problem. The approach you take with high-level synthesis can actually complicate verification if you don’t do it right. One of the important things is to have a source description that is deterministic and predictable so you can re-use that work you’ve done in C down at the RTL level. The tool that combines synthesis and verification is the right approach.
Eddington: Both of you guys stated the obvious. A high-level synthesis tool has to deliver productivity in design. It has to deliver productivity in verification. That means reliable verification from high-level models. But right now we’re all limited by these application-specific domains. The question is how we expand beyond those.

SLD: What are the limitations?
Eddington: Mostly it’s the algorithmic guys who are adopting this.
McCloud: I think that was the case three or four years ago. That’s not the case anymore.
Cline: I would agree.
Eddington: Achieving higher levels of abstraction and having design entry environments that are tailored to the different application spaces is what’s going to help this expand a lot more. We’re doing something a little different. C is important, but we have the Matlab in the model-based stuff. That seems to work very well for designers in the system-level space who may not know RTL or C. Software engineers and video engineers know C. But other environments are needed to expand this beyond the application spaces now being addressed.
Cline: Do you worry that ability of the system designer who doesn’t understand RTL is diminished because of their lack of understanding about how the architecture is implemented?
Eddington: No. I don’t think there’s any reason you can’t have a fundamental description that’s understandable and capable of being captured by a guy who has no understanding of RTL.
Cline: We would disagree. We’ve had designs that involve a hardware engineer who knows nothing about C and someone who’s an expert software engineer who understands C to the nth degree. The hardware designer will kick their butt almost every time. The reason is that algorithms can be specified in ways that imply architectures that cannot be implemented in a reasonable amount of silicon. An H.264 implementation is a good one. You can read the data in, but data has a temporal aspect in hardware. In software it’s always there in a buffer and you just go get it. But in hardware it comes in 8 bits. What do you do with the first 8 bits?
Eddington: I agree that if you ask a software engineer to write something in a sequential language, he’s going to write something that cannot be converted into a hardware implementation without having to do some fundamental changes. In our case, we’re not doing pure language. We’re building on an approximately timed, higher-level, model-based data flow graph.
McCloud: High-level synthesis doesn’t remove the need to design. You don’t just download an MPEG-4 algorithm and push a button. It’s not a tool intended to turn software developers into hardware engineers. You still need to understand what you’re trying to create, and that’s best done by hardware designers. But what it does do is remove a lot of the details you don’t have to worry about.

System-Level Design sat down with Keith Barkley, senior engineer in IBM’s systems and technology group; Steven Schulz, president and CEO of Silicon Integration Initiative (Si2); Yatin Trivedi, director of standards and interoperability programs at Synopsys; Ian Mackintosh, chairman of the OCP International Partnership (OCPIP), and Michael Meredith, vice president of technical marketing at Forte Design Systems. What follows are excerpts of that conversation.

By Ed Sperling

SLD: Problems lead to standards, followed by new problems that require standards. What are the problems that need addressing now?

Schulz: Our next effort will be to create a standard for 3D chip integration. This is an important area as Moore’s Law runs out of economic steam, if not technologically. The need for stacking die, and having standards for through-stack vias, how you handle the electrical modeling of that and the geometrical positioning and synchronizing of them has to be done not only across a multivendor flow for a particular die, but across different companies that are putting together the different die that you’re assembling into a package. Many companies have said they’ve gone as far as they can go without standards. You need the processor and stacked memory. If you’re doing a wireless communication device you’ll need the RF fabric with analog baseband on top of some digital and some memory. Often it’s easier and cheaper to do it with different die.

SLD: Is that because of heat?

Schulz: Both heat and economics. To continue integration in 2D is getting too costly, the line lengths are too long, there are uncertainties of how you do the routing, the design fabric—everything has its own specialty from a manufacturing standpoint. The real estate is a problem.

Meredith: As a general rule of thumb, the need for standards in EDA are always at the top and at the bottom. At the bottom, it’s where new process geometries create new challenges. And at the top, as we try to raise the level of abstraction we’ve got SystemC and ESL standards.

Trivedi: Whether it’s top and bottom or front and back, the IP goes all over the place. How you use it, deploy it, verify it and integrate it may be in the middle of the design process. I think of it more as exigencies, not top or bottom

Mackintosh: I think the hotspot right now in all of this is the economy. The result is that more people are open to standards and need to share costs. They’re far more open to collaborating and getting to market faster because there are fewer opportunities these days. Standards allow you to commoditize expert knowledge.

Barkley: Even internally at IBM we’ve been trying to share IP among the P series and Z series. We had to enforce internal standards just to be able to share things among our own groups. In terms of sharing costs, IBM years ago had its own internal models, GL1, NBRs, which really gave us a competitive advantage. What we found is that we couldn’t afford to do everything ourselves. We started working on OpenAccess in 2003. We’ve gone from GL1 to Oasis. We’ve gone from internal data models like VIM and CDBA to OpenAccess. We’ve moved away from our internal models and rules to industry standards, which allows us to use some of the vendor simulation and analysis tools we had to develop internally. That actually prevented us from using some of the vendor-provided software, which we had access to for years.

SLD: IBM has always trumpeted its proprietary tools as a competitive advantage. Has it gotten too expensive to continue with that?

Barkley: Yes, and that’s no longer the case. At the end of the day we have to make designers productive. There are some conflicting opinions inside of IBM, but from a high level our design executives never considered this stuff proprietary. Over the last five years we’ve been collaborating with Cadence on the advanced routing and chip optimization. We shared technology, design rules and software IP. There’s not a whole lot we consider proprietary now except product road maps. We are not an EDA organization.

Trivedi: From a user perspective, you can see why sharing makes sense. They are creating a subsystem that needs to prototype outside, so they need to have certain standards and well-defined processes, or they need to import things because they can’t do everything themselves. It’s a matter of what the rationale is for you to share. At one time IBM, HP, Intel and TI did everything themselves. Everyone was an IDM (integrated device manufacturer). There was no need to share. The only thing you knew was how many pins it had and there was a data sheet. That was the interface. Now you’re working at a much more granular level. I can only produce libraries, for example, that everyone else uses. Or I produce this IP block and everyone else uses it. Or I develop the software and I need to know your register definition.

Meredith: The financial model is the same, whether you’re collaborating or sharing. People don’t have the money to do everything themselves. They need to be able to collaborate with specialists in some areas. What that requires is the creation of an ecosystem of specialists working together.

Trivedi: The question is really how much control you want to exert and how much you can exert. The more control you can exert, the less need for standards.

Schulz: That also means you’re self-sufficient, from A to Z.

Meredith: But if there are five gorillas in the industry, that means each job is being done five times and their customers are paying for it to be done five times. It’s an inefficient approach to delivering value.

SLD: Let’s roll this back a little bit. When did big companies like IBM and TI stop developing their own tools and begin using off-the-shelf tools? And why?

Schulz: It’s a function of the maturing of the industry. Back in the 1970s at TI we grew our own crystals. As the industry matures, you specialize. And a bad economy forces those issues. In the past, we weren’t at the level of complexity involved now in moving from concept to packaged device. In the past, the IDMs owned their own fabs. Many of them are fab-lite these days. The business is much more fragmented. We have more integration, more features, and more levels of abstraction.

Mackintosh: The issue is integration. Because of that, there’s much more compartmentalization across the chain. The result is that people can only afford to play in certain areas.

SLD: And they need to extract value from those areas.

Mackintosh: Yes. They need to decide which areas to play in and eventually they have to learn to share.