Peggy Aycinena’s interview with Prakash Narain
Prakash Narain: creating a unique workplace culture at Real Intent
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.
Lending a ‘Formal’ Hand to CDC Verification: A Case Study of Non-Intuitive Failure Signatures — Part 1
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.
Photo Booth Blackmail!
 | Graham Bell Sr. Director of Marketing of Real Intent |
Real Intent had a photo booth at its exhibit in Austin this week at the Design Automation Conference. I thought it would be cool to give a photo souvenir of the 50th conference for anyone who strolled by. On hand to work the booth were Julia and Antonio and they helped everyone enjoy themselves.
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
Real Intent is on John Cooley’s “DAC’13 Cheesy List”
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
Does SoC Sign-off Mean More Than RTL?
| Graham Bell Sr. Director of Marketing of Real Intent |
This blog was first published in the System-Level Design Community of Chip Design Mag.
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.
Ascent Lint Rule of the Month: DEFPARAM
 | Shiva Borzin Technical Marketing Manager |
This month we are going to look at the use of the parameter statement in Verilog, which is used to define a constant local to a module. References to a parameter are made by using its name. A parameter can be redefined on an instance-by-instance basis in two different ways: parameter redefinition in the instantiation itself, or by using a defparam statement.
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.
Video: Gary Smith Tells Us Who and What to See at DAC 2013
| Graham Bell Sr. Director of Marketing of Real Intent |
Real Intent is again, this year, on Gary Smith’s writeup of “must see” products at DAC 2013 in the RTL Sign-off category.
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!
Real Intent is on Gary Smith’s “What to see at DAC” List!
Gary Smith EDA: What to see @ DAC 2013
Your Real Intent Invitation to Fun and Fast Verification at DAC
 |
||
See the Latest Developments in Ascent Early Verification and Meridian CDC Sign-off
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 Meridian Clock Domain Crossing with Advanced Flows and Management Features Ascent XV: Complete Solution for X Verification Meridian Constraints: Comprehensive SDC Management and Verification Ascent IIV: Automatic Detection of Functional Bugs Without a TestBench Joint Meridian CDC and DeFacTo SIGNOFF DFT Flow Presentation
|
||
DeepChip: “Real Intent’s not-so-secret DVcon’13 Report”
 | Prakash Narain, Ph.D. President, CEO Real Intent, Inc. |
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