Block reuse to speed up chip-level timing analysis

Synopsys has reworked its PrimeTime static timing analysis tool to speed up full-chip analyses by making better use of the block-level runs performed earlier in development.

Robert Hoogenstryd, director of marketing for design analysis and sign-off tools at Synopsys, said the growing density of system-on-chip (SoCs) has pushed customers into running full-chip analyses using simple models of blocks that can introduce inaccuracies and problems during sign-off. A further problems lies in the way that timing constraints are expressed at the block and at the full-chip level.

“Customers want one set of constraints,” said Hoogenstryd. “In reality, the constraints they are using for static timing analysis and during design are different. Sometimes, people over-constrain the synthesis tool because they want to make it work harder on a part of the block.”

If these over-tight constraints are passed to the full-chip analysis, it may result in a design that appears to miss timing when, in reality, it is working fine. The context is also important as a path within a block may be designed to have no more than 3ns of delay. However, within the context of the full chip, it may help the design complete if the budget can be moved by hundreds of picoseconds in either direction, particularly if the boundaries of the block are not clocked registers but feeding in and out of combinatorial logic in an adjacent block.

The use of models in full-chip analysis compounds the problem of remaking timing budgets because, in many cases, they are simple tables of results built from a block-level analysis and so cannot be used to work out of the block could meet a revised budget. However, these models massively speed up execution.

Hoogenstryd said improvements in algorithms have provided a seven-fold speedup in execution “but eventually that runs out of steam”.

“We decided to take a step back and ask what else can we do to leverage the fact that people are doing these designs hierarchically,” he said.

The new version of PrimeTime works around the problem by storing information from block-level analyses in a database and referring to them during full-chip analysis for blocks that do not need to be re-analysed.

“Our typical experience is that customers are running lots of block-level static timing analyses so why not exploit all that data?” said Hoogenstryd. “At the full-chip level you don’t have to rerun everything you have done at the block level.”

To allow block-level analyses to be reused, the constraints can be marked so that they only apply at the block level and so are not promoted to full-chip level if they are not appropriate. This also allows constraints that are only appropriate for full-chip analysis to be fed in at an early stage.

Ken Rousseau, vice president of engineering for PrimeTime R&D, said: “One of the exciting things about this is that you can trade off between visibility and runtime efficiency. If you use data representations, it runs really fast. But if one part is difficult, you can run that flat at the top level and use representations for the other blocks.”

Rousseau said the ability to move easily between representations can help with rebudgeting. “If the designer can work at the top level, they can give a path a little more slack.”

By using the database to find path timings, the tool can achieve a tenfold speedup over a flat analysis, Hoogenstryd claimed, and use a lot less memory to store the design. 

Recent articles

Info Message

Our sites use cookies to support some functionality, and to collect anonymous user data.

Learn more about IET cookies and how to control them