By Bernard Murphy
CES 2010 was quite a party, coming off the misery of 2008-2009. Tablets were everywhere, smart phones are racing ahead, the PC is dead. Our industry is reinventing the electronic experience yet again. I saw one forecast of a $1 trillion consumer electronics market within a few years. This is heady stuff. It restores hope not only in the future of electronics but also the possibility that electronics growth may help to power the global economy back to solid growth. It makes you proud to be an engineer (with perhaps a little queasiness over accelerating an electronically connected and personally disconnected society).

And yet… This is not easy money. Consumers are fickle, they have a finely tuned sense of value, and everyone with a stake in electronic products wants a piece of their wallet. Products must be feature-rich, adaptable to a wide range of markets and quickly re-spun to add more features or different form factors. If you think these devices already have all the features they need, think about Google “near-field communications” or “energy harvesting.” This is not a market for long-term enterprise/catalog product teams. This is pure survival of the fittest, and fit means fast and adaptable. Check out this article if you want more Darwinian analogies.

This consumer market is not just another turn of the screw on “chips are getting bigger, time to market is shrinking.” This is qualitatively different. The size of the prize and the level of competition dictate we will be paid only for features. The premium for development, and time to market for a new feature introduction (especially if you are not first to market with that feature), can be six months or less. In this new reality it is essential to drive cost and risk out of product development. Handcrafted, integration-focused register transfer level (RTL) design commands no differentiated value and increases cost, risk and delay. High-level synthesis has its place at the block/algorithm level but is not the solution to the integration problem. Think Dell—fast feature assembly needs pre-defined, well-characterized reusable blocks assembled as automatically as possible with robust hookup checks to reduce (not eliminate) debug cycles in verification.

Several thought leaders—including Texas Instruments and STMicroelectronics among IDMs, and Samsung and Canon among system OEMs—already have re-engineered their design processes around exactly this approach. They have organizations that produce, maintain and qualify IP (and inspect incoming IP), platforms on which they can quickly spin variants and automated assembly tools and dedicated integration teams to reduce cycle time to handoff RTL. But this is not a game only for the rich or for major corporate initiatives. Small companies and teams are achieving the same level of productivity using the same methods, scaled down. All it takes is a willingness to set the process and tools in place, to forgo tweaking (starting from someone else’s RTL, and tweaking is not re-use) and to accept that it’s now all about execution in delivering platform variants.

The party was fun and the opportunity is tremendously exciting, but it’s only for those who are ready to change their game.

–Dr. Bernard Murphy is chief technology officer at Atrenta.

By Ron Craig
Atrenta recently conducted a user survey on timing constraints, in an effort to find out more about how they are being managed and where the issues are. I expected a diverse range of feedback on different use models, roadblocks etc., but it was very interesting to see some trends pop up:

1. 94% of respondents said that timing constraints were a problem.
2. About 30% of respondents noted that bad timing constraints had resulted in silicon failure, and about 60% said bad constraints had resulted in tapeout delays.
3. 70%-plus said they planned to simply “try harder” during their next project to avoid these problems, with no plans to use any kind of automated verification or management techniques.So even though timing constraints are enough of a problem to be killing chips, most design teams are continuing to follow the same practices that have failed them in the past—in the hope that things will somehow get better!

The survey also collected details on the approaches that design teams are taking today, which turn out to be a mixture of manual review and waiting to see what their backend tools complain about.

As I reviewed the numbers, I concluded that either we (the EDA industry) are failing to get the message across that better solutions exist, or design teams are somehow deluding themselves. It’s clear to me from discussions with a broad range of customers that the biggest competitor for any kind of automated timing constraint verification and management solutions (Atrenta’s included) is the user who believes that they have everything under control. Maybe timing constraint management is the schematic entry of chip design? The old solutions may have worked in the past, but they stopped scaling a long time ago.

When it comes to investigating potential solutions, design teams tend to have a laser focus. The question I’ll frequently hear is: “My last chip died due to a problem with XYZ. Would your tool have caught it?”

Unfortunately I’m not a good enough planner to carry around a hundred variants on my product pitch, so over the years I’ve learned that listening is the most important skill. Even though we offer a range of solutions proven to catch chip killers, the customer may only hear us talk about one – the one that they care about.

It’s naturally tempting to focus on preparing for known problems, but what about the unknown ones? Despite their best intentions, designers leave landmines in their designs all the time, issues which may only be triggered when moving to a new technology node. The evidence is mounting that when it comes to timing constraints, we’re reaching a breaking point where the old techniques aren’t working anymore. A customer of ours noted that a recent design of theirs had more than a million lines of timing constraints, but they actively minimized risk by employing our solutions to catch constraint issues before they became problems. Their approach has its roots in lessons learned from past failures, failures that their business can’t afford to repeat.

It’s clear that when it comes to timing constraints, the old ways aren’t working anymore. The time has come to start looking for problems before they become expensive problems.

–Ron Craig is senior marketing manager at Atrenta.

By Mike Gianfagna
He’s a comic legend. The master of the one-liner. I had the good fortune of being in a comedy club in New York City one evening a long time ago when Rodney stopped by to try out a new comedy routine. He simply walked in and took the microphone for 45 minutes. Apparently, he did those impromptu appearances a lot “back in the day”. One of Rodney’s most famous one-liners is “I don’t get no respect,” and that’s the topic of this Early Edition.

I’ve ranted about flawed business models and the Original Sin in other posts. That’s not the focus here. Instead, I want to pose one simple question: “Why is EDA the only complex business enterprise software product that is expected to work out of the box?” And what does a lack of respect have to do with the question?

Rodney Dangerfield: "When I was young my parents moved a lot, but I always found them."

Let’s examine the market of complex business enterprise software for a moment. Yes, EDA software is complex business enterprise software. It performs highly specialized tasks on mission critical company data and interfaces to other supply chain functions. So does product lifecycle management software, enterprise resource planning software and shop floor control software.

Here’s the difference: Those other forms of software require customization to fit into the company’s infrastructure and use model. That customization is done through highly specialized software deployment services. It can take months and sometimes years to integrate and deploy an enterprise-level software system. The customer expects it, plans and budgets for it, and works closely with the integration team to make sure things are successful.

So then, why are such services so inappropriate for EDA software? Anyone who has tried to sell such services to the EDA end customer knows the response. “I paid you for the software, and now I have to pay you again to make it work in my environment? No!” While enterprise resource planning or product lifecycle software is expected to require customization, EDA software is not. Yet EDA software is every bit as complex as those other applications (EDA developers will argue their code is substantially more complex), and making such a system fit into the customer’s design flow clearly is not a “drop in” exercise.

If you examine the financial statements for enterprise software companies, you will find that services revenue is typically around 20% to 25% of total revenues. The number is way smaller for most EDA companies – customers won’t stand for it. Yet, the result of that point of view is significant methodology, data management and efficiency challenges. From 20 feet away, this just doesn’t seem to make any sense. Unless you come to the conclusion that “EDA don’t get no respect”.

My wife came by earlier today and asked me what I was writing about. She’s done marketing work in EDA, semiconductor and enterprise software companies, among others. So her opinion is relevant beyond the fact that I have a marital duty to listen to her. When I explained the premise of this piece, she said “enterprise software is more expensive than EDA software, so people pay for the implementation service to protect their investment”.

That was the “aha” moment for me. Problem solved. Let’s raise the price of EDA software, say 10X. Customers will now pay to protect their investment, and EDA tools will work together in a much smoother way. I wish I had thought of that sooner.

–Mike Gianfagna is vice president of marketing at Atrenta.

By Mike Gianfagna
The EDA business model has seen a lot of discussion. Perpetual, time-based, pay as you go, EDA cards, etc., etc. The implications of the chosen business model can have dramatic effects on the overall health of the company involved. Changing the business model can cause mighty companies to topple and weak companies to seem strong (at least for a while). Current trends, such as cloud computing, promise to add even more degrees of freedom. At the end of the day, there is still one fundamental question: Should you pay for software, or pay for success?

With few exceptions, EDA has been sold as a cost of doing business, with no real connection to success. In fact, there is an inverse influence. The worse-off the design is, the more EDA tools you’ll need to fix it. So, bad design practices and tight schedules really help the model along.

If you look through the history of EDA you will find times when the pay-per-use model was tried. Still coin-operated, but at least payment was tied to usage. On the surface, this seems to somehow tie what is paid to the benefit received. The problem with this model is that automation works best when it is aggressively used, and pay-per-use schemes incent the customer to use the software less, and not more. Back to the drawing board.

A rather famous counter-example of EDA’s somewhat dysfunctional business model was developed by a semiconductor IP provider—Artisan Components.

From the Artisan Components Web site, circa 2004.

Artisan gave away their IP for free to end users and the foundry paid the bill in the form of wafer sales royalties to Artisan. Brilliant move. More foundry tapeouts are facilitated, and payment only occurs when there is actual silicon revenue, which is the end goal for everyone.

Some other IP vendors put a twist on this idea by charging wafer sales royalties to the end customer (and not the foundry) if their IP was used. In both of these models, everyone makes money *only* when wafer volume is achieved. This is not a coin-operated model, but a success-based model. Seems to make more sense.

Well, it does, right up to the point where the vendor asks for a cut of the end customer’s profit. That’s driven by margin on the chip sale, which is driven by the wafer price. If you ask for a royalty based on wafer volume you are definitely affecting the profit for the end customer, and not in a good way. These discussions are usually short, and don’t usually end in “yes.” I think this needs to change. If we are going to see EDA continue to grow in the years ahead, we’ll need to work this out. A success-based model makes a lot more sense. There are isolated cases of this model, but not in mainstream EDA. Who will make the first move to change this? It will be interesting to watch and see.

–Mike Gianfagna is vice president of marketing at Atrenta.

By Mike Gianfagna
I was a little late with the Early Edition this month. This is kind of embarrassing given the name. Anyone in EDA sales will understand why. It’s the end of the quarter, about a week to go. I’ve been really, really busy. Many EDA companies will book more than 50% of the quarter’s business in the next week. The bean counters have a name for this phenomenon:

the hockey stick. For some, it can be unnerving. Non–uniform book of business, characterized by a spectacular rise in deals closing near the end of the quarter. Every EDA company sees it from time to time. But that’s not the topic of this blog. Rather, it’s what’s behind the hockey stick. Much has been written about the fact that EDA software doesn’t get monetized correctly. It’s an industry that in some very real ways makes the semiconductor business possible. Yet the size of EDA is in the neighborhood of two orders of magnitude smaller than the semi business it supports. This seems odd. What causes such a disparity? I propose this phenomenon is caused by the Original Sin of our industry.

Over the years, I have agreed and disagreed with things EDA industry analyst Gary Smith has said. A few years back he came up with a gem of a comment. Paraphrasing, he pointed out that the EDA industry is, at its root, an outsourcing business. That is, EDA started as a captive business inside some of the larger IDMs and vertically integrated companies—Bell Labs, Texas Instruments, RCA, General Electric, National Semi and IBM, to name a few. All had fairly large internal CAD development teams.

In the early 1980’s, some of the developers from these companies set up shop as independent software suppliers. Daisy, Mentor and Valid are the “famous” ones from that era. Only one remains today. Consider the sales cycle in those early days of EDA. The person that used to develop software for a particular IDM now comes through the front door to sell commercial software tools to their prior employer. The person sitting across the table from them used to be their internal customer. They are now their (potential) external customer. That person knows exactly what it will take to develop the software being sold. They watched it at close range for many years.

The prospect of getting these tools from an external supplier does have advantages. Lower cost of ownership, exchanging fixed cost for variable cost, amortization of development over a larger user base, etc. So, these early and very educated customers calculate the cost of internal development and offer just a slight premium over that cost to the new EDA vendor. And the EDA vendor takes that deal. That’s the Original Sin. At that moment, the EDA vendor had a choice. They could have positioned the value of the software relative to the business they were creating for their customer. You can’t tape out a chip without EDA tools, and no tape outs means no business. Or, you could just take the low hanging fruit represented by the cost-based deal, and not push for the value-based deal. The early vendors chose incorrectly, and we’ve been trying to fix it ever since.

I’ve always felt like selling EDA tools was akin to selling cars to master mechanics. The customers could do it themselves. They have the know-how, but maybe not the time. So how important is your product? Do you sell the value of the working car today, or do you succumb to the argument that the master mechanic could build the same car anytime they wanted? Assuming they had the time, resources and inclination to do so.

I would like to propose a hypothetical scenario. My question is directed at EDA tool users, not developers. Let’s assume for a moment that antitrust laws don’t exist. Further, let’s assume that the CAD Cartel meets every six months and fixes the price for all EDA tools, worldwide. Those numbers are, say, 5X the current cost of EDA tools and there is no discounting. In this hypothetical world, what do you do? Do you pay 5X what you are currently paying, or do you re-start internal development in your company? Carefully think about the real, burdened cost for that effort and how long it will take to bear fruit. Remember, you can’t sell the resultant software externally because of the CAD Cartel – they are very powerful.

There is a cost factor that makes it compelling to do it yourself. Is it 5X, larger or smaller? I think this is an interesting discussion. None of this will ever happen in the world as we know it, so don’t let reality creep in (too much).

–Mike Gianfagna is vice president of marketing at Atrenta.

By Mike Gianfagna
The EDA360 White Paper that Cadence Design Systems published a few months back certainly has everyone talking. It’s well written. The messages are compelling. The content has a viral quality. The printed collateral is visually appealing. The microsite is engaging. Most of us only wish we had the marketing budget to do this kind of stuff.

A healthy marketing budget is a necessary but not sufficient requirement to communicate a compelling vision, however. You can have Bill Gates-class money, and if you don’t have a good idea, it just doesn’t matter. What I want to focus on for a moment is the other side of the buzz. Everyone is talking up EDA360 – interpreting its message, endowing it with all kinds of subtle, and not-so-subtle implications. Here is one person’s view of what EDA360 is NOT:

Let’s start with the obvious. EDA360 isn’t a recipe for struggling startups to find liquidity. The vision is bigger than any one company, especially a small one, to accomplish. Apologies to the venture community – EDA360 isn’t a way to find a quick exit.

