Semiwiki on LinkedIn Semiwiki on Facebook Semiwiki on Twitter Register / Log in 
Array
(
    [content] => 
    [params] => Array
        (
            [0] => /forum/threads/most-of-the-re-spins-are-due-to-functional-defects.2331/
        )

    [addOns] => Array
        (
            [DL6/MLTP] => 13
            [Hampel/TimeZoneDebug] => 1000070
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000970
            [ThemeHouse/XPress] => 1010570
            [XF] => 2021770
            [XFI] => 1050270
        )

    [wordpress] => /var/www/html
)

Most of the re-spins are due to Functional defects?

Asic With Ankit

Asic With Ankit

Member
Dear Readers,

I have been hearing on re-spins of chips. Many companies have gone through this painful phase because of several reason/defects. Nobody likes re-spin for chip as it is expensive and time consuming! Companies have a fear to loose time to market for their products because of this reason.

Let us understand the various factors which could cause re-spin for chips. If you ask industry experts or Semiconductor veterans they could share their experience. I have been discussing this topic with couple of people and have concluded few factors which could cause re-spin.

1.Firmware Issues
2.Power Issues
3.Mixed-Signal Interface related Issues
4.Race Condition Issues
5.Clocking domain Issues
6.Functional Issue etc...

From the experience and discussion it looks like most of the time Function Issues/defects have triggered a re-spin for the Chips. When we talk about functional issues, attention comes to our mind is for functional logic verification part. Considering complexities in the ASICs companies have started investing time and money for the functional verification part of the Chips to reduce the chances of re-spin.

To reduce the chances of re-spin for chips, people have started using various precautions like

- A reusable and scalable verification
- More effective block (IP) level verification
- Verification reuse from block level to System level
- Architecture of test bench using reusable methodologies
- Constraint Random Verification approach (Refer: Blog post on Constraint Random Verification)

Random functional verification is giving us a enough confidence on functional defects. Random verification generates corner scenarios, stress testing on functional scenarios and logical permutation for configuration.
Random verification just gives us a confidence on functional defects but not giving us confirmation that Chip will not have to go through re-spin because of any of the functional issue.

Share your experience on Chip re-spin.

Happy Reading-Sharing,
ASIC With Ankit

<script src="//platform.linkedin.com/in.js" type="text/javascript"></script>
<script type="IN/Share" data-counter="right"></script>
 
Last edited by a moderator:
In my past experience, power dissipation, "leakage" was the major issue forcing a respin. This has noticeably increased, as issues of mobile device functionality and battery life have increased exponentially. Hence, Intel's multi-Billion dollar partnership, and its CES announcement of a 7 watt Atom. My understanding has been that the heat dissipation tools available from the big EDS firms were not keeping up with the market need. A fellow Intel alumni, fab engineer, has developed his own EDA tool, which is in trials at the moment. The company, Trajectory Design Automation is still in stealth mode.
 
Yes, Andrew Labun.. Imagine my surprise to find a design engineer of that caliber, and fellow Intel alumni here at UBC....Andrew is a good friend, and a thoughtful entrepreneur. I think he has a winner, and is linking up with the right people. The challenge is that there are desperately few people who even understand EDA up here.
 
David Mayes • In my experience, power dissipation, "leakage," was the major issue driving respins. This has noticeably increased, as issues of mobile device functionality and battery life have increased exponentially. Hence, Intel's multi-Billion dollar partnership, and its CES announcement of a 7 watt Atom. My understanding has been that the heat dissipation tools available from the big EDS firms were not keeping up with the market need.
 
Thanks Daniel for the info, useful information !

Since the companies have started following the methodology and constraint random verification approach, they have reduced the chances of re-spin due to functional defects. From last few years, EDA tools for functional verification have become matured and at the same time industries have accepted these kind of tools for their verification keeping methodology in mind. I would say people have tried to reduce the cause of re-spin and we are still trying to reduce those factors. Share your experience.

Thanks,
ASIC With Ankit
 
Asic With Ankit said:
Thanks Daniel for the info, useful information !

Since the companies have started following the methodology and constraint random verification approach, they have reduced the chances of re-spin due to functional defects.
Click to expand...

I would add "adding more resources (time and people) to the verification effort". Having engineers targeted for
verification of a product that were not the designers helps find bugs that the designers might miss (designers
verifying their own biases). Once management has seen that more money put into verification yields fewer
re-spins and a faster overall time to market, they jump on board.

Other common reasons in my experience for a re-spin.
1. Incomplete Requirements. After delivering an ASIC to an internal or external customer, it often reveals
what wasn't specified, or creates a wish list for the "next revision" which somehow needs to be justified
(and so one of those wish list items becomes a "functional defect" for business reasons).
Sometimes this is recognized in the design phase, but the discussion doesn't adequately address all issues.
2. Incomplete Modeling. An outside model is not fully characterized (or available at all in some cases) forcing
the design engineer to guess or not even be aware of the models faults. Particularly an issue with a
new node or operating condition release from a fab or new IP (or IP from a young company).
 
Other re-spin issues from a custom chip standpoint:
1. Not enough time to finalize functional and post layout verification
2. Not enough resources to fully verify designs
3. Bugs in the software coding for place & route
4. Swiftly changing specs (yes they do happen)
5. Using IP that was verified as a standalone block without also verifying it when it is integrated into the chip. Got bit on that one.
 
Katy said:
Other re-spin issues from a custom chip standpoint:
1. Not enough time to finalize functional and post layout verification
2. Not enough resources to fully verify designs
3. Bugs in the software coding for place & route
4. Swiftly changing specs (yes they do happen)
5. Using IP that was verified as a standalone block without also verifying it when it is integrated into the chip. Got bit on that one.
Click to expand...

I agree with your all points, In present days mostly I have been observing chaning specs is painful for designer as well as verification engineer!
Demanding requirements are becoming dynamic w.r.t market and consumer need so people are changing specs accordingly which causes a problem in Design Verification side. Very important point!

Thanks,
ASIC With Ankit
 
Shovan Das • As we all know ASIC doesn't have a way like s/w for bug patches. No matter how robust verification is there would be some functional bugs. Few bugs would be critical enough needing respin. A reasonable ASIC project plan should have schedule for at least 2 respins. Otherwise it's not realistic. I have seen other reason for respin such as physical layer issues. Respin are also meant to cover those.

Article says we can invest in more verification. This is true and it reduces probability of critical bugs. I would be careful in not extending verification so much that schedule is impacted. I would rather like the ASIC in lab and nail the bugs and go for respin. Because finding bugs in lab is much faster than finding bugs in simulation verification. Emulator can be used and I like them lot. However, they are expensive and need upgrades frequently.

Finally, respin is unavoidable and sometime saves time compared to extended verification. Any reasonable project plan should have schedule and resources for few respin.
 
Eric Bouche • Agree about not having the software patches but I have seen some very creative designs where few options are embedded in the first tape out and testing/characterization is done to select the best of these options ...
 
You must log in or register to reply here.
Back
Top