Blog Archive
June 2016
6/30/2016: Fix X-pessimism in Netlists with Practical Techniques
6/30/2016: In Memory of Dr. Miles Copeland: Innovator and Mentor
6/16/2016: How SoC Design is Driving Constraints Management and Verification
May 2016
5/27/2016: DAC Preview: 6 Tech. Presentations, Panel on Verification Cost, and the BEST Parties!
5/12/2016: The Switch from Atrenta to Real Intent for CDC, Lint, and X-prop
5/05/2016: May 17 Event: More than Moore – Enabling the Power of System Scaling
April 2016
4/28/2016: 7 Design Faults Leading to Clock and Data Glitches
4/21/2016: DVClub Silicon Valley: “Using UVM Virtual Sequencers & Virtual Sequences”, Wed. Apr. 27
4/14/2016: Verification Coffee Break – Where are We Going?
4/07/2016: UPF 3.0 – Making Power Intent Manageable, Incremental and Executable
March 2016
3/31/2016: How Physical Implementation Can Break Your Clock-Domain Crossing Logic
3/10/2016: Informal, Unformal, or Appformal? …and new FormalWorld.org
3/03/2016: DVCon Recap
February 2016
2/25/2016: Free Panels and Keynote at DVCon in Silicon Valley
2/12/2016: The Times They are a-Changin’: Gravity Waves, Moore’s Law, and Record Basketball
2/05/2016: Super Bowl 50, and Semiconductor and Design Predictions for 2016
January 2016
1/28/2016: CDC Verification of Fast-to-Slow Clocks – Part 3: Metastability Aware Simulation
1/21/2016: CDC Verification of Fast-to-Slow Clocks – Part 2: Formal Checks
1/14/2016: CDC Verification of Fast-to-Slow Clocks – Part 1: Structural Checks
December 2015
12/18/2015: DeepChip.com Survey: “Real Intent to possibly replace SpyGlass?”
12/10/2015: Best of “Real Talk”, Q4 Summary and Latest Videos
12/03/2015: Exposing and Eliminating X-optimism Bugs in RTL
November 2015
11/25/2015: Happy Thanksgiving and 2 Political Cartoons!
11/19/2015: Video: “Why A New Gate-level CDC Verification Solution?”
11/12/2015: Is SystemVerilog the COBOL of Electronic Design?
11/05/2015: Google Designing Its Own Next-Generation Smartphone SoCs?
October 2015
10/30/2015: The Many Tentacled Monster Under My House (with Pictures)
10/23/2015: Is Silicon the New Fabric for Our Lives?
10/16/2015: DAC Verification Survey: What’s Hot and What’s Not
10/09/2015: On-the-Fly Hardware Accurate Simulation, New Meridian CDC, ASICON Tutorial
10/02/2015: Correcting Pessimism without Optimism – Part Two
September 2015
9/24/2015: Correcting Pessimism without Optimism – Part One
9/17/2015: Calypto Design Systems: A Changed Partner
9/10/2015: Thunderbolt 3 and USB Type-C: the 40 Gbps + 100W Answer
9/03/2015: The Power of Dynamic Voltage Frequency Scaling
August 2015
8/27/2015: The Future of 3D Technologies is Fast and Heterogeneous
8/20/2015: Good news! The Next Big Thing in Verification is Already Here.
8/17/2015: A Verification Standard for Design Reliability
8/06/2015: New 3D XPoint Fast Memory a Big Deal for Big Data
July 2015
7/30/2015: Technology Errors Demand Netlist-level CDC Verification
7/23/2015: Video: SoC Requirements and “Big Data” are Driving CDC Verification
7/16/2015: 50th Anniversary of Moore’s Law: What If He Got it Wrong?
7/09/2015: The Interconnected Web of Work
7/06/2015: In Fond Memory of Gary Smith
7/01/2015: Richard Goering and Us: 30 Great Years
June 2015
6/12/2015: Quick 2015 DAC Recap and Racing Photo Album
6/05/2015: Advanced FPGA Sign-off Includes DO-254 and …Missing DAC?
May 2015
5/28/2015: #2 on GarySmithEDA What to See @ DAC List – Why?
5/14/2015: SoC Verification: There is a Stampede!
5/07/2015: Drilling Down on the Internet-of-Things (IoT)
April 2015
4/30/2015: Reflections on Accellera UCIS: Design by Architect and Committee
4/23/2015: DO-254 Without Tears
4/17/2015: Analysis of Clock Intent Requires Smarter SoC Verification
4/09/2015: High-Level Synthesis: New Driver for RTL Verification
4/03/2015: Underdog Innovation: David and Goliath in Electronics
March 2015
3/27/2015: Taking Control of Constraints Verification
3/20/2015: Billion Dollar Unicorns
3/13/2015: My Impressions of DVCon USA 2015: Lies; Experts; Art or Science?
3/06/2015: Smarter Verification: Shift Mindset to Shift Left [Video]
February 2015
2/27/2015: New Ascent Lint, Cricket Video Interview and DVCon Roses
2/20/2015: Happy Lunar New Year: Year of the Ram (or is it Goat or Sheep?)
2/12/2015: Video: Clock-Domain Crossing Verification: Introduction; SoC challenges; and Keys to Success
2/06/2015: A Personal History of Transaction Interfaces to Hardware Emulation: Part 2
January 2015
1/30/2015: A Personal History of Transaction Interfaces to Hardware Emulation: Part 1
1/22/2015: Intel’s new SoC-based Broadwell CPUs: Less Filling, Taste Great!
1/19/2015: Reporting Happiness: Not as Easy as You Think
1/09/2015: 38th VLSI Design Conf. Keynote: Nilekani on IoT and Smartphones
December 2014
12/22/2014: December 2014 Holiday Party
12/17/2014: Happy Holidays from Real Intent!
12/12/2014: Best of “Real Talk”, Q4 Summary and Latest Videos
12/04/2014: P2415 – New IEEE Power Standard for Unified Hardware Abstraction
November 2014
11/27/2014: The Evolution of RTL Lint
11/20/2014: Parallelism in EDA Software – Blessing or a Curse?
11/13/2014: How Big is WWD – the Wide World of Design?
11/06/2014: CMOS Pioneer Remembered: John Haslet Hall
October 2014
10/31/2014: Is Platform-on-Chip The Next Frontier For IC Integration?
10/23/2014: DVClub Shanghai: Making Verification Debug More Efficient
10/16/2014: ARM TechCon Video: Beer, New Meridian CDC, and Arnold Schwarzenegger ?!
10/10/2014: New CDC Verification: Less Filling, Picture Perfect, and Tastes Great!
10/03/2014: ARM Fueling the SoC Revolution and Changing Verification Sign-off
September 2014
9/25/2014: Does Your Synthesis Code Play Well With Others?
9/19/2014: It’s Time to Embrace Objective-driven Verification
9/12/2014: Autoformal: The Automatic Vacuum for Your RTL Code
9/04/2014: How Bad is Your HDL Code? Be the First to Find out!
August 2014
8/29/2014: Fundamentals of Clock Domain Crossing: Conclusion
8/21/2014: Video Keynote: New Methodologies Drive EDA Revenue Growth
8/15/2014: SoCcer: Defending your Digital Design
8/08/2014: Executive Insight: On the Convergence of Design and Verification
July 2014
7/31/2014: Fundamentals of Clock Domain Crossing Verification: Part Four
7/24/2014: Fundamentals of Clock Domain Crossing Verification: Part Three
7/17/2014: Fundamentals of Clock Domain Crossing Verification: Part Two
7/10/2014: Fundamentals of Clock Domain Crossing Verification: Part One
7/03/2014: Static Verification Leads to New Age of SoC Design
June 2014
6/26/2014: Reset Optimization Pays Big Dividends Before Simulation
6/20/2014: SoC CDC Verification Needs a Smarter Hierarchical Approach
6/12/2014: Photo Booth Blackmail at DAC in San Francisco!
6/06/2014: Quick Reprise of DAC 2014
May 2014
5/01/2014: Determining Test Quality through Dynamic Runtime Monitoring of SystemVerilog Assertions
April 2014
4/24/2014: Complexity Drives Smart Reporting in RTL Verification
4/17/2014: Video Update: New Ascent XV Release for X-optimization, ChipEx show in Israel, DAC Preview
4/11/2014: Design Verification is Shifting Left: Earlier, Focused and Faster
4/03/2014: Redefining Chip Complexity in the SoC Era
March 2014
3/27/2014: X-Verification: A Critical Analysis for a Low-Power World (Video)
3/14/2014: Engineers Have Spoken: Design And Verification Survey Results
3/06/2014: New Ascent IIV Release Delivers Enhanced Automatic Verification of FSMs
February 2014
2/28/2014: DVCon Panel Drill Down: “Where Does Design End and Verification Begin?” – Part 3
2/20/2014: DVCon Panel Drill Down: “Where Does Design End and Verification Begin?” – Part 2
2/13/2014: DVCon Panel Drill Down: “Where Does Design End and Verification Begin?” – Part 1
2/07/2014: Video Tech Talk: Changes In Verification
January 2014
1/31/2014: Progressive Static Verification Leads to Earlier and Faster Timing Sign-off
1/30/2014: Verific’s Front-end Technology Leads to Success and a Giraffe!
1/23/2014: CDC Verification of Fast-to-Slow Clocks – Part Three: Metastability Aware Simulation
1/16/2014: CDC Verification of Fast-to-Slow Clocks – Part Two: Formal Checks
1/10/2014: CDC Verification of Fast-to-Slow Clocks – Part One: Structural Checks
1/02/2014: 2013 Highlights And Giga-scale Predictions For 2014
December 2013
12/13/2013: Q4 News, Year End Summary and New Videos
12/12/2013: Semi Design Technology & System Drivers Roadmap: Part 6 – DFM
12/06/2013: The Future is More than “More than Moore”
November 2013
11/27/2013: Robert Eichner’s presentation at the Verification Futures Conference
11/21/2013: The Race For Better Verification
11/18/2013: Experts at the Table: The Future of Verification – Part 2
11/14/2013: Experts At The Table: The Future Of Verification Part 1
11/08/2013: Video: Orange Roses, New Product Releases and Banner Business at ARM TechCon
October 2013
10/31/2013: Minimizing X-issues in Both Design and Verification
10/23/2013: Value of a Design Tool Needs More Sense Than Dollars
10/17/2013: Graham Bell at EDA Back to the Future
10/15/2013: The Secret Sauce for CDC Verification
10/01/2013: Clean SoC Initialization now Optimal and Verified with Ascent XV
September 2013
9/24/2013: EETimes: An Engineer’s Progress With Prakash Narain, Part 4
9/20/2013: EETimes: An Engineer’s Progress With Prakash Narain, Part 3
9/20/2013: CEO Viewpoint: Prakash Narain on Moving from RTL to SoC Sign-off
9/17/2013: Video: Ascent Lint – The Best Just Got Better
9/16/2013: EETimes: An Engineer’s Progress With Prakash Narain, Part 2
9/16/2013: EETimes: An Engineer’s Progress With Prakash Narain
9/10/2013: SoC Sign-off Needs Analysis and Optimization of Design Initialization in the Presence of Xs
August 2013
8/15/2013: Semiconductor Design Technology and System Drivers Roadmap: Process and Status – Part 4
8/08/2013: Semiconductor Design Technology and System Drivers Roadmap: Process and Status – Part 3
July 2013
7/25/2013: Semiconductor Design Technology and System Drivers Roadmap: Process and Status – Part 2
7/18/2013: Semiconductor Design Technology and System Drivers Roadmap: Process and Status – Part 1
7/16/2013: Executive Video Briefing: Prakash Narain on RTL and SoC Sign-off
7/05/2013: Lending a ‘Formal’ Hand to CDC Verification: A Case Study of Non-Intuitive Failure Signatures — Part 3
June 2013
6/27/2013: Bryon Moyer: Simpler CDC Exception Handling
6/21/2013: Lending a ‘Formal’ Hand to CDC Verification: A Case Study of Non-Intuitive Failure Signatures — Part 2
6/17/2013: Peggy Aycinena’s interview with Prakash Narain
6/14/2013: Lending a ‘Formal’ Hand to CDC Verification: A Case Study of Non-Intuitive Failure Signatures — Part 1
6/10/2013: Photo Booth Blackmail!
6/03/2013: Real Intent is on John Cooley’s “DAC’13 Cheesy List”
May 2013
5/30/2013: Does SoC Sign-off Mean More Than RTL?
5/24/2013: Ascent Lint Rule of the Month: DEFPARAM
5/23/2013: Video: Gary Smith Tells Us Who and What to See at DAC 2013
5/22/2013: Real Intent is on Gary Smith’s “What to see at DAC” List!
5/16/2013: Your Real Intent Invitation to Fun and Fast Verification at DAC
5/09/2013: DeepChip: “Real Intent’s not-so-secret DVcon’13 Report”
5/07/2013: TechDesignForum: Better analysis helps improve design quality
5/03/2013: Unknown Sign-off and Reset Analysis
April 2013
4/25/2013: Hear Alexander Graham Bell Speak from the 1880′s
4/19/2013: Ascent Lint rule of the month: NULL_RANGE
4/16/2013: May 2 Webinar: Automatic RTL Verification with Ascent IIV: Find Bugs Simulation Can Miss
4/05/2013: Conclusion: Clock and Reset Ubiquity – A CDC Perspective
March 2013
3/22/2013: Part Six: Clock and Reset Ubiquity – A CDC Perspective
3/21/2013: The BIG Change in SoC Verification You Don’t Know About
3/15/2013: Ascent Lint Rule of the Month: COMBO_NBA
3/15/2013: System-Level Design Experts At The Table: Verification Strategies – Part One
3/08/2013: Part Five: Clock and Reset Ubiquity – A CDC Perspective
3/01/2013: Quick DVCon Recap: Exhibit, Panel, Tutorial and Wally’s Keynote
3/01/2013: System-Level Design: Is This The Era Of Automatic Formal Checks For Verification?
February 2013
2/26/2013: Press Release: Real Intent Technologist Presents Power-related Paper and Tutorial at ISQED 2013 Symposium
2/25/2013: At DVCon: Pre-Simulation Verification for RTL Sign-Off includes Automating Power Optimization and DFT
2/25/2013: Press Release: Real Intent to Exhibit, Participate in Panel and Present Tutorial at DVCon 2013
2/22/2013: Part Four: Clock and Reset Ubiquity – A CDC Perspective
2/18/2013: Does Extreme Performance Mean Hard-to-Use?
2/15/2013: Part Three: Clock and Reset Ubiquity – A CDC Perspective
2/07/2013: Ascent Lint Rule of the Month: ARITH_CONTEXT
2/01/2013: “Where Does Design End and Verification Begin?” and DVCon Tutorial on Static Verification
January 2013
1/25/2013: Part Two: Clock and Reset Ubiquity – A CDC Perspective
1/18/2013: Part One: Clock and Reset Ubiquity – A CDC Perspective
1/07/2013: Ascent Lint Rule of the Month: MIN_ID_LEN
1/04/2013: Predictions for 2014, Hier. vs Flat, Clocks and Bugs
December 2012
12/14/2012: Real Intent Reports on DVClub Event at Microprocessor Test and Verification Workshop 2012
12/11/2012: Press Release: Real Intent Records Banner Year
12/07/2012: Press Release: Real Intent Rolls Out New Version of Ascent Lint for Early Functional Verification
12/04/2012: Ascent Lint Rule of the Month: OPEN_INPUT
November 2012
11/19/2012: Real Intent Has Excellent EDSFair 2012 Exhibition
11/16/2012: Peggy Aycinena: New Look, New Location, New Year
11/14/2012: Press Release: New Look and New Headquarters for Real Intent
11/05/2012: Ascent Lint HDL Rule of the Month: ZERO_REP
11/02/2012: Have you had CDC bugs slip through resulting in late ECOs or chip respins?
11/01/2012: DAC survey on CDC bugs, X propagation, constraints
October 2012
10/29/2012: Press Release: Real Intent to Exhibit at ARM TechCon 2012 – Chip Design Day
September 2012
9/24/2012: Photos of the space shuttle Endeavour from the Real Intent office
9/20/2012: Press Release: Real Intent Showcases Verification Solutions at Verify 2012 Japan
9/14/2012: A Bolt of Inspiration
9/11/2012: ARM blog: An Advanced Timing Sign-off Methodology for the SoC Design Ecosystem
9/05/2012: When to Retool the Front-End Design Flow?
August 2012
8/27/2012: X-Verification: What Happens When Unknowns Propagate Through Your Design
8/24/2012: Article: Verification challenges require surgical precision
8/21/2012: How To Article: Verifying complex clock and reset regimes in modern chips
8/20/2012: Press Release: Real Intent Supports Growth Worldwide by Partnering With EuropeLaunch
8/06/2012: SemiWiki: The Unknown in Your Design Can be Dangerous
8/03/2012: Video: “Issues and Struggles in SOC Design Verification”, Dr. Roger Hughes
July 2012
7/30/2012: Video: What is Driving Lint Usage in Complex SOCs?
7/25/2012: Press Release: Real Intent Adds to Japan Presence: Expands Office, Increases Staff to Meet Demand for Design Verification and Sign-Off Products
7/23/2012: How is Verification Complexity Changing, and What is the Impact on Sign-off?
7/20/2012: Real Intent in Brazil
7/16/2012: Foosball, Frosty Beverages and Accelerating Verification Sign-off
7/03/2012: A Good Design Tool Needs a Great Beginning
June 2012
6/14/2012: Real Intent at DAC 2012
6/01/2012: DeepChip: Cheesy List for DAC 2012
May 2012
5/31/2012: EDACafe: Your Real Intent Invitation to Fast Verification and Fun at DAC
5/30/2012: Real Intent Video: New Ascent Lint and Meridian CDC Releases and Fun at DAC 2012
5/29/2012: Press Release: Real Intent Leads in Speed, Capacity and Precision with New Releases of Ascent Lint and Meridian CDC Verification Tools
5/22/2012: Press Release: Over 35% Revenue Growth in First Half of 2012
5/21/2012: Thoughts on RTL Lint, and a Poem
5/21/2012: Real Intent is #8 on Gary Smith’s “What to see at DAC” List!
5/18/2012: EETimes: Gearing Up for DAC – Verification demos
5/08/2012: Gabe on EDA: Real Intent Helps Designers Verify Intent
5/07/2012: EDACafe: A Page is Turned
5/07/2012: Press Release: Graham Bell Joins Real Intent to Promote Early Functional Verification & Advanced Sign-Off Circuit Design Software
March 2012
3/21/2012: Press Release: Real Intent Demos EDA Solutions for Early Functional Verification & Advanced Sign-off at Synopsys Users Group (SNUG)
3/20/2012: Article: Blindsided by a glitch
3/16/2012: Gabe on EDA: Real Intent and the X Factor
3/10/2012: DVCon Video Interview: “Product Update and New High-capacity ‘X’ Verification Solution”
3/01/2012: Article: X-Propagation Woes: Masking Bugs at RTL and Unnecessary Debug at the Netlist
February 2012
2/28/2012: Press Release: Real Intent Joins Cadence Connections Program; Real Intent’s Advanced Sign-Off Verification Capabilities Added to Leading EDA Flow
2/15/2012: Real Intent Improves Lint Coverage and Usability
2/15/2012: Avoiding the Titanic-Sized Iceberg of Downton Abbey
2/08/2012: Gabe on EDA: Real Intent Meridian CDC
2/08/2012: Press Release: At DVCon, Real Intent Verification Experts Present on Resolving X-Propagation Bugs; Demos Focus on CDC and RTL Debugging Innovations
January 2012
1/24/2012: A Meaningful Present for the New Year
1/11/2012: Press Release: Real Intent Solidifies Leadership in Clock Domain Crossing
August 2011
8/02/2011: A Quick History of Clock Domain Crossing (CDC) Verification
July 2011
7/26/2011: Hardware-Assisted Verification and the Animal Kingdom
7/13/2011: Advanced Sign-off…It’s Trending!
May 2011
5/24/2011: Learn about Advanced Sign-off Verification at DAC 2011
5/16/2011: Getting A Jump On DAC
5/09/2011: Livin’ on a Prayer
5/02/2011: The Journey to CDC Sign-Off
April 2011
4/25/2011: Getting You Closer to Verification Closure
4/11/2011: X-verification: Conquering the “Unknown”
4/05/2011: Learn About the Latest Advances in Verification Sign-off!
March 2011
3/21/2011: Business Not as Usual
3/15/2011: The Evolution of Sign-off
3/07/2011: Real People, Real Discussion – Real Intent at DVCon
February 2011
2/28/2011: The Ascent of Ascent Lint (v1.4 is here!)
2/21/2011: Foundation for Success
2/08/2011: Fairs to Remember
January 2011
1/31/2011: EDA Innovation
1/24/2011: Top 3 Reasons Why Designers Switch to Meridian CDC from Real Intent
1/17/2011: Hot Topics, Hot Food, and Hot Prize
1/10/2011: Satisfaction EDA Style!
1/03/2011: The King is Dead. Long Live the King!
December 2010
12/20/2010: Hardware Emulation for Lowering Production Testing Costs
12/03/2010: What do you need to know for effective CDC Analysis?
November 2010
11/12/2010: The SoC Verification Gap
11/05/2010: Building Relationships Between EDA and Semiconductor Ventures
October 2010
10/29/2010: Thoughts on Assertion Based Verification (ABV)
10/25/2010: Who is the master who is the slave?
10/08/2010: Economics of Verification
10/01/2010: Hardware-Assisted Verification Tackles Verification Bottleneck
September 2010
9/24/2010: Excitement in Electronics
9/17/2010: Achieving Six Sigma Quality for IC Design
9/03/2010: A Look at Transaction-Based Modeling
August 2010
8/20/2010: The 10 Year Retooling Cycle
July 2010
7/30/2010: Hardware-Assisted Verification Usage Survey of DAC Attendees
7/23/2010: Leadership with Authenticity
7/16/2010: Clock Domain Verification Challenges: How Real Intent is Solving Them
7/09/2010: Building Strong Foundations
7/02/2010: Celebrating Freedom from Verification
June 2010
6/25/2010: My DAC Journey: Past, Present and Future
6/18/2010: Verifying Today’s Large Chips
6/11/2010: You Got Questions, We Got Answers
6/04/2010: Will 70 Remain the Verification Number?
May 2010
5/28/2010: A Model for Justifying More EDA Tools
5/21/2010: Mind the Verification Gap
5/14/2010: ChipEx 2010: a Hot Show under the Hot Sun
5/07/2010: We Sell Canaries
April 2010
4/30/2010: Celebrating 10 Years of Emulation Leadership
4/23/2010: Imagining Verification Success
4/16/2010: Do you have the next generation verification flow?
4/09/2010: A Bug’s Eye View under the Rug of SNUG
4/02/2010: Globetrotting 2010
March 2010
3/26/2010: Is Your CDC Tool of Sign-Off Quality?
3/19/2010: DATE 2010 – There Was a Chill in the Air
3/12/2010: Drowning in a Sea of Information
3/05/2010: DVCon 2010: Awesomely on Target for Verification
February 2010
2/26/2010: Verifying CDC Issues in the Presence of Clocks with Dynamically Changing Frequencies
2/19/2010: Fostering Innovation
2/12/2010: CDC (Clock Domain Crossing) Analysis – Is this a misnomer?
2/05/2010: EDSFair – A Successful Show to Start 2010
January 2010
1/29/2010: Ascent Is Much More Than a Bug Hunter
1/22/2010: Ascent Lint Steps up to Next Generation Challenges
1/15/2010: Google and Real Intent, 1st Degree LinkedIn
1/08/2010: Verification Challenges Require Surgical Precision
1/07/2010: Introducing Real Talk!

