Every year, Forbes publishes a list of the Best Companies To Work For. The winners are always big companies, ones well known by you and me. The problem is that Forbes’ polling techniques are flawed. If they were not, EDA stalwart Real Intent would most definitely make the list, particularly if the folks from Forbes were to have been in on a recent phone call with Real Intent President & CEO Prakash Narain.

Read more

In Austin, at the 50th DAC earlier this month,  I delivered a poster presentation on “Lending a ‘Formal’ Hand to CDC Verification: A Case Study of Non-Intuitive Failure Signatures”.   In this first blog in a series, I will set the stage for the issues around the case study of failures in a common clock domain crossing synchronizer.

At DAC 2012 last year, we surveyed more than 300 participants to understand trends in the CDC verification space.  More than half had a new design project starting within 3 months, which indicates reduced design cycles.  Almost 1/3rd had over 50 clock domains in their design. Extrapolating from our DAC 2011 survey, we see a definite trend of increasing CDC complexity.  Almost 2/3rd had to incur the penalty of an ECO due to a CDC bug.

For the reasons above, CDC Analysis tools topped their shopping list.

As CDC verification is becoming mainstream, it is imperative to refine and fine tune the CDC flow to balance the verification effort. As indicated by the pie-chart on the bottom-right, ‘Automatic Formal’ is another technology that the industry is looking to leverage. In this presentation, we show how the application of formal analysis in the CDC space can be used by design engineers to verify their CDC constructs and how this can alleviate the CDC verification challenge from the shoulders of verification engineers.

Whenever a signal changes too close to the clock edge it is being sampled on, the captured value is non-deterministic due to setup/hold violations. This phenomenon is called Metastability and without proper prevention and verification, metastability propagation could cause serious design errors. For synchronous designs, this is not a major issue as Static Timing Analysis (STA) tools can flag these issues with setup/hold checks.

However, metastability is an unavoidable issue for signals crossing asynchronous clock domains as clock domain crossings are not timed by STA tools. Due to the asynchronous nature of the transmit and receive clocks, it is possible that the transmit data might change within the setup and hold window of the receive clock, hence resulting in an unpredictable value and delay at the output of the flop.

To avoid the pitfalls of Metastability, designers use certain synchronization schemes to ensure correct exchange of information between asynchronous clock domains. One such common scheme is depicted below, where a synchronized control signal is used to enable the loading of the data being sent from the transmitting domain to the receiving domain.

A ‘control’ signal is one that is synchronized directly by a multi-flop synchronizer. A ‘data’ signal is one that is not directly synchronized but whose synchronization is controlled by a corresponding ‘control’ signal.

The conditions that need to be met by the control and data signals in such a scheme are outlined below. The two conditions highlighted in Green are candidates for formal analysis to verify. These two conditions are the focus of this presentation and are described later on.

Design flows that do not currently leverage a dedicated CDC verification tool attempt to fill in the gap by using custom scripts wrapped around STA tools and custom gate-level simulation environments. Typically, these are cumbersome to maintain and are not scalable.

Due to the adoption of the above approaches, the CDC problem has traditionally been deemed a back-end issue and left to the verification and CAD engineers to tackle. This often leads to lengthy verification and debug iterations due to incomplete understanding of the CDC nuances of the design. Additionally, CDC verification done later in the flow translates to a longer delay waiting for the design fix to be rerun through all the earlier stages in the flow.

Our recommendation is to move CDC verification to the design team and adopt a flow involving automatic formal CDC technology. By being automatic and not requiring the developement of a testbench or specification of assertions, automatic formal technologies preclude the traditional verification maxim that a designer should not verify his/her own block. At the same time, it leverages the fact that a designer understands the CDC constructs in the design and can quickly comprehend a failure signature and make an appropriate design fix. This shortens the CDC verification cycle and results in higher quality RTL handoffs to downstream teams.

In the next blog, I will discuss a case study involving non-intuitive failure signatures to support this recommendation.

We had lots of fun hats, glasses, props, and feather boas for dress up.   Between Julia and myself we were able to get some great photos.  Here are just a few for your viewing pleasure.   And at the bottom of the page, you can click on the link to see blackmail photos for ARM, Synopsys, Cadence, Mentor Graphics, Breker, Oasys, Excellicon, Blue Pearl, LibTech, DeFacTo, Concept Eng, Tela, Oski Tech, Tanner, AMIQ, ClioSoft, Chip Path, Forte, Open Text, GlobalFoundries, Adapt IP, ThinkBold, Cayenne, and IBSystems (EDACafe).   Enjoy!

Feeling Good!

Rockin’ It!

Three Amigos!

Click Here to See the Full Blackmail Photo Gallery

]]> http://www.realintent.com/real-talk/867/photo-booth-blackmail/feed 0 http://www.realintent.com/real-talk/864/real-intent-is-on-john-cooleys-dac13-cheesy-list http://www.realintent.com/real-talk/864/real-intent-is-on-john-cooleys-dac13-cheesy-list#comments Mon, 03 Jun 2013 16:31:54 +0000 admin http://www.realintent.com/real-talk/?p=864 Continue reading →]]> John Cooley: “My Cheesy Must See List for DAC 2013″

Real Intent Meridian CDC has “System Verilog and SDC support; improved bus handling, faster formal engine, new reporting and configurability that reduces noise; processes 500 M gates of RTL in 12 hours WITHOUT needing abstraction models that SpyGlass and Questa need.” CDC sign-off analysis. Nvidia, Cavium, Magnum. (booth 1031) Ask Sarath Kirihennedige. Freebie: flashlight

 

Real Intent Ascent Lint — Version 2.0 has 60 new rules, new FSM checks; new Emacs; runs faster and lints 450 M gates 1 hour, with “no need for hierarchical processing like Atrenta”. Nvidia says they see “50x faster runs vs. Atrenta SpyGlass”.

 

Real Intent Ascent XV does “fast static hazard analysis to find X-sources and nets susceptible to X-issues. X-optimism bugs are isolated during RTL simulation. At netlist level, X-pessimism is identified and corrected. Now does X audits for power-up. (booth 1031) Ask Lisa Piper. Freebie: flashlight

As the cost of failure continues to rise, SoC engineers see the growing importance of ensuring their work is as correct as possible as soon as possible in the design process. They cannot afford to carry errors forward from one stage to the next, where their impact grows while their causes become more obscured.

This requirement is driving the shift in design exploration and hand-off to the register transfer level. Using RTL for sign-off eases the integration of heterogeneous IP and makes it easier to check that the blocks are interfacing correctly with the host design, easier to check how clocks will cross these interfaces, and easier to check different power signatures and design testability. It also cuts the functional simulation load, especially when designs are being exercised at the system-level by reducing the number of states and the necessity to check for correct functionality.

What tools are available to improve the quality of RTL code before it reaches simulation and passes to synthesis? The latest generation of lint technology can handle full-chip designs of 500 million gates or more, and yet still can offer concise reporting. Timing constraints management and checking ensures correct timing for the block and full-chip level, so long as any changes in the RTL are reflected in the SDC files for the design. The SDC itself needs to be verified for correctness and consistency, and is essential for sign-off-grade analyses such as clock design crossing (CDC).

Reset analysis ensures that the design will come in a known good state, and later iterations of the design can be used to save chip area and routing resources through a more intelligent application of reset signals.

Automatic formal verification techniques can be used to find obscure functional bugs in the RTL, especially in finite state machines, and root out issues such as bus contention or dead code that violate the implicit intent of the RTL.

Clock domain crossing analysis, so important in these days of design reuse, IP, and complex power management schemes, can be carried out using a combination of formal and structural methods, which helps trap the corner case combinations of timing and functionality that lead to errors.

Power analysis and optimization techniques address issues such as reset checking, retention flop and isolation-cell analysis and optimization, clock/power gating, and sequential/combinational optimizations. These interventions can be so extensive that it makes sense to go back to the linting stage to recheck the design, and to clear the way for DFT analysis and optimization.

Working at the RTL signoff level means that even those without DFT expertise can develop DFT strategies and analyze them for the testability they bring to the design.

As a last step, it is important to manage the way that the simulation and synthesis processes handle the unknown (X) states thrown up by power management strategies that turn blocks on and off, and complicates clock-crossing domains. A proper analysis of this issue can reveal functional bugs that have been hidden at the RTL level by too much optimism about the impact of X states, and can reduce the impact of excessive pessimism about the impact of X states after synthesis.

But is RTL signoff also signoff for the SoC? For specific problems such as clock-domain crossing, consistency of SDC, X-propagation issues including reset optimization, and design for testability, the answer is no. Why? Because despite our desire to eliminate gate-level analysis, it is still required to sign off on specific problems. Unfortunately, gate-level analysis severely strains the capacity of EDA tools and processing times are not fast. Only the best-in-class tools can handle both the RTL and gate-level views of the design.

Can legacy RTL tools achieve the desired signoff, or are a new generation of tools needed?

Design teams for years have used a linting-based technology for analysis of designs. When issues are uncovered they are either fixed or waived by the designer. This approach has been used for IP or block-level qualification. We now see attempts to adapt this dated technology for full-chip analysis using an abstraction model for the IP blocks, and then doing a top-level check. This is not a sign-off technology, because the abstraction process blindly omits important details from the block-level. We believe the correct approach is to use a solution that has been architected from the ground up to attack a specific problem domain, and one that uses a smart hierarchical approach that retains block-level information. This will handle both RTL and gate-level views, and will deliver the speed, capacity and precision needed for a sign-off solution.

Real Intent is at booth #1031 at the Design Automation Conference in Austin, TX. Stop by and we would be happy to discuss SoC sign-off with you.

Use of the defparam statement can easily cause confusion and trouble in the following ways:

• Hierarchically changing the parameters of a module which may not be visible at the level of the affected module
• Placing the statement in a separate file from the instance being modified
• Using multiple statements in the same file to change the parameters of an instance
• Using multiple statements in multiple different files to change the parameters of an instance

To avoid unintended constant redefinitions, some companies disallow the use of defparam statements in their design flows.   In the following example, the value of the parameter top.SIZE is changed at the very bottom level of hierarchy and may easily be missed. The designer may think that the SIZE and WIDTH parameters are still set to 8 as opposed to 4.

module top (q, d, clk, rst);

  parameter SIZE = 8;

  output [SIZE-1:0] q;

  input [SIZE-1:0] d;

  input  clk, rst;

  myregb # (SIZE) r1 (.q(q), .d(d), .clk(clk), .rst(rst));

endmodule

module myregb (q, d, clk, rst);

  parameter  WIDTH = 8;

  output [WIDTH-1:0] q;

  input [WIDTH-1:0] d;

  input  clk, rst;

  dff # (WIDTH) myflop (.q(q), .d(d), .clk(clk), .rst(rst));

endmodule

module dff (q, d, clk, rst);

  parameter C = 1;

  output [C-1:0] q;

  input [C-1:0] d;

  input clk, rst;

  reg [ C-1:0] q;

  defparam top.SIZE = 4;

  always @ (posedge clk or posedge rst)

        if (rst) q <= 0;

        else    q<= d;

endmodule

The Ascent Lint rule DEFPARAM catches the use of defparam statements in Verilog designs so they can be removed. The question remains what is the best way to redefine the value of a parameter that does not cause confusion for designers and waste precious debug time.

Instead of using defparam statements to redefine the value of a parameter, designers are advised to use the named parameter redefinition method introduced in Verilog-2001.   This is a superior method over the positional parameter assignment list introduced in Verilog-1995.    Ascent Lint rule POS_PARAM_LIST catches the cases where positional parameter redefinition is used.  In the above example, the following instantiations use the positional parameter assignment method and will cause two violations if the rule POS_PARAM_LIST is enabled:

  myregb # (SIZE) r1 (.q(q), .d(d), .clk(clk), .rst(rst));

  dff # (WIDTH) myflop (.q(q), .d(d), .clk(clk), .rst(rst));

To increase clarity of the design and prevent design bugs, the instantiations should use named parameter assignment as:

  myregb # (.WIDTH(SIZE)) r1 (.q(q), .d(d), .clk(clk), .rst(rst));

  dff # (.C(WIDTH)) myflop (.q(q), .d(d), .clk(clk), .rst(rst));

Ascent Lint offers other parameter related rules.  For more information, please leave me a comment or contact Real Intent at info@realintent.com.

*Note: The defparam statement has been depreciated, meaning that it may be removed from the Verilog language in a future revision of the Verilog LRM.

References: Clifford E. Cummings, New Verilog-2001 Techniques for Creating Parameterized Models.

I spoke with Gary Smith on Tuesday, May 21, to get his thoughts on who made the list and why, and other events at DAC you should know about… like the Denali Party.  The sound has some noise in it and I apologize for that.  Still the video is worth watching. Enjoy!

See the Latest Developments in Ascent Early Verification and Meridian CDC Sign-off

