harry … the ASIC guy

It was 1992 and I was supporting the Motorola Iridium project in Chandler, AZ. There was a project lead named Steve who I was tasked to work with. My job was to get certain elements of our DesignWare library working properly to support his ASIC design team.

Steve was a bit of a control freak. Whenever there were technical decisions to be made, Steve wanted to be the one making the decisions. And once he made his decision, there was no changing it. You see, Steve had a big ego and did not like to be wrong, much less wrong in front of his team.

Unfortunately, his decisions were not always the correct decisions and I had no problem telling him that. You see, I had a big ego too.

As you can imagine, Steve and I did not get along very well.

Fortunately, I had a boss who had dealt with Steve before and who gave me some advice that I carry to this day. He suggested that I bring the relevant facts to Steve and present them in such a way that the decision was obvious. Then, I needed to say these words, “I’m not sure what is the best choice. What do you think?”

As hard as it was for me to relinquish control of these decisions, it turned out to be the right way to handle Steve. Instead of feeling like he was put on the spot to win a debate with the local AE, he felt like a respected authority figure. With this pressure removed, Steve usually ended up making the right decision (i.e. the one I would have recommended).

Steve was happier. I was happier. And we got a lot more productive work done as a result!

__________

The soft skills that I describe in the story above do not come naturally to most engineers. A matter of fact, I’ve often heard it said “he’s a great engineer, but I’d never take him to a client”. So I was very interested when I came across a press release describing how Mentor Graphics and RTM Consulting collaborated to develop a soft skills training class for Mentor consultants. I sent an email to Paul Hofstadler, VP of Consulting at Mentor, requesting to talk to him about the class, and he graciously accepted.

According to Paul, Mentor’s Services are typically focused on deploying to their clients new working processes around the EDA tools that Mentor sells. That is, they are teaching their clients to fish, rather than selling them fish. As you can imagine, it requires a great deal of influence and political savvy to effectively implement these types of changes in a client’s organization. Unfortunately, these skills don’t necessarily come naturally for most engineers. Indeed, when Mentor went back and examined the projects that had challenges, they discovered that the core issues were not technical, but rather involved corporate politics and communication issues.

Paul decided that he needed to increase the soft skills of his consultants in order to be more effective on projects and to recognize opportunities for more business in a tough economy. “More than half the work in consulting is finding and growing people”.  Rather than building a training program internally, or piecing one together from existing off-the-shelf classes, Paul engaged with RTM Consulting to develop a customized class to meet Mentor’s specific needs. “We didn’t want to pull our best consultants off of time critical customer projects to develop the class. They are the ones guiding our customers through complex projects. In addition, we wanted the outside point of view that RTM brought to the situation.”

Most of the course material came from RTM Consulting . The specific case studies and industry specific material came from Mentor. Paul had senior consultants help with the development of the material, especially the case studies which were based on real experiences. The result is a 3 day course that is very hands-on. There is standard lecture time and also several 5-6 person role play case studies. “The collaboration with Mentor Graphics was key to honing in on customization of the training to give the them the best chance at gaining the right skills necessary, and providing a solid return on their educational investment”, according to Randy Mysliviec, CEO of RTM Consulting.

Paul Hofstadler particularly praised the case studies. “The case studies were the most interesting part of the course. I never knew what was going to come out of them. Each group solved the case studies slightly differently using the skills taught in the class.” Even so, Paul resisted the urge to let the consultants bring real customer situations into the class for fear that the entire class would end up working on one real customer case. Instead, Mentor asked consultants to present real case studies after the class, several weeks later, and present them to the internal team. This served as a reinforcement of the material and helped to put the course material into practice.

A 3-day training course for the entire consulting team seems like a big investment. “Ironically, the cost of soft skills training can often be offset by just a single large project overrun or a collection of overruns”, according to Randy Mysliviec. Fortunately, the timing of the class coincided with an end of year lull in delivery, so Mentor was able to implement the training class with minimal customer project impact as well.

Since the training was administered just a few months ago, it is difficult to definitively measure the value. However, there is strong anecdotal evidence that it is working. One senior consultant, who was very skeptical at the beginning, used the techniques in the class to turn around a difficult customer (similar to my story at the beginning of this post). Paul has indicated that “consulting orders this quarter are a lot better than last quarter” and he attributes that in part to the training, particularly the parts that help consultants recognize potential follow-on opportunities for more business.

