RE: Cadence Goals Comments - 2

Here were the 3 bullets from Duaine's/Matt's  slides that were discussed at
length today:
  
n *  No transactor modeling constructs need to be changed to move from
acceleration to simulation.   (changed per Shabtay's correction)
n
 
 *   Interfaces and architecture do not need to be changed to move from
simulation to emulation 
n
 
 *  Compatible use models will be maintained between simulation and
emulation. 
 
 
I'd like to suggest changes to make these clearer. It's understood that all
these requirements are prefaced implicitly by "To be SCEMI 2.0 compliant.."
 
* The hardwire side of a transactor shall require no source code changes to
be run in the equivalent simulation mode.
 
this rules out non-LRM compliant constructs put into the hw description of a
transactor just for emulation compilation. it requires that if hw side
constructs are "black boxes" for emulation compilation, then the underlying
functionality must be provided for simulation mode. it doesn't rule out
pragmas or attributes as long as these are not essential for proper
functionality. it leaves open usage of pragmas/attributes for emulation-only
modes of operation like concurrent streaming (with the requirement that
things run in simulation-only mode correctly, just not concurrently)
 
by "the equivalent simulation mode" I mean if it's a VHDL transactor, run in
a VHDL simulator, verilog transactor -> verilog simulator, SystemVerilog ->
SV simulator. Perhaps there's better language for what I'm trying to say....
do we need a phrase like "the appropriate simulator" to indicate we mean a
verilog simulator for a transactor whose hw side is written in verilog?
should this be an agreed-upon glossary item so we can continue to discuss
this precisely?
 
* 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.
 
this mandates LRM compliance of the source code on both the hw and sw sides,
nothing more. anything can be underneath the LRM-compliant constructs as
long as it's portable (which, hopefully, is redundant after saying it's LRM
compliant). However, I hope that we can agree that "whatever is underneath"
ought to be publicly available -- that is, a user should not have to buy a
tool other than a simulator to be able to run a SCEMI 2.0 model in
simulation mode.   I think IP providers will appreciate this proviso.
Comments?????
 
 
I'm not going to suggest a change for the "compatible use" bullet because I
don't fully understand what this means. It seems to me that if the first two
bullets are given, then something like compatible usage should follow. This
term is imprecise and needs clarification.
 
 
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". 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.
 

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

-----Original Message-----
From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Matt Kopser
Sent: Thursday, March 31, 2005 7:37 AM
To: itc@eda.org
Subject: Cadence Goals Comments - 2


Trouble getting both presentations through the reflector.  Here is the
SECOND one. (Modified
version of Duaine's presentation.)
 
Matt


  _____  

From: Matt Kopser 
Sent: Wednesday, March 30, 2005 11:46 PM
To: 'itc@eda.org '
Subject: Cadence Goals Comments


All,
 
I've attached 2 presentations. (Sorry about the late submittal of these --
I've been catching
up after taking some vacation time...)
 
At any rate, the first presentation is very short, and is basically a
commentary on the
means by which the committee moves forward. (In it I echo Richard's comment
about
focusing in the *interface* in ITC.)
 
The other presentation is a modified version of Duaine's 3/24 version of the
goals presentation.
The bulk of the changes are in slide 13 -- plus an additional slide at the
end of the presentation
summarizing high-level goals of ITC -- with the focus on interface, mindful
of modeling issues.
 
And for clarification: Duaine's recent email seems to indicate that Cadence
is not interested
in working on modeling issues. That's not quite accurate. Cadence believes
that ITC is not
the appropriate forum to handle modeling issues -- yet modeling issues are
indeed important.
The first presentation suggests alternate committee(s) to handle such
issues.
 
Again, sorry for the late arrival of these documents,
 
Matt