Fix X-pessimism in Netlists with Practical Techniques

Lisa Piper   Lisa Piper
   Technical Marketing Manager

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.

What is X-pessimism?

X-pessimism occurs in gate-level designs when an X signal at the input of some digital logic causes the simulation output to be an unknown value, even though in real hardware the value will be deterministic (i.e., 1 or 0). X-pessimism makes it hard to get netlist simulations up and running quickly.

Figure 1 shows a simple example. When the values of in1 and in2 are both 0, the simulation value at the output is 0, as would happen in hardware. But when the ‘input’ value is an unknown X, and the values of in1 and in2 are both 1, the simulation value at the output is X in simulation but is 1 in real hardware. Specifically, we say it is 1-pessimistic because the output should have been a value of 1 (as the example suggests, ‘0-pessimistic’ is also possible).

X-pessimism where an X results when the values of in1 and in2 are both 1 (Real Intent)

Unlike Figure 1, the logic cone of the cloud in real designs is often very complex. The selected output can be driven by a logic expression and the input can also be a logic expression. In such cases, the output X value is sometimes a result of pessimism but at others simply the propagation of an X that was optimistic in RTL. One can be artificially corrected without harm, but the other could be a major bug. Refer to “X-Propagation Woes – A Condensed Primer”2 for more details.