“In this economy, it is more important than ever to understand the customer’s needs, communicate effectively, and deliver excellent solutions on every engagement” said Paul in summary. “It is clear to me that our projects are running more smoothly after the training. As a bonus, our repeat customer order rate is up indicating that we are continuing to deliver high value to our customers despite the ‘interesting’ times in which we find ourselves.”

Due to the success of the training, Mentor is looking at extending the training to other parts of the consulting organization and to other organizations in Mentor. In the meantime, RTM Consulting is offering the course for other customers, minus the Mentor specific material, of course. “The soft skills needs at Mentor are certainly not unique in the professional and consulting services world”, says’ Randy Mysliviec. “Most technology and pure services companies do a good job of teaching their teams about products, services, and technologies they need to know to effectively serve clients. What is most often missed are the soft skills necessary for consultants to effectively interact with their clients.”

Thanks to folks like RTM Consulting, these soft skill aren’t hard to learn after all.

harry the ASIC guy

I recall taking a course called The Counselor Salesperson when I was an AE at Synopsys. The course was very popular across the industry and was the basis for the book Win-Win Selling. It advocated a consultative approach to sales, one in which the salesperson tries to understand the customer’s problem first and provide a solution that he needs second. Sounds obvious, but how often do you encounter a salesperson who knows he has what you need and then tries to convince you that you have a problem?

One of the techniques in the process is called the “Magic Wand” wherein the salesperson asks the customer “What would it be like if …”. This open-ended type of question is designed to free the customer’s mind to imagine solutions that he’d otherwise not consider due to real or imagined constraints. That’s the type of question I asked last week when I asked: What would you do with 1000 CPU’s? And boy did it free your minds!

Before I go into the responses, you may be wondering what was my point in asking the question in the first place.  Well, not so surprisingly, I’m looking to understand better the possible applications of cloud computing to EDA and ASIC design. If a designer, design team, or company can affordably access a large number of CPUs for a short period of time, as needed, what would that mean? What would they be able to do with this magic wand that they would not even have thought of otherwise?

I received 8 separate responses, some of them dripping with humor, sarcasm, and even disdain. Good stuff! I’ve looked them over and noticed that they seem to fall into 4 groups, each of which highlights a different aspect or issue of this question.

“Rent Them Out”

Gabe Moretti had the best response along these lines, “(I’d) heat my house and pool while selling time to shivering engineers”. Jeremy Ralph of PDTi put some dollar value on the proposition, calculating that he could make $8.25M per month sub-licensing the licenses and CPUs. While Guarav Jalan pointed out that I’d need to also provide bandwidth to support this “pay-as-you-use” batch farm.

The opportunity is to aggregate users together to share hardware and software resources. If I buy a large quantity of hardware and software on a long-term basis at discounted rates, then I can rent it out on a shorter-term basis at higher rates and make money. The EDA company wins because they get a big sale at a low cost-of-sales. The customers win because they get access to tools on a pay-as-you-go basis at lower cost without a long-term commitment. And I win because I get to pocket the difference for taking the risk.

“Philanthropy”

One of the reasons that Karen Bartleson and I get along so well is that we’ve both been around the EDA industry for some time (we’ll leave it at that). As a result, we not only feel connected to the industry, but also some sense of responsibility to give back. Karen would train university student’s on designing SOCs. I’d train displaced workers on tools that can help them find a new job.

Even though this is not really a business model, I think it is still something that the EDA vendors should consider. Mentor is already very active in promoting it’s Displaced Worker Program. Autodesk and SolidWorks are giving away free licenses to the unemployed. This type of program should be universal. Using cloud computing resources is an easy way to make it happen without investing in lots of hardware.

(On a side note: PLEASE, PLEASE encourage anyone you know at Synopsys and Cadence to follow Mentor’s lead. Synopsys did this in 2001 and Cadence once had a “Retool-To-Work” program that was similar. I truly believe that both companies have that same sense of corporate responsibility as Mentor has, but for some reason they have not felt the urgency of the current situation. I am personally going to issue a daily challenge on Twitter to Synopsys and Cadence to follow suit until it happens. Please Retweet.)

“Do Nothing”

John Eaton pointed out that it is very difficult to use any additional capability offered as “pumpkinware” if you know it will evaporate within a month. It would take that long to set up a way to use it. And John McGehee stated that his client already has all the “beer, wine, and sangria” they can drink (New Yorkers - do you remember Beefsteak Charlie’s?), so he’d pass. John: Can you hook me up with your client ?

Seriously,  it certainly requires some planning to to take advantage of this type of horsepower. You don’t just fire off more simulations or synthesis runs or place and route jobs without a plan. For design teams that might have access to this type of capability, it’s important to figure out ahead of time how you will use it and for how long you will need it. If you will be running more sims, which sims will they be? How will you randomize them? How will you target them to the most risky parts of the design?

“Run Lots of Experiments”

Which brings us to Jeremy Ralph’s 2nd response. This one wins the prize as best response because it was well thought out and also addressed the intention of the magic wand question: what problem could you solve that you otherwise could not have solved? Jeremy would use the resources to explore many different candidate architectures for his IP (aka chiplet) and select the best one.

One of the key benefits of the cloud is that anyone can have affordable access to 1000 CPUs if they want it. If that is the case, what sorts of new approaches could be implemented by the EDA tools in addressing design challenges? Could we implement place and route on 1000 CPUs and have it finish in an hour on a 100M gate design? Could we partition formal verification problems into smaller problems and solve what was formerly the unsolvable? Could we run lots more simulations to find the one key bug that will kill our chip? The cloud opens up a whole new set of possibilities.

__________

I’ve learned a lot from your responses. Some were expected and some were not. That’s what’s fun about doing this type of research … finding the unexpected. I’ll definitely give it some thought.

harry the ASIC guy

If I gave you 1000 CPUs to use for a month … and 1000 licenses of any EDA tool you want … what would you do?

What would it be worth?

harry the ASIC guy

My last blog post, entitled The Weakest Lynx, got a lot of attention from the Synopsys Lynx CAEs and Synopsys marketing. Please go see the comments on that post for a response from Chris Smith, the lead support person for Lynx at Synopsys. Meanwhile, the final part of this series … The Missing Lynx.

About 7 months ago, I wrote a blog post entitled Birth of an EDA Revolution in which I first shared my growing excitement over the potential for cloud computing and Software-as-a-Service (SaaS) to transform EDA. About a week later, Cadence announced a SaaS offering that provides their reference flows, their software, and their hardware for rent to projects on a short-term basis. About a week after that, I wrote a third post on this topic, asking WWSD (what will Synopsys do) in response to Cadence.

In that last post, I wrote the following:

Synopsys could probably go one better and offer a superior solution if it wanted to, combining their DesignSphere infrastructure and Pilot Design Environment.  If fact, they have done this for select customers already, but not as a standard offering. There is some legwork that they’d need to do, but the real barrier is Synopsys itself. They’ve got to decide to go after this market and put together a standard offering like Cadence has … And while they are at it, if they host it on a secure cloud to make it universally accessible and scalable, and if they offer on-demand licensing, and if they make it truly open by allowing third party tools to plug into their flow, they can own the high ground in the upcoming revolution.

Although I wrote this over 6 months ago, I don’t think I could have written it better today. The only difference is that Pilot has now become Lynx. “The ASIC Cloud”, as I call it, would look something like this:

As I envision it, Synopsys Lynx will be the heart of The ASIC Cloud and will serve to provide the overall production design flow. The Runtime Manager will manage the resources including provisioning of additional hardware (CPU and storage) and licenses, as needed. The management cockpit will provide real-time statistics on resource utilization so the number of CPUs and licenses can be scaled on-the-go. Since The ASIC Cloud is accessible through any web browser, this virtual design center is accessible to large corporate customers and to smaller startups and consultants. It’s also available to run through portable devices such as netbooks and smartphones.

If you think I’m insane, you may be right, I may be crazy. But it just might be a lunatic you’re looking for. To show you that this whole cloud computing thing is not just my fever (I have been sick this past week), take a look at what this one guy in Greece did with Xilinx tools. He basically pays < $1 per hour to access hardware to run Xilinx synthesis tools on the Amazon Elastic Compute Cloud. Now, this is nothing like running an entire RTL2GDSII design flow, but he IS running EDA tools on the cloud, taking advantage of pay-as-you go CPU and storage resources, and taking advantage of multiple processors to speed up his turnaround time. The ASIC Cloud will be similar and on a much greater scale.

