[IM19] Re: SCE-MI Transactor Definition

Per,

Some comments embedded ...

Bojsen, Per wrote:
> Hi John,
>
> > Let me explain general intent, then address each of your questions.
> > The intent was to have SceMiClockControl's instantiated just inside
> > the transactor modules to identify the module that is considered a
> > transactor. But then to allow instantiation of ports at various
> > levels of hierarhcy within the transactor.
> >
> > Each port then would be identified as a relative path that could
> > be concatinated to the path of the transactor.
>
> This makes sense except for the transactors that do not want to
> do clock control.
>
> > One can certainly argue that transactors should not be required
> > to do clock control. The easiest way to solve this without breaking
> > the existing requirements is to instantiate a clock control with
> > its readyForCclock tied high.
>
> Right, that would work, but it seems a tad odd to have to instantiate
> a SceMiClockControl macro that is inactive just to identify the
> module as the top-level of a transactor :-)
>
> > However, we may want to consider relaxing the requirement for this ...
>
> I guess you agree with my comment above :-)
>
> > It may be that we don't even need a parameter. Perhaps we only
> > need to be concerned with forming the whole path to a given port
> > as the concatination of what the user gives as the transactor
> > path with what is given as the relative port path.
> >
> > The users themselves can probably decide which level of hierarchy
> > transactor begins. From the infrastructure point of view, this
> > is probably completely arbitrary.
>
> This proposal seems to be in conflict with the requirements of the
> infrastructure linker and the parameter file. The parameter file
> will contain MessageInPort and MessageOutPort objects with
> TransactorName and PortName attributes. The infrastructure linker
> must derive these which appears to be in conflict with letting the
> user decide where the transactor is as you suggest. How can we
> reconcile what you propose with the requirements of the infrastructure
> linker and the parameter file?

johnS:
Good point. Perhaps what we can do is this:

If the infrastructure linker finds a message port at some level of
hierarchy above which there is no clock control instance,
then, we assume transactor name to be the immediate parent
of that port and port name to be the port instance label
in that parent.

This heuristic will correctly handle the most common cases
where ports are instantiated immediately inside the transactors.
And where ports appear at various levels of hierarchy, users
will only need to know to specify path to their parents
as the "containing transactors".

-- johnS

>
> Per
>
> --
> Per Bojsen Email: <bojsen@zaiqtech.com>
> Zaiq Technologies, Inc. WWW: http://www.zaiqtech.com
> 78 Dragon Ct. Tel: 781 721 8229
> Woburn, MA 01801 Fax: 781 932 7488
>

______________________________/\/ \ \
John Stickley \ \ \
Principal Engineer \ \________________
Mentor Graphics - MED \_
17 E. Cedar Place \ john_stickley@mentor.com
Ramsey, NJ 07446 \ Phone: (201) 818-2585
________________________________________________________________
Received on Wed Mar 24 19:23:17 2004