Common ‘quick fixes’

Three techniques are frequently used to address X-pessimism:

  1. Eliminate all Xs.
  2. Perform artificial random initialization of uninitialized flops.
  3. Manual analysis.

All have major drawbacks. Let’s take a more detailed look at each.

The first step toward eliminating all Xs is to add a reset to all memory elements. This gets rid of the most common source of Xs: uninitialized flops. However, synchronous resets can lead to pessimism issues being introduced during synthesis. Also, there are other significant X-sources this does not address. These include explicit X-assigns for flagging illegal states, bus contention, and out-of-range references.

But the greater issue with eliminating all Xs is that the necessary resets eat into power, size, and routing budgets. Resettable flops are larger, consume more power, and require additional routing resources. The technique is practical only for smaller designs.

The second approach artificially randomizes the initialization of uninitialized memory elements at time 0. This helps in simulation but does not necessarily match real hardware. It also, again, does not address all X-sources. X-optimism bugs that were masked in RTL will probably be artificially masked again in the netlist simulation. Missing such a bug can lead to very expensive late-stage repair.

The third approach is to manually analyze the root cause of all X-differences between the outputs of the RTL and gate-level simulations, determine the correct values and time, and then force and release pessimistic nodes. This can be difficult.

A gate-level realization transforms RTL into something that is more complex, has a different structure, and has unfamiliar signal names. It takes a lot of time to chase down pessimistic Xs in netlist simulations, particularly where there is a mixture of Xs attributable to either optimism or pessimism – and you do not initially know which. The process can take months for large designs and even then it is easy to overlook bugs because of deadline pressures.