It may take some time for Synopsys to warm up to this idea, especially since it is a whole new business model for licensing software. But for a certain class of customers (startups, design services providers) it has definite immediate benefits. And many of these customers are also potential Lynx customers.

So, Synopsys, if you want to talk, you know where to find me.

__________

That wraps up my 5-part series on Synopsys Lynx. If you want to find the other 4 parts, here they are:

Part 1 - Synopsys Lynx Design System Debuts at SNUG

Part 2 - Lynx Design System? - It’s The Flow, Stupid!

Part 3 - Strongest Lynx

Part 4 - The Weakest Lynx

harry the ASIC guy

Earlier this week I wrote about the strengths of the new Synopsys Lynx flow offering. Today, the weakest Lynx.

1. Limited 3rd-Party Tool Support.

Synopsys states that Lynx is “flexible and inherently configurable to readily incorporate 3rd-party technology”. And it is true that they have done nothing to prevent you from incorporating 3rd-party tools. They also have done little to help you incorporate these tools. In most cases, incorporating 3rd party tools means digging in to understand the guts of how Lynx works. That means getting down and dirty with makefiles and tcl scripts and mimicking all the special behavior of the standard Lynx scripts for Synopsys tools. For instance, here are a few of the things you might need to do:

• Break up your tcl scripts into several tcl scripts in separate directories for the project and block
• Access special Lynx environmental variables by name in your makefiles and TCL scripts
• Have your tool output special SNPS_INFO messages formatted for the metrics GUI to parse out of the log file
• Update your scripts for new versions of Lynx if any of these formats have changed.

If you are motivated, I’m sure you can hack through the scripts and figure it out. However, to my knowledge (I looked in Solvnet, correct me if I am wrong) there is no application note that clearly documents the steps needed and the relevant files, variables, and message formats to use.

It’s not surprising that Synopsys does not want to make this too easy. One goal of offering the Lynx flow is to encourage the use of an all Synopsys tool flow. If it were truly a wide open flow with easy addition of 3rd-party tools, then there would be less of a hook to use Synopsys tools. (Personally, I disagree with this approach and think Synopsys would be better off offering a truly open flow, but that’s the next post).

As a result, Lynx will be used only by customers using a predominantly Synopsys tool flow. I think that is OK by Synopsys. They’d rather sell a few less Lynx licenses rather than support the use of 3rd-party tools. Unfortunately for designers using other tools, Lynx does not currently have that much to offer.

2. Lynx Is Difficult To Upgrade

One of the complaints of Lynx’s predecessors is that it is not easy to upgrade from version to version. That is because it is a set of template scripts, not an installed flow. What do I mean?

When you create a project using Lynx, a set of template scripts are copied from a central area and configured for you based on your input. Let’s call this V1.0. As you go through the design process, you customize the flow by changing settings in the GUI, which in turn changes the local scripts that you copied from the central area. Now, let’s say that you want to upgrade to V1.1 because there are some bug fixes or new capabilities you need to use. You can’t do that easily. You have 2 alternatives:

1. Create a new project using v1.1 and try to replicate any customizations from the v1.0 project in the v1.1 project. I hope you kept good notes.
2. Diff the new scripts and the old scripts and then update your version 1.0 scripts to manually upgrade to v1.1.

Admittedly, Synopsys provides release notes that identify what has changed and that will help with approach #2. And they try to avoid making gratuitous variable name changes. Even then, the upgrade process is error-prone and manual. In most cases, for any one project, customers will just stick with the version of Lynx that they started with in order to avoid this mess. Then they’ll upgrade between projects. That negates the benefit of having a flow that is always “up-to-date”.

In my humble opinion, a better way to architect the flow would have been to have a set of global scripts that are untouchable and a set of local scripts that can be customized to override or supplement the global scripts. In that case, a new version of Lynx would replace the global scripts, but the local scripts, where all the customization is done, could remain unchanged.

3. Debugging Is Difficult

Have you ever tried to debug a set of scripts that someone else wrote? Even worse, scripts that are broken up into multiple scripts in multiple directories. Even worse, by looking at log files that do not echo directly what commands were executed. Even worse, you were told you never had to worry about the scripts in the first place. And worst of all, when you called for support, nobody knew what you were talking about.

That is what debugging was like in Pilot, Lynx’s most recent predecessor.

