Open side-bar Menu
 Real Talk

Posts Tagged ‘netlist’

How Physical Implementation Can Break Your Clock-Domain Crossing Logic

Thursday, March 31st, 2016

At DVCon’16, Mark Litterick presented a paper and presentation on “Full Flow Clock Domain Crossing – From Source to Si.”   Here is the abstract for the paper:

Functional verification of clock domain crossing (CDC) signals is normally concluded on a register-transfer level (RTL) representation of the design. However, physical design implementation during the back-end pre-silicon stages of the flow, which turns the RTL into an optimized gate-level representation, can interfere with synchronizer operation or compromise the effectiveness of the synchronizers by eroding the mean time between failures (MTBF). This paper aims to enhance cross-discipline awareness by providing a comprehensive explanation of the problems that can arise in the physical implementation stages including a detailed analysis of timing intent for common synchronizer circuits.

Mark works for Verilab as senior verification consultant and holds the position of fellow. He is based in Munich, Germany.  To see more of Mark’s technical papers, check out his profile page on the Verilab web-site.

Even though, you may have signed-off for CDC at RTL, logic synthesis, design-for-test and low-power optimization tools can break CDC at the gate-level, the physical implementation stage of design. Real Intent’s Meridian products provide clock-domain crossing verification and sign-off.  Our most recent offering is Meridian Physical CDC and provides sign-off at the netlist level of the design.  It uses a mix of structural and formal methods to identify  glitching and other errors that break the correct registration of signals crossing clock domains. (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.

Technology Errors Demand Netlist-level CDC Verification

Thursday, July 30th, 2015

Multiple asynchronous clocks are a fact of life on today’s SoC. Individual blocks have to run at different speeds so they can handle different functional and power payloads efficiently, and the ability to split clock domains across the SoC has become a key part of timing-closure processes, isolating clock domains to subsections of the device within which traditional skew-control can still be used.

As a result, clock domain crossing (CDC) verification is required to ensure logic signals can pass between regions controlled by different clocks without being missed or causing metastability. Traditionally, CDC verification has been carried out on RTL descriptions on the basis that appropriate directives inserted in the RTL will ensure reliable data synchronizers are inserted into the netlist by synthesis. But a number of factors are coming together that demand a re-evaluation of this assumption.

A combination of process technology trends and increased intervention by synthesis tools in logic generation, both intended to improve power efficiency, is leading to a situation in which a design that is considered CDC-clean at RTL can fail in operation. Implementation tools can fail to take CDC into account and unwittingly increase the chances of metastability. (more…)

DownStream: Solutions for Post Processing PCB Designs
Verific: SystemVerilog & VHDL Parsers
TrueCircuits: IoTPLL

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