( ESNUG 470 Item 4 ) -------------------------------------------- [10/31/07]

Subject: ( ESNUG 469 #5 ) Cadence's benchmark cheating claim exaggerated?

> These complex rules are intended to reduce litho hot spots, which depend
> in very complicated ways on the surrounding geometry.  Although your
> design could pass DRC without these advanced rules, you can be sure they
> did not get into the LEF by accident -- it's quite tricky to write them
> so that they get rid of various manufacturing problems without affecting
> density any more than necessary.  Clearly the foundry believes these
> additional rules are needed for good yield; otherwise why go to the
> trouble of adding them?
>
> I was not involved in any of these evaluations in any way, but I am quite
> surprised to see anyone say "DRC clean" == "Decent yield".  This was never
> strictly true, and is less and less of a working approximation in every
> generation.  The market for DFM tools shows that the VCs with their
> wallets, and the existing companies with their R&D budgets, have put their
> money behind this observation.
>
>     - Lou Scheffer
>       Cadence                                    San Jose, CA


From: [ An EDA Employee ]

Hi John,

Anon please as I did before.  Thanks.

It seems that there was no benchmark cheating in the first place.  I don't
wish to bring out new argument.  I will just answer some of Lou's comments.

 1. "each of which meets all the official design rules"

    Doesn't clean DRC mean meets all the official design rules?  If a
    rule is recommended, is there is a reason for it not be mandatory?
    Yes, it may affect yield but it may affect area, too.  It's a balance.

 2. "redundant vias"

    This is not a good example for DFM, but it illustrates a good point
    why a P&R benchmark has to be judged by people who are familar with
    P&R.  I say it is not a good example because the issue of via failure
    is so well know many years ago.  Even on 0.25 um (or even 0.35 um)
    project we use redundant vias.  When setting up a process tech or a
    new tool, the percentage cover of redundant via is always something
    in the report.

 3. "It's not at all surprising that a foundry LEF would have bigger
     than minimum rules in it."

    I would be very surprised.  The LEF must follow the Design Rule
    Document.  If there is a need for extra spacing, it must appear
    somewhere in the Design Rule Document.  If it is not then it is
    because you know/believe in something that is different from the
    people from the FAB.

 4. "Clearly the foundry believes these additional rules are needed for
     good yield; otherwise why go to the trouble of adding them."

    This way of thinking is not engineering.  If this is true than I can
    also say the way that some features in SoC Encounter do not work too
    well are because Cadence R&D believes it shold be like that.  Again,
    I stress that LEF must follow design rule.  If it is necessary to
    have it in the LEF, than it must be added to the design rule.

 5. "surprised to see anyone say "DRC clean" == "Decent yield""

    I think nobody that replied make this statement.  So I think you
    should not be surprised.

I also want to point out that there is no data to show that non-Cadence
routers cannot route with the original LEF from the FAB.  What we know is
that Synopsys/Magma routers can route with the optimised LEF.

Lastly, I think a better solution is to find a way to measure yield and
include this measurement in a P&R benchmark.  But I think the industry
does not have a means to measure DFM/yield yet.

    - [ An EDA Employee ]
Index    Next->Item







   
 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)