harry … the ASIC guy

My morning routine is pretty, well, routine.

Get up.  Wake the kids.

Check email.  Ask the kids to stop jumping on the couch.

Check Twitter. Tell the kids again to stop jumping on the couch.

Check my Google Reader. Glare at the kids with that “I’ve asked you for the last time” look.

You get the idea.

This Wednesday morning, somewhere in between conversations with my kids, walking the dog, and getting ready for work, I came across the following comment on a friend’s blog:

Ron, we are listening.

http://www.mentor.com/blogs

Ron Fuller
Web Manager, Mentor Graphics

For background, Ron Ploof is the guy who got the crazy idea almost 3 years ago that Synopsys should be doing something in this new world called social media. (Actually, I don’t think the term “social media” had even been coined back then). He evangelized this belief to the VP of Marketing at Synopsys and created for himself a job as Synopsys’ “New Media Evangelist” (actual title on his business card). He launched Synopsys’ first foray into social media, including podcasts, videos, and most prominently, blogs.

Synopsys’ success motivated Cadence to follow suit (something confided to me by Cadence’s former community manager). And it seems, according to the comment on Ron’s blog, it also motivated Mentor’s move into social media.

__________

I wanted to find out more about the Mentor blogs and I was able to set up some time to talk over lunch with Sonia Harrison at Mentor (see her sing at the Denali DAC party) . Sonia had helped me set up my previous interview with Paul Hofstadler and had extended me an invitation to attend the Mentor User2User conference (which, unfortunately, I could not attend). As it turns out, Sonia was the absolutely right person to talk to.

Even though I had only now become aware of Mentor blogs, Mentor had evidently coordinated their launch with the launch of their new website several months ago. Sonia was quite humble, but it seems that she was the driving force behind the blogs and Mentor’s presence in other social media like Twitter. She had been watching what was going on for some time, hesitant to jump in without a good plan, and now was the time.

According to Sonia, Mentor’s motivation for doing the blogs was to extend into a new media their “thought leadership” in the industry, to draw customers in to their website, and to exchange information with customers. Interestingly, Mentor did not hire an outside social media consultant or community manager like Cadence had. Rather, the project was homegrown. Sonia recruited various technical experts and others as bloggers. She developed “common sense” social media guidelines to make sure bloggers were informed of and played by social media rules (e.g. no sensitive or proprietary information, be polite, respect copyrights, give attribution).

According to Sonia, “one of the more difficult things was to get people to commit to blogging regularly. Writing takes time, it’s almost a full time job.” Despite this additional work burden, Mentor has no plans to bring in professional journalists as bloggers like Richard Goering at Cadence. And it doesn’t seem they need to. Simon Favre received a blog of the week award from System Level Design a few weeks ago, so they are doing quite well on their own.

Sonia does not have any specific measurable goals (page views, subscribers, etc.), which I think is a mistake, especially when her upper management comes asking for evidence that these efforts are paying off. My friend Ron likes to tell me that social media is the most measurable media ever and it’s a shame not to use the data.

I started playing with the site later in the afternoon and noticed a few things. First, when I added a comment to one of the blogs without registering, it did not show up right away, nor did I get a message that the comment was being moderated. It did show up later in the day, but it would be nice to at least be told that it was “awaiting moderation”. Still better, why moderate or require registration at all? The likelihood of getting inappropriate comments from engineering professionals is very low, and they can always be removed if need be. Moderation of comments will also kill a hot topic in its tracks. I’ve personally had the experience of publishing a new blog post late at night and waking up to several comments, some addressing other comments. Had I moderated the blog, none of those comments would have even showed up until later in the day.

Second, there was no way to enter a URL or blog address when leaving a comment. It is pretty standard practice to have this feature to allow readers to “check out” the person leaving the comment. Hopefully thay can add this.

On the positive side, the most important feature of a blog is the content and the content looks very good, especially the PCB blogs. Also, there is apparently no internal review or censorship of blog posts, so bloggers have the freedom to write whatever they want, within the social media guidelines of course.

 __________

It’s been almost 3 years since Ron made his first pitch to his manager. Who would have thought that the Big 3 and many others would have adopted social media in such a short time. Meanwhile, my kids are still jumping on the couch.

