Blog Archive
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!

CDC Verification of Fast-to-Slow Clocks – Part 3: Metastability Aware Simulation

Roger Hughes   Dr. Roger B. Hughes
   Director of Strategic Accounts

We continue the short blog series that addresses the issue of doing clock domain crossing analysis where the clocks differ in frequency. In Part 1 and Part 2, we discussed the use of structural and formal checks when there is a fast-to-slow transition in a clock domain crossing. In this blog, we will present the third and final step using a design’s testbench.

The next step in the verification process of fast-to-slow clock domain crossings is to do metastability-aware simulation on the whole design. When running a regular simulation test bench, there is no concept of what could happen to the design if there was metastability present in the data or control paths within the design. One of the key reasons for doing CDC checks is to ensure that metastability does not affect a design. After structural analysis ensures that all crossings do contain synchronizers, and formal analysis ensures that the pulse width and data are stable, a whole-chip metastability-aware simulation is needed to see if the design is still sensitive to metastability. Functional monitors and metastability checkers are shown in Figure 7. No changes are made to the design, and the necessary monitors and checkers are written in an auxiliary Verilog simulation test bench file. This auxiliary file is simply referred to by the original simulation test bench file to invoke the metastability checking. As a prerequisite, this step requires that the design have a detailed simulation test bench.

Figure 7 – Metastability aware simulation checks the tolerance of downstream logic to the presence of jitter in the data path through the use of functional monitors and CDC checkers.

Figure 7 – Metastability aware simulation checks the tolerance of downstream logic to the presence of jitter in the data path through the use of functional monitors and CDC checkers.

Meridian CDC enables metastability simulation sign-off by offering two capabilities. First, it randomly inserts cycle jitter onto the control or data crossings to mimic the metastability effect; Second, it writes simulation checkers to catch violations during simulation. This combined effect enables metastability simulation sign-off using Meridian CDC.

FAST-TO-SLOW CLOCK METHODOLOGY SUMMARY

To provide rigorous clock domain crossing checks on a design, especially one containing transitions of a fast-to-slow nature, three steps must be done.

  1. Use structural checking to ensure all crossings – including fast-to-slow clock and slow-to-fast clock – are CDC safe. This means that all crossings have been checked to have the data switched via a control signal that has the appropriate levels of synchronization.
  2. Use formal verification on all CDC crossings to ensure control signals have a sufficient pulse width to enable the receiving domain clock to capture the transmit domain’s control pulse. This step is especially important for all fast-to-slow clock domain crossings. Use formal analysis to examine the data transitions for data stability. These checks are PULSE_WIDTH and DATA_STABILITY, respectively.
  3. Use metastability-aware simulation on the entire design with an existing simulation test bench to insert random metastability into data and control crossings. Run the simulation against specialized checkers that are automatically generated to prove that the design is not sensitive to metastability.

After these three steps are carried out, designers will have full confidence that the fast-to-slow clock domain crossings are analyzed correctly.

CONCLUSION

Modern CDC tools, such as Meridian from Real Intent, provide a mix of approaches for sign-off of clock domain crossing analysis. Three techniques were progressively discussed when fast-to-slow clocks were used. Structural checks can be quickly run even on large designs on the whole design When a design is has passed structural analysis, formal checks of certain crossings can be done locally. This is required for all fast-to-slow clock transitions of control signals, either on the feed-forward circuit or on the feedback circuit, depending on which circuit has a fast-to-slow transition. Finally, simulation test benches can be augmented with random metastability injection and checkers to verify that the design is tolerant of metastability.



Jan 28, 2016 | Comments


CDC Verification of Fast-to-Slow Clocks – Part 2: Formal Checks

Roger Hughes   Dr. Roger B. Hughes
   Director of Strategic Accounts

We continue the short blog series that addresses the issue of doing clock domain crossing analysis where the clocks differ in frequency. In Part 1, we ended the discussion noting that when there is a fast-to-slow transition, there is a possibility that a short duration control pulse may be completely missed by the receive domain and a formal analysis is required to discover if this is a potential problem. We will look at how formal analysis can verify this kind of transition.

