Open side-bar Menu
 Real Talk

Posts Tagged ‘reset analysis’

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.


High-Level Synthesis: New Driver for RTL Verification

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

dffDesigners are are also concerned about the resettability of their designs and if they power-up into a known good state.  (more…)

S2C: FPGA Base prototyping- Download white paper

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