netlisting question. Why are stopviews also in the switchvie

F

fogh

Guest
Hi All,

I for instance often see for a diva configurations:
switchviewlist=(auLvs schematic extracted)
stopviewlist=(auLvs)

But the same goes for other simulators. And I wonder why auLvs was put also in
the switchviewlist.
 
Why are stopviews also in the switchviewlist ?
switchviewlist=(auLvs schematic extracted)
Click to expand...
stopviewlist=(auLvs)

Because of the netlister takes the switchlist
and scans your top hierarchy for instances with
the views in the switch list. If it find one with
a view also in the stop list a netlist entry will
be made, if not the netlister goes on hierarchy level
down for the specific instance (whith no stop view on this level)
.... and so on ... and so on.

So the switch list defines the views wich can be traversed
down and also the stop views, which have to be additional defined
in the stop list.
Aslo the stop list has a priority, first view highest prio,
the switch list has no prioriy.

Bernd
 
Because the way it work is that when it reaches a particular cell,
it tries each entry in the switch list in turn, and switches into the first
view in the switch list it finds.

If that view is then in the stop list, it stops expanding the hierarchy.

The switch list is the priority order for picking views. If stopping
views weren't in the switch list, it wouldn't know whether they should take
priority over other views or not.

Regards,

Andrew.

On Thu, 25 Nov 2004 10:54:57 +0100, fogh
<cad_support@skipthisandunderscores.catena.nl> wrote:

Hi All,

I for instance often see for a diva configurations:
switchviewlist=(auLvs schematic extracted)
stopviewlist=(auLvs)

But the same goes for other simulators. And I wonder why auLvs was put also in
the switchviewlist.
Click to expand...
 
It makes a bit more sense now. If you have block-beharioral models, I understand
that you get a shorter netlist when you use:

switchviewlist=(veriloga schematic)
stopviewlist=(veriloga)

than when you use:
switchviewlist=(schematic veriloga)
stopviewlist=(veriloga)

But it is not a necessity to put the stopview in the switchlist, in the latter
case ? There should not be any difference if you use
switchviewlist=(schematic)
stopviewlist=(veriloga)



Andrew Beckett wrote:
Because the way it work is that when it reaches a particular cell,
it tries each entry in the switch list in turn, and switches into the first
view in the switch list it finds.

If that view is then in the stop list, it stops expanding the hierarchy.

The switch list is the priority order for picking views. If stopping
views weren't in the switch list, it wouldn't know whether they should take
priority over other views or not.

Regards,

Andrew.

On Thu, 25 Nov 2004 10:54:57 +0100, fogh
cad_support@skipthisandunderscores.catena.nl> wrote:


Hi All,

I for instance often see for a diva configurations:
switchviewlist=(auLvs schematic extracted)
stopviewlist=(auLvs)

But the same goes for other simulators. And I wonder why auLvs was put also in
the switchviewlist.
Click to expand...
 
On Thu, 25 Nov 2004 20:42:42 +0100, fogh
<cad_support@skipthisandunderscores.catena.nl> wrote:

It makes a bit more sense now. If you have block-beharioral models, I understand
that you get a shorter netlist when you use:

switchviewlist=(veriloga schematic)
stopviewlist=(veriloga)

than when you use:
switchviewlist=(schematic veriloga)
stopviewlist=(veriloga)

But it is not a necessity to put the stopview in the switchlist, in the latter
case ? There should not be any difference if you use
switchviewlist=(schematic)
stopviewlist=(veriloga)
Click to expand...
If you miss out veriloga from the switch list, it will _never_ pick veriloga
views. So there is no point in putting it in the stop list either.

Of course, if your design has schematics for everything, then it won't make
any difference!

I don't understand why you think that in the latter case you should not need
to put it in the switch list - unless it's because the design has schematics
for everything? Or are you just thinking that it should put the stop list at
the end of the switch list automatically? (if so, how would it prioritise the
views if there is more than view in the stop list?). Remember, the switch list
is ordered, but the stop list isn't. And it would be rather imprecise with
rules like that.

The rule is that it will only switch into views in the switch list, and only
stop on views that it has switched into and are in the stop list. That's it
(unless you're using a config to control the switching more specifically,
or are using things like nlAction=stop properties on the design).
It's simple, well defined, and works.

Note that in general veriloga should not be in the stop list, since it can
have structure, and putting it in the stop list would stop it being able to
descend down into blocks instantiated within the veriloga.

Andrew.
 
Andrew Beckett wrote:
On Thu, 25 Nov 2004 20:42:42 +0100, fogh
cad_support@skipthisandunderscores.catena.nl> wrote:


It makes a bit more sense now. If you have block-beharioral models, I understand
that you get a shorter netlist when you use:

switchviewlist=(veriloga schematic)
stopviewlist=(veriloga)

than when you use:
switchviewlist=(schematic veriloga)
stopviewlist=(veriloga)

But it is not a necessity to put the stopview in the switchlist, in the latter
case ? There should not be any difference if you use
switchviewlist=(schematic)
stopviewlist=(veriloga)




If you miss out veriloga from the switch list, it will _never_ pick veriloga
views. So there is no point in putting it in the stop list either.

Of course, if your design has schematics for everything, then it won't make
any difference!

I don't understand why you think that in the latter case you should not need
to put it in the switch list - unless it's because the design has schematics
for everything? Or are you just thinking that it should put the stop list at
the end of the switch list automatically? (if so, how would it prioritise the
views if there is more than view in the stop list?). Remember, the switch list
is ordered, but the stop list isn't. And it would be rather imprecise with
rules like that.

The rule is that it will only switch into views in the switch list, and only
stop on views that it has switched into and are in the stop list. That's it
(unless you're using a config to control the switching more specifically,
or are using things like nlAction=stop properties on the design).
It's simple, well defined, and works.

Note that in general veriloga should not be in the stop list, since it can
have structure, and putting it in the stop list would stop it being able to
descend down into blocks instantiated within the veriloga.
Click to expand...
The setup makes sense. The priorityless stoplist is the main reason
why stopviews must be in the switchlist.
In fact I now remember Icame to this conclusion when experimenting,
some time ago. But I stays a bit counterintuitive.

If you dont mind, I have another question still:
If I want to trick ADE to generate some custom netlist, and I give
stopviews for a simulator that is different from the simulator currently
selected in ADE, what siminfo CDF will be used by the netlister ?
 
On Sat, 27 Nov 2004 23:52:19 -0500, fogh <adff@xs4all.nl> wrote:

The setup makes sense. The priorityless stoplist is the main reason
why stopviews must be in the switchlist.
In fact I now remember Icame to this conclusion when experimenting,
some time ago. But I stays a bit counterintuitive.

If you dont mind, I have another question still:
If I want to trick ADE to generate some custom netlist, and I give
stopviews for a simulator that is different from the simulator currently
selected in ADE, what siminfo CDF will be used by the netlister ?
Click to expand...
A particular ADE netlister will always use the simInfo for that netlister. It
does not use the simInfo which matches the stopping view. The stopping
view merely tells the netlister to stop expanding the hierarchy; the simInfo
for the netlister controls what is output at that point.

Regards,

Andrew.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top