editor's blog
Subscribe Now

Algorithms or Methodologies?

You see it two to four times a year from each EDA player: “x% Productivity Gains with y Tool!” Cadence recently had such an announcement with their Incisive tool; Synopsys has just had a similar story with FineSim.

As I was talking with the Cadence folks about this, I wondered: How much of this productivity gain comes as a result of engine/algorithm improvements, and how much as a result of methodology changes? The answer is, of course, that it comes from both.

But there’s a difference in when the benefits accrue. Engine improvements are immediately visible when you run the tool. Methodology changes: not so much. And there are actually two aspects to methodology.

The first is that, of course, a new methodology requires training and getting used to. So the first project done using a new methodology will take longer; the next one should be better because everyone is used to the new way of doing things. This is a reasonably well-known effect.

But there may be an extra delayed benefit: some methodology changes require new infrastructure or have a conversion cost. If, for example, you replace some aspect of simulation with a new formal tool, you have to modify your testbench and create the new test procedure from scratch. There may be, for instance, numerous pieces of IP that need to be changed to add assertions. These are largely one-time investments, with incremental work required on follow-on projects.

In this example, it may be that, even with the conversion work, things go faster even on the first project. But productivity will be even better next time, when much of the infrastructure and changes are ready and waiting.

As to the engines, I was talking to the folks at Mentor yesterday, and wondered whether improvements to the tools themselves become asymptotic: does there come a point when you just can’t go any faster? Their answer was, “No,” since there’s always some bottleneck that didn’t used to be an issue until the other bigger bottlenecks got fixed. The stuff that got ignored keeps bubbling up in priority, the upshot being that there’s always something that can be improved to speed up the tools.

Leave a Reply

featured blogs
Jan 17, 2020
I once met Steve Wozniak, or he once met me (it's hard to remember the nitty-gritty details)....
Jan 17, 2020
[From the last episode: We saw how virtual memory helps resolve the differences between where a compiler thinks things will go in memory and the real memories in a real system.] We'€™ve talked a lot about memory '€“ different kinds of memory, cache memory, heap memory, vi...
Jan 16, 2020
While Samtec started as a connector company with a focus on two-piece, pin-and-socket board stacking systems, High-Speed Board Stacking connectors and High-Speed Cable Assemblies now make up a significant portion of our sales. To support development in this area, in December ...
Jan 16, 2020
Betting on Hydrogen-Powered Cars On-demand DRC within P&R cuts closure time in half for MaxLinear Functional Safety Verification For AV SoC Designs Accelerated With Advanced Tools Automating the pain out of clock domain crossing verification Mentor unpacks LVS and LVL iss...

Featured Video

RedFit IDC SKEDD Connector

Sponsored by Wurth Electronics and Mouser Electronics

Why attach a header connector to your PCB when you really don’t need one? If you’re plugging a ribbon cable into your board, particularly for a limited-use function such as provisioning, diagnostics, or testing, it can be costly and clunky to add a header connector to your BOM, and introduce yet another component to pick and place. Wouldn’t it be great if you could plug directly into your board with no connector required on the PCB side? In this episode of Chalk Talk, Amelia Dalton chats with Ben Arden from Wurth Electronics about Redfit, a slick new connector solution that plugs directly into standard via holes on your PCB.

Click here for more information about Wurth Electronics REDFIT IDC SKEDD Connector