Comments on: Devil in the Details: Trends in ASIC Prototyping http://chipdesignmag.com/sld/blog/2008/10/23/devil-in-the-details-trends-in-asic-prototyping/ Deep Insights for Chip Architects and Engineers Thu, 24 May 2012 23:22:49 +0000 hourly 1 http://wordpress.org/?v= By: J Ralph http://chipdesignmag.com/sld/blog/2008/10/23/devil-in-the-details-trends-in-asic-prototyping/comment-page-1/#comment-52 J Ralph Sat, 25 Oct 2008 06:05:36 +0000 http://chipdesignmag.com/sld/?p=360#comment-52 If the 50 – 60% of re-spins caused by logic and functional errors could be broken down into more granularity, I wonder what the causes are? Is it communication errors between the different developers? Is it mis-understandings during the analysis of specs and requirements? Is it errors that could be caught by better code reviews? Is it un-realistic schedules and feature creep? Is it poor functional verification planning and coverage? Is it poor partitioning and un-needed complexity? Could FPGA physical prototyping have caught the errors? While throwing more functional verification at the problem reduces the likelihood of a re-spin, preventing the issues at the source with smarter design methodologies is far less costly. All too often the design techniques are rushed and skimped. The design mentality is to hammer out RTL as quick as possible, and let the verification engineer find the bugs. Designers are in the best position to prevent and find and fix bugs since they know the design better than others. It takes verification engineers a lot longer to find and track down bugs, since they are less familiar with the design. If the 50 – 60% of re-spins caused by logic and functional errors could be broken down into more granularity, I wonder what the causes are? Is it communication errors between the different developers? Is it mis-understandings during the analysis of specs and requirements? Is it errors that could be caught by better code reviews? Is it un-realistic schedules and feature creep? Is it poor functional verification planning and coverage? Is it poor partitioning and un-needed complexity? Could FPGA physical prototyping have caught the errors?

While throwing more functional verification at the problem reduces the likelihood of a re-spin, preventing the issues at the source with smarter design methodologies is far less costly. All too often the design techniques are rushed and skimped. The design mentality is to hammer out RTL as quick as possible, and let the verification engineer find the bugs. Designers are in the best position to prevent and find and fix bugs since they know the design better than others. It takes verification engineers a lot longer to find and track down bugs, since they are less familiar with the design.

]]>