I’ve been told that Synopsys has tried to address these issues in Lynx. They now have a switch that will echo the commands to the log files. The Runtime Manager can supposedly locate the errors in the log files and correlate them to the scripts. And now that Lynx is a supported product, Support Center and ACs should know how to help. Still, I’d like to see it to believe it. From what I understand, many of these features are still a bit flakey and almost all the Synopsys consultants, the largest user base for the flow, do not use the new GUIs yet.

__________

In summary, Lynx’s main weakness is that it was not originally architected as a forward compatible, open flow for novice tools users, which is what it is being positioned as. In fact, it started out as a set of scripts written by Avanti tool experts for Avanti tool experts to use with Avanti tools. Synopsys has done a lot to try to morph the flow into something that allows 3rd-party tools, upgrades more easily, and eases debug, but the inherent architecture limits what can be done.

So, what should have been added to make Lynx better? You’ll want to read the next in the series: The Missing Lynx.

Part 1 - Synopsys Lynx Design System Debuts at SNUG

Part 2 -  Lynx Design System? - It’s The Flow, Stupid!

Part 3 -  Strongest Lynx

Part 5 - The Mising Lynx - The ASIC Cloud

harry the ASIC guy

I know. I know. I know.

I said that I was going to publish the final post in a 3-part series on Synopsys Lynx last Friday. However, as I put my notes together, I realized how much there is to say. So, I’m breaking up the last post into 3 separate posts: The Strongest Lynx, The Weakest Lynx, and The Missing Lynx (clever, huh?).  First, the Strongest Lynx.

I think that the best way to understand the strengths of Lynx is to consider who is Synopsys’ intended customer for this flow offering. After all, the offering is designed for them. In that regard, since adopting Synopsys Lynx is such a big change in methodology, Synopsys is looking for customers who are already planning some sort of major transition, including:

• Startup companies who have no design flow to begin with
• Companies making a significant transition to a new technology node or process (e.g. 90nm => 45nm)
• Companies expanding their existing design capabilities (e.g. ASIC => COT)
• Companies moving towards an all Synopsys flow (e.g. vendor consolidation)
• Companies downsizing their in-house CAD teams

These companies are already committed to some sort of change in design flow, so Synopsys offers them a “buy” alternative to making it in-house. Synopsys Lynx is attractive to the extent that it accelerates that transition process and allows the design teams to be productive faster. In that light, the 3 greatest strength of Lynx seem to be:

1. 75-90% of a working design flow out-of-the-box.

I’m sure methodology experts and tool experts, if given a chance to dig into the Lynx scripts, would find areas to make improvements to the flow.  Nonetheless, I can say from experience managing teams using earlier versions (Tiger, Pilot), that Lynx provides a complete design flow that requires very little customization “out-of-the-box”. It is the same design flow that has evolved from almost 10 years of delivering design services and is being used by Synopsys’ own design services organization, so indeed they “eat their own dog food“. Synopsys says that they are doing more regression testing, which should increase quality. There is documentation and training, and Synopsys offers 1 week of on-site assistance to install and start customizing it.

2. A design flow that optimizes across the various tools.

It’s well understood that smaller process geometries require the various tools in the flow to work together more closely, exchanging data and anticipating what the other tools will do downstream. Synopsys claims to have implemented several such flows in Lynx, particularly highlighting their low-power flow. If this is true, that should result in better results than a point-tool approach.

3.  Ease-of-use features that help average tool users be productive more easily.

Design flows for very small geometries (65nm, 45nm, 32nm) are extremely complex and demand a depth of expertise across all the tools that is difficult to find. As a result, there is a need to simplify the design process and tool usage so “average” design teams can still implement these chips effectively. The Runtime Manager supposedly frees the designer from having to edit makefiles or tcl scripts, allowing control over all the appropriate variables through GUI settings and menus and debug of script errors through the GUI. Similarly, the Management Cockpit promises to provide valuable metrics without digging through log files and reports. If they deliver on these promises, the Runtime Manager and Management Cockpit will make average designers more productive more quickly. I have some doubts, though, especially since these GUIs are brand new and have not had extensive testing. I’d be interested to know if these run as smoothly as advertised or if there are issues getting them to deliver.

In summary, Lynx’s strength is in providing a 75-90% complete Synopsys design flow that optimizes across the tools to increase the design quality and provides graphical capabilities to make the flow easier to use for the average non-tool-expert designer. To my knowledge, none of the other major EDA vendors offer anything similar, either in scope or maturity.