In summary, these established approaches do not address pessimism caused by Xs from all sources. They mask issues in the gate-level simulations due to X-optimism in RTL simulations. They cannot handle larger SoC designs.

Ascent XV–Netlist

If a node is determined to be 1- (or 0-) pessimistic, that means its real circuit value is 1 (or 0) but simulation will produce 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 – that is, the node represents the deterministic value real hardware would see. After forcing, the node must be immediately released.

But not all Xs should be arbitrarily forced to a known value, only those that result from pessimism.

Ascent XV-Netlist from Real Intent makes your gate-level simulation hardware-accurate by correcting pessimism as appropriate. It statically identifies potentially pessimistic nodes, then uses that information to create SimPortal files that augment the simulation to correct X-pessimism on-the-fly.

Undertaking static analysis before simulation significantly reduces the number of nodes that must be analyzed during simulation itself. Also, 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 potentially pessimistic nodes in the design as you go, independent of the testbench.

A bottom-up hierarchical static analysis can also be done at the block level. When all the blocks are integrated for full-chip simulation, this proves a very scalable approach. The SimPortal has been designed to minimize compile time and memory overhead. You can control the verbosity at simulation time, and choose to drop back to simple monitoring or even turn off both correction and monitoring at any point in time.

The Ascent XV X-pessimism flow and methodology has two main components and is shown graphically in Figure 2.

  1. Run static analysis to determine which data input values can cause monitored nodes to exhibit pessimism. Generate design-specific SimPortal data files.
  2. Run SimPortal simulation to find out which nodes experienced the input combinations that cause pessimism.