GTG

harry the ASIC guy

Last night you may have watched the NBA Playoff game in which the Orlando Magic came back to defeat the heavily favored Cleveland Cavaliers. Great game!!!

Or the finale of American Idol in which Kris Allen came back to defeat the heavily favored Adam Lambert. Great show!!!

What did I do last night? I listened to the Q2 2009 Synopsys earnings call. Great conference call!!!

(OK … I’ll admit it wasn’t as exciting and nail biting as either of the other viewing options. Just think of it like this: I took on the work of listening to the call and summarizing it for you, in order to free you up to watch the game or idol. You can thank me later )

Here’s the summary. (You can read the full transcript here if you like).

Financials

On the up side, Synopsys had a good Q2, beating their revenue and earnings per share guidance slightly. On the down side, Synopsys lowered its revenue and cash flow guidance slightly for the rest of the year, allowing for potential customer bankruptcies, late payments, and reduced bookings. Customers are approaching Synopsys to “help them right now through this downturn”, i.e. to reduce their cost of software. It looks like the recession is finally catching up to them.

As I finish off this post on Thursday morning, it looks like the analysts agree. Synopsys shares are down 10%, so it seems they are getting punished for revising their forecast. 

Still, Synopsys is in very good financial health, with $877M in cash and short term investments. Their cash flow is going to go down the rest of the year, so they will eat into this fund, but they will still have plenty to selectively acquire strong technology that might add to their portfolio, as they did with the MIPs Analog Business Group.

Themes

There were 2 themes or phrases that kept recurring in the call that I am sure were points of emphasis for Aart.

First, the word “momentum” was used 6 times (by my count) during the call. Technology momentum. Customer momentum. Momentum in the company. Clearly, Synopsys is trying to portray an image of the company building up steam while the rest of the industry wallows in the recession.

Second, customers are “de-risking their supplier relationships”, i.e. looking to consolidate with an EDA vendor with strong financials who’ll still be there when the recession ends. Again, Synopsys is trying to portray itself as the safe choice for customers, hoping to woo customers away from less financially secure competitors like Cadence and Magma. This ties in with the flurry of “primary EDA vendor” relationships that Synopsys has announced recently.

The opportunity for Synopsys (and danger for the competition) is to pick up market share during this downturn and it looks like that may be happening as companies “de-risk” by going with the company with the “momentum” and a “extraordinarily strong position”. Or at least that’s the message that Synopsys is sending.

Technology

Aart did rattle off the usual laundry list of technology that he wanted to highlight, including some introduced last year (e.g. Z-route). Of note were the following:

• Multi-core technology in VCS with 2x speedup (is 2x a lot?)
• Custom Designer, which Aart called “a viable alternative to the incumbent” (ya know marketing didn’t pick the word “viable”)
• Analog IP via the MIPS Analog Business Group acquisition, especially highlighting how that complements the Custom Designer product (do I see “design kits” in the future?)
• The Lynx Design System (see my 5-part series)
• IC-Validator (smells like DRC fixing in IC Compiler - Webinar today, I’ll find out more)

__________

In summary, Synopsys had a good quarter, but they have finally acknowledged that they are not immune to the downturn and they expect to get impacted the next few quarters.

harry the ASIC guy

Last Thursday, the same day that Synopsys announced it’s acquisition of MIPS’ Analog Business Group (ABG) for $22M in cash, I had a long overdue lunch with a former colleague of mine at Synopsys. We spent most of the time talking about family, and how each other’s jobs were going, and the economy, and the industry in general.

At some point, the discussion got around to Aart DeGeus and his leadership qualities. My friend, who plays bass guitar with Aart on occasion, shared with me his observations of Synopsys’ CEO outside of work. “He’s a born leader, even when he’s playing music,” my friend said as he related one story of how Aart lead the band in an improvisational session with the same infectious enthusiasm he brings to Synopsys. Here’s a look.

While driving back from lunch, I recalled a field conference from the mid 1990s where Aart introduced the notion of “Synopsys 2″. Synopsys 2 was to be a new company (figuratively, not literally) that would obsolete Synopsys 1 and take a new leadership role in a transforming industry. At that time, Synopsys 1 was the original “synthesis company” along with some test and simulation tools. The industry challenge driving Synopsys 2 was the need for increased designer productivity to keep up with chip sizes increasing due to the inexorable and ubiquitous Moore’s Law.