If this sounds like an endorsement, you’ll want to read the next in the series : The Weakest Lynx.

Part 1 - Synopsys Lynx Design System Debuts at SNUG

Part 2 -  Lynx Design System? - It’s The Flow, Stupid!

Part 4 -  The Weakest Lynx

Part 5 - The Mising Lynx - The ASIC Cloud

harry the ASIC guy

(This is the 2nd in a 3 part series on the newly introduced Synopsys Lynx Design System. You can find Part 1 here) .

When Pilot was introduced some years back, one of the bigger discussion points concerned what to call this thing. I’m not talking about whether to call it Pilot or some other name. I’m talking about what-the-heck-is it.

• Is it a flow?
• Is it an environment?
• Is it a system?
• Is it a platform?

In the end, the marketing folks decided that it was an environment, which included a flow and other stuff like:

• Tools for prepping IP and libraries
• A configuration GUI
• A metrics reporting GUI

Lynx adds a Runtime Manager to the product, so now it is no longer an environment. It’s a Design System. Well, with all due respect to the marketing folks who wrung their hands making this decision, I’d like to say one thing:

It’s the flow, stupid!

Sure, the metrics GUI can create pretty color-coded dashboards that even a VP can understand. “We’re red, dammit. Why aren’t we green”. And the Runtime Manager can configure the flow, and launch jobs, and monitor progress, also with pretty colors. And the “Foundry Ready System” … well, I’m still trying to figure out what that even means, even though I know what it is. But it’s the flow at the core of Lynx (nee Pilot nee Tiger nee Bamboo) that is the real guts of the product and the reason you’d want to buy it or not buy it. It’s the engine that makes Lynx run. So let’s take a tour.

At the core, the Lynx flow is a set of makefiles and Perl scripts that invoke Synopsys tools with standardized tcl scripts. (Clarification: All the scripts in the flow are tcl – one tiny bit of perl which comes with ICC-DP is re-used but anything the user touches is going to be in Tcl). Together, these scripts implement a flow that has been designed to produced very good results across a large number of designs.  The flow operates with a standard set of naming conventions and standard directory structures. In all, the Lynx flow covers all the steps from RTL to GDSII implementation.

There are actually 5 major “steps” in the flow:

1. Synthesis
2. Design-for-Test (may now be combined with #1)
3. Design Planning
4. Place and Route Optimization
5. Chip Finishing

Each of these steps is further broken down into smaller tasks. For instance, Place and Route might be divided into:

• Placement Optimization
• Clock Optimization
• Clock Routing
• Routing
• Routing Optimization
• Post Route Optimization
• Signal Integrity Optimization

The scripts also implement the analysis tasks such as parasitic extraction, static timing analysis, formal verification, IR drop analysis, etc. In all, they cover everything a design team needs to go from an RTL design to tapeout. If there is a task that is missing (e.g. Logic Bist insertion), you can add an entire new step to the flow by modifying the makefiles by hand, or using the GUI to create a new task. If you want it to use a 3rd party tool, you can do that too by having the makefile call that tool. Third party tools actually are a little more complicated than that, but that gives you the idea. (Clarification from Synopsys: Third party tools can be executed. The system is very open to including other tools – Synopsys just doesn’t promote this loudly. A key thing about the Lynx flow is that you do not ever need to even look at a Makefile, or execute a make command  – “no Makefile knowledge required” – since it is all handled graphically through the GUI – people should not be worried that they have to learn make).

So, you may ask, what’s the big deal? After all, isn’t this the way that most design teams / CAD teams implement their flows, more or less. What is so special about a set of makefiles and tcl scripts?

Honestly, you probably could go off and design something very similar on your own. And it might be better or more closely suited to your needs than this standard flow from Synopsys. Only you can make that choice because only you know what is important to you. The advantages of using a flow like Lynx from Synopsys are:

• 90-95% of what you need you can get off-the-shelf and you can modify the rest if you need to.
• The flow is being constantly updated with each new major release of the Synopsys tools so you don’t suffer from “flow inertia” and find yourself with an outdated flow.
• The flow is being constantly tested, not just through regressions, but by the Synopsys consultants using it on real customer projects. So the quality is high.
• In areas such as power, Synopsys can optimize the flow across multiple tasks and steps and tools, something that it would be hard for non tool experts to do.
• You can use the engineers who would have been designing your flow to do real work.

Of course there are disadvantages as well:

• It’s an all Synopsys flow, so you have to use Synopsys tools to get the most benefit. If you currently use other 3rd party tools, then the benefit is reduced proportionately. Or you can convert to the Synopsys tool, but that costs money and time and maybe it’s not the best-of-breed as a point tool.
• The scripts are actually divided into many pieces of scripts that call each other. Although very modular, this can be confusing for a novice user if he is trying to modify the flow or debug a problem.
• Lynx has a “strongly preferred” directory structure that is very deep. They do this for some good reasons, but this might go against the norm at your company and ignite a “religious feud”.
• Once you’ve invested in this flow by training up your organization and building your own scripts and utilities on top, you’re pretty committed to Synopsys. Not a problem if Synopsys is your long term partner, but if you want to fool around or have a fear of commitment, not so good.

The bottom-line is that Lynx provides you with the same tool flow that the Synopsys consultants use on their own projects. If you are using an all or predominantly Synopsys flow, then I think it’s worth looking at.

(Friday: What I like. What I don’t like. And What Could Be Better)

Part 1 - Synopsys Lynx Design System Debuts at SNUG

Part 3 -  Strongest Lynx

Part 4 -  The Weakest Lynx

Part 5 - The Mising Lynx - The ASIC Cloud

harry the ASIC guy

I stopped by a lunchtime presentation yesterday given by the local Synopsys AC. He was updating my client on what was new in Design Compiler and other tools when he put up a slide that said something like this:

set_max_area 0 (now default setting)

For those who don’t know what this means, it tells the synthesis engine to try to make the design area as small as possible, which is obviously a desirable goal. Why would anyone ever want to set their area goal higher? If you’ve used Design Compiler before, you know that this has been somewhat of a running joke, a command that was in each and every synthesis script every written, as follows:

set_max_area 0

So it got me thinking. Were there any other artifacts of a bygone EDA era that were still were hanging around, like a running joke, that had served their purpose and needed to be put to rest. Of course there were, or I would not be writing this post. Here are 3:

1) Perpetual licenses. As Paul McClellan points out on his excellent EDA Graffiti blog, in the early days of EDA “the business model was the same business model as most hardware was sold: you bought the hardware, digitizers, screens and so on… And you paid an annual maintenance contract for them to keep it all running which was about 15-20% of the hardware cost per year.” EDA companies loved perpetual licenses for 2 reasons.

1. They got to recognize all the revenue for the purchase at the time of the sale, so they were able to show better numbers on the books quicker.
2. Once you “bought” the software, you only paid a small fee each year for maintenance. If you wanted to switch to another competitor’s tool, you’d need to pay that up-front perpetual license cost again, which was a real disincentive to switch. Basically, they could lock you in.

Even though most EDA companies have gone to a subscription license model, some still predominantly license software as perpetual. With the advent of short term licensing like Cadence’s eDaCard and Synopsys’ e-licensing, the perpetual model is as outdated as Sarah Palin.

2) Large direct sales teams. I need to be really careful here, because I worked in various customer facing roles at Synopsys for almost 15 years and I still have several friends who work in direct sales at various EDA companies. Many of them are very skilled and I don’t want to cause them to lose their jobs. But the fact is that all of us rely on “the Web” to get information on all things, including EDA tools, much more than we rely on salespeople. I’m part of the older generation (although I don’t feel or act that way), but the newer generation of customers views the internet in all its forms (static web pages, social networks, blogs, podcasts, twitter) like the air that they breath. They can’t live without it. And if you think they are going to want to have to schedule a visit from a “salesperson” to get access to a tool they are interested in, then you don’t have a clue about what these people expect. They expect to go to a web page, log in (maybe), and be off and running. And if your tool ain’t accessible that way, sorry, they’re not interested. Of course, that sounds shortsighted, but that’s they way it is and will be, like it or not.

This does not mean that some direct sales has no use or value. After all, a company is writing the check, not an individual with a credit card. And sophisticated customers will still (for now) want to install software and use it, so they will still need support. So there will still be a need for some direct sales and support, but much of the early stages of the sales process will move to the Web.

3)  Closed tool suites and solutions. As I stated in a previous post, most EDA companies seek to fence customers in rather than provide streams to nourish them. With all due regards to folks like Karen Bartleson and Dennis Brophy who have unselfishly worked to promote standards, we fall far short of the goals of the Cad Framework Initiative, which sought to enable true plug-n-play interoperability between EDA tools. It’s definitely getting better, due mostly to customer pressure. But we still have a long way to go before we have truly standard standards that enable collaboration between EDA suppliers. So, if you’re an EDA company, get with the standards.

That’s just 3. I’m sure there’s more. Let me know if you come up with others:

harry the ASIC guy

Last Wednesday at DVCon, Peggy Aycinena MC’ed what used to be known as the Troublemakers Panel, formerly MC’ed by John Cooley. The topic, “EDA: Dead or Alive?” Well, having attended Aart’s Keynote address immediately preceding and having attended Peggy’s panel discussion, I can answer that question in the immortal words of Miracle Max, “EDA is only MOSTLY dead”. But first, some background.

Back in the mid 90s, I attended a Synopsys field conference where Aart delivered a keynote addressing the challenges of achieving higher and higher productivity in the face of increasing chip size. The solution, he predicted, would be design reuse in the form of intellectual property. Although most of us had only the faintest idea of what design reuse entailed and could barely fathom such a future, Aart’s prediction has indeed come true. Today, there is hardly a chip designed without some form of soft or hard IP and many chips are predominantly IP.

Some years later, he delivered a similar keynote preaching the coming future of embedded software. This was before the term SoC was coined to designate a chip with embedded processors running embedded software. Again, only a handful understood or could fathom this future, but Aart was correct again.

So, this year, immediately preceding Peggy’s Panel, Aart delivered another very entertaining and predictive keynote. After describing the current economic crisis in engineering terms using amplifiers and feedback loops, he moved to the real meat of the presentation which addressed the growing amount of software content in today’s SoCs. He described how project schedules are often paced by embedded software development and validation. How products are increasingly differentiated based on software, not hardware. And he predicted a day when chips would only have custom hardware to implement functions that could not be performed with programmable software. In essence, he described a future with little electronic design as we know it today, where hardware designers are largely replaced by programmers.

Immediately following Aart’s keynote was Peggy’s panel. (If you want to know exactly what occurred, there is no place better to go than Mike Demler’s blow-by-blow account.) Peggy did her best to challenge the EDA execs to defend why EDA would not die out. She kept coming back to that same question in different ways and the execs kept avoiding directly answering the question, choosing instead to offer such philosophical logic such as: “If EDA is dead, then semiconductors are dead. If semiconductors are dead, then electronics are dead. And since electronics will never die, EDA will never die”.

On the surface, logic such as this is certainly comforting. After all, who can imagine a future without electronics? Upon closer inspection, however, and in light of Aart’s keynote, there is plenty reason for skepticism.

Just as Aart was right about design reuse and IP…

Just as Aart was right about embedded software …

I believe that Aart is right about hardware design being replaced by software development.

As processors and co-processors become faster and more capable of handling tasks formerly delegated to hardware…

As time-to-market drives companies to sell products that can be upgraded or fixed later via software patches…

As fewer and fewer companies can afford the cost of chip design at 32nm and below…

More companies will move capabilities to software running on standard chips.

With that, what becomes of the current EDA industry. Will it adapt to embrace software as part of its charter. Or will it continue to focus on chip development.

Personally, I think Aart is right again. Hardware will increasingly become software. And an EDA industry focused on hardware, will be increasingly “mostly dead”.

harry the ASIC guy

I’m still up at the Design Verification Conference (DVCon) and have not had a chance to summarize last evening’s Software-As-A-Service and Cloud Computing EDA Roundtable. I will do that over the weekend and have a complete rundown next week, including slides.

In the meantime, I wanted to pass on some information that was announced a week or so ago and which I became aware of just this week. Mentor Graphics has initiated a Displaced Worker Program to provide free training to customers who have lost thier jobs in the last 6 months. Back last Decemeber I had issued a challenge to the EDA vendors to do just this. I don’t know if this challenge had any affect; hopefully they did this because they thought it was the right thing to do.

So far Mentor is the only company that has done this, to my knowledge. I’ve personally had discussions with one other of the “Big 3″, so hopefully they will follow suit. Maybe Mentor’s offer will help prompt them.

What do you think? Should they do this?

harry the ASIC guy