RE: Cadence Goals Comments - 2

Hi Russ,

> * The hardwire side of a transactor shall require no source code changes
to
> be run in the equivalent simulation mode.

This pertains more to modelling than to the interface, doesn't it?  While I
think I know what you are getting at, I think you need to qualify to sound
something like this:

  * A compliant SCE-MI implementation shall make it possible to write the
    hardware side of a transactor such that no source code changes are
    required to run in the equivalent simulation mode.

I did not qualify SCE-MI with a version number because I believe this is
possible to do for SCE-MI 1.x already.  So I guess the purpose of this
bullet is to make sure nothing gets introduced to the SCE-MI standard
that would break this.

The reason I believe you need to qualify the statement with `make it
possible to write' is that a user can write anything and it is not hard
to write something that is entirely acceptable to the emulator and runs
correctly on the emulator but fails on the simulator.  This can be very
subtle differences such as 2-state and 4-state logic.  This is a problem
even if you stay entirely within the LCD of all synthesizable subsets.

I am guessing you were trying to make a stronger statement though . . .

> it requires that if hw side constructs are "black boxes" for emulation
> compilation, then the underlying functionality must be provided for
simulation
> mode.

If I'm reading this correctly, this sounds like a new requirement/goal
to me that does not follow from the above.  Are you saying that you want
to require of SCE-MI implementations that they always provide a simulation
only mode as well as the mode for their primary target platform?  This
is certainly not a requirement in SCE-MI 1.x which only concerns itself
with one platform/engine at a time.

> * The message exchange interface between the software and hardware
> side must both be able to run using the appropriate simulator without
> changes to source code.

Aagin, I think we need to qualify this statement as above.  Here I'm
assuming you're talking about the code that interfaces to the SCE-MI
transport.  

> this mandates LRM compliance of the source code on both the hw and sw
> sides, nothing more.

Can you elaborate on this?  It sounds like you're stating that a
SCE-MI implementation must accept any code the user wrote as long
as it is legal HDL/C/C++/HVL code according to the relevant LRMs?
Somehow I doubt this as this goes way beyond even the most ambitious
language subset/superset discussion we've had recently.

> Also, as an aside: I've tried to use the terminology that I think was
> most commonly used in the SCEMI 1.x spec(s) in describing the
> "transactor" as a conglomerate of things on both the "hw side" and
> "sw side".

Actually, SCE-MI defines a transactor to be the stuff on the hardware
side only.  The stuff on the software side is called a proxy model.
See for instance Figure 4 on p. 13, Figure 6 on p. 17, Section 4.3.2
on p. 15, and Section 5.3.1 p. 37.

I agree that most people nowadays consider the transactor to be
something that typically spans the boundary between the software and
hardware side and Shabtay was proposing to change the definition of
`transactor' to reflect that.  He chose to call the hardware side
BFM and there is already a name for the software side: proxy model.

> The terms "BFM and proxy model" I don't think are entirely synonymous
> with "hw side, and sw side". For example, I have many transactors
> which don't interface to a bus at all -- a peekable/pokeable memory
> is one example.

True, but that could be solved by generalizing the definition of
the term `BFM'.  I normally think of BFM in this more general sense,
since `hardware side of the transactor' is a bit cumbersome as a
term :-)

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