Re: SCE-MI Transactor Definition

Per,

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

-- 
This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Principal Engineer               \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________