When Mentor bought Sierra, they filled the doughnut hole with physical design jelly. I don’t see how Mentor fits any kind of Cadence hole. Perhaps this is a stock market maneuver, which would mean that it must defy logic.

The churn and uncertainty is bound to ripple on for years if the merger/take-over actually goes ahead.

As you mentioned, Mentor’s rag-tag collection of ESL tools and IDEs has some interesting pieces, like Catapult. The verification space is equally muddled in terms of overlaps and missing pieces.

With the large overlaps, hostile nature of the bid and general size of the combined company, I’d be quite surprised if it does go ahead, but like you, I’m not a 16th century fortune teller.

So is Mentor Jonah in this story?

Grant (and Juergen),

By way of full disclosure to other readers, I run marketing at Bluespec.

I wanted to comment on two items: 1. Juergen’s view; and 2. The comments that Grant has heard from some people questioning whether Bluespec is highe enough to be ESL Synthesis.

On the first item, I think Juergen makes an interesting point. Customers seemed to be concerned with overall chip development/verification and software readiness. Unless C-RTL blocks are the longest pole in a chip schedule tent by a material amount, then accelerating them is not going to materially impact overall chip development (though local portions may improve). And, I’m not sure how C->RTL synthesis improves software development.

We need high-level synthesis that supports both algorithmic and complex control IP and SOC interconnect. Atomic transactions can enable this.

To the second point as to whether Bluespec is as high-level as other ESL solutions, I think the answer depends on how you define abstraction:

* If you define high-level as writing in a sequential language, then no we are not high-level. With Bluespec, design is done explicitly in parallel. Does something have to be sequential to be high-level?

* If you define high-level as expressing solely function and not architecture, then we are not high-level. Though if that were your definition then there is no high-level design today. Every high-level tool requires architectural guidance for synthesis.

Bluespec is based on atomic transactions. Atomic transactions are not part of C/C++, which have no way to express concurrency, or SystemC, which offers a similar model to RTL for concurrency. Both RTL and SystemC require low-level, detailed manual control over shared resources.

Atomic transactions allow us to raise the level of abstraction for both control and algorithmic IP.

And, Bluespec allows a degree of parameterization that is both very powerful and synthesizable. It allows one to parameterize on feature and architecture — and most importantly, have the control logic automatically generated for them.

These two unique capabilities often make Bluespec designs significantly shorter than those written in C/C++/SystemC. An HD-quality H.264 decoder was written in fewer than 10,000 lines of code. At DAC, I had a video engineer experienced in C->RTL synthesis ask me over an over again — “How so short?” An arbiter for a network processor was written in 1/14th the lines of code of a Verilog one. I don’t measure abstractness by lines of code, but it can be a proxy.

If you want to see a really cool example of what general purpose high-level synthesis is capable of, please take a look at this year’s MEMOCODE Codesign Contest results at http://rijndael.ece.vt.edu/memocontest08/everybodywins/#results. How did the winning team do this? They did the whole design for the FPGA in hardware and did it in three weeks (despite splitting it across three people). And, they skipped system level simulation and integrated directly on the FPGA. I’d be happy to send the paper describing the winning solution to anyone that contacts me at Bluespec (gharper@bluespec.com).

There are a lot of voices in the EDA world stating that the only answer is C, despite years and years of commercial and research efforts demonstrating that automatic parallelization are not a general solution. The software industry has all but abandoned automatic parallelization — in favor of applications explicitly written in parallel. Why is the EDA industry pushing it so hard?

Here are some interesting reads:

Tim Mattson of Intel on writing parallel software versus auto-parallelization: http://www.eda.org/edps/slides/par-prog-doing-it-right-epc-hardcopy.pdf

Winner of this year’s Pistilli Award for Women in EDA on whether behavioral synthesis (as classically defined by automatic parallelization, ed.) will ever succeed:

http://www.scdsource.com/experts.php?id=201&page=1

A quote from Akash Deshpande, CTO of system design at ARC: “Automatic parallelization? Forget about it, at least for performance-critical applications”

Finally, from Tim Sweeney, famous video game designer at
Epic Games [Unreal, Gears Of War, … on Xbox 360, PlayStation 3, ...]:

“C++ is ill-equipped for concurrency”

[ on Shared State Concurrency programming ]
“This is hard! … There must be a better way!”

Models from the IP vendor are the ideal in many cases, not just for the configurable IP business. But sometimes the IP vendors do not feel like releasing models, or the chips in question are old hat. For example, someone using an oldish Intel chipset along with some standard x86 processor and then a pile of custom ASICs, FPGAs, and standard network controllers to build a board… there is no real “IP” being bought here, really just standard chips.

What is the model here that makes sense? Right now, it seems to be tool vendors or consultants building these models from the manuals and providing them to the needy software developers. This tends to get resolved simply because the value of doing software development on a model is so great that procuring the models is less of a problem. Just pay someone to do it. And twist some arms to get hte documentation needed.

Marketing comes up with a grand idea. Then if you are into the whole ESL thing, you almost immediately want to start slinging prototypes around, exploring the performance, maybe running snippets of algorithms, exploring the bandwidth issues and other performance corners that are the focus of much of the back and forth of the initial system and architectural design.

Peripherals on the boundaries of the chip functionality can be happily abstracted away to a large degree, but models of those core bits that really influence the performance are key. Worse still when you are considering evaluating different options from external IP vendors.

The models are never ready when you want them, usually because the companies are still designing the IP and either do their design first and create a model last, or wrote the model in some other language than the one you want to use, for a customer that uses a different interface or hooks up to a different sort of modeling tool.

All of these are very solvable problems and can easily be worked around with a 6 month lead time and some money and engineers thrown at the problem.

But for system design, you need those models now and you’d better be finished in 6 months time or maybe turning it into a nearly final virtual prototype to be starting your software development.

The killer for ESL IP availability, if you want to be using anywhere near current IP or the latest and greatest processors is the complete lack of lead time on the need for models. Excel almost always wins that race.

Do tools make it easier to write and use models? I would suggest that tools can add to the cost of developing models because many of the value add features require the model developer learn and use proprietary APIs. This is a significant burden when the model is to be reused in several different tools. In ESL, interoperability extends far beyond the transaction interfaces. We still must take huge strides in interoperability for model configuration, instrumentation and debug.

Who holds the burden of evidence here? Is it OSCI? Have they done enough to convince the modeling-public that SystemC models have sufficient horsepower to compete with other approaches? Is it possible to answer these questions in a public forum without breaching a clause in a software license?

Are we using the correct metrics to compare these different approaches? Is it all just about simulation speed or should we be looking at the product of simulation speed /and/ development effort? Are these alternative modeling styles even universally applicable or are we just talking about better ways to hack an ISS?

If I may abuse Grant’s metaphor a little: lets not forget that doors have locks. Is that the true value of “the other side of the door”? Who is locked in? Who is locked out?