How can I promote the termorder "warning" to become "fatal e

[fogh]

Hi All,

despite my explanation efforts, some designers prefer to ignore this:

\o Netlist Warning: Mismatch was found between the terminals in the cellView and
\o those on the pin order property on the schematic, or on the termOrder
\o property on the CDF. The internal default order is being used. Please
\o eliminate the mismatch if any of the above properties must be used for
\o netlisting.

AFAIK, this means that they very well be simulating with the differential inputs
swapped or any other misconnection. So I don t want this simulation to start at all.

Do you know how I can customise ADE and turn this into a fatal error, so that
the simulation starts only when they have their CDF updated ?

Or do you have other suggestions ? (place a trigger, in schematic save, symbol
save, or simulation start. Get this fixed automatically rather than having the
designer perform the "create cellview from cellview" by hand ...)

 

[A. B.]

fogh wrote:

Hi All,

despite my explanation efforts, some designers prefer to ignore this:

\o Netlist Warning: Mismatch was found between the terminals in the
cellView and
\o those on the pin order property on the schematic, or on the
termOrder
\o property on the CDF. The internal default order is being used.
Please
\o eliminate the mismatch if any of the above properties must be
used for
\o netlisting.

why the cdf has to be updated manually. Your designers want that to be
automatic or at least provide a way like setting a varialble something
like (alwaysUpdateCFD true) and leave the manual to one who wants to
do it.
This is of course not intended for you but mainly for Cadence people
since you raised the issue.

 

[fogh]

Gerry,

I don t really want to modify the swapability of terminals for aulvs or
assura, what I would like is that spectre simulations do not start when the
termorder of cells is wrong.

G Vandevalk wrote:

There is an lvs option to allow terminal order to be swapped.
This is to be used as an LVS aid when things are messed up.
Turn the option off and the LVS will fail. (i.e. you get your fatal errors!)

-- Gerry


"fogh" <cad_support@skipthisandunderscores.catena.nl> wrote in message
news:112ubhnf5vnen8e@news.supernews.com...

Hi All,

despite my explanation efforts, some designers prefer to ignore this:

\o Netlist Warning: Mismatch was found between the terminals in the

cellView and

\o those on the pin order property on the schematic, or on the

termOrder

\o property on the CDF. The internal default order is being used.

Please

\o eliminate the mismatch if any of the above properties must be used

for

\o netlisting.

AFAIK, this means that they very well be simulating with the differential

inputs

swapped or any other misconnection. So I don t want this simulation to

start at all.

Do you know how I can customise ADE and turn this into a fatal error, so

that

the simulation starts only when they have their CDF updated ?

Or do you have other suggestions ? (place a trigger, in schematic save,

symbol

save, or simulation start. Get this fixed automatically rather than having

the

designer perform the "create cellview from cellview" by hand ...)

 

[fogh]

A. B. wrote:

fogh wrote:

Hi All,

despite my explanation efforts, some designers prefer to ignore this:

\o Netlist Warning: Mismatch was found between the terminals in the
cellView and
\o those on the pin order property on the schematic, or on the
termOrder
\o property on the CDF. The internal default order is being used.
Please
\o eliminate the mismatch if any of the above properties must be
used for
\o netlisting.


why the cdf has to be updated manually. Your designers want that to be
automatic or at least provide a way like setting a varialble something
like (alwaysUpdateCFD true) and leave the manual to one who wants to
do it.
This is of course not intended for you but mainly for Cadence people
since you raised the issue.

That is indeed the next step.

But first of all, I want to make sure that people do not simulate a GIGO system
(garbage in garbage out) when the want to verify their finely crafted ICs.

 

[S. Badel]

AFAIK, this means that they very well be simulating with the
differential inputs swapped or any other misconnection. So I don t want
this simulation to start at all.

I think what you say is not true, except in the case where doing gate(block)-level schematics
where the netlists of the cells are in an external include file. (which is quit unlikely)
If you're netlisting from top to bottom, then this will have no impact, because there's
no need to match terminals by position.
Only in the case where the netlist for a subblock is already done, there is need to
set the terminal netlisting order to a predefined (matching) value.
I might be wrong, but i'd see it in this way.

This warning appears usually when you first create a cell, then generate the CDF info
(this is done automatically when generating a symbol i.e.)
and after modify the cell (add/remove/rename pins) without updating the CDF.
because the term list isn't up to date, netlister cannot guess the order in which it
has to netlist them, so it will generate a default order which is, if i'm not wrong,
outputs, then inputs, then ios last.

One workaround is to re-generate the CDF information, using artGenerateHierSymbolCDF().

The following env. variable might interest you, as it may prevent cdf to get out of sync
asimenv.misc updateCDFtermOrder boolean t

Other threads discussed this issue, you might be interested:
http://groups.google.ch/groups?hl=fr&lr=&client=firefox-a&rls=org.mozilla:en-USfficial_s&selm=Pine.SGI.4.30.0409131610240.22048-100000%40world.std.com
http://groups.google.ch/groups?hl=fr&lr=&client=firefox-a&rls=org.mozilla:en-USfficial_s&selm=3e255ff8%40news.ecs.soton.ac.uk

If this doesn't solve your problem, I do not see any other solution than giving a couple of kicks in
the as{2}...