A formal check also is required on a slow-to-fast data crossing with feedback. In such a circuit, as shown in Figure 4, an acknowledge signal coming from the receiving fast-clock domain to the transmitting slow-clock domain also requires a formal Pulse Width check. Although the control pulse (request) is going from slow to fast and does not need a formal pulse width check, the acknowledge pulse-width check is necessary because the acknowledge signal (the feedback circuit) is going from a fast to a slow clock and, in order for the acknowledge to be properly captured, the acknowledge pulse (transmitted from the receiving side) must be sufficiently wide to be captured (received on the transmitting side) by the slower clock domain of the transmitting side flops. Failure to check for this condition is the reason behind many a request/acknowledge circuit not working as expected. Note that feedback circuits in a fast-to-slow crossing are operating in a slow-to-fast mode and the acknowledge signal in such a circuit does not need to be pulse-width checked. In short, all fast-to-slow control signal transitions, whether connected in a feed-forward or a feedback manner need to be formally pulse-width checked to ensure integrity of the control aspect of the clock domain crossing.

Figure 4 – Slow-to-Fast Clock Crossing with Feedback (red flops are slow clock, blue flops are fast clock).

Figure 4 – Slow-to-Fast Clock Crossing with Feedback (red flops are slow clock, blue flops are fast clock).

To check if the fast-to-slow clock domain crossings have control signals that can be captured by the receive domain clock, Meridian CDC offers formal analysis capability targeted at the asynchronous clock domain crossings of interest. There is a requirement that the control pulse in the fast transmit domain must be of a certain minimum width in order to be captured by the slower receive domain clock. Figure 5 shows that TX CNTL must be held high for several clock periods of Clk1 for the TX domain flop value to be captured by the RX domain Sync1 flop and then passed into RX domain Sync2 flop. A formal check called PULSE_WIDTH verifies that the transmit domain’s control pulse has sufficient length to be captured by the receive domain’s clock in all circumstances. This check examines all the pulse generation logic and takes into consideration the clock frequency ratio during detailed formal analysis to determine pass or fail. If there is a case in which the pulse length is insufficient, a counter example is generated to show the circumstances in which this would occur. If PULSE_WIDTH passes, the crossing shown always has correct control pulse duration to ensure there will not be a missed control pulse.

Figure 5 – Fast-to-slow clock domain crossing with sufficient pulse length. Here the TX CNTL pulse is held high for a sufficient number of TX Clk1 periods so that an edge of RX Clk2 is able to sample the value on the TX CNTL flop into the RX CNTL Sync1 flop, which then can pass the value to RX CNTL Sync2. This can be formally proven using the PULSE_WIDTH check of Meridian CDC.

Figure 5 – Fast-to-slow clock domain crossing with sufficient pulse length. Here the TX CNTL pulse is held high for a sufficient number of TX Clk1 periods so that an edge of RX Clk2 is able to sample the value on the TX CNTL flop into the RX CNTL Sync1 flop, which then can pass the value to RX CNTL Sync2. This can be formally proven using the PULSE_WIDTH check of Meridian CDC.

There also needs to be a check on the data path. There is a possibility that if the data is not held stable for a long enough period, it might get missed in the receive domain. For example, suppose the transmit domain has the data sequence <D0><D1><D2><D3>, etc. This sequence of data changes is shown in Figure 5. If the data changes before the control signal has been passed to the receive domain, it is possible that the receive domain might miss some data and end up with <D0><D1><D3>… if <D2> was not correctly transmitted to the receive domain. An additional formal check in Meridian CDC called DATA_STABILITY ensures that the data transitions at a slow enough rate to be captured by the transmit domain clock and then transferred to the receive domain. Only a formal check using full sequential analysis of behavior can do this correctly.

Figure 6 – Fast-to-slow clock domain crossing with data instability. It is important that the data is held stable long enough to be captured by the receive clock RX Clk2. If the data changes too quickly, an element of the data will be missing in the receive clock domain, as shown with D2 missing from the data stream in the receiving clock domain. This can be formally proven using the DATA_STABILITY check in Meridian CDC as part of the formal analysis.

