cell libraries and place and route

[Andrew Beckett]

Erik,

In which case, why not get the simulator to do it? Having another process in
there to process the netlist:

a) wouldn't help the case where subckt instances have m factors
b) would have to include a complete spectre parser (which spectre already
has...)
c) would not help with the mapping of original components in the schematic to
the netlist (in fact would make it worse, unless perhaps it update the map
information in the netlist dir).

Regards,

Andrew.

On 1 Aug 2003 20:21:15 -0700, erikwanta@starband.net (Erik Wanta) wrote:

Andrew:
How about postprocessing the netlist to convert all the devices with a
specified mfactor (m, np, M, _M, ...) to iterated instance notation
(M0_0, M0_1...)? I suppose you could have the case of iterated
instances and m>2.
---
Erik

Andrew Beckett <andrewb@DELETETHISBITcadence.com> wrote in message news:<837hiv00p9esmlk837o5g5dctnjgvuoa8o@4ax.com>...
Hi Erik,

It's possible, but wouldn't then handle custom netlist procedures (each
custom netlist procedure would have to implement this); nor would it handle
m factor on subckt instances; nor would it help people working from netlists.

So I think the simulator is probably the right place to do it.

Regards,

Andrew.

On 30 Jul 2003 19:52:46 -0700, erikwanta@starband.net (Erik Wanta) wrote:

Andrew:
Instead of splitting the devices up inside spectre, how about a
netlist option that prints out the devices that use the mfactor in the
iterated instances format?
---
Erik

erikwanta@starband.net (Erik Wanta) wrote in message news:<84018314.0307300939.206fd778@posting.google.com>...
Andrew:
I like the idea of the option to split the devices up that are using
mfactor inside spectre for dcmatch and monte carlo.

We try to discourage the use of iterated instances and use the mfactor
and layoutXL generate multiple instances. The only problem we have
are layout designers who refuse to use layoutXL.
---
Erik

Andrew Beckett <andrewb@DELETETHISBITcadence.com> wrote in message news:<ccgfiv0n3sn18nf3c773mo5asfcdht4q4n@4ax.com>...
Frederic,

Fairly recently I did propose the opposite:

PCR: 419311
Title: montecarlo and dcmatch need to allow mismatch with m factor

Where I outlined:

Commonly instances have the "m" parameter on them to indicate multiple
devices. This is generally used to indicate that a device will be laid
out using m devices in parallel.

However, the problem with doing this is that for mismatch type analyses
(i.e. montecarlo and presumably the new IC50 dcmatch), all the
separate parallel instances are going to end up being 100% correlated,
because the m-factor is being taken account within the device equations.

We need to come up with some way of handling this. One possibility would
be to split the devices up (inside spectre) into really separate parallel
devices. Of course, the downside is that this would slow the simulation
down and increase the memory usage significantly.

The user can workaround this by using instance names such as M1<0:8
in composer (i.e. an iterated instance), but this means that you pay
the penalty for there being parallel devices in normal simulations.