Figure 2: Ascent XV X-Pessimism Flow and Methodology (Real Intent)

This methodology takes another complex issue out of fixing X-pessimism. In RTL, Xs can hide functional bugs due to X-optimism. These bugs will be brought to light in netlist gate simulations. Unfortunately because Xs also cause X-pessimism in netlist simulations, you then need the time and insights to determine whether a mismatch is due to X-optimism, X-pessimism, or something else.

Ascent XV-Netlist eliminates Xs caused by X-pessimism, removing the major source of simulation RTL and netlist simulation differences and thereby the need for manual analysis and filtering.

A full breakdown of Ascent XV’s features and advantages is shown in Figure 3.

Figure 3: The Ascent XV solution (Real Intent)

Summary

Xs exist in all designs and it is difficult to prevent them occurring for practical reasons. Simulation results may differ because of Xs hidden in the RTL simulation by X-optimism, or present in gate-level simulation due to X-pessimism.

Pessimism can be fixed by overriding the simulator because you know that real hardware will always resolve to a deterministic value. The challenge is confirming that an X value is a result of X-pessimism and not simply X-propagation. Only then can you force it to the right value at the right point in time so that the simulation matches that for real hardware.

Ascent XV-Netlist Pessimism corrects X-pessimism on-the-fly so the simulation is hardware accurate. Ascent XV cuts the time required to get gate-level simulations started by an order of magnitude. Its ease-of-use and capacity, make it the only practical solution for large SOCs.



Jun 30, 2016 | Comments


In Memory of Dr. Miles Copeland: Innovator and Mentor

Graham Bell   Graham Bell
   Vice President of Marketing at Real Intent

miles-copelandI had just learned this week that my mentor into the world of EDA, Dr. Miles Copeland had passed away recently.

At Carleton University in Ottawa, Canada, Copeland was the former chair of the Department of Electronics and Professor Emeritus in the Faculty of Engineering and Design. He was an IEEE Fellow and was known for his passion for teaching and research innovation.

In addition to educating two and a half generations of electrical engineers, Copeland had established Carleton’s research capacity in the area of analog and radio frequency integrated circuit design, including the development of computing techniques to enable and reinforce research and learning.

The focus on computing techniques was how I came to work with Copeland.

As a recent graduate of the Department of Computer Science with a focus on computer hardware, I was hired by Dr. Copeland, as a research engineer, to port SPICE, a 14,000 line Fortran program, into a 16-bit microcomputer (Corvus Concept) that was based on the Motorola 68000 micro-processor. This allowed students to simulate their circuits before fabricating them in-house on the University’s 2-inch wafer line. Later on, I worked with Copeland on extending a mixed-analog digital simulator, SPLICE, to handle mixed sampled data circuits, specifically switched-capacitor filters.  We published the research in an IEEE journal that led me to be hired to work on the PSPICE simulator in California.  I owe my entire career in high-tech to Miles Copeland.

Copeland was actively involved in consultation and research collaboration with industry, notably at Nortel, Bell Northern Research and General Electric. His widely used research innovations include groundbreaking work that enabled the design of fully integrated radios. His research was also key to the design of modern telecommunications circuits that are used in today’s personal communications devices and wireless data communication

Over his distinguished teaching career, Copeland supervised nearly 50 masters and PhD students.

In recognition of his achievements, Copeland recently received the 2016 Institute of Electrical and Electronics Engineers (IEEE) Donald O. Pederson Award in Solid-State Circuits. For nearly a century, the IEEE has paid tribute to technical professionals whose exceptional achievements and outstanding efforts have made a lasting impact on technology and society. He was named a Fellow of the IEEE in 1989.

Copeland was presented with the prestigious award on February 1, 2016 at the International Solid-State Circuits Conference in San Francisco. While accepting the award, he reflected back on his time in the Faculty of Engineering and Design.

“This award recognizes Carleton’s leadership in engineering research and innovation,” noted Copeland. “I appreciate the acknowledgement of my hard work and that of Carleton graduate students, whose research helped Nortel establish itself early on as a dominant company in the telecommunications market.”

Dr. Copeland is missed by me and the many colleagues and friends in the Faculty of Engineering and Design at Carleton as well as hundreds of former students. A scholarship was recently established in Dr. Copeland’s name to support outstanding Electronics students. To make a contribution to the fund, please visit futurefunder.ca or contact Corrie Hobin, Assistant Director of Faculty Advancement, Engineering and Design at corrie.hobin@carleton.ca for more information.



