Comments embedded ...

Bojsen, Per wrote:
> Hi,
> 
> in order to bind message ports one must provide a transactor name
> and a port name.  On p. 35 of the standard, the transactor name is
> defined as the instance name of the top-level of the transactor
> where a transactor is defined as a module containing a
> SceMiClockControl macro immediately inside it (I take this to mean
> the SceMiClockControl macro is instantiated at one hierarchy level
> below the top-level of the transactor).  This definition is reiterated
> in a couple of places.  This raises some issues:

johnS:
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.

> 
>   1) A transactor is required to include a SceMiClockControl instance
>      even if it does not intend to actually do any clock control.
>      In the committee we have during the recent meetings been talking
>      about a class of transactors that will not do clock control.
>      What of these transactors?

johnS:
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.

However, we may want to consider relaxing the requirement for this ...

> 
>   2) With the proposed variable length message ports, transactors
>      can take advantage of implicit clock control so do not need to
>      instantiate a SceMiClockControl macro.  This implies that a
>      different mechanism for identifying the top-level of a transactor
>      instance is required.

johnS:
Perhaps it can be done heuristically without adding a new mechanism.
See below ...

> 
>   3) It does not appear to be allowed to instantiate the
>      SceMiClockControl macro in some sub-module.  However, based on
>      the definition of port name, it *is* allowed to instantiate
>      port macros in sub-modules.  Given 1 and 2, would it make sense

johnS:
Yes, this is correct.

>      to change the definition of transactor to not rely on the
>      SceMiClockControl macro, but instead rely on an agreed upon
>      parameter that identifies a module as a top-level of a
>      transactor?

johnS:
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.

-- johnS

> 
> Per
===========================================================================

> 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?  

Per