Posts Tagged ‘x-pessimism’
Thursday, June 30th, 2016
Most functional verification is done before the RTL is handed off for digital synthesis. Gate-level simulations take longer and are hard to debug, but still needed to verify some circuit behavior. Ideally, the output of the RTL simulation will match the output of gate-level netlist simulation after synthesis. But that is not typically the case. Besides the obvious things verified in your gate-level simulations, there are always unknown values (Xs). Some will not be seen in the RTL due to X-optimism, but there will be additional Xs in the gate-level simulations due to X-pessimism.
X-optimism in RTL and other generic issues around unknown states are discussed in more detail in the paper ‘X-Propagation Woes – A Condensed Primer‘. Some basic familiarity with the concept is assumed here.
This paper focuses on X-pessimism at the netlist level. It discusses some current techniques and their limitations, and then describes a more efficient X-pessimism strategy based on Real Intent’s Ascent XV. (more…)
Thursday, December 3rd, 2015
X-optimism occurs when an unknown X value is incorrectly resolved to a known value in RTL simulation. Optimism issues can be difficult to detect and debug because the X is no longer visible once the optimism occurs. The functional issue may not show up at an output for many, many clock cycles after the optimism. X-optimism issues also show up in a gate-level netlist or FPGA-based prototypes, but debug is difficult due to limited visibility in FPGAs, and netlist designs are less familiar post-synthesis. Trying to find an X-optimism bug in an FPGA model is like looking for a needle in a haystack due to limited visibility. In netlist simulations the design hierarchy is flattened, signal names changed, and there is a danger that the X under consideration will be mistaken for a pessimistic node and forced to a known value that hides a functional issue.
Real Intent’s Ascent XV uses static analysis to identify potential X-optimism issues at RTL so they can be fixed prior to simulation, ensuring efficient and accurate simulations. Fixing optimism issues in RTL streamlines getting netlist simulations or FPGA-based prototypes, up and running faster and reduces costly iterations. (more…)
Thursday, October 15th, 2015
At the Design Automation Conference in San Francisco, Real Intent did a survey of 201 visitors to our booth. We focused on RTL and gate-level verification issues. Below is a brief introduction and you can see the entire survey on the DeepChip.com web-site.
DAC’15 “When is your next design start?”
0-3 months : ########################################### (52%)
3-6 months : ###################### (26%)
6-12 months: ################## (22%)
These numbers are very similar to what was reported in 2012 on DeepChip. With half of the future design starts occurring in the next 3 months, this leads me to think design activity is remaining strong despite any EDA user consolidation we might have seen with the big mergers of various chip companies, and the slowing of the Chinese economy. However, the latest IC forecast from Gartner has 2015 growth falling from 5.4% at the beginning of 2015 down to 2.2% in July.
Thursday, October 8th, 2015
In this blog, we are presenting the highlights from Real Intent’s Fall 2015 Verification Newsletter. First are some thoughts from Prakash Narain, CEO, followed by an introduction to the new 2015 release of Meridian CDC for clock-domain and reset-domain crossing sign-off, and finally a review of our fall events including an ASICON tutorial.
Thoughts From Prakash Narain, President and CEO…
Most functional verification for SoC and FPGA designs is done prior to RTL hand-off to digital synthesis, since gate-level simulations take longer to complete and are significantly harder to debug. However, gate-level simulations are still needed to verify some circuit behavior. Unfortunately, X’s in gate-level simulations can cause differences in the RTL simulation output and the gate-level simulation output. X’s generally exist in all designs – it can be difficult to prevent this for practical reasons. Simulation results may be different because of X’s that are hidden in the RTL simulation by X-optimism, or additional X’s may exist due to X-pessimism in gate-level simulations. Pessimism can be fixed by overriding the simulator because you know that real hardware would always resolve to a deterministic value. The challenge is confirming that the X value is a result of X-pessimism and not simply X-propagation, and then forcing it to the right value at the right point in time so the simulation matches that of real hardware.
Thursday, October 1st, 2015
Part one of this article focused on the issues of X-pessimism at the netlist level and why the current solutions are inadequate. In In part two, we look at how the Ascent XV tool correctly addresses X-safe verification.
If a node is determined to be 1(or 0) pessimistic, that means its real circuit value is 1(or 0), but simulation produces an X. A pessimistic simulation value can be corrected by forcing a 1(or 0) on the node until the conditions for pessimism no longer hold, at which time, it is released. This does not mean that all X’s can be arbitrarily forced to a known value. Only X’s that result from pessimism should be forced, and they must be forced to represent the deterministic value that real hardware would see and released immediately when the pessimism stops.
Ascent XV-netlist makes your simulation hardware accurate by appropriately correcting pessimism. Ascent XV statically identifies the potentially pessimistic nodes and then uses that information to create SimPortal files that augment gate-level simulation to correct X-pessimism on the fly. By doing the analysis statically before the simulation starts, the number of nodes that must be analyzed during simulation is significantly reduced. Also, the X-analysis during simulation can be reduced to a table look-up when the potentially pessimistic node has an X-value. The SimPortal files monitor the potentially pessimistic nodes in the design on the fly, independent of the testbench. (more…)
Thursday, September 24th, 2015
Most functional verification for SoC and FPGA designs is done prior to RTL hand-off to digital synthesis because gate-level simulations take longer to complete and are significantly harder to debug. However, gate-level simulations are still needed to verify some circuit behavior. Ideally, the output of the RTL simulations will match the output of gate-level netlist simulations on the same design after synthesis. And why wouldn’t they? Besides the obvious things that are being verified in your gate-level simulations, there are also unknown values (X’s) that were not seen in RTL due to X-optimism, and additional X’s in the gate-level simulations due to X-pessimism. Part one of this article focuses on the issues of X-pessimism at the netlist level and why the current solutions are inadequate.
Thursday, June 25th, 2015
The propagation of unknown (“X”) states has become a more pressing issue with the move toward billion-gate SoC designs, and especially so with power-managed SoC designs. The SystemVerilog standard defines an X as an “unknown” value used to represent the state in which simulation cannot definitely resolve a signal to a “1,” a “0,” or a “Z.”
Synthesis, on the other hand, defines an X as a “don’t care,” enabling greater flexibility and optimization. Unfortunately, Verilog RTL simulation semantics often mask the propagation of an X value, while gate-level simulations show additional Xs that will not exist in real hardware.
The sheer complexity and common use of power management schemes increase the likelihood of an unknown “X” state in the design translating into a functional bug in the final chip. This possibility has been the subject of two technical presentations at the Design and Verification Conference during the last couple of years: I’m Still in Love With My X! But, Do I Want My X to Be an Optimist, a Pessimist, or Eliminated? and X-Propagation Woes: Masking Bugs at RTL and Unnecessary Debug at the Netlist. Let’s look more closely at this issue and the requirements for a solution.
Thursday, April 9th, 2015
In a recent blog, Does Your Synthesis Code Play Well With Others?, I explored some of the requirements for verifying the quality of the RTL code generated by high-level synthesis (HLS) tools. At a minimum, a state-of-the-art lint tool should be used to ensure that there are no issues with the generated code. Results can be achieved in minutes, if not seconds for generated blocks.
What else can be done to ensure the quality of the generated RTL code? For functional verification, an autoformal tools, like Real Intent’s Ascent IIV product can be used to ensure that basic operation is correct. The IIV tools will automatically generate sequences and detect whether incorrect or undesirable behavior can occur. Here is a quick list of what IIV can catch in the generated code:
- FSM deadlocks and unreachable states
- Bus contention and floating busses
- Full- and Parallel-case pragma violations
- Array bounds
- Constant RTL expressions, nets & state vector bits
- Dead code
Designers are are also concerned about the resettability of their designs and if they power-up into a known good state. (more…)