Open side-bar Menu
 Real Talk

Posts Tagged ‘x-propagation’

Fix X-pessimism in Netlists with Practical Techniques

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…)

The Switch from Atrenta to Real Intent for CDC, Lint, and X-prop

Thursday, May 12th, 2016

John Cooley’s Deepchip.com web-site likes to publish end-user experience with various EDA tools.  On May 6, he published a posting on why a designer switched from Atrenta SpyGlass to Real Intent for CDC, Lint, and X-propagation analysis.  His report details the reasons for converting to our best-in-class tool suite.

Here is the first part of the posting:

We had been using SpyGlass from Atrenta, and it worked OK for us, but we
were told by our local Real Intent sales guy that “there would be fewer
iterations for Lint, easier setup for CDC, lower-noise reporting, and
faster runtimes” — if only we evaled his tools.

REAL INTENT MERIDIAN CDC VS. ATRENTA SPYGLASS CDC

I spent one work week (5 days) evaluating Meridian CDC. We used different
designs to evaluate this tool. The first was 850K gate design that had
3 asynchronous clock domains. For the analysis setup, Meridian CDC
automatically detected all the clock/reset candidates correctly at block-
level as well as the top-level. No additions were needed for the setup
file, while our Spyglass run did require manual editing of the setup.
The Meridian runtime for this block was ~5 minutes.

The second design was 4 million gates and had 5 asynchronous clock domains.
Again the automatic clock/reset detection worked as expected. The runtime
was ~15 minutes.

Read the rest of the report on CDC, lint and X-propagation here.

Have you switched EDA tools recently?  How was that experience?

Verification Coffee Break – Where are We Going?

Thursday, April 14th, 2016

Pranav Ashar, CTO at Real Intent was interviewed in April by SemIsrael, Israel’s leading semiconductor design and development portal, on the latest trends in the world of verification. Below, I have embedded video clips that cover each of the five questions he addressed. You can watch the entire video here.

Q1. What is the current trend driving verification?

(more…)

Exposing and Eliminating X-optimism Bugs in RTL

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…)

On-the-Fly Hardware Accurate Simulation, New Meridian CDC, ASICON Tutorial

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.

(more…)

Correcting Pessimism without Optimism – Part Two

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…)

Correcting Pessimism without Optimism – Part One

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.
(more…)

A Verification Standard for Design Reliability

Thursday, August 13th, 2015

_do-254The great thing about a standard is that once you decide to use it, your life as a designer is suddenly easier.  Using a standard reduces the long list of choices and decisions that need to be made to get a working product out the door.  It also gives assurance to the customer that you are following best practices of the industry.

A standard for the world of aviation electronics (avionics) is the RTCA/DO-254, Design Assurance Guidance For Airborne Electronic Hardware.  It is a process assurance flow for civilian aerospace design of complex electronic hardware typically implemented using ASICs or big FPGAs.  In the USA, the Federal Aviation Administration (FAA) requires that the DO-254 process is followed.  In Europe there is an equivalent standard called EUROCAE ED-80.

At first glance the standard seems daunting. It defines how design and verification flows must be strongly tied to both implementation and traceability. In DO-254 projects, HDL coding standards must be documented, and any project code must be reviewed to ensure it follows these standards.  They address the following issues: (more…)

Reset Expectations with X-Propagation Analysis

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.

(more…)

#2 on GarySmithEDA What to See @ DAC List – Why?

Thursday, May 28th, 2015

The last two weeks before the Design Automation Conference in San Francisco are a busy time.  For us marketeers, it has been called “our Superbowl.”  We want to get the word out that we have something new and important to show visitors to at our exhibit booth.  But there is more going on which I will mention after I talk about our booth activities.

Real Intent is number two on the GarySmithEDA What to See @ DAC list.   I know why we are number two on the list.  But I don’t want to give the secret away. If you know the reason, then please let everyone know in the comments section at the end of the blog.

Here are the quick titles for our technical presentation in our demo suites.

  • Ascent Lint with 3rd Generation iDebug Platform and DO-254
  • Meridian CDC for RTL with New 3rd Generation iDebug Platform
  • Ascent XV with Advanced Gate-level Pessimism Analysis
  • Accelerate Your RTL Sign-off
  • Hierarchical CDC Analysis and Reporting for Giga-gate Designs
  • Next-Generation Meridian Constraints for SDC
  • Autoformal RTL Verification
  • FPGA Sign-off and Verification

Click on this appointment sign-up link to arrange a meeting with us. (more…)

CST Webinar Series



Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy