cell libraries and place and route

[Svenn Are Bjerkem]

Erik Wanta wrote:

Svenn:
The states are critical to repeatability. If the state is saved as a
cell view then it gets copied when the test bench is copied. It can
also be data managed and shared with other engineers all over the
world. If the states are saved as cell views and then copied to

Read you loud and clearly now. I wasn't thinking in this direction so I
had a slight problem with understanding.

I am just a little afraid that the cellview listing in the library
manager is going to be filled up beyond practicallity.

--
Svenn

 

[Andrew Beckett]

On Thu, 24 Feb 2005 08:33:42 +0100, Svenn Are Bjerkem <svenn.are@bjerkem.de>
wrote:

Andrew Beckett wrote:

There is a plan to do this properly (not just do this trigger idea) in an
upcoming release. Not sure about assura states, but the ADE-related states
would be unified and have both a cellView and directory-based model.

Do I understand you correctly if I assume that Cadence is working on a
more user friendly dialog to save states?

Yes, and the ability to save states as cellViews. Also, to unify the multiple
state mechanisms within ADE.

Andrew.

 

[Andrew Beckett]

On Sat, 26 Feb 2005 20:28:35 -0500, fogh <adff@xs4all.nl> wrote:

Yes, and the ability to save states as cellViews. Also, to unify the multiple
state mechanisms within ADE.

Andrew,
how many such deliciously good news like this are still in your sleeve ?
Can you anounce those relating to ADE in the c.c.c ?