EDA360 doesn’t define the rules for a new board game, although that actually might be fun for the nerds among us.

EDA360 isn’t pure Cadence marketing hype. OK, some people think maybe that’s exactly what it is. Here is a test – if you were going to use a high visibility platform like this to promote your company’s products and direction, wouldn’t you make sure the message lined up with what you were offering?

So, take a close look through the EDA360 document. See anything in there that looks like a current Cadence product – maybe even a roadmap presentation from last year or something like that? You’ll find yourself stretching here.

Here’s my favorite one – EDA360 isn’t a template for your company’s new brochure. You don’t take the document’s message, copy all the figures, and say “me too.” That’s IP reuse taken too far. The vision behind EDA360 requires a new approach to design methodology and customer acquisition. It demands a fundamentally new approach to the market and a collaborative attitude to get there. “Me too” doesn’t work.

So what is EDA360? It represents a lot of ideas, strategies and predictions. For me, the most compelling piece is access to new customers and new markets. Let’s face it, EDA has been stuck in the same demographic for a while now. As an industry, we’re good at figuring out how to win existing budget from a competitor but not so good at finding new budget. EDA360 proposes there is a new demographic – the software development community who writes code for consumer products.

These folks typically live with the hardware they get and do their best to make the software work on it. The semiconductor and EDA communities think this is just fine. After all, we’re at the center of the universe, right? The arrows always radiate out from what we’re doing.

What if we decide the arrows are pointing in the wrong direction? What if the software development community drives the hardware architecture? That would make for a very different design methodology, one with a new source of potentially unambiguous specs. In this upside-down world there might be new customers, new budget, and a process to define multiple hardware variants in a new, market-driven manner. Not bad.

Making the arrows point the other way won’t be easy, conquering new markets never is. I, for one, am excited by the prospect. If we can all stay focused on this goal, maybe EDA can start growing again. I look forward to that reality.

–Mike Gianfagna is vice president of marketing at Atrenta.

By Ron Craig

I live in a reasonably remote area—defined as more than 10 miles from the nearest Starbucks. Given that I spend a fair amount of time driving, I’m conscious of things like safety and mileage. One thing that has a big impact on both is the health of my tires, and after having a recent replacement set installed I noticed that my ‘local’ tire shop offered things like regular re-inflation, pressure checking, etc. As tempting an offer as this may be, it struck me that there’s somehow something not right in driving more than 15 miles to have the pressure of my tires checked. Wouldn’t it instead make more sense to check them myself before I even emerge from my driveway, avoiding the risks associated with low pressure or bad wear before they really become a problem and prevent me from even reaching the tire shop?

A similar thought came to mind recently as I reviewed the results of a user survey on timing constraints, focused on how they are handled and the issues they cause. Across design teams in more than 30 companies worldwide, it was surprising to see that although more than 90% of engineers admitted regular problems with timing constraints (resulting in tapeout slips and even silicon failure), 70% simply resolved to try harder the next time around and keep using the techniques which were clearly failing them up to this point. It’s also interesting to note that roughly 70% of users rely on their existing back-end tools to point out any mistakes in their timing constraints. They put trust in these tools like I could put trust in my tire shop, but this means putting up with considerable (often undetected) risk on the way there.

The solution in my case is to use a reliable, hand-held tire pressure gauge coupled with some visual inspection. But is there a ‘hand-held pressure gauge’ for timing constraints? Even if there is, there’s a paradox to overcome – the engineer who writes the RTL code is the one who best understands how it should be constrained but doesn’t understand the complexities of timing constraints, whilst the engineer who takes on the role of timing constraints ‘guru’ is so far removed from the original design process that he doesn’t understand the design well enough to constrain it. So perhaps the problem isn’t one of technology at all; maybe this is all about how we allow users to access the technology.

Let’s look at the car maintenance analogy again. I definitely don’t want to take on responsibility for alignment, balancing and the whole host of other things that allow me to get the best (and safest) use of my tires. It is reasonable, however, for me to take on a little responsibility like pressure checking. In the chip design world, this kind of limited empowerment can definitely help RTL designers and engineers at the front end of the implementation process develop something that’s much less likely to turn into a problem further down the road.

Constraints checks should be built into existing customer verification regressions and they shouldn’t add much overhead for the design team. Bad constraints need to be identified and fixed at the source, rather than being used to drive expensive back-end tools. That reduces iterations, avoids tapeout slips, and everyone can sleep better knowing that there are no hidden ‘surprises’ in their timing constraints.

So if I told you that a handheld tire pressure gauge could avoid potential problems many of orders of magnitude more expensive than the cost of the gauge itself – wouldn’t you be crazy not to use one?

Ron Craig is senior marketing manager at Atrenta.