Weird things can happen during a presentation to a customer!
I was visiting a customer site giving an update on the latest release of our Ascent and Meridian products. It was taking place during the middle of the day, in a large meeting room, with more than 30 people in the audience. Everything seemed to be going smoothly.
Suddenly there was an uproar, with clapping and cheers coming from an adjacent break room. Immediately, everyone in my audience opened their laptops, and grinned or groaned at the football score.
The 2014 FIFA World Cup soccer championship game was in full swing!
As Germany scored at will against Brazil, I lost count of the reactions by the end of the match! The final score was a crushing 7-1.
It disturbed my presentation alright, but it also gave me some food for thought.
If I look at SoC design as a SoCcer game, the bugs hiding in the design are like potential scores against us, the chip designers. We are defending our chip against bugs. Bugs could be related to various issues with design rules (bus contention), state machines (unreachable states, dead-codes), X-optimism (X propagating through x-sensitive constructs), clock domain crossing (re-convergence or glitch on asynchronous crossings), and so on.
Bugs can be found quickly, when the attack formation of our opponent is easy to see, or hard to find if the attack formation is very complex and well-disguised.
It is obvious that more goals will be scored against us if we are poorly prepared. The only way to avoid bugs (scores against us) is to build a good defense. What are some defenses we can deploy for successful chips?
We need to have design RTL that is free from design rule issues, free of deadlocks in its state machines, free from X-optimism and pessimism issues, and employs properly synchronized CDC for both data and resets and have proper timing constraints to go with it.
Can’t we simply rely on smart RTL design and verification engineers to prevent bugs? No, that’s only the first line of defense. We must have the proper tools and methodologies. Just like, having good players is not enough; you need a good defense strategy that the players will follow.
If you do not use proper tools and methodologies, you increase the risk of chip failure and a certain goal against the design team. That is like inviting penalty kick. Would you really want to leave you defense to the poor lone goal keeper? Wouldn’t you rather build methodology with multiple defense resources in play?
So what tools and methodologies are needed to prevent bugs? Here are some of the key needs:
- RTL analysis (Linting) – to create RTL free of structural and semantic bugs
- Clock domain crossing (CDC) verification – to detect and fix chip-killing CDC bugs
- Functional intent analysis (also called auto-formal) – to detect and correct functional bugs well before the lengthy simulation cycle
- X-propagation analysis – to reduce functional bugs due to unknowns X’s in the design and ensure correct power-on reset
- Timing constraints verification – to reduce the implementation cycle time and prevent chip killer bugs due to bad exceptions
Proven EDA tools like Ascent Lint, Ascent IIV, Ascent XV, Meridian CDC and Meridian Constraints meet these needs effectively and keep bugs from crossing the mid-field of your design success.
Next time, you have no excuse for scores against you (i.e. bugs in the chip). You can defend and defend well using proper tools and methodologies.
Don’t let your chips be a defense-less victim like Brazil in that game against Germany! J