Subject: Re: Action Item recommendation
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Mon Jan 28 2002 - 20:43:45 PST
> From schandra@tvr.asc.corp.mot.com Mon Jan 28 18:48:43 2002
>
> Kev,
> But wouldnt this situation occur only in case of "split" mode?
>
> cheers,
> Sri
I don't think I did a good job on the last e-mail, so here is another
go with more rigor.
There are actually a couple of issues -
1) where does the auto-inserted module appear in the hieararchy?
2) what's it's name?
The auto-inserted modules all need a name regardless of the mode of
insertion, and the name needs to be some product of the objects
involved in the insertion and be unique in the context it is
instantiated in. Since the A/D modules are associated with a particular
port or net then that is the primary identifier, since the convertor
is either A2D, D2A or both, the source and target views should be next
e.g.:
\ms-auto:mixed1:convert(discrete->analog) // D2A
\ms-auto:mixed1:convert(analog->discrete) // A2D
\ms-auto:mixed2:convert(analog,discrete) // combined convertor
Since discrete views may differ (if we do wreal as a physical wire type
or you mix technologies) you would probably need to add it in too e.g.:
\ms-auto:mixed_net:convert(analog->discrete(real))
// A2D with real target.
- as there is only one analog view it doesn't need sub-typing.
The issue of split mode naming depends on the placement of the
instances, if you use process-bound semantics the instance would be
a child of the process's parent instance and will use the process's
name as the final part of the identifier e.g.:
\ms-auto:mixed_net:convert(analog->discrete):process(proc_0)
With port-bound semantics the interfaces appear to be instantiated
in the context of instance where the bound port is, rather than in
the instance of the driving/receiving processes/ports so the path
to the process/port's instance needs to added e.g.:
\ms-auto:mixed_net:convert(analog->discrete):instance(sub1/sub2)
- I don't think the child port name is actually necessary, and the
instance path wouldn't be necessary if the module is instantiated
at that level instead (which is probably preferable anyway).
Discipline names and actual conversion module names don't need to
be part of the instance name, but could be added for clarity. Not
including them makes the names invariant wrt. technology.
Whether you use '__' and regular characters or the "escaped" form
won't make much difference to the uniqueness of the names, but
will affect whether secondary tools looking at VCD etc. can work
out what is going on. E.g. I'm currently using a fairly dumb
toggle coverage tool, and it would be good if I could just filter
out all signals beginning "\*-auto:".
I think both formats should be defined in the LRM and be a runtime
choice for the user.
Regards,
Kev.
> Kevin Cameron x3251 writes:
> #
....
> #
> #
> #More specifically something like:
> #
> # <auto-instance name> :== '\ms-auto:'<port name>':'<interface module name>':'<insert mode>
> # <insert mode> :== 'split;'<child>,<port>|'merged;'<discipline name>
> #
> #e.g.:
> #
> # top.I1.I2.I3.\ms-auto:mixednet:i0:merged;cmos3.vcc
> # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> #
> # top.I1.I2.I3.\ms-auto:mixed2:i1:split;sub1,in.dly
> # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> #
> #- then tools and users know what is going on :-)
> #
> #Kev.
> #
This archive was generated by hypermail 2b28 : Mon Jan 28 2002 - 20:44:48 PST