It’s been widely reported that for every $1 spent on EDA tools that the users end up spending another $3 to make the flow of tools work together. This means job security for CAD groups however it’s a drain on the budget and slows down productive design work.
Synopsys just announced something called L y n x Design System that addresses this issue of managing EDA tools flows, for both Synopsys and other tools.
You get three basic technologies with L y n x:
* Runtime Manager
* Management Cockpit
* Foundry Checks
This is a good idea and has been around for over a decade. At Viewlogic in the 90’s we offered this kind of product, Mentor had this with the infamous 8.0 Falcon Framework release, and every FPGA tool vendor today offers a pre-packaged flow.
My big unanswered question is one of pricing. Like Cadence it appears that Synopsys will require that you call an Account Manager (sales person) to get a price quote. I’d say that L y n x is worth about $15-50K.
CAD groups will now have to consider whether they should cobble together their own flow or just use the L y n x Design System instead.
You may have to purchase some consulting time from Synopsys to get L y n x up and running faster than by reading the manual and blazing your own trail.
On a pure marketing note, why didn’t Synopsys trademark their new product name?
This sounds oddly like the Frameworks that were rejected by the industry 20 years ago.
I must be getting old. I feel like I’ve seen everything before.
Ray,
It’s not really a framework, rather it steers you through the complex sequence of tools that need to be run, taking into account file dependencies. Could be Synopsys plus non-Synopsys tools in the flow.
Traditionally the Synopsys tools have been command line driven for text-thinking geeks, with L ynx we now have something graphical to use in managing the flow.
What about using requirements and scripting the process with Make and Perl? I guess i am getting old too.
Michael,
Yes, Make and Perl are wonderful tools and serve the software development community quite well. They also require a high degree of skill to implement, debug and extend when a new tool becomes available.
I think that this L ynx system makes it easier for anyone to create and update a tool flow. It really comes down to price and the make versus buy decision that any CAD group faces.
I believe that with a central CAD team (that does the “glue” work) the ratio is not that bad – maybe 1:1 or worst case 1:2. I doubt that an offering like L y n x – one size fits all – is applicable for bigger shops; again, even such a pre-defined “flow” would need significant customization for the specific product lines. And, what is often forgotten, such a tool has to fit to the company’s IT ecosystem – OS platforms, load balancing, and(!) configuration management. So unless L. is either _very_ well architectured so that it runs on virtually any platform (Windows, Linux, Solaris, …) and offers the hooks to plug in your job management system (Sun Grid, LSF, Runtime, …) and your config management (version control: ClearCase, ClioSoft, DesignSync, IC Manage, Subversion, …) – or – Synopsys offers a very attractive setup service with the product, I believe that you are better off setting up your own flow; ideally based on open technologies like Perl, Tcl and GNU make that allow all kinds of other integrations (databases, web, …).
What about design / revision management – This is a huge problem!
ironic
I shared fully Marek’s comments.
Moreover I see another important parameter to look at in : Dependencies wrt EDA Vendor.
While design house are already dependant on EDA Vendor for their EDA Tools (therefore their database -see note below – and other aspects), is it good for them to add another dependency on top of that i.e on the “flow” glue ?
It is already diffcult for Design House to get from EDA Vendor the right attention wrt to their requirement for current tooling, will it be efficient also to get their attention to the “glue” itself.
(currently I have not much insight on L_, could be a very stable and plug&play tool – no vendor services absolutely required to customize, to plug into your IT system)
My opinion is that if EDA Vendors want to help Deisgn house for the flow then we should start from the backbone and not from glue.
and the backbone is “open design database”. (OpenAcess or whatever prioritary format’s DB with a public complete and performant API. question : Is TCL an API language or is it C/C++ ?)
and standard import/export format.
Next step beyond Open design database is open engine (SOA?).
This sounds like a tool that has been around for a long time – Run-time Design Automation had a tool called FlowTracer that was a dependence aware flow tool. It used TCL and the basic framework and integrated data and tools into a graphical diagram that would track dependencies… Not old, just seen it before.
Rick,
You’re right on that point, many smaller companies have offered flow automation tools it just takes the bigger EDA companies awhile to see the light or risk making an investment.
Synopsys has a webcast on this: http://w.on24.com/r.htm?e=145260&s=1&k=EBB1A2D19F5DD661DE16508EAD93B52B
The webcast wouldn’t work in FireFox even with the latest Real Player, it would only work for me in IE using Windows Media Player. Maybe it has something to do with my 64 bit Vista OS.