Potentially the other way around could be done (at least in simple cases).
The problem is where do you stop? I think you'd want to do it both before
the hierarchy was flattened (so that subckts in parallel get m-factor'd up),
and then after flattening (to catch any others which happened to end
up in parallel after flattening - although in this case you'd probably be
restricted to single primitives in parallel). Doing this reduction could take
a reasonable amount of time (it can do in a verification tool), so it
would have to be an option.

Then you'd have the issue of relating the simulated results back to the
original netlist. For example, what if you'd asked to save the current
in _one_ of the devices that got paralleled up? Or what if you wanted to
look at the operating point data for one of these devices. It could get quite
confusing (or hard to handle).

An interesting idea though. I'm not sure how often people use the iterated
instance approach though - in other words, would it really be worth the effort
of implementing this (which I suspect could end up being a can of worms...)
when the "right" thing to do is to use the m-factor (with the proviso of PCR
419311 above).

Any thoughts?

Regards,

Andrew.

On Tue, 29 Jul 2003 12:53:54 +0200, eda support guy
cad_support_at_catena_dot_the_netherlands> wrote:


Andrew,

You mentioned here something that always puzzled me. Putting 2
identical devices, in parallel in a netlist does increase the simulation
cpu-time compared to putting one device with m=2. This is true with
spectre, and also with any spice-like simulator that I know of.

Now, would it not be easy for spectre programmers to do a little
"network preprocessing" in spectre and replace identical devices in
parallel by devices with an M>1 ? This, of course applies not only to
device models or devices modelled as subcircuits, but to any identical
subcircuit, or any identical "subparts" in a circuit.
Those two identical parts should have their nodes virtually shorted,
thereby easily reducing the admittance (or tableau, etc ...) matrix size.

I admit this can bring it share of problems, for instance in
implementing DCmatch or other sensitivity analysis, but the simulation
speedup would outweight the trouble, wouldn t it ?

Now, this would be too easy, and it is not done in spectre or *spice, so
I m probably overseeing stg. Anyone please tell me what ?

--
Frederic

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[Dionis]

Vladimir,

One more thing you might check is techfile used for stream-in/out or layers
map file
if you used it. I 100% agree that XOR is required. Besides diva/assura or
dracula
you can use SKILL to write XOR procedure. In general it should flat
temporary views
of original and streamed-in layouts and XOR all layers from technology
section of techfile.

Good luck
Dionis

"eda support guy" <cad_support_at_catena_dot_the_netherlands> wrote in
message news:3f16a983@shknews01...

Vladimir wrote:
Hi!
Does anybody know any information about a bug of StreamOut or
StreamIN? I heard something like that from my friend. But recently we
met the same situation. When I translated GDS file we transferred to
foundry (only one layer) back to Cadence I found out the original
layout and GDS translated layout are different.
I checked PIPO.log file. There is no error. Moreover the missed layout
according to PIPO.log was succesfully translated. I checked statistics
related to missed block. That showed that a hadred of rectangulars,
poligons, cell and so on was successfully translated without any
problem. The only one layer was translated. But when I opened layout
one block has no layout. I suppose this happened for version 4.4.5 or
4.4.6.
Vladimir Fomin

Vladimir,

Masks are expensive enough... When tapeing-out I d recommend you put
yourself in paranoid mode and perform a check like this:
-stream-out
-snap gds2 to mask grid
-stream-in
-use dracula/diva/assura to Xor the streamed-in and source db's.

 

[eda support guy]

An quick thought on Monte-Carlo: when only process spread is simulated
but all devices track, one can still benefit from virtually shorting
parrallel branches together: for N branches merged, the variance on
parameters will be simply divided by N.

eda support guy wrote:

Andrew,

It is indeed a bit of work to implement that all virtually shorted net
names are for the simulator just aliases for the same net, while a pin
name is to be treated as a fraction of the M'ed up pin. And it is also
true that the benefit would not extend to analyses where
components/branches with identical parameters are to be treated as
different (like DCmatch and MC).

As for the reasons why people will enter vectors or even explicitly
place identical instances in parallel, here are a few I can remember of:
- the support for M is buggy is either CDF, simulators' netlister, or
diva/dracula/assura (ext or lvs) ruledeck.
- the M'ed pcells do not satisfy the needs of layout ( rings for latchup
prevention, contacts to increase conductance to backgate, interdigitated
or cross-quad placement for matching ...)

That is probably for one of those reasons that pushed Austria
Mikrosystem to disable the m factor. There is extra schematic capture
effort involved in using vectors instead of M parameter. Since it is not
the path of least resistance, one can be confident that designers do not
do this gratuitously. Do you (cadence corp) have a set of "real life"
schematics from customers ? If so, statistics can be made, to check how
often it happens and thus how much simulation improvement it would bring.

Since I m new to the newsgroup, I take the occasion to thank you for
keeping it lively.

Andrew Beckett wrote:

Frederic,

Fairly recently I did propose the opposite:

PCR: 419311
Title: montecarlo and dcmatch need to allow mismatch with m factor

Where I outlined:

Commonly instances have the "m" parameter on them to indicate
multiple
devices. This is generally used to indicate that a device will be
laid
out using m devices in parallel.

However, the problem with doing this is that for mismatch type
analyses
(i.e. montecarlo and presumably the new IC50 dcmatch), all the
separate parallel instances are going to end up being 100%
correlated, because the m-factor is being taken account within the
device equations.

We need to come up with some way of handling this. One possibility
would
be to split the devices up (inside spectre) into really separate
parallel
devices. Of course, the downside is that this would slow the
simulation
down and increase the memory usage significantly.

