cell libraries and place and route

Thanks a lot Anderson,
Yes, this is what I am doing! I am through with the first 3 steps you
have mentioned and am having some issues/problems with the fourth.
For step 4 , I am planning to use the inherent cdf callback associated
with each parameter. This seems to work , but I am not able to repeat
the same behaviour consistently. Can you elaborate a bit on how you
went about step 4?
Thanks once again,
Hrishikesh
 
I am trying to make it as generic as possible .
Currently I am not having problems with symbols, but I will like to
keep this in mind while coding.
Thanks a lot,
Hrishikesh
 
Could Cadence change the default of the shifted mouse clicks over the
LSW to be the same as the unshifted ones?

The left mouse mouse click is the same (( i.e select layer) whether
shifted or not, but the center and right clicks only
function when unshifted, and not shifted ... most #W^^&*&%@#$$%
annoying ...

-- Gerry
 
Not sure what you mean by fixing.

It is possible with DIVA ( and i am sure with ASSURA too ) to take the
output DRC markers and
turn them into new layout. I have used this capability when converting
a layout from one vendor to
another and have used it to do condtiional grows of specific sized
emitters in an analog technology.
(i.e. size the length only of 0.4ux5u EMI to 0.4ux6u while leaving
alone 0.5u wide EMI ... )

Careful use of the output layer in the internal DRC tools can fix
errors, but unless you are
very careful, you may not be able to revers the change.

One limitation is that DIVA flattens the data to the top level without
special care ...

YMMV ---

-- Gerry
 
Your problem is due to the nature of parasitic resistor extraction.

When you enable PRE code, the "conductors" that do not exist over
"contacts" turn into parasitic resistor bodies.

The LVS code can be set up to understand that "pre" parasitic resistors
can be ignored for LVS.

The problem involves how the "STAMPING" command works.

( It is very similar to the error yo get when you "label" a signal in
an area the PRE wants to create a resistor body. )

To make this all work, you need to decide which location is your
reference node ... All other locations are (due to you asking for PRE )
at some other impedance ... disconnected by some small parasitic
resistance ....

So ... I suggest you label your "substrate node" by placing a "pin" or
"text" on top of a "contact" directly to the substrate.
(Directly is over a "contact" to the conductive substrate or to a
non-resistive conductor directly to the substrate.

You can place as many of these as you want as they should all be
direclty connected ....

(but you cannot make the bulk node itself resistive as this will cause
even more problems ... )

Note that in your examples you use METAL between the substrate contact
and your label ... this will fail ...


YMMV

-- Gerry
 
Is the below is a known issue? if so any workarounds?

test1 = 500 * 1.001
test2 = test1 * 10.0
(Now value of test2 is 5005.0)
floor(test2) will give 5004.
 
Could Cadence change the default of the shifted mouse clicks over the
LSW to be the same as the unshifted ones?

The left mouse mouse click is the same (( i.e select layer) whether
shifted or not, but the center and right clicks only
function when unshifted, and not shifted ... most #W^^&*&%@#$$%
annoying ...

-- Gerry
 
Not sure what you mean by fixing.

It is possible with DIVA ( and i am sure with ASSURA too ) to take the
output DRC markers and
turn them into new layout. I have used this capability when converting
a layout from one vendor to
another and have used it to do condtiional grows of specific sized
emitters in an analog technology.
(i.e. size the length only of 0.4ux5u EMI to 0.4ux6u while leaving
alone 0.5u wide EMI ... )

Careful use of the output layer in the internal DRC tools can fix
errors, but unless you are
very careful, you may not be able to revers the change.

One limitation is that DIVA flattens the data to the top level without
special care ...

YMMV ---

-- Gerry
 
Your problem is due to the nature of parasitic resistor extraction.

When you enable PRE code, the "conductors" that do not exist over
"contacts" turn into parasitic resistor bodies.

The LVS code can be set up to understand that "pre" parasitic resistors
can be ignored for LVS.

The problem involves how the "STAMPING" command works.

( It is very similar to the error yo get when you "label" a signal in
an area the PRE wants to create a resistor body. )

To make this all work, you need to decide which location is your
reference node ... All other locations are (due to you asking for PRE )
at some other impedance ... disconnected by some small parasitic
resistance ....

So ... I suggest you label your "substrate node" by placing a "pin" or
"text" on top of a "contact" directly to the substrate.
(Directly is over a "contact" to the conductive substrate or to a
non-resistive conductor directly to the substrate.

You can place as many of these as you want as they should all be
direclty connected ....

(but you cannot make the bulk node itself resistive as this will cause
even more problems ... )

Note that in your examples you use METAL between the substrate contact
and your label ... this will fail ...


YMMV

-- Gerry
 
Is the below is a known issue? if so any workarounds?

test1 = 500 * 1.001
test2 = test1 * 10.0
(Now value of test2 is 5005.0)
floor(test2) will give 5004.
 
On Wed, 08 Mar 2006 10:31:02 +0530, Pradeep Kumar Chawda
<pradeep_chawda22@DELETETHISyahoo.co.in> wrote:

Is the below is a known issue? if so any workarounds?

test1 = 500 * 1.001
test2 = test1 * 10.0
(Now value of test2 is 5005.0)
floor(test2) will give 5004.
Click to expand...
See countless posts before on similar subjects. This is a standard floating
point rounding problem - which occurs in pretty much all high level languages
(including C).

If you do:

sstatus(fullPrecision t)
test2 => 5004.999999999999
printf("%.12f" test2)
test2-5005.0 => -9.094947e-13

The problem is caused by the fact that floating point numbers are represented
with a finite binary mantissa, and so 1.001 is a recurring fraction (should be
infinitely recurring, but is truncated due to the finite precision). When
multipled, you end up with rounding errors (small, but still noticeable if you
look).

To avoid this either use round(), or use a small tolerance added to the value
before you floor it.

Andrew.
 
If you are porting the entire library from one process to another, why
do you need to worry about callbacks? Aren't these already defined in
the primitives in the new process, so all you should have to do is
calculate the new values....

example :
old nmos width was w and was stuffed with total width of device
new nmos width is wf and is just width of finger

callback should already exist on nmos for wf..... what am I missing?

David
 
When the parameter values are replaced through skill code , the
callbacks (CDF callbacks to be precise) are not executed. Also some of
the parameters might be calculated through this callback mechanism
(AD/AS/PD/PS for e.g.) and would not be updated, hence the porting
would not be accurate. The callbacks do exist , but they have to be
called/executed/triggered through the code .

Hrishikesh


DReynolds wrote:
If you are porting the entire library from one process to another, why
do you need to worry about callbacks? Aren't these already defined in
the primitives in the new process, so all you should have to do is
calculate the new values....

example :
old nmos width was w and was stuffed with total width of device
new nmos width is wf and is just width of finger

callback should already exist on nmos for wf..... what am I missing?

David
Click to expand...
 
Thank you for reminding me... I had forgotten about this detail. How
about something like:
foreach(inst primInstances
cdf =cdfGetInstCDF(inst)
cdfgData =cdf
evalstring(cdf->w->callback)
)

so you make a list of primitives that you know you need to trigger the
callback on then get cdf, and eval a prop that has uses the callback

David


David
 
This is what I am doing. But this is not recommeded, also I am not
getting consistent results with this approach. I would like to know if
there is a better solution to this issue or an altogether different
mechanism for callback ????
Hrishikesh
 
This is what I did.

;;To capture old properties of interest. I use a case statement to
sort through the instances. I broke up these functions based
;; on device type. Below is excerpts of my function for fets.
foreach(prop cdfGetInstCDF(inst)~>parameters
propName=prop~>name
case( propName
("wf" wf=prop~>value)
("lf" l=prop~>value)
("m" m=prop~>value)
("nf" fingers=prop~>value)
) ; end case propName
) ; end foreach prop

;;Then I swap out old instance and put in the new. I one point I just
did a replace, but all the old properties from the
;; old symbol showed up on the new one. Makes it pretty cluttered.
Also, if the symbols share the same property
;; names, the values will come over - even if the CDFprop is supposed
to be read only. This also assumes that the
;; pins are all in the same locations/orgins are the same.
;; below is one line from my case statement
('nfet dbDeleteObject(inst)
newInst=schCreateInst(objId dbOpenCellView("newLibrary"
"nfet" "symbol") name xcord:ycord orient)
)

;; To update values. Since the pdk already has the callbacks, I did
not want to re-write them. Plus I wanted to make sure
;; that the properties stayed within valid model limits. So to take
advantage of them
;; I did the following. I set the value first to a value that is less
likely to occur to trigger the callback, and then reset it
;; to the real value - so the change of value triggers the callback.
Though it uses the form so this code is a bit slower.
geDeselectAllFig(objId)
geSelectFig(newInst)
schHiObjectProperty()
schObjPropForm->wf->value="2.01u"
schObjPropForm->wf->value=wf
schObjPropForm->lf->value="501n"
schObjPropForm->lf->value=l
schObjPropForm->nf->value="23"
schObjPropForm->nf->value=fingers
schObjPropForm->m->value="23"
schObjPropForm->m->value=m
hiFormApply(schObjPropForm)
hiFormCancel(schObjPropForm)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

I also put in some basic checks for w and l to make sure they were in
range. Example, if the w from the old pdk
is too small for the new pdk, the callback would reset the value to the
min value for the new pdk, and I would add
text over the symbol alerting the designer that the value had to
change.

Tamara

I
 
Hi Pradeep, please try this any any other programming language you can
get your hands on. You should get
the same results in Perl, Python, Java, C, C++, Fortran
or anything i can think of.

Try it out and let me know what answer you get and with other language
you are are using.

-jim
 
Sure. All you need to do is create a recognition layer with terminals
that are conductors. To populate the parameters for your model you need
to measure some relationship from the recognition shape to other
polygons and save this.
Then netlist out the call to your device and then simulate.

(i.e. you write your own Assura extraction deck and call your own
models. )
 
Hi all,
I hope that someone can help to solve the problems I encountered while
setting up cadence's affirma for distributed processing for cadence's
Affirma.

For the distributed processing, I intend to run the master queue
manager on the machine call eskimo and submit a distributed job to the
same machine (quad-processors). Eskimo is a Sun-Blade-1000 running
solaris 5.8. To accomplish that, I did the following steps.

1. setenv LBS_CLUSTER_MASTER eskimo
2. created a queue_config_file containing the following
Fast 1
eskimo 2
3. excuted cdsqmgr by entering
Click to expand...
cdsqmgr /users/joe/fab1/queue_config_file
4. execute cadence in the machine call eskimo via icfb, open up Cadence
Analog Design Enviroment
5. Problems started when i tried to check the setup for distributed
processing via Setup -> Simulator/Directory/Host -> distributed ->
Check setup. The check stopped after encountering Error (219). The log
from the check is included below
###############################################################
Checking Distributed Processing (DP) setup..........
###############################################################
Current User is: joe
Submission host name is: eskimo

Checking for DP environment variables.....
###############################################################

Environment variable LBS_CLUSTER_MASTER is set to eskimo
Checking for LBS mode setup
Checking if cdsqmgr is running properly on "eskimo" .........
ERROR (219): The script failed to detect the OS type of eskimo
###############################################################
Setup check terminates with 1 errors and 0 warnings.
Click to expand...
6. check in the unix prompt with adptest also yielded unsatisfactory
results, the log for it is included below as well.
eskimo:/users/joe/fab1> adptest

BEGIN Artist Distributed Processing Setup Test

Testing for existence of LBS_CLUSTER_MASTER variable...
PASSED.

Testing opening of Artist Job Server...
Launching Artist job server...
Artist job server has initialized!
PASSED.

Please be patient - the remaining portion of the test takes some time.

Testing job submission to host `eskimo' on queue `Fast'...
Waiting for ipc:-1 to terminate
Click to expand...
Has anyone ever encountered similar problems before or know how to
solve the problem?

Thank you!

Regards,
STL
 
Hi,

Maybe someone could clarify one more question in this thread, please.
Is there is any possibility to deal with two-dimensional arrays of
instances and wires?
I have a 2D array of cells, and so far I could not find a way to
instantiated it, rather than
creating an additional component X- which is 1D array, and than creating
an array of X's.

And correspondingly is there a way to index wire in a 2D manner.

Thank you.
Alex


Virtuoso Schematic Editor User Guide,
Section: Multiple-Bit Wire Connections
Section: Wire-to-Iterated Instance Connections
Section: Multiple-Bit Wire Naming Conventions


Bernd

JC wrote:
Hi,
Using the Cadence schematic tool, I have a cell instantiated 128
times, Icell1<127:0>.
I want groups of 4 cells at the time to have the same input, so there
will be 32 signals, x<31:0> going to 128 cells.
I can label the bus to the input
etc., x<1>, x<1>, x<1>, x<1>, x<0>, x<0>, x<0>, x<0
but it is a very long string.
What is the syntax to abbreviate it, such as
etc., ((x<1>) *4), ((x<0>) *4)
or something even shorter such as
bit=0; (((x<bit + 1>) *4) *32)
Thanks,
Joe
joe.clark@nospm@adtran.com
Click to expand...


--
Alex
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top