RE: Cadence Goals Comments - 2

> -----Original Message-----
> From: Bojsen, Per [mailto:bojsen@zaiqtech.com] 
> Sent: Friday, April 01, 2005 7:39 AM
> To: 'vreeland@broadcom.com'; 'Matt Kopser'; itc@eda.org
> Subject: 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?  

Yes, but that's what was on the slide. It talked about "modeling constructs"

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

When coming out of reset ( a likely case ), the simulation-only run of a
model may propagate Xs and U's such that the simulation will fail whereas on
an emulator, these may default to 0's and 1's and allow the simulation to
pass. That is one common scenario.

Do we need to address this? It could get a little complicated. For example,
do we want to allow initial blocks in hw source code that set the transactor
to a state common in emulation and simulation? Do we explicitly say the
emulation compiler must ignore initial blocks -OR- do we recognize standard
synthesis pragmas like //translate_off and //translate_on ?

I've always felt it's important to address the simulation-only mode in
SCEMI. The question is; how deep do we go?


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

Yes. Or, SCE-MI models could be simulatable outside of implementation
products (using off-the-shelf simulators).


> This is certainly not a requirement in SCE-MI 1.x which only 
> concerns itself with one platform/engine at a time.

This is a big shortcoming of SCE-MI 1.x in my view.

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

No, that is not what I meant at all. What I said was, in order to be able to
run in simulation-only mode, the "whole" transactor model (sw side and hw
side) ought to consist of LRM compliant HDL (on the hw side) and C/C++ (on
the SW side). The SCE-MI spec is free to further specify subsets of these
languages that it will support, or interfaces within these languages that
SCE-MI models must adhere to (e.g., the SCE-MI 1.1 API on the sw side).

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

Hmm, we've always used the term "transactor" for the whole tool -- sw side
and hw side. When someone calls me and asks "do you have a transactor for
the XYZ bus?" if I were to say, "yes, and I also have a proxy model" that
would cause a lot of unnecessary confusion. But you're right, the spec
defines it to be the hw side only. I guess I just don't like the term "BFM",
but I'll drop this point until/unless we take up writing a new glossary for
the new spec.

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




---------------------------------------
---    Russ Vreeland (949)926-6143  ---
---    vreeland@broadcom.com        ---
---    Senior Principal Engineer    ---
---    Broadcom Corporation         ---
---------------------------------------