Well, that would be saying...
Actually I need to be careful about some of these, since if they're a way off,
plans have a habit of changing - it's always dangerous announcing things too
early (certainly if it is before I've seen it in action).

Andrew.

 

[hikom]

hi,
i would sugest to search the hierarchy for flip-flops first. therefore
you have to check any instance on top level whether it is a flip-flop
(ff) or a hierarchical block:
if (instId~>cellName == "flipflopCell"
//save instId in a ff-list
)
if (isObject(instId)
//the current instance is a hierarchical block
cv=dbOpenCellViewByType(instId~>libName instId~>cellName
"schematic")
//search this level for ff and append them on ff-list including
hierarchical information --> /block1/ff2
)

after this you can access the spectre simultion results by ocean
commands (i think getdata(value(/block/ff2/term1 1ľs))) to get the
waveforms at a certain ff.

greetings,
hikom

 

Mark Summers wrote:
[snip]

In order to accomplish this I need to find the clock and data inputs
of all
flip-flops in the schematic. I need a function that will search
through the
hierarchy for instances that are flip-flops and then return the nodes

connected to the data and clock inputs. These nodes that are
returned need
to be correct with respect to the simulation schematic hierarchy. IE
if a
flip-flop is two levels down, function should return
ILEVEL1/ILEVE2/NODENAME.

I've taken a stab at this before. The code pretty much recursively
decends the design hierarchy, building the hierarchy path one instance
at a time. Where I became stuck was on signals whose local nets are
connected to something further up the design hierarchy or at the
top-level.

On these cases the node name I would build was "/DUT/I34/I35/VDD".
Trying to get the voltage using Ocean would fail:

v( "/DUT/I34/I35/VDD". ?results 'tran)

because this is actually connected to the top level "VDD" node. In
these cases the following would work:

v( "/VDD" ?results 'tran)

Does anyone know if there is a public function that can used to map the
local node name to the one at the highest level of hierarchy?

Jason

 

[Mark Summers]

I have the same problem that you are describing. Any help would be good
<jason.dot.jacobs@gmail.com> wrote in message
news:1110999302.274193.293850@o13g2000cwo.googlegroups.com...

Mark Summers wrote:
[snip]
In order to accomplish this I need to find the clock and data inputs
of all
flip-flops in the schematic. I need a function that will search
through the
hierarchy for instances that are flip-flops and then return the nodes

connected to the data and clock inputs. These nodes that are
returned need
to be correct with respect to the simulation schematic hierarchy. IE
if a
flip-flop is two levels down, function should return
ILEVEL1/ILEVE2/NODENAME.


I've taken a stab at this before. The code pretty much recursively
decends the design hierarchy, building the hierarchy path one instance
at a time. Where I became stuck was on signals whose local nets are
connected to something further up the design hierarchy or at the
top-level.

On these cases the node name I would build was "/DUT/I34/I35/VDD".
Trying to get the voltage using Ocean would fail:

v( "/DUT/I34/I35/VDD". ?results 'tran)

because this is actually connected to the top level "VDD" node. In
these cases the following would work:

v( "/VDD" ?results 'tran)

Does anyone know if there is a public function that can used to map the
local node name to the one at the highest level of hierarchy?

Jason

 

[Andrew Beckett]

On Mon, 14 Mar 2005 10:11:38 +0000, "Keith S." <false@nospam.com> wrote:

Your best bet is to use OSS to flatten the schematic to a new view
(simFlattenWithArgs is the function to look at). Then check each
instance in this view, and if it's a flop, look at its instTerms
and find the nets connected to the inputs you're interested in.
The flattener will take take of the hierarchical net naming for
you.

- Keith

Personally I wouldn't do this by flattening the schematic - unless you really
need to. If you can gather the information whilst traversing the hierarchy
(using some kind of recursive function) that will generally be more efficient
than producing a flattened database.

Sometimes you need a persistent flattened database (often for floorplanning
type reasons) - but for this type of usage, I'd probably not go about it by
flattening the hierarchy.

If however you're likely to need the flattened hierarchy information several
times for different purposes, then it may be worth doing. Also, if the design
size is small, it doesn't really matter.

A few years back one of my colleagues used a flattening type approach
(although he didn't do it with OSS) - and once I'd made some suggestions about
doing it recursively, and we'd optimised the code, a run with a very large
database went from several hours down to something like 90 seconds...

Of course, your mileage may vary.

Andrew.

 

[Andrew Beckett]

On Wed, 16 Mar 2005 04:05:09 -0600, morgenst@izm.fhg-dot-de.no-spam.invalid
(hikom) wrote:

hi keith,

please can you explain what OOS is? Where can I find information about
it? Thanks in advance.

Greetings,
hikom

OSS, not OOS. Open Simulation System. Look for it in cdsdoc.
Nothing like reading the manual to learn how to do something ;-)

Mind you, consider my previous post - this may be the simplest method, but not
necessarily the most efficient (depending on your needs).

Andrew.

 

[Keith S.]

Mark Summers wrote:

my ultimate goal is to generate a skill routine that will extract timing
information from a spectre(most likely run through ocean) to allow for
digital timing verification on custom digital blocks. I want to get setup
and hold margin.

In order to accomplish this I need to find the clock and data inputs of all
flip-flops in the schematic. I need a function that will search through the
hierarchy for instances that are flip-flops and then return the nodes
connected to the data and clock inputs. These nodes that are returned need
to be correct with respect to the simulation schematic hierarchy. IE if a
flip-flop is two levels down, function should return
ILEVEL1/ILEVE2/NODENAME.

If anyone has any suggestions on methods to search a simulation schematic
and return all nodes connected to each flip-flop instance I would
appreciate it.

Your best bet is to use OSS to flatten the schematic to a new view
(simFlattenWithArgs is the function to look at). Then check each
instance in this view, and if it's a flop, look at its instTerms
and find the nets connected to the inputs you're interested in.
The flattener will take take of the hierarchical net naming for
you.

- Keith

 

[hikom]

hi all,
of course you have to evaluate the netset properties and values to
process inherited connections. in our algorithm we searched the
current path from a given instance to a term on top level of a
hierarchical schematic. if you have a specific question, feel free to
contact me.

if the schematic is flatten before the search, this algorithm will be
more easy. but why should it be not so efficient? because of the huge
amount of data?

greetings, hikom.

 

[Andrew Beckett]

On 25 Mar 2005 18:01:47 -0800, "PK" <peter.kinget@gmail.com> wrote:

Hi,

I am trying to get a flat netlist for (analog) transistor level
circuits drawn in the schematic editor. From the editor I typically
call the "Analog Design Environment" and run spectre simulations. For
some special simulations I modify the spectre netlists, and I am
looking for _flat_ netlists i.e. not subckt...

I tried by using a .simrc file in my homedir that does a simNetlistHier
= nil ; this is reflected in the ~/simulation -> cell_name -> .....
spectre -> ... netlist -> si.env file. However, the netlists that are
generated are hierarchical...

Any suggestions?

Thanks,

PK

I don't think the spectre netlister supports flat netlisting. Why on earth
would you want a flat netlist anyway?

Andrew.

 

[S.Badel]

You can set your labels as 'alias' (there is a check-box when you create
the label). this avoids the error you are describing in the schematic ;
i don't know however how this is handled by the layout xl.

the other way to avoid this, which is cross-tool and most well-behaved,
is to avoid shorting nets together, only short pins (input pins). if you
want to short a net to ground (or whatever) then make a cell out of
what you have, with a pin for the net in question, then instantiate this
cell in a higher-level cell and short at your will. because your net
labels are in different levels in the hierarchy, there won't be any
clash, and any tool should be able to handle this.

stéphane


L. Coleman wrote:

I'm getting errors in Virtuoso schematic composer when I try to connect
signals on a bus to gnd. The errors are that the signals are shorted
to gnd and that they're shorted together. I was able to get rid of the
errors by putting a patch component (from basic library) between gnd
and each bus signal. However the patch causes an error when running
the "generate from source" command in the layout editor. I also tried
a 0 ohm resistor, which also got rid of the error in the schematic but
caused an error in layout. Any suggestions?

 

[S.Badel]

if this is just about displaying the correct one, you may try using an
ilLabel, with something like this:

if( ilInst~>model=="X"
aelSuffixNotation(ilInst~>A)
aelSuffixNotation(ilInst~>B)
)

but i noticed, the ilLabels are often updated only after you do a
redraw, which may not please you.

even though i never tried what you tried, i'm not really surprised it
does not work. cdf callback are to be seen as 'user interface', just to
show some feedback to the user - but don't rely on them. you never know
when they will be called and when they won't, what they can do and what
they can't. (this is my secure approach to cdf)

if you need to netlist different parameters depending on the model type,
however, it may be more tricky. it may necessitate a custom netlist
procedure.

stéphane

 

[Andrew Beckett]

On 31 Mar 2005 17:26:40 -0800, "PK" <peter.kinget@gmail.com> wrote:

For an in house tool we are developing we want to have a unique
instance for each device.

I am kind of surprised that it seems this cannot be done. I thought
that for LVS purposes, flat netlists are required anyway. But, I am not
a CAD specialist so I am probably wrong on this.

-- Peter

Most LVS tools flatten the netlist themselves. Diva doesn't, but then again
that has its own netlist format, so it's a moot point.

Simulators also flatten the netlist themselves. It just allows a much more
efficient, and understandable, representation of the design to do
it hierarchically. It adds complexity to be able to produce a flat netlist,
because if there are any parameterised expressions, these need to be evaluated
for each flatten instance. Since no Cadence tools need a flat spectre netlist,
it probably was very low (off the bottom!) on the priority list of things to
be done!

Regards,

Andrew.

 

[S.Badel]

Gerd wrote:

Found the answer:

if( ilInst~>model=="X"
strcat("A=" aelSuffixNotation(ilInst~>A))
strcat("B=" aelSuffixNotation(ilInst~>B))
)

yes! or play with sprintf("A=%g" ilInst~>A)

 

[S.Badel]

Stephane, you mentioned the possibility of writing a custom netlist
procedure. Out of curiosity, do you know in which manual i can find
information on how to do this?

this one includes some information: "Direct SImulation Modeling Guide"

this one, chapter 4, describes the classes/functions used in this:
"Cadence Analog Design Environment SKILL Language Reference"

also this one, chapter 13, for examples : "Virtuoso AMS Environment User
Guide"


cheers,

stéphane

 

[S.Badel]

yes! or play with sprintf("A=%g" ilInst~>A)

sorry the correct syntax is sprintf(nil "A=%g" ilInst~>A)

 

[S.Badel]

Try using 'model' or 'modelName' instead of 'ModelName'.
also try putting this parameter in the list of 'otherParameters' in the
CDF simInfo.

This is from "Cadence Analog Design Environment User Guide", chapter 3,
"Design Variables and Simulation Files for Direct Simulation":

By convention, if the parameter model (with prompt Model Name) is set,
the value is used as the component name.

I remember having done this successfully ; if this doesn't work i can
dig in my archives...

stéphane

 

[S.Badel]

danmc wrote:

the connectivity part works like a champ. The schCheck() part doesn't
because the schematics created by cdlin are really just a connectivity
database and it has this schType=schNoEdit set on them which prevents
schCheck() from doing anything.

-Dan

they say cdlin schematics are editable since version 5.0.33 (i don't
know i never use cdl).

since then there is also the connectivity-to-schematic which allows to
generate wired schematics instead of connectivity-only. (schematic
generation options in the cdlin form, conn2sch() with skill).

you still have the good old auLvsFixTimeStamps( cvId ) which may get rid
of the problem.

stéphane

 

[Pete nospam Zakel]

In article <1112356455.190356.283480@o13g2000cwo.googlegroups.com> "Gerd" <gerdbeeckman@yahoo.com> writes:

Ok, i will have a look.

Do you know if you can make the model name a variable in the CDF data
for auCdl netlisting?

cdfId->simInfo->auCdl = '( nil
netlistProcedure ansCdlCompPrim
instParameters (m L W)
termOrder (D G S B)
propMapping (nil m VarProp)
namePrefix "M"
modelName "N"
)

Whatever i put for modelName (names, variables, quotes, no quotes), it
is always printed literally in the CDL netlist...

The single quote preceding the paren opening the list means "do not evaluate
members", so in the above everything inside the parens (included lists) will
consist of nil, a symbol, a string or a list of nil, symbol and/or string.
Nothing will be evaluated.

If you want a variable to be evaluated, use list():

cdfId->simInfo->auCds = list( nil
'netlistProcedure 'ansCdsCompPrim
'instParameters '(m L W)
'termOrder '(D G S B)
'proMapping '(nil m VarProp)
'namePrefix "M"
'modelName variableName
)

-Pete Zakel
(phz@seeheader.nospam)

The Third Law of Photography:
If you did manage to get any good shots, they will be ruined
when someone inadvertently opens the darkroom door and all of
the dark leaks out.