Open side-bar Menu
 Decoding Formal

Archive for the ‘Blog’ Category

Calling All Formal Enthusiasts: Join the Oski “Decoding Formal” Club

Thursday, August 15th, 2013

In our years of providing formal verification services to leading-edge semiconductor companies, I have had the pleasure of meeting and working with many smart and dedicated engineers who paved the way of formal adoption in their companies – studiously applying formal technology to verify more complex designs as well as building up formal methodology so formal can become part of sign-off criteria in their verification flow. I have had countless discussions with these individuals on the nature of formal technology, best practices in formal application, and ways of getting the most out of formal tools in verification. These are valuable mutual learning experiences for all of us.

In working with these formal technologists and practitioners, I have always wanted to create a forum for these kindred spirits – formal enthusiasts, pioneers, leaders and friends who work in different companies but on the same mission. The goal is to promote idea sharing among us so together we can further advance formal technology and broaden formal adoption in the industry.

(more…)

IP Customers Beware! “Silicon Proven” IP May Not Be Fully Verified

Friday, July 26th, 2013

The verification of all configurations (reaching in millions) of an (silicon) IP is a challenge. I have experienced this problem first-hand both from the vendor side as an embedded SRAM (eSRAM) compiler designer, and from the customer side, as an architect of a wireless SoC using 3rd party IPs.

When I was eSRAM compiler designer, eSRAM used to support hundreds of thousands of configurations based on address widths, data widths, data masking, low power features, etc. In order to meet performance for different configurations, I sometimes designed different internal architectures of eSRAMs for different configurations. Due to the large number of configurations, verification is performed only on the configurations where the designer identifies the greatest need, for example when there is an architecture change either in the design or layout. Though this approach may appear to be comprehensive, I have seen silicon failures because the configurations picked for silicon had not been verified. The failures were due either to design modeling error or layout programming error. These failures could have been caught at the verification stage, if all configurations of eSRAMs were verified. However using simulation as the sole verification technology, verifying all configurations was simply not possible.

(more…)

CST: Webinar series
TrueCircuits: IoTPLL



Internet Business Systems © 2017 Internet Business Systems, Inc.
25 North 14th Steet, Suite 710, San Jose, CA 95112
+1 (408) 882-6554 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise