Azuro discusses Rubix tool

Azuro's Rubix tool is a middle path between conventional RTL design and the idealised but often impractical world of self-timed logic.

Rubix works by identifying what Azuro chief executive officer Paul Cunningham calls chains: paths that start at an input or at a junction where feedback enters the path, and continue until they reach an output or a feedback junction.

The tool then traverses these chains, watching the path delays between each pair of registers in the chain.

It then starts with the largest path delay - the critical path - in the chain.

It looks at the delay on the path preceding the critical one, and if there is slack, it skews the clock on the register at the beginning of the critical path to arrive early, using up some of the available slack.

Then it looks at the path after the critical one.

If there's slack there, Rubix delays the clock to the register at the end of the critical path.

The result of these two intentional clock skews is that there is now more than one clock period available for signals to traverse the critical path.

The clock can now be turned up a bit and still meet timing.

Once slack has been created in what was the critical path, the new critical path is found, and this action repeated, until all possible slack in the chain has been used.

The bottom line, says Cunningham, is that after this optimisation the maximum clock frequency is set by the average path delay in a chain, not the maximum path delay.

With no impact on the logic, the output of the physical synthesis tool, or the downstream analysis or place-and-route tools, fmax can be improved by up to 30 per cent.

The Rubix tool runs more or less automatically, so there is little required of the user beyond understanding what is going on.

The process is far less problematic than trying to generate balanced clock trees, Cunningham says, especially in the light of the added complexities of clock tree optimisation below 90 nm.

For instance, Rubix could reduce the clock network's sensitivity to random variations by spreading slack around among the paths.

There are a few complexities, some of which Rubix deals with and some of which are left to the user.

One problem, which required a lot of development time on the tool, is that if the user is not careful, it can be hard to keep the clock network from growing rapidly as the optimisation process is carried out, Cunningham said.

Recognising how to produce all necessary clock skews, in the correct places, without creating excess power dissipation or congestion in the clock nets is also addressed by Rubix.

One issue left partially to the user is design-for-test.

'Not having balanced clock trees can mess up scan-chain stitching,' Cunningham said.

'So we included a scan-chain reordering capability in Rubix.

Apparently, this process requires some intervention, and obviously it would impact downstream test insertion or DfT design operations late in the flow.

For the future, Cunningham speculates that Rubix could be used to achieve a greater fmax on a given design, and to create enough slack at a given frequency to allow turning down the supply voltage, making significant savings in dynamic and static power.

Rubix has been in the hands of some early users for some time now, and is scheduled for general availability this month.

Back to top