cheers,

stéphane

 

[fogh]

S. Badel wrote:

AFAIK, this means that they very well be simulating with the
differential inputs swapped or any other misconnection. So I don t
want this simulation to start at all.
I think what you say is not true, except in the case where doing
gate(block)-level schematics
where the netlists of the cells are in an external include file. (which
is quit unlikely)
If you're netlisting from top to bottom, then this will have no impact,
because there's
no need to match terminals by position.
Only in the case where the netlist for a subblock is already done, there
is need to
set the terminal netlisting order to a predefined (matching) value.
I might be wrong, but i'd see it in this way.

This warning appears usually when you first create a cell, then generate
the CDF info
(this is done automatically when generating a symbol i.e.)
and after modify the cell (add/remove/rename pins) without updating the
CDF.
because the term list isn't up to date, netlister cannot guess the order
in which it
has to netlist them, so it will generate a default order which is, if
i'm not wrong,
outputs, then inputs, then ios last.

One workaround is to re-generate the CDF information, using
artGenerateHierSymbolCDF().

The following env. variable might interest you, as it may prevent cdf to
get out of sync
asimenv.misc updateCDFtermOrder boolean t

Other threads discussed this issue, you might be interested:
http://groups.google.ch/groups?hl=fr&lr=&client=firefox-a&rls=org.mozilla:en-USfficial_s&selm=Pine.SGI.4.30.0409131610240.22048-100000%40world.std.com

http://groups.google.ch/groups?hl=fr&lr=&client=firefox-a&rls=org.mozilla:en-USfficial_s&selm=3e255ff8%40news.ecs.soton.ac.uk


If this doesn't solve your problem, I do not see any other solution than
giving a couple of kicks in the as{2}...

I believe you are right about the meaning of the warning: the order in the
subckt and the instance will be consistent if the subcircuit was generated by
the netlister. There can be a problem when there is a verilogA model.

Thanks for all the references.

 

[Erik Wanta]

This is not a new issue. Some related PCRs:
PCR162848
PCR179601
PCR343522
PCR699316
PCR715381
PCR721911
PCR741895
PCR762930
PCR778940

I understand the use of simInfo->termOrder for primitive devices but we
typically don't create primitive devices and just use those from our
design kit provider. If we don't have simInfo->termOrder for
schematics with hierarchy the simulations run fine in spectre. That
begs the question why we would want to have this termOrder property
saved with the cell. All these properties do is cause endless pain and
frustration.

My understanding of the progression of this problem:
1. design->create cellview->from cellview created simInfo->termOrder
for everything. When pins were added or deleted from a symbol the
simInfo->termOrder would not get updated.
2. Someone complained and Cadence responded by adding a warning during
netlisting that the simInfo->termOrder didn't match the cell terminal
list.
3. We now get tons of warnings while netlisting that mask warnings we
care about or errors.
4. We wrote some SKILL to update the simInfo->termOrder for our
libraries but we don't want to continuously police our libraries and
make sure our simInfo->termOrder is up to date.
5. We requested that there be a way to update the simInfo->termOrder
when the symbol is checked and saved. This led to
envSetVal("auCore.misc" "updateCDFtermOrder" 'boolean t) which is not
bulletproof. It fails if the prop.xx is checked out and can't be
edited. It takes time to check out and update the prop.xx...

In short, the Cadence approach to the problem has been to try to
provide ways to keep this simInfo->termOrder property up to date. This
is a band-aid solution and doesn't work in practice. We still have
cells where the simInfo->termOrder doesn't match the terminal list
resulting in warnings and netlist errors. Given that spectre, ADSsim,
ultrasim ... don't need the simInfo->termOrder on schematics with
hierarchy we question why Cadence is adding a property to the database
that it doesn't need and then has to babysit/bookkeep it. We want to
delete all the simInfo->termOrder properties from all our non-primitive
cells and have a way to disable the automatic creation of
simInfo->termOrder when we do a Design->Create Cellview->From Cellview
so that we can end these warnings, netlist errors, and simulation
confusion once and for all.
---
Erik

 

[G Vandevalk]

There is an lvs option to allow terminal order to be swapped.
This is to be used as an LVS aid when things are messed up.
Turn the option off and the LVS will fail. (i.e. you get your fatal errors!)

-- Gerry


"fogh" <cad_support@skipthisandunderscores.catena.nl> wrote in message
news:112ubhnf5vnen8e@news.supernews.com...

Hi All,

despite my explanation efforts, some designers prefer to ignore this:

\o Netlist Warning: Mismatch was found between the terminals in the
cellView and
\o those on the pin order property on the schematic, or on the
termOrder
\o property on the CDF. The internal default order is being used.
Please
\o eliminate the mismatch if any of the above properties must be used
for
\o netlisting.

AFAIK, this means that they very well be simulating with the differential
inputs
swapped or any other misconnection. So I don t want this simulation to
start at all.

Do you know how I can customise ADE and turn this into a fatal error, so
that
the simulation starts only when they have their CDF updated ?

Or do you have other suggestions ? (place a trigger, in schematic save,
symbol
save, or simulation start. Get this fixed automatically rather than having
the
designer perform the "create cellview from cellview" by hand ...)