Figure 6 – Fast-to-slow clock domain crossing with data instability. It is important that the data is held stable long enough to be captured by the receive clock RX Clk2. If the data changes too quickly, an element of the data will be missing in the receive clock domain, as shown with D2 missing from the data stream in the receiving clock domain. This can be formally proven using the DATA_STABILITY check in Meridian CDC as part of the formal analysis.

For all the formal checks, additional information is required beyond just using the structural checks. In structural checking, the environment can be captured automatically with very little user input required for resets and clocks. In contrast, formal checks require that all the reset signals be very accurately associated with their corresponding clocks. All clock frequencies must be specified for the appropriate formal checks to be made on the fast-to-slow clock domain crossings. So setup for formal is necessarily more complex and requires detailed design knowledge about all the frequencies of clocks and combinations of those frequencies. For example, multi-mode designs also need the selection signals for mode selection to be specified by the user. Where appropriate, automatic multi-frequency analysis also can be addressed by the formal engines within Meridian CDC.

In Part Three, the conclusion for this series, we will discuss doing metastability-aware simulation on the whole design.



Jan 21, 2016 | Comments


CDC Verification of Fast-to-Slow Clocks – Part 1: Structural Checks

Roger Hughes   Dr. Roger B. Hughes
   Director of Strategic Accounts

This is a reprise of  a short blog series that addresses the issue of doing clock domain crossing analysis where the clocks differ in frequency, and the use of three different techniques for a complete analysis.

INTRODUCTION

CDC checking of any asynchronous clock domain crossing requires that the data path and the control path be identified and that the receive clock domain data flow is controlled by a multiplexer with a select line that is fed by a correctly synchronized control line.  Meridian CDC will always identify all the data and associated control paths in a design and will ensure that the control signals passing from a transmit clock domain to an asynchronous receive clock domain are correctly synchronized.  There are three separate techniques that are used within Meridian CDC: structural checking, formal checks and simulation-based injected metastability checks.

STRUCTURAL CHECKING

The structural checking approach does not care if the asynchronous transitions are slow to fast clocks or fast-to-slow clocks.  It will ensure that all the transitions are correctly synchronized in terms of having the appropriate synchronizer flops.  From a structural perspective, the entire design can be checked in one run and all the clock domain transitions checked for correctness.  Let’s look at an example CDC in Figure 1, with transmit clock Clk1 on the left (orange flops), and the receiving clock Clk2 on the right (blue flops).

Fig. 1 – A Typical Synchronized Control and Data Clock Domain Crossing.

Fig. 1 – A Typical Synchronized Control and Data Clock Domain Crossing.

It can be seen in Figure 2, where positive going clock edges are shown by the vertical lines, that all will work well for a slow-to-fast clock transition.  This is because any change of a control signal in the slow domain will always be captured by one of the edges of the receive domain clock, Clk2, before Clk1 causes the control signal to be released since Clk2 is faster than the transmit domain clock, Clk1.  Also, for slow-to-fast clock transitions the data will typically always be stable long enough to be captured and transmitted through to the receive domain.  In Figure 2, the possible Clk2 edges that could capture the TX CNTL signal in RX CNTL Sync2 flop are shown with dashed vertical lines.

Figure 2 – Slow-to-Fast Clock Crossing. There are many possible clock edges, shown dashed, of RX Clk2 that can sample the value held in the TX CNTL flop. The dot-dash edge is the first possible transition into Sync1, dashed are transitions into Sync2. There is no issue with TX CNTL period as long as the signal is sampled by one clock edge of TX Clk1.

Figure 2 – Slow-to-Fast Clock Crossing. There are many possible clock edges, shown dashed, of RX Clk2 that can sample the value held in the TX CNTL flop. The dot-dash edge is the first possible transition into Sync1, dashed are transitions into Sync2. There is no issue with TX CNTL period as long as the signal is sampled by one clock edge of TX Clk1.

However, the situation is different in a fast-to-slow clock domain crossing.  When there is a fast-to-slow transition, there is a possibility that a short duration control pulse may be completely missed by the receive domain.  To address this concern, and others that cannot be addressed by a purely structural CDC check, formal analysis is required.

Next time we will look at how formal analysis can verify this kind of transition.



Jan 14, 2016 | Comments


DeepChip.com Survey: “Real Intent to possibly replace SpyGlass?”