You are invited to visit the Real Intent booth at the 50th DAC. Real Intent is known for having the fastest, highest-capacity verification tools for early functional analysis including Lint, and for advanced timing sign-off of designs with multiple clock domains (CDC) at both RTL and gate-level.

By completing our quick survey at the booth, you will be entered into drawings for a cool BeagleBone Black 1Ghz computer. There’s More! Our free photo-booth will give an entertaining take-away for you and your colleagues. You can look forward to both fast verification and fun times at this year’s DAC!

Our technical presentations will bring you up to date with our new product releases that have been proven on 500M+ gate SoC designs. Click on the links below to book your appointment at the Real Intent booth #1031.

New Ascent Lint 2.0 Release with Advanced Debugging
We’ve taken the industry’s fastest linter for clean RTL before simulation and synthesis to a new level. Since DAC 2012, more than 65 comprehensive unique rules have been added to Ascent Lint 2.0, while maintaining its analysis speed of 450M gates in less than one hour, with no need for hierarchical processing. See why Integrated Device Technology says “the product is easy to use and debug is fast and efficient.” Come and preview our new 2013 release which expands our high coverage rule set and introduces new design source file functionality. Schedule a Time.

Meridian Clock Domain Crossing with Advanced Flows and Management Features
Meridian CDC continues to advance its market-leading speed, capacity and low-noise analysis of asynchronous clock domains in SoC designs. At DAC 2013, we preview in private meetings our next generation CDC management solution with a new waiver-free flow. You will not want to miss seeing the future for advanced sign-off. Schedule a Time.

Ascent XV: Complete Solution for X Verification
Ascent XV provides a comprehensive solution and flow for making an RTL design X-robust. It enables clean RTL simulation in which performance and bug coverage is not impacted by X-effects. Unique reset analysis identifies uninitialized flops early in the design phase and suggests a minimal number of hardware resets for complete initialization which reduces routing overhead. The comprehensive X-hazard report identifies all X-sources, X-sensitive nets and ranks which nets to analyze first. The automatic generation of X-accurate models allows X-optimism functional bugs to be unmasked during RTL simulation. Ascent XV provides initialization and optimization capability for power-managed blocks to ensure that the combination of resets and retention flops are able to establish a known state. At the netlist level, Ascent XV identifies and corrects X-pessimism saving weeks on gate-level simulation. At DAC, discover the most comprehensive solution for X-verification. Schedule a Time.

Meridian Constraints: Comprehensive SDC Management and Verification
With Meridian Constraints, SDC is verified for completeness and correctness from design inception, through synthesis to back-end place and route. In a private meeting, preview our new interface which tightly integrates with the rest of your tool flow. Schedule a Time.

Ascent IIV: Automatic Detection of Functional Bugs Without a TestBench
Ascent IIV goes beyond Ascent Lint by leveraging formal techniques for functional verification. It uses the implied intent of the RTL to automatically formulate checks. Ascent IIV provides an immediate return on investment by quickly finding elusive bugs in RTL blocks and by pinpointing the root cause of the problem. Its smart reporting prioritizes your debug effort by marking up to 90% of the failures as secondary or duplicate, reducing the time spent on analysis. Discover the new 2013 release with substantial performance improvements, an improved reporting structure and important new FSM checks. Schedule a Time.

Joint Meridian CDC and DeFacTo SIGNOFF DFT Flow Presentation
For the first time, see a combined RTL sign-off flow for both CDC and DFT that accelerates the sign-off process. The new flow integrates DeFacTo’s SIGNOFF RTL DFT evaluation and enhancement platform, with Real Intent’s Meridian CDC, offering a best-in-class solution for SoC design teams worldwide. Schedule a Time.

  ]]> http://www.realintent.com/real-talk/842/your-real-intent-invitation-to-fun-and-fast-verification-at-dac/feed 0 http://www.realintent.com/real-talk/832/deepchip-real-intents-not-so-secret-dvcon13-report http://www.realintent.com/real-talk/832/deepchip-real-intents-not-so-secret-dvcon13-report#comments Thu, 09 May 2013 18:56:14 +0000 admin http://www.realintent.com/real-talk/?p=832 Continue reading →]]> DeepChip: “Real Intent’s not-so-secret DVcon’13 Report”

Hi, John,

After the recent DVcon’13 in February in Santa Clara, the employees inside Real Intent collectively got together and wrote this trip report about the conference. I hope your DeepChip readers like it.

- Prakash Narain

Real Intent, Inc.                Sunnyvale, CA

Read more