Aart’s vision for this new EDA order was twofold. First, behavioral synthesis would allow designers to design at a higher, more efficient, and more productive level of abstraction, thereby increasing their productivity. In fact, your’s truly helped develop and deliver the very first DAC floor demo of Behavioral Compiler. I also developed a very simple but elegant presentation of the power of behavioral synthesis that was used throughout Synopsys, garnered the praise of Aart himself, and sits in my desk as a memento of my time at Synopsys. Unfortunately, behavioral synthesis never really caught on at the time. Oh well. So much for that.

The second part of Aart’s productivity vision was design reuse. Needless to say, that vision has come true in spades. I don’t have reliable numbers at my finger tips, but I would guess that there is hardly a chip designed without some sort of implementation or verification IP reuse. Some chips are almost entirely reusable IP, with the only custom logic stitching it all together. I can’t imagine designing 100M gate chips without design reuse.

Design teams looking for digital IP were faced with a straightforward make vs. buy decision. On the one hand, most design teams could design the IP themselves given enough time and money. They could even prototype and verify the IP via FPGA protoytype to make sure it would work. But could they do it faster and cheaper than buying the IP and could they do it with a higher level of quality? The design team that decided they could do a better, faster, cheaper job themselves, did so. The others bought the IP.

But analog and mixed signal IP is very different. Whereas most design teams have the skills and ability to design digital IP, they usually do not have the expertise to design complex analog and mixed signal IP. Not only are analog designers more scarce, but the problem keeps getting harder at smaller geometries. Ask any analog designer you know how hard it is to design a PLL at 65 nm or 45 nm. What were 4 corner simulations at 90nm become 16 corner or even monte-carlo simulations at 45 nm and below. Not only is analog design difficult, but it often requires access to foundry specific information only available to close partners of the foundries. And even if you can get the info and design the IP, there is no quick FPGA prototype to prove it out. You need to fab a test chip (which is several months), complete with digital noise sources to stress the IP in its eventual environs. The test chip can cost several million dollars (much more than an FPGA protoype for digital IP) and you’d better count on at least one respin to get it right.

That is why Synopsys’ acquisition of the MIPS ABG IP is such a good move. The “value proposition” for analog IP is so much greater than for digital IP. It’s not a matter of whether the customer can design the IP faster, better, cheaper, it’s whether he can design it at all. By expanding its analog IP portfolio, at a bargain price, Synopsys is well positioned to provide much of the analog and mixed signal IP at 65 nm and below. In addition, this acquisition gives Synopsys a real analog design team with which they can perform design services, something they have coveted but lacked for some time.

Once again, it looks like Aart is taking the leadership role. Look for other companies to follow the leader.

harry the ASIC guy

About a month and a half ago, I wrote a 5 part series of blog posts on the newly introduced Lynx Design System from Synopsys:

• 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
• Part 5 - The Mising Lynx - The ASIC Cloud

One key feature, the inclusion of pre-qualified technology and node specific libraries in the flow, was something I had pushed for when I was previously involved with Lynx (then called Pilot). These libraries would have made Lynx into a complete out-of-the-box foundry and node specific design kit … no technology specific worries. Indeed, everyone thought that it was a good idea and would have happened had it not been for resistance from the foundries that were approached. Alas!

In the months before the announcement of Lynx, I heard that Synopsys had finally cracked that nut and that foundry libraries would be part of Lynx after all. Whilst speaking to Synopsys about Lynx in preparation for my posts, I asked whether this was the case. Given my expectations, I was rather surprised when I was told that no foundry libraries would be included as part of Lynx or as an option.

The explanation was that it proved too difficult to handle the many options that customers used. High Vt and low Vt. Regular and low power process. IO and RAM libraries from multiple vendors like ARM and Virage. Indeed, this was a very reasonable explanation to me since my experience was that all chips used some special libraries along the way. How could one QA a set of libraries for all the combinations? So, I left it at that. Besides, Synopsys offered a script that would build the Lynx node from the DesignWare TSMC Foundry Libraries.

