no need to check and save in analog artist (restoring the ic442 behavior)

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.

 

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

 

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.

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!

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.