Jun 30, 2016 | Comments


How SoC Design is Driving Constraints Management and Verification

Graham Bell   Graham Bell
   Vice President of Marketing at Real Intent

There were a number of announcements at DAC 2016 in Austin concerning SDC timing constraints verification and management.  Real Intent announced the newest release of Meridian Constraints for sign-off of SoC designs. It features new and unique functional analysis, data-driven debug, and support for distributed design development.

In this blog, I want to cover the drivers for a new kind of Constraints verification tool.

Constraints Management today is clearly different from the pre-SOC and pre-IP eras. The design process is now truly distributed with much legacy and third-party IP in any new SOC design. This implies that the SDC creation process must go through the three steps of (a) aggregation from the component SDCs to an overall SoC-level SDC, (b) refinement of the SoC-level SDC, and (c) dis-aggregation of the SoC-level SDC into SDCs for the synthesis partitions. The key point here being that the synthesis-partition boundaries need not align with the logical boundaries of the component IPs.

In the pre-SOC and pre-IP era, SDC was created for the monolithic design just prior to synthesis followed by dis-aggregation (budgeting) for the synthesis partitions. It is a benefit that the component IP comes with the associated SDC, but it also means that the SDC management software must be able to digest the component SDCs and create a consistent monolithic SoC-level SDC, i.e. component SDC promotion to the SOC top-level along with SDC consistency checking becomes first-order requirements in an SDC management tool. This has been borne out in surveys we have done with designers, which reveal a 30% pain-point number for consistency checking.

SDC used to be needed first for synthesis followed by static timing analysis (STA), meaning that it was needed late in the design process. In the SoC era, sign-off activity occurs at the RTL level before synthesis partitions are decided. As an important example, RTL must be signed off for clock-domain crossing (CDC) checks before synthesis. Similarly, functional timing exceptions and Reset schemes must be signed-off in RTL before synthesis and STA. These sign-off items require a detailed clocking spec for the sign-off to be meaningful and robust. Not every single SDC detail required for synthesis and STA need to be present at this stage, but the SDC must be detailed enough for CDC sign-off to be reliable. In the SOC and IP-integration era, SDC is needed first for RTL sign-off followed by synthesis and then STA.

Missing and incorrect clock specs are important issues faced in the RTL sign-off process. Usually these gaps can be filled by an analysis of the design and providing the user with templates of SDC commands to be added to the existing constraints. This is borne out in our survey of designers in which the combination of constraints checking, constraints creation and exception verification stands out as a major overhead.

Depending on design methodology, it is true that many exceptions may be “timing intent”, i.e. static configuration registers, resets, etc.  These are not the types of exceptions that can result in silicon failures.  The 20-30% of structural failures cost 100% of the time and money for a re-spin, and it’s important to have a methodology that can validate them completely.  This requires not only a structural analysis of hardware control structures for multi-cycle paths, but also a complementary formal methodology to find any corner cases.  In addition, the ability to configure your exception validation via assertions is crucial to having a complete understanding of your design operation and assumptions before taping out.

If we look at sign-off from the perspective of CDC verification, some tool vendors suggest that the CDC setup process is all about getting clean SDC at RTL level. Getting clock information right is a first step in CDC methodology but it’s just the first step. For a CDC tool to be noise free and waiver free, it should be configurable so it can understand and adapt to various CDC design styles/methodologies used by different design teams across the industry. Also SDC itself is limited because its written for timing intent only, so SDC has no information about what resets signals are in the design.

Meridian Constraints from Real Intent meets the needs of design teams to create, manage, and verify all of their SDC timing constraints. It also ensures that constraints completely cover the design, correctly match the functional and timing goals, and are consistent between different blocks and levels in the design. Having correct and complete constraints and associated clock definitions ensures timing goals are met. Leveraging functional analysis capability with industry-leading formal analysis technology in Meridian Constraints gives users maximum confidence in the correctness of their exceptions, minimizing the risk of a re-spin due to bad exceptions that cause incorrect circuit operation.

This article was based on contributions by Pranav Ashar, CTO, Vikas Sachdeva, senior technical marketing manager, and Daryl Kowalski, senior manager of product engineering at Real Intent.



Jun 16, 2016 | Comments


DAC Preview: 6 Tech. Presentations, Panel on Verification Cost, and the BEST Parties!

Graham Bell   Graham Bell
   Vice President of Marketing at Real Intent

