A not quite idle question about what you would want from Div

[Diva Physical Verificatio]

If you had the opportunity to bribe the Diva developers, what would you
spend your money on? Pick a few important items and decide how you would
spread your bribe budget amongst them. Post your thoughts here or send
me an email. Mine are:

$5 Assura rule compatibility for 90nm designs. This is the subset of
the Assura rule language actually used in 90nm DRC and Extract decks.

$7 DRC and Extract performance. Both specific pathological cases and
in general.

$4 Coeffgen performance.

As you can see, I'm cheap.

 

[Diva Physical Verificatio]

For finding the slotting holes, have you tried finding inner-most holes
using geomGetUnholed(geomHoles(met1 voids))? This finds the holes that
do not have anything in them. The hole formed by the edge seal will have
chip data in it, so you won't get it. Perhaps you can send me some
shapes where this had odd results?

Use geomConnect(pin) to replace the automatic association of layout pins
to derived layers. It works like geomConnect(label), but for pins
instead. You have to specify all pin to layer associations. Partial
manual, partial automatic, is not available.

Partial connectivity is on the wish list as an enabler for multiple
antenna checks. Passing information between antenna checks to check for
accumulated gate damage is also there. The error GUI too.

I'll add non-conductor shapes in resistance, which need a different
fracturing algorithm. And net labeling falling on a resistor body. I
really don't understand the contacts as resistors idea, beyond what is
already in Diva.

Can you assign relative priority to any of this? We are using a
prioritization model that takes the relative interest in any item into
account. This seems to work better than the usual rank of importance
model, but means we try to get people to say "A is half of B which is a
third of C".

Anybody offended by honest input is an idiot. I'm always a little
annoyed when I find people are using convoluted workarounds where a
"new" feature from years ago is available. I blame a lack of information
flow out to customers for most of it since the most common response to
comments like I make above is "When was that added?"

Your FAE can get you a copy of the latest Diva Reference Manual in PDF
format from the Diva internal home page. Be aware it is likely to be
ahead of anything you can install by a month or two, the delivery
process being what it is. Appendix A has a "What's New" listing. I can't
post it here or the Legal people will send Niall The Healer to visit me.

On Wed, 19 Jan 2005 10:52:35 -0500, "G Vandevalk" <vdvalk@rogers.com>
wrote:

My top things to improve would be:

Better handling of the slotting problem.
(a trivial in concept , but falls off the compute/size cliff without very
careful coding
(
Try 1
A slot is a hole in a conductor --- but since the entire chip has an
edge seal ... all of the area outside the chip is a hole)
Try 2.
A slot is a "hole" in a conductor that has a maximum area and/or size
that is less than the width of the surrounding
conductor. (ugly to implement, likely to give any decent sized test case
run time seizure.)
Try 3 Size the conductor Up by 1/2 of the "I am not a hole, I am outside"
dimension.
"Real-holes" ( are the areas that are the resulting areas that are
completely inside and touching the initial conductor
and have no "holes" in them. This is a good compromise, but will cause
some strange results and will run very slow.
Try 4 -- define some minimum conductor width that does not realistically
surround a "Real-hole" and remove this from the
initial oversize ... ( undesize the conductor by --- something a bit larger
than min conductor and/or min conductor with/contact
dimension to be the layer used to generate potential "real-holes" ...
careful here ... if you pick an undersize number that is
large ... this will also cause compute paralysis. Then generate the holes
as in Try 3.
)
I had so much trouble with this problem on diva/Dracula/calibre/Hercules ...
that I was able to bring all of them
"to their knees" with this test. But from a mathematical point of view it is
a very expensive problem.
One way I was able to "improve" the performance was to re-write some of the
sizing into many incremental
steps. (and try to avoid the optimizing rule engines that "improve away"
this fix. )

Partial connectivity (to drive reliability & process-induced charging and
voltage dependant rules ...)
I have created situations where multiple customer rules require multiple
runs just because incremental
connectivity was not present.

Better documentation/understanding/control of how pin-layers/labels
conductors interact
I have tried many ways to "fool" the program into creating two copies of a
conductor that have one that is
"NOT!" connected to the "conductor" "pin layer. ( rich man's partial
connectivity ... I want to create
2 (or N) copies of the conductor to do some esoteric rule checking.
Expensive ... but so is reading in the
data multiple times ... )

Better user/ interface for real world fixing of errors. ( DRCwhy ...
Extractwhy ... (USERWhy???)
(DRC debugging does not always involve "fixing" the errors. Sometimes you
"Document the exceptions"
and go on .. The U/I makes this tricky.

Make PRE work better
(i.e . Try making a well resistive. Try making some contacts into resistors
... argh
some control of sub-nets in PRE. (i.e. guess what happens to a net label
when you make the layer resistive.

That is the first few I remember. Note that these problems were at one time
common to all
verification platforms. I know that some of this has improved in some
packages, but I have
not done an in depth probing of each capability in a few years. Typically we
are "stuck" with
the Foundry's choice of signoff and do most Physical verification here.

Hope I haven't offended anyone by a bit of ranting ...

-- Gerry Vandevalk

Root 2 is still bigger than 1

"Diva Physical Verification" <diva@cadence.com> wrote in message
news:d62ru0dtbf1geo0cp37ue39d0ep6srtos8@4ax.com...
If you had the opportunity to bribe the Diva developers, what would you
spend your money on? Pick a few important items and decide how you would
spread your bribe budget amongst them. Post your thoughts here or send
me an email.

 

[Diva Physical Verificatio]

On Thu, 20 Jan 2005 16:29:04 -0500, "G Vandevalk" <vdvalk@rogers.com>
wrote:

I'll add non-conductor shapes in resistance, which need a different
fracturing algorithm. And net labeling falling on a resistor body. I
really don't understand the contacts as resistors idea, beyond what is
already in Diva.

The non-conductor shapes can already be done. Simply connect the "resistive"
conductor to a marker layer (i.e. lpps "conductor C" ) and the contact area
is always a conductor. You need to make 2 copies of this ... (silly) because
the contact layer cannot be the same as one of the conductors (why?)
I always do this to connect the top metal to a "conductive" pad opening
layer through another copy of the pad layer.

The reason a via layer cannot also be a conductor layer is Diva's layer
storage mechanism does not support multiple read streams. The scanline
manager knows where every edge comes from and has no mechanism for
creating duplicate edge structures from a single layer file, which would
be needed by the connectivity analysis code.

By non-conductor I meant shapes that are not relatively long and thin.
Maybe simple interconnect is a better term. The fracturing algorithm is
biased toward shapes where the current paths are simple. Interconnect T
and + junctions are it's limit for complex current flows. The fracturing
code does poorly with blobs. Think a rectangle with six standard width
paths coming in on each of the four sides.

I would like some way to "see" the parasitics before reduction.
My biggest problem is that I need to re-run PRE for each process corner.
All of my non-parasitic devices can be paramterized with physicals so I can
"corner" (real bad verb) the netlist from simulation, but the parasitics are
reduced so I must re-run for each corner.

Is this a matter of using different constants in each extraction? Or do
you vary the actual widths of the material? If it is the first case, I
can see an easy way for you to provide all the constants at the same
time and generate parasitics with multiple properties. Mesh reduction
would take into account all fragment values and not remove a fragment
that did not meet the limit for all values. Then it would be a matter of
netlisting using the appropriate property, which sounds like what you do
with your drawn devices.

On another topic, do you have any large rule deck and design
combinations that really stress Diva's runtime? I'm talking hours and
days here. Performance analysis is something I'd like to see done this
year. We've had some pathological data cases come in recently that
resulted in significant improvement in narrow areas of the code. I don't
know how many people are seeing these and not letting us know about it.
Also, there are some areas we know we could make much faster, but have
no idea if they would actually help anybody. If nobody writes rules that
would take advantage of the change, it's a waste of time to do it.

 

[G Vandevalk]

My top things to improve would be:

Better handling of the slotting problem.
(a trivial in concept , but falls off the compute/size cliff without very
careful coding
(
Try 1
A slot is a hole in a conductor --- but since the entire chip has an
edge seal ... all of the area outside the chip is a hole)
Try 2.
A slot is a "hole" in a conductor that has a maximum area and/or size
that is less than the width of the surrounding
conductor. (ugly to implement, likely to give any decent sized test case
run time seizure.)
Try 3 Size the conductor Up by 1/2 of the "I am not a hole, I am outside"
dimension.
"Real-holes" ( are the areas that are the resulting areas that are
completely inside and touching the initial conductor
and have no "holes" in them. This is a good compromise, but will cause
some strange results and will run very slow.
Try 4 -- define some minimum conductor width that does not realistically
surround a "Real-hole" and remove this from the
initial oversize ... ( undesize the conductor by --- something a bit larger
than min conductor and/or min conductor with/contact
dimension to be the layer used to generate potential "real-holes" ...
careful here ... if you pick an undersize number that is
large ... this will also cause compute paralysis. Then generate the holes
as in Try 3.
)
I had so much trouble with this problem on diva/Dracula/calibre/Hercules ...
that I was able to bring all of them
"to their knees" with this test. But from a mathematical point of view it is
a very expensive problem.
One way I was able to "improve" the performance was to re-write some of the
sizing into many incremental
steps. (and try to avoid the optimizing rule engines that "improve away"
this fix. )

Partial connectivity (to drive reliability & process-induced charging and
voltage dependant rules ...)
I have created situations where multiple customer rules require multiple
runs just because incremental
connectivity was not present.

Better documentation/understanding/control of how pin-layers/labels
conductors interact
I have tried many ways to "fool" the program into creating two copies of a
conductor that have one that is
"NOT!" connected to the "conductor" "pin layer. ( rich man's partial
connectivity ... I want to create
2 (or N) copies of the conductor to do some esoteric rule checking.
Expensive ... but so is reading in the
data multiple times ... )

Better user/ interface for real world fixing of errors. ( DRCwhy ...
Extractwhy ... (USERWhy???)
(DRC debugging does not always involve "fixing" the errors. Sometimes you
"Document the exceptions"
and go on .. The U/I makes this tricky.

Make PRE work better
(i.e . Try making a well resistive. Try making some contacts into resistors
.... argh
some control of sub-nets in PRE. (i.e. guess what happens to a net label
when you make the layer resistive.

That is the first few I remember. Note that these problems were at one time
common to all
verification platforms. I know that some of this has improved in some
packages, but I have
not done an in depth probing of each capability in a few years. Typically we
are "stuck" with
the Foundry's choice of signoff and do most Physical verification here.

Hope I haven't offended anyone by a bit of ranting ...

-- Gerry Vandevalk

Root 2 is still bigger than 1

"Diva Physical Verification" <diva@cadence.com> wrote in message
news:d62ru0dtbf1geo0cp37ue39d0ep6srtos8@4ax.com...

If you had the opportunity to bribe the Diva developers, what would you
spend your money on? Pick a few important items and decide how you would
spread your bribe budget amongst them. Post your thoughts here or send
me an email.

 

[G Vandevalk]

"Diva Physical Verification" <diva@cadence.com> wrote in message
news:hpatu0pg6vdod7a48pa0vg4rfoqhuoanb0@4ax.com...

For finding the slotting holes, have you tried finding inner-most holes
using geomGetUnholed(geomHoles(met1 voids))? This finds the holes that
do not have anything in them. The hole formed by the edge seal will have
I have not used this. It may simplify the hole location.

chip data in it, so you won't get it. Perhaps you can send me some
shapes where this had odd results?

The odd results were due to the rule designer (me!) forgetting the cardinal
rule of layer biasing (i.e. root2 is bigger than 1) and creating bogus data
outside of where I thought I could. (on a pruned corner ... a 45degree bend
was biased into another shape ... more of quirk ... but made me understand
that
the hole problem was harder than I thought.

Note that my concerns were initially driven by some convoluted metal
cheezing
rules that were initially proposed by several of the (MLA) companies. (MLA
... Multi Letter Acronyms)

They wanted slots in all lines >30u wide ... but they had a very vague
definition of what a slot was.
I showed them several structures and they said they were not slots.
I showed them several structures and they said they were slots.
To get to to root of this problem (not root2! ) I needed to understand the
physics of what they were looking
for. ... At the time we just maded the rule that lines must be <30u (i.e
line undersized by 15 ... remaider was error.)
This passed the interpretation of the rule, but could create bad structures
....

Use geomConnect(pin) to replace the automatic association of layout pins
to derived layers. It works like geomConnect(label), but for pins
instead. You have to specify all pin to layer associations. Partial
manual, partial automatic, is not available.

geomConnect(pin) sounds very useful.
Partial connectivity is on the wish list as an enabler for multiple
antenna checks. Passing information between antenna checks to check for
accumulated gate damage is also there. The error GUI too.


I'll add non-conductor shapes in resistance, which need a different
fracturing algorithm. And net labeling falling on a resistor body. I
really don't understand the contacts as resistors idea, beyond what is
already in Diva.

The non-conductor shapes can already be done. Simply connect the "resistive"

conductor to a marker layer (i.e. lpps "conductor C" ) and the contact area
is always
a conductor. You need to make 2 copies of this ... (silly) because the
contact layer cannot
be the same as one of the conductors (why?)
I always do this to connect the top metal to a "conductive" pad opening
layer through another
copy of the pad layer.

Can you assign relative priority to any of this? We are using a
prioritization model that takes the relative interest in any item into
account. This seems to work better than the usual rank of importance
model, but means we try to get people to say "A is half of B which is a
third of C".

I would like some way to "see" the parasitics before reduction.

My biggest problem is that I need to re-run PRE for each process corner.
All of my non-parasitic devices can be paramterized with physicals so I can
"corner" (real bad verb) the netlist from simulation, but the parasitics are
reduced so
I must re-run for each corner.

Anybody offended by honest input is an idiot. I'm always a little
annoyed when I find people are using convoluted workarounds where a
"new" feature from years ago is available. I blame a lack of information
flow out to customers for most of it since the most common response to
comments like I make above is "When was that added?"

Sometimes the "new" feature isn't quite what you were looking for. But I

must admit
that once the tool has the feature you want, then the workarounds are
redundant and
typically (usually) inefficent.

Your FAE can get you a copy of the latest Diva Reference Manual in PDF
format from the Diva internal home page. Be aware it is likely to be
ahead of anything you can install by a month or two, the delivery
process being what it is. Appendix A has a "What's New" listing. I can't
post it here or the Legal people will send Niall The Healer to visit me.

By the way, I still think the diva tool is one of the most powerful tools to
manipulate data. I have written several chip data final processors that
manipulated the data using the rules for some very particular processes and
have never found something that diva cannot do.

Keep up the great work.

-- Gerry

On Wed, 19 Jan 2005 10:52:35 -0500, "G Vandevalk" <vdvalk@rogers.com
wrote:

My top things to improve would be:

Better handling of the slotting problem.
(a trivial in concept , but falls off the compute/size cliff without very
careful coding
(
Try 1
A slot is a hole in a conductor --- but since the entire chip has an
edge seal ... all of the area outside the chip is a hole)
Try 2.
A slot is a "hole" in a conductor that has a maximum area and/or size
that is less than the width of the surrounding
conductor. (ugly to implement, likely to give any decent sized test case
run time seizure.)
Try 3 Size the conductor Up by 1/2 of the "I am not a hole, I am
outside"
dimension.
"Real-holes" ( are the areas that are the resulting areas that are
completely inside and touching the initial conductor
and have no "holes" in them. This is a good compromise, but will cause
some strange results and will run very slow.
Try 4 -- define some minimum conductor width that does not realistically
surround a "Real-hole" and remove this from the
initial oversize ... ( undesize the conductor by --- something a bit
larger
than min conductor and/or min conductor with/contact
dimension to be the layer used to generate potential "real-holes" ...
careful here ... if you pick an undersize number that is
large ... this will also cause compute paralysis. Then generate the
holes
as in Try 3.
)
I had so much trouble with this problem on diva/Dracula/calibre/Hercules
....
that I was able to bring all of them
"to their knees" with this test. But from a mathematical point of view it
is
a very expensive problem.
One way I was able to "improve" the performance was to re-write some of
the
sizing into many incremental
steps. (and try to avoid the optimizing rule engines that "improve away"
this fix. )

Partial connectivity (to drive reliability & process-induced charging and
voltage dependant rules ...)
I have created situations where multiple customer rules require multiple
runs just because incremental
connectivity was not present.

Better documentation/understanding/control of how pin-layers/labels
conductors interact
I have tried many ways to "fool" the program into creating two copies of
a
conductor that have one that is
"NOT!" connected to the "conductor" "pin layer. ( rich man's partial
connectivity ... I want to create
2 (or N) copies of the conductor to do some esoteric rule checking.
Expensive ... but so is reading in the
data multiple times ... )

Better user/ interface for real world fixing of errors. ( DRCwhy ...
Extractwhy ... (USERWhy???)
(DRC debugging does not always involve "fixing" the errors. Sometimes you
"Document the exceptions"
and go on .. The U/I makes this tricky.

Make PRE work better
(i.e . Try making a well resistive. Try making some contacts into
resistors
... argh
some control of sub-nets in PRE. (i.e. guess what happens to a net label
when you make the layer resistive.

That is the first few I remember. Note that these problems were at one
time
common to all
verification platforms. I know that some of this has improved in some
packages, but I have
not done an in depth probing of each capability in a few years. Typically
we
are "stuck" with
the Foundry's choice of signoff and do most Physical verification here.

Hope I haven't offended anyone by a bit of ranting ...

-- Gerry Vandevalk

Root 2 is still bigger than 1

"Diva Physical Verification" <diva@cadence.com> wrote in message
news:d62ru0dtbf1geo0cp37ue39d0ep6srtos8@4ax.com...
If you had the opportunity to bribe the Diva developers, what would you
spend your money on? Pick a few important items and decide how you
would
spread your bribe budget amongst them. Post your thoughts here or send
me an email.