Dammy Olopade, verification engineer at Intel, had a grim forecast for delegates during a panel on verification at the recent Design Automation Conference (DAC) in San Diego: "There will be a Titanic before the tides change."

In the mid-1990s, analysts such as industry veteran Gary Smith talked of the design gap that opened up between the capability of chip manufacturing versus what designers could realistically design using languages operating at the standard register transfer level (RTL). Then the semiconductor intellectual property (IP) business got going and designers became used to buying in virtual components from elsewhere.

Suddenly, the design gap closed because the problem was no longer one of "how do I design a million-gate chip?", it was "how do I interleave the new hundred thousand gates this design needs with the IP and, more importantly, how can I be sure it all works?" The design gap turned into the verification gap and it is still with us although its form keeps changing.

The combination of formal verification and large simulation farms has largely put paid to functional bugs - it might take a while to get to the end, but designs should make it to the fab without a showstopping bug even with a large proportion of IP that has to be treated as a black box.

Prakash Narain, CEO of design-tools company Real Intent, said: "The amount of new logic going from one design to the new one is actually very small.
But new failure modes are emerging that are challenging existing verification models. You can have fully verified RTL and still fail."

Two problems have arisen that are causing problems. One is that it takes far longer than a single clock cycle for a signal to cross a chip. The best way to deal with this is to separate the chip into islands of synchronous design and then link them up using asynchronous protocols. "Clocks will disappear gradually," claimed Olopande. "But the EDA industry's asynchronous design tools are not rich enough yet."

There are tools that will check for potential problems where the signals from different clocking domains meet but the bugs can be subtle and hard to find. A more insidious problem comes from the techniques used to reduce power consumption because of the way it can cause discrepancies between simulation and reality.

The problem lies in indeterminate values. When a block powers down, it does not have any state until it fires back up again and starts to operate. Most of the time, this does not matter. But it is very easy for a piece of design written in RTL to assume the state of a connected block and build that into its logic. It might assume that the lack of an input is the same as a 0, which could be a dangerous assumption if it propagates further into the logic block. The trouble is a simulator can make different assumptions to what happens in reality when a synthesis tool takes that construct and reduces it into Boolean logic. A discrepancy between simulation and reality is well on its way to being a showstopping bug.

Normally, the checking for indeterminate or 'X' states is done by hand but Broadcom verification specialist YC Wong pointed out that it takes time to write directed tests for X propagation. "We are trying to use more automation for X propagation tracing," he said.

The result is that bugs are moving into the gaps between the recognisable fragments of the design. No-one realised that the dividers between the Titanic's bulkheads would fail - Olopande's metaphor may be closer to reality than it seems.

Very good blog, I'd love reading this very informative content.

Thank you for posting.

Text

I heard about this conference. And still looking to get more information for this, this post helps a lot. Thank you

Denon 4311

Thank you for this information. I am also waiting for the coming Automation Conference (DAC) on June 3-7, 2012.

Best home theater for me Onkyo TXSR508.