Mentor Graphics: All your apples in one boat?

Thank You

I disagree... if you look at the global problem for things like placement, etc they are not linear, right. But if you apply a hueristic to it and can linearize it over a small subset, than that is the same thing. Divide and conquer. Take PNR. If you place a design flat, ya it doesn't grow linearly. But if you partition it and run the partitions in parallel then you can get linear growth by running all partitions in parallel and then just dealing with the corner cases. This is something we've all been doing for years with a hierarchical design style. Taking a chip and PNRing it as a group of spacially diverse blocks greatly speeds up runtime as you don't get hit by the high end "non linear" growth problem. DRC is the same way, even better, as the interactions are not nearly as nasty as placement... the partitioning is done for you, just do it spacially if you want (or if you are smarter spacially across hierarchy). The only corner cases are halo rules (for example, metal density) at the boundaries. Yes, at some point you get diminishing returns, but DRC has been shown to be able to scale fairly nicely (see my post at ESNUG) if implemented properly. Ya, it might not scale linearly to 1000 CPU, but if you look at the subset of what people might want to run, then its "damned near linear". Plus, at some point do you want to add 100 more CPUs to go from 30 minutes to 15 minutes?

Mike, I see your point and I admit I reacted in a knee-jerk fashion. In general,from editors like You and John Cooley I expect less exaggeration and more real data. The newsletter from EDA companies are already, pretty good at exaggeration!!! Another comment, which is all marketing and no truth is "The company cites benchmarks that indicate the parallel architecture offers run times that increase in a linear fashion with the size of the design". If the run time scales linearly with design size, that means all of their algorithms that process the design, have linear time-complexity. I am not sure if any EDA algorithm runs in *linear fashion*. -Developer (who does not work for mentor)

Mike, As much as the experience was somewhat akin to taking a 2x4 upside the head, I enjoyed reading your post. Definitely provocative and I?m sure it is thought provoking for your readers. That said, I?m sure you won?t be surprised to hear I have a couple of comments. First off, anyone who finds it surprising that Calibre is important to Mentor Graphics needs to take all the sharp objects off of their desk, put them in the trash, call security, and step away until someone comes to remove the trash. Of course Calibre?s important to Mentor as it is the leading solution in the industry attacking DFM and has had a growth rate commensurate with the importance of the problem. I?ll admit to getting lost in the twist of logic that then essentially says, ?Because it is important to Mentor, it isn?t important to the industry.? Huh? The only reason Calibre is important to Mentor is because it is important to the industry. Over 800 logos have purchased the product, we accumulate around 25 new ones every quarter, and there are few designs in the world that don?t get touched by Calibre at some point in the transition from design to silicon. Paul Ranko?s comments in a previous post give a great example of why what we have done is news-worthy as they completely miss the point of the nmDRC release. The engineers that wrote the first line of Calibre also wrote this re-architecture. Rather than a complete re-write of the code-base, this was a very innovative architectural twist that enabled us to keep the same quality while radically changing performance characteristics. Instead of declaring that this is a new product and telling all of our users to buy it if they want it, we are releasing this as an enhancement available to all users on support. And rather than a buggy dot zero release, even the beta has been incredibly stable, with just one bug found to date that was introduced by the implementation of the architecture. Finally, instead of requiring our users to re-write their entire infrastructure to take advantage of the performance advantages of the new architecture, we are backwards compatible with the old rule files, having deprecated only one relatively obscure operation. All of this implemented as the core of a DFM platform that takes the issue well beyond DRC. There?s no doubt I have my agenda; there?s no doubt this success of this product is in Mentor?s and my best interest; there is also no doubt that this is important to the industry. I?m looking forward to reading more posts like this from you. It would be ok if it isn?t about us for a while.  Joe Sawicki Vice President and General Manager Design to Silicon Division (aka Calibre)

"I'm sure it isn't an easy feat reworking a tool so that it runs faster and has a higher capacity, but essentially you hear that in any and all EDA upgrade releases." I think you are wrong in "essentially you hear that in any and all EDA upgrades". I am myself an EDA developer for a long time, and this is simply not true.