no need to check and save in analog artist (restoring the ic

[fogh]

Hi All,

This is a first draft. It behaves not exactly like ic442, because it
saves the cellview. Thanks in advance for posting any improvement.

Criticism is welcome too. BTW, what motivated this change between
ic442 and ic443 ?



;;________________________________________________________________________________________________

/*
supress the need to check&save before simulations.
*/

let( (tool flowchart)

tool=asiGetTool('spectre)
flowchart = asiGetFlowchart( tool )

procedure( CmAsiCNS(session)
let( ( (cv session->data->cellView) status )
and(
cv
schExtractStatus(cv)=="obsolete"
cv->mode != "r" || dbReopen( cv "a" )
schExtractConn(cv)
dbSave(cv)
);and
status=not(schExtractStatus(cv)=="obsolete")
);let
);proc

flowchart->data->asiNetlist->preFunc='CmAsiCNS

);let

 

[Andrew Beckett]

On Thu, 05 May 2005 17:56:00 -0400, fogh <adff@xs4all.nl> wrote:

Hi All,

This is a first draft. It behaves not exactly like ic442, because it
saves the cellview. Thanks in advance for posting any improvement.

Criticism is welcome too. BTW, what motivated this change between
ic442 and ic443 ?



;;________________________________________________________________________________________________

/*
supress the need to check&save before simulations.
*/

let( (tool flowchart)

tool=asiGetTool('spectre)
flowchart = asiGetFlowchart( tool )

procedure( CmAsiCNS(session)
let( ( (cv session->data->cellView) status )
and(
cv
schExtractStatus(cv)=="obsolete"
cv->mode != "r" || dbReopen( cv "a" )
schExtractConn(cv)
dbSave(cv)
);and
status=not(schExtractStatus(cv)=="obsolete")
);let
);proc

flowchart->data->asiNetlist->preFunc='CmAsiCNS

);let

I'm not going to comment on the code - it's a bit of a hack, and I'd probably
do it by changing the menu items to do the check first, and then calling the
normal netlist and run function, instead of hacking the flowchart... (I think
I've suggested that before in this forum).

It didn't change between IC442 and IC443. What happened was that it is
different between spectreS and the spectre interface (which was introduced in
IC443). When you ran a simulation, it used to spend more time traversing the
hierarchy to find any cellViews that needed checking, and then doing that
checking, than it did doing the netlisting. In large, hierarchical designs,
this could be significant overhead when most of the time the checking had been
done. So now with the spectre interface, it just tells you if something is out
of date when it tries to netlist it.

One of the big efforts of the new (in IC443) spectre direct interface was to
streamline the whole process, to make getting to the start of the simulation
as fast as possible. Cutting out cdsSpice, using true incremental netlisting,
avoiding traversing the hierarchy to check if it needed checking (which adds
another hierarchy traversal) all added to this improvement.

Note that in the spectreS interface it did a check of any cellView down the
hierarchy. Also, it didn't save it - as yours is doing.

Regards,

Andrew.

 

[fogh]

Andrew Beckett wrote:

Hi All,

This is a first draft. It behaves not exactly like ic442, because it
saves the cellview. Thanks in advance for posting any improvement.

Criticism is welcome too. BTW, what motivated this change between
ic442 and ic443 ?

I'm not going to comment on the code - it's a bit of a hack, and I'd probably
do it by changing the menu items to do the check first, and then calling the
normal netlist and run function, instead of hacking the flowchart... (I think
I've suggested that before in this forum).

Would this keep consistency between the icon and the menu actions ?
Is there is cleaner way with flowchart (such as a proper flowchart step rather
than a "preFunc") ?

It didn't change between IC442 and IC443. What happened was that it is
different between spectreS and the spectre interface (which was introduced in
IC443). When you ran a simulation, it used to spend more time traversing the
hierarchy to find any cellViews that needed checking, and then doing that
checking, than it did doing the netlisting. In large, hierarchical designs,
this could be significant overhead when most of the time the checking had been
done. So now with the spectre interface, it just tells you if something is out
of date when it tries to netlist it.

One of the big efforts of the new (in IC443) spectre direct interface was to
streamline the whole process, to make getting to the start of the simulation
as fast as possible. Cutting out cdsSpice, using true incremental netlisting,
avoiding traversing the hierarchy to check if it needed checking (which adds
another hierarchy traversal) all added to this improvement.

I fully appreciate the effort and the decision made with the move to direct
netlisting. I wish something like that happened with db properties and CDF
properties.

Note that in the spectreS interface it did a check of any cellView down the
hierarchy. Also, it didn't save it - as yours is doing.
( Actually, the very first version did no save and returned always OK status. )

It a bit arbitrary, but I guessed that extraction of the topcell is good
enough for those fast-moving flat designs made mostly of behavioral blocks. When
it grows and has a proper hierarchy, it also typically has longer simulation
times, and the designer can be expected to take the time to check&save before
submitting.

 

[Andrew Beckett]

On Mon, 09 May 2005 12:50:11 +0200, in comp.cad.cadence you wrote:

I'm not going to comment on the code - it's a bit of a hack, and I'd probably
do it by changing the menu items to do the check first, and then calling the
normal netlist and run function, instead of hacking the flowchart... (I think
I've suggested that before in this forum).

Would this keep consistency between the icon and the menu actions ?
Is there is cleaner way with flowchart (such as a proper flowchart step rather
than a "preFunc") ?

Well, hacking around with the flowchart is dangerous, in that it might break
in future versions - I would be wary of doing.

If you change the menus file, you can change both the icon and the menu item,
so that's why I suggested it.

I fully appreciate the effort and the decision made with the move to direct
netlisting. I wish something like that happened with db properties and CDF
properties.

CDF is a bit of a complicated problem. Even if we'd provided callbacks at the
DB level for DB properties, there would still be a fundamental problem - such
a scenario would prevent the use of inherited parameters, since callbacks
would get triggered whenever the property changes. So, there's no way that
an instance within a block which has different values of an inherited
parameter could fire a callback. I suppose it would need some kind of concept
of a variant (a bit like a pcell) for this to work, and even then, any
callbacks would have to be triggered down through the hierarchy (which could
get very expensive).

Anyway, that's a whole different kettle of fish!

Note that in the spectreS interface it did a check of any cellView down the
hierarchy. Also, it didn't save it - as yours is doing.
( Actually, the very first version did no save and returned always OK status. )
It a bit arbitrary, but I guessed that extraction of the topcell is good
enough for those fast-moving flat designs made mostly of behavioral blocks. When
it grows and has a proper hierarchy, it also typically has longer simulation
times, and the designer can be expected to take the time to check&save before
submitting.

Personally I think it's a good habit to get into, as lots of things depend on
the schematic being checked. It's only one key press, so it's not exactly a
big amount of effort to check it...

Andrew.