Real Intent is bringing its advanced Ascent and Meridian technology, EDA expertise and espresso energy to the 53rd Design Automation Conference (DAC) in Austin, Texas, June 5-9, 2016. Before I mention the BEST DAC parties, Real Intent invites attendees to Booth #527 to:

  • Learn the latest information about Real Intent’s Ascent family of tools for the fastest static RTL verification prior to synthesis and simulation, and its Meridian tools that enable CDC and SDC sign-off at the RTL and gate-level.
  • View technical presentations to get up to speed on Real Intent’s latest advancements, proven on giga-gate SoC and FPGA designs. Click here to make an appointment for one of our private suite presentations:
    • How to Accelerate Your RTL Sign-off
    • Ascent Lint with New Visualization and VHDL 2008
    • Meridian CDC with New Analysis and Data-driven Flow
    • Ascent XV with Advanced Gate-level Pessimism Analysis
    • Case Studies in Physical CDC Analysis for Gate-Level Sign-off
    • New Next-Generation Constraints Exception Verification
  • Complete a quick verification survey to be entered into drawings for a cool Roku 4 streaming player and an Amazon Echo wireless speaker and voice commander.
  • Espresso Yourself and enjoy a high-speed coffee from our DeLonghi Magnifica super-automatic coffee machine, to celebrate faster verification and design.
  • Visit Real Intent and OpenText (Booth #638), Real Intent’s “Espresso Yourself” partner at DAC; get a ticket stamped by both companies to enter drawings to win $100 Amazon Gift Cards.
  • Receive a rose as a sweet thank-you gift.

Real Intent also invites attendees to view What is the Real Cost of Verification — a stimulating panel on Thursday, June 9, from 3:30-4:30 p.m. in room 18AB. Moderated by Kelly Larson of Paradigm Works, panelists Harry Foster of Mentor Graphics Corp., Pranav Ashar of Real Intent, Inc., Raviv Gal of IBM Research, and Subhasish Mitra of Stanford University will discuss what design cost really includes. They also will explore how to measure and improve verification coverage, reduce rework, and improve the chances of first-time silicon success.

BEST DAC PARTIES

Sunday:

Kick-off your DAC with the Welcome Reception, 5:30pm – 7:00pm, 4th floor foyer of the convention center.  Just before, from 5;00pm – 5:30pm is the Gary Smith EDA at the ESD Alliance Kickoff in Ballroom D.

Monday:

HOT Party, Speakeasy, 412 Congress Ave., 7:30 pm to 11:30 pm

Join Heart of Technology and their sponsors at the swankiest party at DAC. They’ll be pouring the giggle water and serving the eats, Al Capone style. Entertainment will be provided by Killer Tofu, the 1990s band playing Green Day, TLC, Grunge and other music you crave. Once again, we are supporting CASA of Travis County with this fundraiser. It’s going to be the bees knees, man! So get your rags together and join us on June 6 at the Speakeasy, voted Austin’s “best swanky” and “best place to party.”  Free to get-in, donations accepted.  Tickets here: HOT Party at DAC 2016

Tuesday:

The Denali Party By Cadence, Tuesday, 8:00pm to 12:30am, Maggie Mae’s, 323 E 6th Street. You need to pre-register (do it now) and you must pick up your wristband at the Cadence booth #107 before noon on Tuesday, or your reservation will be given to another guest.

*********************************

Stars of IP 2016, 8:00 pm to 1:00 am, Revival Public House, 340 E 2nd Street
(right across the street from the Austin Convention Center), ticket required.

This is a private party organized by IPextreme and their IP partners and friends. Visit one of the co-hosts below on the DAC Exhibit Floor to inquire about spare tickets.

2016starsofipcohosts[1]

Mon., Tues., Wed., Thu.: Don’t forget the daily receptions, 6:00pm to 7:00pm, (5:30pm on Thu.) in the Trinity Street Foyer of the convention center.

See you at the show!



May 27, 2016 | Comments


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

Graham Bell   Graham Bell
   Vice President of Marketing at Real Intent

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?



May 12, 2016 | Comments


May 17 Event: More than Moore – Enabling the Power of System Scaling

Graham Bell   Graham Bell
   Vice President of Marketing at Real Intent

More than Moore – Enabling the Power of System Scaling:
An Open Discussion About Design and Manufacturing Challenges

Join the ESD Alliance on the evening of May 17th at 6PM when we will be hosting an open dialogue about system scaling solutions and what it will take to propel them into the mainstream for semiconductor design and manufacturing. Although various system scaling technologies (such as interposer-based designs, using die-level IP blocks, like HBM) are already in use today, they have not yet crossed into the mainstream.

MultiChip Module

System scaling offers an excellent alternative path to pursuing Moore’s Law by moving the integration focus from the transistor to the integration of several heterogeneous pre-fabricated and proven devices, in the form of die-level IP, into an advanced IC package. Although new sub- 10nm process technologies continue to drive Moore’s Law, development cost and times at these advanced nodes are beyond the reach of much of the mainstream market.

It will take collaboration and cooperation between modeling, design, analysis/verification, manufacturing and test in order to unlock the potential of these new integration solutions. The objective for the meeting is to have an open discussion to identify the highest priority issues that should be jointly worked on to streamline the path to widespread adoption. The ESD Alliance is in the process of forming a working group representing both manufacturing and design to work on practical solutions and is seeking community input on direction and priorities.

This is an open event and we encourage anyone who is involved with or interested in system scaling from either the design or manufacturing perspective to attend. Please join us at 6 pm for networking, food and beverages prior to the open discussion forum, starting at 6:30.

Register Now!
Register Now!
There is no charge for this event.
Participants:
Bob Smith, Executive Director, ESD Alliance
Herb Reiter
, President, eda2asic Consulting, Inc.
Event Details:
Date: Tuesday, May 17 th , 2016
Time: 6:00 PM – 8:00 PM
6:00 PM – 6:30 PM – Registration and networking
6:30 PM – 7:30 PM – Presentations
7:30 PM – 8:00 PM – Discussion
Location: ESD Alliance (SEMI)
3081 Zanker Rd.
San Jose, CA 95134


May 5, 2016 | Comments


7 Design Faults Leading to Clock and Data Glitches

Graham Bell   Graham Bell
   Vice President of Marketing at Real Intent

Recently I came upon an article by Ankush Sethi of Freescale on the importance of avoiding bad design practices that lead to glitches in clocks which result in asynchronous behavior. He points out:

It is very important to make digital designs free of any clock or data glitches to ensure correct functioning. There are many cases where such issues have caused functional failure, or increased design time through incurring extra debug effort. Hence, it is very important for a designer to take care of such issues at the earliest stages of design once flagged by a tool or gate-level synthesis.

Here is his introduction followed by an iframe of the article from EDN magazine.

With the increasing complexity of SoCs, multiple and independent clocks are essential in the design. The design specifications require system level muxing of some of these clocks before they are sent to actual IP. Also, to save power, clock gating cells are inserted in clock paths. While implementing these muxing and gating cells, a designer tends to make mistakes that can lead to glitches. A glitch on a clock signal exposes a chip (or a section of a chip) to asynchronous behavior. A glitch-prone clock signal driving a flip-flop, memory, or latch may result in incorrect, unstable data. This paper discusses structural faults that can lead to glitches in clocks. Also, some bad design practices that lead to glitches in data are discussed. Read the rest of 7 Design Faults Leading to Clock and Data Glitches



Apr 28, 2016 | Comments


DVClub Silicon Valley: “Using UVM Virtual Sequencers & Virtual Sequences”, Wed. Apr. 27

Graham Bell   Graham Bell
   Vice President of Marketing at Real Intent

Please join Silicon Valley verification and design engineers on April 27, 2016 at Dave and Buster’s in Milpitas for a catered lunch, networking, and presentation by Cliff Cummings.  This is a no charge event.

eventbrite_register_button

 Agenda:

11:30am: Doors Open / Networking

12:00pm: Lunch / Presentation

1:00pm: Networking

“Using UVM Virtual Sequencers & Virtual Sequences”

What are virtual sequencers and virtualssequences and when should they be used? Tests that require coordinated generation of stimulus using multiple driving agents benefit from using virtual sequences. This presentation will clarify important concepts and usage techniques related to virtual sequencers and virtual sequences that are not well documented in existing UVM reference materials. This presentation will also detail the m_sequencer and p_sequencer handles and the macros and methods that are used with these handles. The objective of this presentation is to simplify the understanding of virtual sequencers, virtual sequences and how they work.

Cliff Cummings is President of Sunburst Design, Inc., a company that specializes in world-class SystemVerilog, Synthesis and UVM Verification training.Cliff has presented hundreds of SystemVerilog seminars and training classes and has been a featured speaker at multiple world-wide SystemVerilog and Assertion Based Verification seminars. Cliff has been an active participant on every IEEE Verilog and SystemVerilog committee, and has presented more than 50 papers on Verilog & SystemVerilog related design, synthesis, and OVM/UVM verification techniques, including more than 20 that were voted “Best Paper.” Cliff holds a BSEE from Brigham Young University and an MSEE from Oregon State University.

eventbrite_register_button[1]



Apr 21, 2016 | Comments


Verification Coffee Break – Where are We Going?

Graham Bell   Graham Bell
   Vice President of Marketing at Real Intent

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?

Q2. How are designers meeting these challenges?

 Q3. What static verification solutions are needed?

Q4. What about debug?

Q5. What’s next?

Q6. What is the importance of the Israeli market to Real Intent?



Apr 14, 2016 | Comments


UPF 3.0 – Making Power Intent Manageable, Incremental and Executable

Vinod Viswanath  Vinod Viswanath

UPF provides a consistent format to specify power design information that may not be easily specifiable in a design description. In certain situations it is undesirable to specify power semantics directly in the HDL, as doing so might tie down the implementation to certain power constraints. UPF provides a way to specify the power intent for different states and contexts, external to the design, to be used for implementation, modeling, simulation and verification. The semantics of UPF are consistent across implementation and verification, guaranteeing that what is being verified is indeed what was implemented.

UPF assumes a logical hierarchy that is a more abstract model of the design hierarchy. The logical hierarchy can be viewed as a conceptual structure for locating power management objects such as power domains and power states. Each object is defined in a specific scope of logical hierarchy. This logical hierarchy can be effectively used in a top-down UPF methodology, where the more abstract states are higher up in the hierarchy (global states), and the lower hierarchical objects are more refined versions of their ancestors.

Such a top-down methodology is actually very close to current SoC design methodology. Previous designs done in-house or via third-party IP are extensively used in SoC design today to reduce development cost and time to market. To manage these IP-based flows, most SoC designs are implemented with hierarchical top-down design flows. Given the complexity of design analysis, hierarchical design flow also allows a way to overcome capacity limitations of design and verification tools. A top-down UPF flow fits seamlessly with this approach. The tricky part comes with the IP blocks. The power intent specification for an IP block to be used in a larger design typically defines the power interface to the block and the power domains within the block. This specification also typically includes constraints on using the block in a power-managed environment. The IP block UPF, which contains the atomic power domains, power states, and the state transitions of the IP block, is often referred to as a constraint UPF. When the IP is being prepared for use in a larger system, the specification can be enhanced to fit the context of the system (for example, it may require adding isolation and retention strategies). The power specification with this context information is referred to as the configuration UPF. Finally, to drive the implementation, we may have to define power distribution network information, logic for the power management cells, etc. This specification is referred to as the implementation UPF.

Once the UPF hierarchy is set up, UPF provides commands to specifying retention strategies, repeater strategies, isolation strategies and level-shifting strategies. Each of these can be defined in various ways to apply specific design features, with precedence orders in cases where multiple strategies apply to the same feature, etc.

While implementing a system, occasionally it might be necessary to implement an instance separately from the top-level scope, with the intention of integrating this block back into the system later in the flow. This flow style is a bottom-up flow. When using a bottom-up flow, the UPF partitioning has to ensure that the implementation of the lower-level instance can be done without the parent scope being available. Self-contained UPF is UPF that defines its own top-level domain and does not require power intent to be defined in any external scope to complete the power intent.

In system level design simulations, faster run times are generally attained via design abstraction. In order to extend this analysis to accommodate power, we have to annotate power information onto this simulation. UPF provides system-level IP power models for exactly this purpose. The power models are intended to be used in system-level design, although, there is nothing to prevent their use in other types of analysis at all levels of design abstraction. From the standard perspective, modeling all types of IP components is supported with no limitations on use. The IP power model cannot make any changes to the state of the system.

Specifically in the 2015 standard, the UPF power state supports a model (-model) and a power function (-pwrfn) switch to support modeling as well as refinement. Power function of a “current” power state is the natural function to use for power computations at that state. More refined power states would have more detailed power functions.  The power model contains an enumeration of all the power states, power consumption data for each, and a definition of all legal power state transitions.

Even with all these power models, the larger problem remains unaddressed. Today, when SoCs are optimized for specific applications, the optimizations are done in isolation without utilizing the knowledge of the workloads. Due to lack of hardware/software cooperation in power management, the platform as a whole cannot anticipate power requirements of the application ahead of time and, instead, has to perform power management reactively.

Going forward, it is quite clear that neither hardware nor software in isolation can make the best decision about power and performance management, and cannot just manage the CPU alone, but must now include the entire platform level, in a holistic way.  Any such holistic approach needs a common representation of power intent at all levels of design hierarchy, and power management engines at each level need to make decisions based on the unified set of power constraints. It is imperative that a holistic platform-level dynamic power management system be aware of (a) different power states supported by different components, both at architectural and microarchitectural level; (b) current power consumption of the platform as a whole, and at the individual component level; (c) power requirements of applications and workloads; and (d) continuous feedback from the platform on performance with respect to overall power constraints. We need a synergistic bottom line across RTL, System level, OS level, Compiler level, and Application level specifications of power intent. The kind of information available at a higher level of abstraction at the OS level or even at the Application level is just not visible to the RTL. To get the most optimized solution,we need all levels of abstraction of the design to be able to communicate their power intent.

This leads to a new set of abstractions all along the design and application hierarchies, the power abstraction. At the workload level, the application needs to specify what kind of power requirements it has. This translates to compiler level constraints and then O/S constraints and so on all the way to the RTL and gate-level designs. There are two new requirements on such a system:. (1) We need feedback going up the abstraction levels. The hardware needs to let the O/S know how it is performing, power-wise and so on. (2)We need a fast and dynamic constraint solver/power manager that can combine the feedback with the spec to generate the next set of optimizations.

Key to all this coming together is a standard way to communicate across these levels of energy abstractions. IEEE Standards Association is addressing this via three ongoing standards efforts – IEEE 1801 (system power), IEEE P2415 (power specification in software and O/S), and IEEE P2416 (power modeling).

Beyond this, thermal considerations cannot be handled in isolation either. The objective of thermal management is to meet “maximum operating temperature” constraints, while maintaining performance requirements. Typically thermal control policies manage power consumption via dynamic frequency and voltage scaling (DVFS) and can be targeted to power density reduction because it has the effect of reducing overall temperature. Thermal control policies using DVFS avoid violations of temperature bounds by transitioning processors into low power modes to cool down, but obviously this incurs a performance penalty. In addition, abrupt power mode transitions due to DVFS could also waste power.



Apr 7, 2016 | Comments