Graham Bell   Graham Bell
   Vice President of Marketing at Real Intent

It’s not a BUG, it’s a FEATURE!

John Cooley at DeepChip.com does an annual survey of visitors to the Design Automation Conference to find out what was interesting, and the biggest lie.

In one of his roll-up articles he looked at Real Intent, Atrenta (acquired by Synopsys), and One Spin.

With acquisitions, customers get nervous and for good reason.  The support and responsiveness they get changes.  Five respondents said they were considering possibly replacing SpyGlass with Real Intent.  One user reported the following conversation:

“Your SpyGlass customer support won’t change as a result of the SNPS acquisition.” They actually said that to me with a straight face.

The article also reported a customer evaluation of our Ascent Lint and Meridian CDC (clock-domain crossing) tools. Here is a quick snippet:

 

Wanted to check whether we could identify design bugs with Real Intent that were being missed before.

Started with Ascent-Lint on one of our small a8051 microcontroller IP blocks which was in pure Verilog design and 17K gates in size.

From the start, we noticed that Ascent Lint was very easy to run.

Within minutes getting it installed we were able to run the tool on our a8051 with practically no time spent on set up.

We caught a few issues even on it. One FSM was missing a “default” statement. The designer missed this issue because of an involved mix of pragmas and `defines in the RTL code. Ascent Lint ran in under a minute to find the need to make a RTL fix for this. There were few other minor FSM-related issues identified we passed those on to the
a8051 design team.

Next we ran their Meridian CDC clock-domain analysis tool on our Ethernet MAC IP, a 40K gate Verilog design which had 4 different clock domains.

…When running Meridian to catch CDC problems, it was correctly able to identify our CNTL synchronizer and our other synchronizer structures automatically.

…The Meridian reports provided appropriate details of the violations without bombarding us with too much information.

After the end of our eval, we decided to start using both Real Intent tools on our next IP development project. We also plan to recommend Ascent Lint and Meridian CDC tools to our consulting clients.

 

You can read the entire report here.

Happy Holidays!



Dec 18, 2015 | Comments


Best of “Real Talk”, Q4 Summary and Latest Videos

Graham Bell   Graham Bell
   Vice President of Marketing at Real Intent

Real Intent has had an exciting 2015!  In the last few months we had a new release of Meridian CDC, a new distribution partner in Israel, and seen many of you at trade shows in China, Israel, Japan, and Germany.  Our YouTube video channel keeps you up to date on all the latest developments at Real Intent, with our most recent on Why A New Gate-level Physical CDC Verification Solution is Needed and X-pessimism: Why do We Care, and What are the Wrong and Right Fixes for it?.  I also discussed “New Physical CDC Sign-off and iDebug analysis” with Sanjay Gangal in an ARM TechCon video interview.

There have been over 50 postings on the Real Talk blog this year, and I have selected the most popular ones read by the EDACafe audience. Here are the top seven:

Is SystemVerilog the COBOL of Electronic Design?
Good news! The Next Big Thing in Verification is Already Here
A Personal History of Transaction Interfaces to Hardware Emulation
In fond Memory of Gary Smith
The Many Tentacled Monster Under My House (with pictures)
Taking Control of Constraints Verification
Billion Dollar Unicorns

Look for more postings on requirements for RTL sign-off in the coming year.

Happy Holidays!



Dec 10, 2015 | Comments


Exposing and Eliminating X-optimism Bugs in RTL

Lisa Piper   Lisa Piper
   Technical Marketing Manager

X-optimism occurs when an unknown X value is incorrectly resolved to a known value in RTL simulation. Optimism issues can be difficult to detect and debug because the X is no longer visible once the optimism occurs. The functional issue may not show up at an output for many, many clock cycles after the optimism. X-optimism issues also show up in a gate-level netlist or FPGA-based prototypes, but debug is difficult due to limited visibility in FPGAs, and netlist designs are less familiar post-synthesis. Trying to find an X-optimism bug in an FPGA model is like looking for a needle in a haystack due to limited visibility. In netlist simulations the design hierarchy is flattened, signal names changed, and there is a danger that the X under consideration will be mistaken for a pessimistic node and forced to a known value that hides a functional issue.

Real Intent’s Ascent XV uses static analysis to identify potential X-optimism issues at RTL so they can be fixed prior to simulation, ensuring efficient and accurate simulations. Fixing optimism issues in RTL streamlines getting netlist simulations or FPGA-based prototypes, up and running faster and reduces costly iterations.

X-optimism Defined

X’s can cause X-optimism in RTL simulations. X-optimism occurs when an unknown value is simulated as though it is a known value in hardware. Consider the example shown in figure 1 below. If the “input” signal is an X value, this means that “input” could be either a 0 or a 1 value in real hardware (because real hardware cannot have a X value). So in real hardware, signal “D” might also be a 0 or a 1 value. However, in simulation, the output “D” would always show as a 1 value.   It is called “optimism” because the unknown was resolved as a known value. This can cause functional bugs to be missed in RTL simulations, though in netlist the X would always be properly propagated.

Figure 1. X-optimism Example.

Figure 1. X-optimism Example.

Ascent XV-RTL Optimism Static Analysis

Ascent XV provides a totally static solution that is used prior to RTL simulation to ensure that simulation is free of X-optimism issues that cause inaccurate simulation. It is also used to monitor or model potential optimism points in simulation should you choose not to fix the issues. The advantage of the Ascent XV approach is that the static analysis identifies the select few constructs that need to be monitored or modeled for X-accuracy, versus all constructs in the design. Figure 2 below shows the flow, with the tasks done by Ascent XV on the left, outputs in the middle, and user actions on the right.

Figure 2. Ascent XV Optimism Flow.

Figure 2. Ascent XV Optimism Flow.

The first step of the flow is to read in the design and specify the clocks and resets. Reset and clocks are used to determine X-sources from uninitialized flops and latches. Ascent XV will automatically generate this design specific specification. Ascent XV supports complex reset scenarios, such as phased resets. Clocks can also be configured for a delayed start. Support of complex reset scenarios is key to an accurate reset analysis.

To analyze X-optimism, you must first identify all X-sources that cause X-optimism. Next, trace where those X-sources can propagate and cause X-optimism issues. The third step is the reporting of the results in a complete and concise manner to enable fixing the issues. Once the analysis is complete, you can also choose to use SimPortal.

X-source Analysis

Minimizing X-sources is key to eliminating X-optimism issues. Structural analysis ensures that all potential sources of X’s are included. The built-in formal analysis minimizes noise and ensures accuracy. X-sources identified by structural analysis include such things as unconnected module input ports, bus contention, operations with an unknown result like reading from a non-existent RAM address, and out of range bit selects and array indices. Formal analysis is then used to identify uninitialized flops and latches in the design, taking into account the design resets and the propagation of known values. Reset analysis minimizes noise by accurately modeling what happens in real hardware, thereby minimizing uninitialized flops and latches as X-sources.

X-propagation Analysis

X-propagation analysis traces where the X-sources can propagate. Ascent XV will trace the propagation of each X-source through the design, noting where it can cause X-optimism and what signals might exhibit optimistic values.

X-optimism Reporting

Ascent XV’s reporting of X-optimism is designed to be concise and to guide the user through understanding first where the X-sources in the design are, and secondly where they can propagate. This enables first eliminating as many X-sources as possible, and then managing the remaining X-propagation issues. Also, Ascent XV has automatic waivers that reduce noise.

The first section of the report shows the results of the X-source analysis, and for each X-source a summary of the propagation analysis. The X-source section identifies the type of X-sources. X-sources are prioritized and sometimes automatically waived based on the propagation analysis.

A VCD waveform trace can be viewed that shows the initialization process. This can be very useful for determining why initialization did not occur.

Once as many X-sources are eliminated as is practical, review of the X-propagation analysis section is needed. This section shows where X-optimism can potentially occur so it can be addressed either via X-accurate coding or SimPortal monitoring and modeling. Constructs with X-accurate coding can be automatically waived to minimize unnecessary analysis. The reporting of X-propagation groups both the signals that might have X-optimistic values together with the control signals to which an X can propagate and cause the optimism. Only those constructs to which an X can propagate are analyzed, and only the control signals to which an X can propagate are listed. The presentation of information helps to determine whether it is best to code for X-accuracy or simply monitor.

A third section of the report provides reset analysis information, indicating how initialized flops became initialized, either from an asynchronous reset, a synchronous reset, or via data propagation of known values. The reset section also shows the initialized value and time of initialization based on the clock specifications.

SimPortal Simulation

Once the X-optimism analysis is complete, Ascent XV can generate SimPortal files to address unresolved issues. SimPortal files are side files that are integrated into an existing simulation environment. Ascent XV’s SimPortal simulation add-ons allow for selective dynamic monitoring and/or automatic X-accurate correction during RTL simulation. The most common example is to monitor whether inputs to the device have X’s, and also to report when an output has an X. Another type of checker will check that X’s do not occur on clocks and resets, as this can also cause optimism.

Summary

Ascent XV- RTL Optimism uses static analysis to eliminate X-optimism issues before you get to simulation, so simulations can run faster with X-accuracy. Its hardware accurate reset analysis uncovers where X’s exist after initialization, and ensures accurate analysis of potential X-propagation. Noise reduction techniques that have improved over 5 years of usage result in precise, compact, and non-redundant reporting of potential X-optimism. The prioritization of X’s that need to be eliminated, reset optimization to ensure that there are no uninitialized flops that can drive control logic, and the root cause analysis of each optimism point, together streamline debug to eliminate potential X-optimism issues before handing off the RTL.

Ascent XV-RTL Optimism has proven to catch missed X-optimism issues in real designs, and is much more efficient than a later debug of issues in hardware or in netlist simulations. Ascent XV can be used to eliminate X-sources in the design, identify where those X’s create an optimism risk, and can correct pessimism at the netlist. Ascent XV is a total X-Verification solution that leverages static analysis to ensure efficient and accurate simulations.



Dec 3, 2015 | Comments


Happy Thanksgiving and 2 Political Cartoons!

Graham Bell   Graham Bell
   Vice President of Marketing at Real Intent

Just in case you have never read a Presidential proclamation, here is the text for Thanksgiving Day, 2015.  I learned something when I read it.  Following this are two political cartoons for your amusement.  Happy Thanksgiving to All!


THANKSGIVING DAY, 2015

– – – – – – –

BY THE PRESIDENT OF THE UNITED STATES OF AMERICA A PROCLAMATION

Rooted in a story of generosity and partnership, Thanksgiving offers an opportunity for us to express our gratitude for the gifts we have and to show our appreciation for all we hold dear.  Today, as we give of ourselves in service to others and spend cherished time with family and friends, we give thanks for the many blessings bestowed upon us.  We also honor the men and women in uniform who fight to safeguard our country and our freedoms so we can share occasions like this with loved ones, and we thank our selfless military families who stand beside and support them each and every day.

Our modern celebration of Thanksgiving can be traced back to the early 17th century.  Upon arriving in Plymouth, at the culmination of months of testing travel that resulted in death and disease, the Pilgrims continued to face great challenges.  An indigenous people, the Wampanoag, helped them adjust to their new home, teaching them critical survival techniques and important crop cultivation methods.  After securing a bountiful harvest, the settlers and Wampanoag joined in fellowship for a shared dinner to celebrate powerful traditions that are still observed at Thanksgiving today:  lifting one another up, enjoying time with those around us, and appreciating all that we have.

Carrying us through trial and triumph, this sense of decency and compassion has defined our Nation.  President George Washington proclaimed the first Thanksgiving in our country’s nascence, calling on the citizens of our fledgling democracy to place their faith in “the providence of Almighty God,” and to be thankful for what is bequeathed to us.  In the midst of bitter division at a critical juncture for America, President Abraham Lincoln acknowledged the plight of the most vulnerable, declaring a “day of thanksgiving,” on which all citizens would “commend to [God’s] tender care” those most affected by the violence of the time — widows, orphans, mourners, and sufferers of the Civil War.  A tradition of giving continues to inspire this holiday, and at shelters and food centers, on battlefields and city streets, and through generous donations and silent prayers, the inherent selflessness and common goodness of the American people endures.

In the same spirit of togetherness and thanksgiving that inspired the Pilgrims and the Wampanoag, we pay tribute to people of every background and belief who contribute in their own unique ways to our country’s story.  Each of us brings our own traditions, cultures, and recipes to this quintessential American holiday — whether around dinner tables, in soup kitchens, or at home cheering on our favorite sports teams — but we are all united in appreciation of the bounty of our Nation.  Let us express our gratitude by welcoming others to our celebrations and recognize those who volunteer today to ensure a dinner is possible for those who might have gone without.  Together, we can secure our founding ideals as the birthright of all future generations of Americans.

NOW, THEREFORE, I, BARACK OBAMA, President of the United States of America, by virtue of the authority vested in me by the Constitution and the laws of the United States, do hereby proclaim November 26, 2015, as a National Day of Thanksgiving.  I encourage the people of the United States to join together — whether in our homes, places of worship, community centers, or any place of fellowship for friends and neighbors — and give thanks for all we have received in the past year, express appreciation to those whose lives enrich our own, and share our bounty with others.

IN WITNESS WHEREOF, I have hereunto set my hand this twentieth day of November, in the year of our Lord two thousand fifteen, and of the Independence of the United States of America the two hundred and fortieth.

BARACK OBAMA



Nov 25, 2015 | Comments


Video: “Why A New Gate-level CDC Verification Solution?”

Graham Bell   Graham Bell
   Vice President of Marketing at Real Intent

Recently, I interviewed Vikas Sachdeva, Sr. Technical Marketing Manager at Real Intent where we discuss why gate-level CDC verification is necessary, what are some of the failure modes that can occur, and why Meridian Physical CDC is the right tool to do gate-level sign-off. You can see the video below.  You can also find more information about Meridian Physical CDC here.

Click here to watch other Real Intent videos on our YouTube Channel.



Nov 19, 2015 | Comments


Is SystemVerilog the COBOL of Electronic Design?

Luc Burgun   David Scott
   Principal Architect

A few weeks ago I attended the “10 Years of IEEE 1800™ SystemVerilog Celebration” lunch at an IEEE Standard Association symposium.  One of the Verilog/SystemVerilog world’s luminaries sat next to me, and he started talking to other luminaries about how his son, as part of a general engineering degree, was using SystemVerilog.

I had to ask: “With more of a software background, what’s his reaction to SystemVerilog?  It must seem like a godawful mess.”

He said, “He used those same words.”

Several months ago, I wondered whether SystemVerilog was the most complex computer language yet invented, and I found this page on StackOverflow.  The number of keywords may not be the best metric of language complexity, but it is simple and easy to calculate.  According to this answer, COBOL (the Common Business-Oriented Language invented in 1959) has 357.  SystemVerilog has 323.  C#, Microsoft’s answer to C++ and JAVA, is a distant third with 102.  If this answer is complete, nothing competes with COBOL and SystemVerilog.

I didn’t even realize COBOL is still very much used, but in financial software, it is.  Learn a little bit about it from Wikipedia, and you see that it is crammed full of miscellaneous features, such as report writing features.  In the Criticism section of the Wikipedia page for COBOL, there is this line: “No academic computer scientists participated in the design of COBOL; all of those on the committee came from commerce or government.”  All this sounds familiar, doesn’t it?

I understand how SystemVerilog came to be, as I was working on Mentor ModelSim/Questa at the time when we beat Synopsys VCS to the first commercial SystemVerilog release.  It was Synopsys’ bid to replace “e“, and ModelSim’s bid to re-brand itself as a verification tool.  Cadence followed.  SystemVerilog is really a number of completely different languages in one.

Now working on the front-end of the toolset of a mid-tier EDA company, one of the few left these days, I have a different take on SystemVerilog.  First, we mostly care about the synthesizable or design subset of the language.  It’s not even clear what that is, and it keeps changing as the synthesis tools get updated, and I think may even be significantly different between ASICs and FPGAs (though I don’t as yet have any solid evidence for that observation.)  While we are eternally grateful for the existence of Verific parser platforms as the bedrock of our front-end, we do our own netlist elaboration or construction later in the flow.  That means we have to contend with the combinatoric complexities of the language: the many different ways in which features may be combined.

Having been previously aware of the test bench part of SystemVerilog, the design side of the language continues to surprise me.  Do we really need elaborate regular-expression matching in case statements?  Did you know that a use model of storing pre-compiled library elements on disk, which everyone knows is the traditional ModelSim compile model, is actually enshrined in the standard “for clarification purposes”?  And what about interfaces?  They don’t allow you to do anything you fundamentally couldn’t do before, but they do make the code more confusing by guaranteeing that you can no longer look at a module by itself and know what its I/O is.  Now you have to look in four places: the module definition, the module instantiation, the interface definition, and the interface instantiation.

I have to spend a few moments on interfaces, as they came up during a hallway discussion at the IEEE symposium.  An interface is a so-called “wire bundle”, an encapsulation of interconnect.  Optionally, it may have modports, which can make some of the wires or variables inaccessible, or restrict them to read or write access.  You can put modports in a generate statement, creating a sort of macro expansion of them.  I defy anyone to point to anything in the LRM that describes how to use modports inside generates.  Declare them, yes; use them, not really.  In versions we had from last year, one simulator just generated a lot of errors, another said modports inside generates were not supported (the right answer, I think), and another bravely tried to implement them — except that I never could figure out how to connect them.  Verific has perhaps the best answer, which is using a so-called generic interface reference, in other words, an interface connection that is bizarrely completely un-typed, allowing any kind of interface to be connected, as long as the names elaborate correctly.  As language design, this is weird.

When I brought up interfaces, the hallway discussion covered more-or-less the following points.  Isn’t an interface just a struct?  They aren’t really useful.  Virtual interfaces are useful.  Interfaces would be useful if you could derive from them like a class.  Does anyone really use interfaces?  Bear in mind these are people who have served on the committee.  I had to point out that the most popular synthesis tool partially supports them.  We have at least two customers using them extensively.  I was gratified that one of the SystemVerilog luminaries agreed that the LRM was “specification by example,” and he told of a very recent customer phone call discussing an error in the interfaces chapter.

You as a user can choose what to use in SystemVerilog; we as a vendor cannot.  In some cases, for example the unique/priority keywords on ifs and cases, for which I implemented Ascent IIV formal checks last year, the language helps by standardizing something previously proprietary.  In other cases, where the language offers new features for creating structure, it merely adds to the combinatoric complexity of building a design correctly.  If there is innovation to be had in EDA, I have the feeling that won’t be where it lies.  It will lie, perhaps, in something like the X-optimism and X-pessimism features of Real Intent Ascent XV — but the complexities of the front-end act as a tax on that effort.



Nov 12, 2015 | Comments


Google Designing Its Own Next-Generation Smartphone SoCs?

Graham Bell   Graham Bell
   Vice President of Marketing at Real Intent

Courtesy Ron Amadeo and Intel

Courtesy Ron Amadeo and Intel

Google is starting to push to have more say in the design and architecture of the chips that run the Android system in smart phones.  They are also apparently making major investments into virtual reality, where some of the chip design effort is expected. And hiring staff from major SoC companies.

Ron Amadeo from the tech publication Ars Technica has published the following online report:  According to a pair of reports from The Information (subscription required), Google has big ambitions for the inside of Android phones. The report says the search giant has sent a long list of requests to chip manufacturers for future SoC designs and that Google is even planning to build its own processors.

The report says that during discussions that happened this fall, “Google representatives put forward designs of chips it was interested in co-developing, including a phone’s main processor.” The new chips are reportedly needed for future Android features that Google hopes to release “in the next few years.” By designing its own chips, Google can make sure the right amount of horsepower gets assigned to all the right places and remove bottlenecks that would slow down these new features.

The report specifically calls out “virtual and augmented reality” as use cases for the new chips. Publicly, only Google Cardboard has surfaced from Google’s VR initiative, but internally, it seems like the company is gearing up for a huge VR push. Some of Google’s biggest names have left their posts on flagship products to go work on the virtual reality team: Jon Wiley, the lead designer of Google Search, and Alex Faaborg, the former lead designer for Firefox, Google Now, and Android Wear. An earlier report from The Wall Street Journal claimed Google was building a version of Android that would become a virtual reality operating system.

Read the rest of Ron Amadeo’s article here and learn who Google is hiring.



Nov 5, 2015 | Comments