In 1999, the movie Blast from the Pastwas released. It begins in Los Angeles in the 1960s, during the Cold War era. In this movie, a nerdy, engineering-type father was afraid of a potential conflict involving nuclear arms. He built a personal, massive fall out shelter/apartment underneath his home. No less than the great Christopher Walken of cowbell fame played the father!
To make a long story short, an airplane crashed in the neighborhood and the father thought this meant that a nuclear bomb had been dropped. He took his pregnant wife with him downstairs and activated a timer that locked the shelter door for 30 years.
During that time, his wife gave birth to a son, played by Brendan Fraser of The Mummy fame, who was deliberately named Adam. After 30 years Adam leaves the shelter and explores Los Angeles, which by then is in the 1990s, and it is both very scary and very exciting for him. After a while, he meets a girl, called Eve, of course, and played by Alicia Silverstone of Clueless fame.
When Adam and Eve meet, Eve experiences a massive blast from the past because Adam exposes her to the culture and worldview of the 1960s.
In today's engineering world, we face many blasts from the past as well. For example the original hardware description languages (HDLs) were developed in the 1980s. They allow for multiple events to occur in a single time slice.
The consequence of this freedom was that EDA vendors, in particular simulation vendors, could make a judgment call in implementing features of the language where specific behavior was simply not stringently defined.
Expect the unexpected
This can lead to situations where identical HDL code leads to different results between different simulators. The use of proper coding style and using proper constructs can avoid the bulk, if not the entire problem. But we all know that this is more of an idealistic view of the world, rather than a practical view, when it comes to computer languages.
One of the biggest complications is the occurrence of race conditions and zero time glitches. In practice, you might logically expect a certain value for a signal, but you might get something totally unexpected.
Even when you analyze the signal’s value transition in a waveform display tool, you might find yourself in a totally alien world. However, if you are a Cadence customer, you are in luck, because we have tools for interpreting that world.
When you probe a signal during a simulation, by default you only get an abstracted view of the world—you see the outcome of the logic evaluation of the simulator. This is done because it makes the waveform database much smaller, and accesses to it much faster, but it records viewer details.
This is OK in most cases because hopefully, you have very few race conditions.
However, with the Incisive simulator we can probe with higher level of granularity and also record the low-level events that occur before the final value of a signal is determined. In this case we use the event switch when creating the waveform database.
Once you record your signal transitions in this way, you get the lowest level details, which you can then use to determine where the races or glitches originate. Figure 1 shows that multiple events occurred between the values of fifty and idle using the yellow one-shot symbol.
Figure 1
Clearer picture
You can then expand the so-called sequence time and you may see that a signal in between a clock rise or fall event will not just go from 0 to 1, or vice-versa, or even stay the same value! Figure 2 shows the events of the transition. In it you can see exactly what happens in between the signal value change.
Figure 2
More importantly, you can see how the driving signals that affect the signal of interest move through different values before they settle.
Be aware, that although this looks like a delay in the waveform display, it actually is not. Here, we are referring to RTL-level simulation, and what you see are the transitions during signal evaluation that are determined by the simulator.
Debugging race conditions and glitches can be rather tricky. However, with the help of the event recording granularity built into the Incisive simulator, you can actually see what is going on and determine the root cause. Most often you will then recode your logic to eliminate the race so that your simulation will actually do what you expect. And remember the simulation does not violate the LRM.
For more information see the product manual Viewing Events in Sequence Time and the associated video that walks your through the process.
Keep your code clean and get rid of those race conditions and glitches!
Axel Scherer
Twitter: @axelscherer
.