The user can workaround this by using instance names such as M1<0:8
in composer (i.e. an iterated instance), but this means that you pay
the penalty for there being parallel devices in normal simulations.

Potentially the other way around could be done (at least in simple
cases).
The problem is where do you stop? I think you'd want to do it both before
the hierarchy was flattened (so that subckts in parallel get
m-factor'd up),
and then after flattening (to catch any others which happened to end
up in parallel after flattening - although in this case you'd probably be
restricted to single primitives in parallel). Doing this reduction
could take
a reasonable amount of time (it can do in a verification tool), so it
would have to be an option.

Then you'd have the issue of relating the simulated results back to the
original netlist. For example, what if you'd asked to save the current
in _one_ of the devices that got paralleled up? Or what if you wanted to
look at the operating point data for one of these devices. It could
get quite
confusing (or hard to handle).

An interesting idea though. I'm not sure how often people use the
iterated
instance approach though - in other words, would it really be worth
the effort
of implementing this (which I suspect could end up being a can of
worms...)
when the "right" thing to do is to use the m-factor (with the proviso
of PCR
419311 above).

Any thoughts?

Regards,

Andrew.

On Tue, 29 Jul 2003 12:53:54 +0200, eda support guy
cad_support_at_catena_dot_the_netherlands> wrote:


Andrew,

You mentioned here something that always puzzled me. Putting 2
identical devices, in parallel in a netlist does increase the
simulation cpu-time compared to putting one device with m=2. This is
true with spectre, and also with any spice-like simulator that I know
of.

Now, would it not be easy for spectre programmers to do a little
"network preprocessing" in spectre and replace identical devices in
parallel by devices with an M>1 ? This, of course applies not only to
device models or devices modelled as subcircuits, but to any
identical subcircuit, or any identical "subparts" in a circuit.
Those two identical parts should have their nodes virtually shorted,
thereby easily reducing the admittance (or tableau, etc ...) matrix
size.

I admit this can bring it share of problems, for instance in
implementing DCmatch or other sensitivity analysis, but the
simulation speedup would outweight the trouble, wouldn t it ?

Now, this would be too easy, and it is not done in spectre or *spice,
so I m probably overseeing stg. Anyone please tell me what ?

--
Frederic



--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[Pete nospam Zakel]

In article <84018314.0308051436.2429fc47@posting.google.com> erikwanta@starband.net (Erik Wanta) writes:

Is it possible to disable form scrollbars?

What exactly do you mean? Do want them not to work? That wouldn't be good
if there were fields not visible, and there is no way to do that.

If you mean the form should always be large enough not to get scrollbars, I
think you do that by passing "?initialSize t" to hiCreateAppForm(), as long
as the form isn't bigger than the screen.

If you mean you want the fields to resize with the form, then you use
attachments (?attachmentList argument to hiCreateAppForm()).

You can also specify ?minSize and ?maxSize to prevent sizing smaller or
larger than the specified bounding box.

Non-attachment (traditional) forms will always get scrollbars if the form
is smaller than necessary to show all the fields.

-Pete Zakel
(phz@seeheader.nospam)

"Politics is perhaps the only profession for which no preparation is thought
necessary."
-Robert Louis Stevenson

 

[Erik Wanta]

Pete:
I have a form. I have the initial size set to:
?initialSize 475:length(asiGetOutputList(asiGetCurrentSession()))*30+270

Note that I set it to 475 because then it doesn't give a horizontal
scrollbar. The form could really be about 350 wide and show
everything, however if I make it even 450 wide I get a horizontal
scrollbar. I was wondering if there was a way that I could tell the
form to not introduce scrollbars at all at any time. If I can use
?minSize and ?maxSize then I could fix the form to the appropriate
dimensions.
---
Erik

pxhxz@cadence.com (Pete nospam Zakel) wrote in message news:<3f303eb2$1@news.cadence.com>...

In article <84018314.0308051436.2429fc47@posting.google.com> erikwanta@starband.net (Erik Wanta) writes:
Is it possible to disable form scrollbars?

What exactly do you mean? Do want them not to work? That wouldn't be good
if there were fields not visible, and there is no way to do that.

If you mean the form should always be large enough not to get scrollbars, I
think you do that by passing "?initialSize t" to hiCreateAppForm(), as long
as the form isn't bigger than the screen.

If you mean you want the fields to resize with the form, then you use
attachments (?attachmentList argument to hiCreateAppForm()).

You can also specify ?minSize and ?maxSize to prevent sizing smaller or
larger than the specified bounding box.

Non-attachment (traditional) forms will always get scrollbars if the form
is smaller than necessary to show all the fields.

-Pete Zakel
(phz@seeheader.nospam)

"Politics is perhaps the only profession for which no preparation is thought
necessary."
-Robert Louis Stevenson

 

[Pete nospam Zakel]

In article <84018314.0308060647.2d34e2c6@posting.google.com> erikwanta@starband.net (Erik Wanta) writes:

Pete:
I have a form. I have the initial size set to:
?initialSize 475:length(asiGetOutputList(asiGetCurrentSession()))*30+270

Note that I set it to 475 because then it doesn't give a horizontal
scrollbar. The form could really be about 350 wide and show
everything, however if I make it even 450 wide I get a horizontal
scrollbar. I was wondering if there was a way that I could tell the
form to not introduce scrollbars at all at any time. If I can use
?minSize and ?maxSize then I could fix the form to the appropriate
dimensions.

If you use ?initialsize t, then it should size to the actual size of the
form unless the form is bigger than the screen.

The type of initial size you are setting means "don't set bigger than this
unless the user resizes".

The ?minSize and ?maxSize prevent the user from resizing beyond these limits.

The other value that can be used for ?initialSize is a field symbol, which
means set the form size to the lower right of that field.

In your case, I think you want to use "?initialSize t".

-Pete Zakel
(phz@seeheader.nospam)

"What we do not understand we do not possess."
-Goethe

 

[Erik Wanta]

Pete:
The form is not bigger than the screen. It should be about 350 wide.
The largest field I have is below. Note it is 300 wide. I have 5
buttons at the top that are 300 wide and the help button. The form
that gets created with initialSize t is about 450 wide. I can
manually resize the form to 300 and the help button goes away and
everything looks good minus the horizontal scrollbar that I can't
disable. Is there a way that I can resize the form with SKILL? Maybe
my best bet is to create a window instead.

list(
hiCreateFrameField(
?name 'xx
?labelText "xx"
)

0:y_start
300:85
12

) ; list

pxhxz@cadence.com (Pete nospam Zakel) wrote in message news:<3f314d52$1@news.cadence.com>...

In article <84018314.0308060647.2d34e2c6@posting.google.com> erikwanta@starband.net (Erik Wanta) writes:
Pete:
I have a form. I have the initial size set to:
?initialSize 475:length(asiGetOutputList(asiGetCurrentSession()))*30+270

Note that I set it to 475 because then it doesn't give a horizontal
scrollbar. The form could really be about 350 wide and show
everything, however if I make it even 450 wide I get a horizontal
scrollbar. I was wondering if there was a way that I could tell the
form to not introduce scrollbars at all at any time. If I can use
?minSize and ?maxSize then I could fix the form to the appropriate
dimensions.

If you use ?initialsize t, then it should size to the actual size of the
form unless the form is bigger than the screen.

The type of initial size you are setting means "don't set bigger than this
unless the user resizes".

The ?minSize and ?maxSize prevent the user from resizing beyond these limits.

The other value that can be used for ?initialSize is a field symbol, which
means set the form size to the lower right of that field.

In your case, I think you want to use "?initialSize t".

-Pete Zakel
(phz@seeheader.nospam)

"What we do not understand we do not possess."
-Goethe

 

[Pete nospam Zakel]

In article <84018314.0308061431.5eb7eb8f@posting.google.com> erikwanta@starband.net (Erik Wanta) writes:

Pete:
The form is not bigger than the screen. It should be about 350 wide.
The largest field I have is below. Note it is 300 wide. I have 5
buttons at the top that are 300 wide and the help button. The form
that gets created with initialSize t is about 450 wide. I can
manually resize the form to 300 and the help button goes away and
everything looks good minus the horizontal scrollbar that I can't
disable. Is there a way that I can resize the form with SKILL? Maybe
my best bet is to create a window instead.

hiSetFormSize( r_form list( x_width x_height ) ) will resize forms.

But I'm confused why you get a scrollbar if you see all the fields when
you size it smaller. Actually, on testing it seems the scrollbar appears
when the form is made smaller than the form buttons, even though they don't
scroll. So it looks like this may be a bug (or maybe a "feature").

I do believe the default minimum width always ensures that all the form
buttons are visible.

If you don't need the form buttons, then a form window might fit your
needs. Or you could reduce the number of buttons you have by choosing
'OKCancel instead of the default 'OKCancelDefApply.

-Pete Zakel
(phz@seeheader.nospam)

"The years of peak mental activity are undoubtedly between the ages of
four and eighteen. At four we know all the questions, at eighteen all
the answers."

 

[Erik Wanta]

Pete:
I just found hiSetFormSize(). Now I can resize the form to the
dimensions that I want.
---
Erik

pxhxz@cadence.com (Pete nospam Zakel) wrote in message news:<3f314d52$1@news.cadence.com>...

In article <84018314.0308060647.2d34e2c6@posting.google.com> erikwanta@starband.net (Erik Wanta) writes:
Pete:
I have a form. I have the initial size set to:
?initialSize 475:length(asiGetOutputList(asiGetCurrentSession()))*30+270

Note that I set it to 475 because then it doesn't give a horizontal
scrollbar. The form could really be about 350 wide and show
everything, however if I make it even 450 wide I get a horizontal
scrollbar. I was wondering if there was a way that I could tell the
form to not introduce scrollbars at all at any time. If I can use
?minSize and ?maxSize then I could fix the form to the appropriate
dimensions.

If you use ?initialsize t, then it should size to the actual size of the
form unless the form is bigger than the screen.

The type of initial size you are setting means "don't set bigger than this
unless the user resizes".

The ?minSize and ?maxSize prevent the user from resizing beyond these limits.

The other value that can be used for ?initialSize is a field symbol, which
means set the form size to the lower right of that field.

In your case, I think you want to use "?initialSize t".

-Pete Zakel
(phz@seeheader.nospam)

"What we do not understand we do not possess."
-Goethe

 

[Erik Wanta]

I thought I could call hiSetFormSize before calling hiDisplayForm().
It seems that is not the case. Any ideas on how to call hiSetFormSize
right after hiDisplayForm?

hiSetFormSize(form 300:length(asiGetOutputList(asiGetCurrentSession()))*30+275)
hiDisplayForm(form)

---
Erik

erikwanta@starband.net (Erik Wanta) wrote in message news:<84018314.0308061431.5eb7eb8f@posting.google.com>...

Pete:
The form is not bigger than the screen. It should be about 350 wide.
The largest field I have is below. Note it is 300 wide. I have 5
buttons at the top that are 300 wide and the help button. The form
that gets created with initialSize t is about 450 wide. I can
manually resize the form to 300 and the help button goes away and
everything looks good minus the horizontal scrollbar that I can't
disable. Is there a way that I can resize the form with SKILL? Maybe
my best bet is to create a window instead.

list(
hiCreateFrameField(
?name 'xx
?labelText "xx"
)

0:y_start
300:85
12

) ; list

pxhxz@cadence.com (Pete nospam Zakel) wrote in message news:<3f314d52$1@news.cadence.com>...
In article <84018314.0308060647.2d34e2c6@posting.google.com> erikwanta@starband.net (Erik Wanta) writes:
Pete:
I have a form. I have the initial size set to:
?initialSize 475:length(asiGetOutputList(asiGetCurrentSession()))*30+270

Note that I set it to 475 because then it doesn't give a horizontal
scrollbar. The form could really be about 350 wide and show
everything, however if I make it even 450 wide I get a horizontal
scrollbar. I was wondering if there was a way that I could tell the
form to not introduce scrollbars at all at any time. If I can use
?minSize and ?maxSize then I could fix the form to the appropriate
dimensions.

If you use ?initialsize t, then it should size to the actual size of the
form unless the form is bigger than the screen.

The type of initial size you are setting means "don't set bigger than this
unless the user resizes".

The ?minSize and ?maxSize prevent the user from resizing beyond these limits.

The other value that can be used for ?initialSize is a field symbol, which
means set the form size to the lower right of that field.

In your case, I think you want to use "?initialSize t".

-Pete Zakel
(phz@seeheader.nospam)

"What we do not understand we do not possess."
-Goethe

 

[Pete nospam Zakel]

In article <84018314.0308061723.2a2aa070@posting.google.com> erikwanta@starband.net (Erik Wanta) writes:

I thought I could call hiSetFormSize before calling hiDisplayForm().
It seems that is not the case. Any ideas on how to call hiSetFormSize
right after hiDisplayForm?

hiSetFormSize(form 300:length(asiGetOutputList(asiGetCurrentSession()))*30+275)
hiDisplayForm(form)

Prior to hiDisplayForm, initialSize is a property of the form struct returned
by hiCreateAppForm, so you can just modify it with

putprop( formstruct 300:length(asiGetOutputList(asiGetCurrentSession()))*30+275
'initialSize )

If the form is non-blocking (?dontBlock t), I think setting it right after
will work, but if it blocks, then you need to use something like hiRegTimer
to call a routine to resize the form from the event loop (because the line
after hiDisplayForm will not get executed until after the form is OKed or
Canceled). If you call hiRegTimer just before hiDisplayForm, the timer
function shouldn't get called until after the form is displayed, so you can
use the shortest timer value.

-Pete Zakel
(phz@seeheader.nospam)

It is impossible to make anything foolproof
because fools are so ingenious.

- Murphy's 6th Corollary

 

[Erik Wanta]

Pete:
OK, I used hiRegTimer to resize the form after it is displayed:
hiRegTimer("hiSetFormSize(form
300:length(asiGetOutputList(asiGetCurrentSession()))*30+275)" 1)
hiDisplayForm(form)

The minor problem remaining is a horizontal scrollbar that I don't
need/want. I just opened a SR 32533816 to allow me to disable
scrollbars.
---
Erik

pxhxz@cadence.com (Pete nospam Zakel) wrote in message news:<3f31c230$1@news.cadence.com>...

In article <84018314.0308061723.2a2aa070@posting.google.com> erikwanta@starband.net (Erik Wanta) writes:
I thought I could call hiSetFormSize before calling hiDisplayForm().
It seems that is not the case. Any ideas on how to call hiSetFormSize
right after hiDisplayForm?

hiSetFormSize(form 300:length(asiGetOutputList(asiGetCurrentSession()))*30+275)
hiDisplayForm(form)

Prior to hiDisplayForm, initialSize is a property of the form struct returned
by hiCreateAppForm, so you can just modify it with

putprop( formstruct 300:length(asiGetOutputList(asiGetCurrentSession()))*30+275
'initialSize )

If the form is non-blocking (?dontBlock t), I think setting it right after
will work, but if it blocks, then you need to use something like hiRegTimer
to call a routine to resize the form from the event loop (because the line
after hiDisplayForm will not get executed until after the form is OKed or
Canceled). If you call hiRegTimer just before hiDisplayForm, the timer
function shouldn't get called until after the form is displayed, so you can
use the shortest timer value.

-Pete Zakel
(phz@seeheader.nospam)

It is impossible to make anything foolproof
because fools are so ingenious.

- Murphy's 6th Corollary

 

[Harald Neubauer]

eda support guy <cad_support_at_catena_dot_the_netherlands> wrote in message news:<3f38ec8f@shknews01>...

But I believe it must be possible also to get spectre to run under
windows, as well. The x86 objects in the linux executable would have to
be first re-linked to the windows target, with all dependencies (such as
globetrotter libraries) and this is probably quite some work.

Why would you like to run spectre on windows?
It runs very fine (remote) on linux, so i do not see a need for Windows...
Regards, Harald

 

[eda support guy]

Harald Neubauer wrote:

eda support guy <cad_support_at_catena_dot_the_netherlands> wrote in message news:<3f38ec8f@shknews01>...


But I believe it must be possible also to get spectre to run under
windows, as well. The x86 objects in the linux executable would have to
be first re-linked to the windows target, with all dependencies (such as
globetrotter libraries) and this is probably quite some work.


Why would you like to run spectre on windows?
It runs very fine (remote) on linux, so i do not see a need for Windows...
Regards, Harald

Because windows is used on so many nodes that have powerful processors
and memory, and these machines are used for an occasional email or
wordprocessor, but most of the time idle.
This is not a cadence related problem, it is more that a set of wintel
machines and a wintel system admin are the legacy here (and this could
be the case at other sites), and all this CPU and RAM is otherwise wasted.
But just to make things clear: I would not _like_ to do it - Unless I
was getting well paid for it ;-)
Besides, there are probably cleaner solutions than re-linking, for
instance a virtual machine (plex86 or VMware).

Rgds,
--
Frederic.

 

[Andrew Beckett]

Don't think so. There are functions to get what is selected in a "show file" or
"view" window, but that's probably not what you're after...

Andrew.

On 13 Aug 2003 07:44:13 -0700, m_rajeswaran@yahoo.com (Rajeswaran M) wrote:

Is there any skill function, to access the text selected by mouse
inside the cadence (ICFB) environment?

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[Bernd Fischer]

Jan,

What you describe is missing in Diva indeed.
In many companies I saw own SKILL functions which
filter the Diva errors and make it possible to access
the errors in a filtered way.

Unfortunately I have not such a function, otherwise I
would give it to you.

Fortunately there is a workaround to access Diva errors
in a filtered way, but not on a per instance base, however
on a error class base.

A diva error was written in the design as a shape of the
layer purpose pair "marker error".
Therefore first of all for the workaround the layer purpose
pair "marker error" must be a valid layer in your Layer
Selection Window (LSW).

The error text itself was attached to this layer purpose pair
"marker error" as property with the name "drcWhy" containing
the error text e.g.
drcWhy : 2 Minimum Metal to Metal spacing

So now you can use the 'Edit -> Search ...' menu in the
layout window to access and search the Diva errors in a
filtered way.

Search for any shape in current cellView Add Criteria

property Name drcWhy == Metal to Metal


This should work for your example to access the
'2 Minimum Metal to Metal spacing'
errors.


Regards Bernd


Jan Mikkelsen wrote:

Hi

Lets do a case study here .. I run a DRC (DIVA) and get the following:

999 Minimum Pad to Via overlap
2 Minimum Metal to Metal spacing

When I start to look for the 2 Metal errors using "Verify -> Markers -
Find" Cadence might choose to start of with the 999 Pad errors .. how the
h*** do I control that list of errors to have cadence show me just the
instances of the error Im interested in?

/Jan

 

[Kholdoun TORKI]

Jan,

About one year ago, Andrew Beckett posted a Skill procedure
which does the Diva errors browsing, with a nice menu.
It is really helpful and very efficient in terms of capacity loading.

You can find this in the Cadence Newsgroup Archive :
http://groups.google.com/groups?q=DRC+markers+selective&hl=en&lr=&ie=UTF-8&selm=3D08DD36.8782E88D%40cadence.com&rnum=1

Regards,

================================================================
Kholdoun TORKI
http://cmp.imag.fr
================================================================

Jan Mikkelsen wrote:

Hi

Lets do a case study here .. I run a DRC (DIVA) and get the following:

999 Minimum Pad to Via overlap
2 Minimum Metal to Metal spacing

When I start to look for the 2 Metal errors using "Verify -> Markers -
Find" Cadence might choose to start of with the 999 Pad errors .. how the
h*** do I control that list of errors to have cadence show me just the
instances of the error Im interested in?

/Jan

 

[Sam Tran]

Hello Jan,

Try this.

After a DRC run, type the following in the command window.

geHiCommonFindMarker()

This should fix all of your problems.

Regards,
Sam


"Jan Mikkelsen" <jhm@NOSPAM.kom.auc.dk> wrote in message
news:bhve0m$1md$1@sunsite.dk...

Hi

Lets do a case study here .. I run a DRC (DIVA) and get the following:

999 Minimum Pad to Via overlap
2 Minimum Metal to Metal spacing

When I start to look for the 2 Metal errors using "Verify -> Markers -
Find" Cadence might choose to start of with the 999 Pad errors .. how the
h*** do I control that list of errors to have cadence show me just the
instances of the error Im interested in?

/Jan

 

[B]

Erik Wanta wrote:

I can't get installscape to bring up the box that allows me to enter
my proxy login/password. The problem might be related to RH9. Does
anyone else have this problem?
---
Erik
Itis working for me (RH9/KDE3). However installing from tar file is

still not possible.
HTH

 

[Henry Salvia]

B wrote:

Erik Wanta wrote:
I can't get installscape to bring up the box that allows me to enter
my proxy login/password. The problem might be related to RH9. Does
anyone else have this problem?
---
Erik
Itis working for me (RH9/KDE3). However installing from tar file is
still not possible.
HTH

We're testing a new version installscape that has some proxy fixes. If
all goes well there will be a new version available for download in a
few days.

Henry Salvia
Mfg SWE Mgr
Cadence