Two weeks ago, at the TSMC Technology Symposium in San Jose, TSMC announced their own Integrated Sign-off Flow that competes with the Lynx flow, this one including their libraries. Now it seems to make sense. TSMC may  have backed out of providing libraries to Synopsys to use with Lynx since they were cooking up a flow offering of their own. I don’t know this to be a fact, but I think it’s a reasonable explanation.

So, besides the libraries, how does the TSMC flow compare to the Synopsys Lynx flow? I’m glad you asked. Here are the salient details of the TSMC offering:

• Complete RTL to GDSII flow much like Lynx
• Node and process specific optimizations
• Uses multiple EDA vendors’ tools  (Synopsys mostly, but also Cadence, Mentor, and Azuro)
• Available only for TSMC 65nm process node (at this time)
• No cost (at least to early adopters … the press release is unclear whether TSMC will charge in the future)
• And of course, libraries are included.

In comparison to Synopsys’ Lynx Design System, there were some notable features missing from the announcement:

• No mention of anything like a Management Cockpit or Runtime Manager
• No mention of how this was going to be supported
• No mention of any chips or customers that have been through the flow

To be fair, just because these were not mentioned, does not mean that they are really missing, I have not seen a demo of the flow or spoken to TSMC (you know how to reach me) and that would help a lot in evaluating how this compares to Lynx. Still, from what I know, I’d like to give you my initial assessment of the strength of these offerings.

TSMC Integrated Signoff Flow

• The flow includes EDA tools from multiple vendors. There is an assumption that TSMC has created a best-of-breed flow by picking the tool that performed each step in the flow the best and making all the tools work together. Synopsys will claim that their tools are all best-of-breed and that other tools can be easily integrated. But, TSMC’s flow comes that way with no additional work required. (Of course, you still need to go buy those other tools).
• Integrated libraries, as I’ve described above. Unfortunately if you are using any 3rd party libraries, you’ll need to integrate them yourself it seems.
• Node and process specific optimizations should provide an extra boost in quality of results.
• Free (at least for now)

Synopsys Lynx Design System

• You can use the flow with any foundry or technology node. A big advantage unless you are set on TSMC 65nm (which a lot of people are).
• Other libraries and tools are easier to integrate into the flow I would think. It’s not clear whether TSMC even supports hacking the flow for other nodes.
• Support from the Synopsys field and support center. Recall, this is now a full fledged product. Presumably, the price customers pay for Lynx will fund the support costs. If there is no cost for the TSMC flow, how will they fund supporting it? Perhaps they will take on the cost to get the silicon business, but that’s a business decision I am not privy to. And don’t underestimate the support effort. This is much like a flow that ASIC vendors (TI, Motorola/Freescale, LSI Logic), not foundries, would have offered. They had whole teams developing and QA’ing their flows. And then they would be tied to a specific set of tool releases and frozen.
• Runtime Manager and Management Cockpit. Nice to have features.
• Been used to create real chips before. As I’d said, the core flow in Lynx dates back almost 10 years and has been updated continuously. It’s not clear what is the genesis of the new TSMC flow. Is it a derivative of the TSMC reference flows? Is it something that has been used to create chips? Again, I don’t know, but I’ve got to give Synopsys the nod in terms of “production proven”.

So, what do I recommend. Well, if you are not going to TSMC 65 nm with TSMC standard cell libraries, then there is not much reason to look at the TSMC flow. However, if you are using the technology that TSMC currently supports, the appeal of a turnkey, optimized, and FREE flow is pretty strong. I’d at least do my due diligence and look at the TSMC flow. It might help you get better pricing from TSMC.

If anyone out there has actually seen or touched the TSMC flow, please add a comment below. Everyone would love to know what you think first hand.
harry the ASIC guy

Rumors are flying concerning some big changes next week in EDA amongst the big players. It first got started by John Blyler on Twitter. Then Magma stock took off this week for no apparent reason. And rumors of a Cadence-Magma merger have been flying around for about a month since Rajeev denied them.

Something may happen or nothing may happen. But it’s always fun to speculate. So, what do you think would be the best merger of the top 4 EDA companies?

Vote here or feel free to leave your comments below. We’ll see who, if anyone, is right

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

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