RE: Meeting minutes 050825

Hi Russ,

You stated that "The SystemVerilog use model is the 90% use case."

We at Cadence believe that the decision which language to use for DUT
and BFM modeling (SystemVerilog, VHDL or Verilog 2001) should be made by
our customers and that a SCE-MI 2.0 standard should respect this
assumption and provide a solution that does not compromise the needs of
any of the SystemVerilog, Verilog 2001 and the VHDL communities. 

I agree with the rest of your email.

Regards,

Shabtay

>-----Original Message-----
>From: Russell Vreeland [mailto:vreeland@broadcom.com]
>Sent: Thursday, September 15, 2005 9:37 AM
>To: 'John Stickley'; Shabtay Matalon
>Cc: itc@eda.org
>Subject: RE: Meeting minutes 050825
>
>Hi.
>
>I want to clarify my request to John and Mentor to give an example,
using a
>text description or something at an equally high level (shouldn't take
more
>than an hour or so or it's too much detail).
>
>The question is: if a SCEMI 2.0 VHDL model were written using function
call
>semantics on the HDL side, and either attributes or metacomments were
used
>to provide additional information required to effect the binding to the
C
>side, how would the system "work" in a pure simulation mode. Let's just
use
>VHDL for the request rather than olderVerilog since the answer should
port
>over to olderVerilog.
>
>It's a given that *something* additional must be added to the simulator
>itself. This is true for both the function based and macro based
paradigms.
>Only in SystemVerilog do we have a truly self-contained executable
>simulation without any external add-ons (libraries, special parsers,
>PLI/FLI
>code, etc.) being needed.
>
>Maybe the best way to describe the system would be to trace data from
the C
>side to the HDL side and back again, describing a feasable binding and
>attribute interpretation mechanism. There might be a very large space
of
>possible schemes to do this, but I'm only interested in an obvious,
fairly
>generic one that can demonstrate the feasibility of a SCEMI 2.0
>specification written this way.
>
>Once this is done, perhaps we can move on to more important topics? The
>SystemVerilog use model is the 90% use case.
>
>---------------------------------------
>---    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 John Stickley
>> Sent: Thursday, September 15, 2005 8:09 AM
>> To: Shabtay Matalon
>> Cc: itc@eda.org
>> Subject: Re: Meeting minutes 050825
>>
>>
>> Shabtay,
>>
>> My apologies, I've been literally without e-mail access for
>> the last week straight and am just getting to this now.
>>
>> As of rev 1.5, I think pragma syntax is still shown for
>> import/export decl syntax (attribute syntax for data type
>> qualifiers), but I think we can be open to making this
>> attribute based as well.
>>
>> -- johnS
>>
>> Shabtay Matalon wrote:
>> > Hi John,
>> >
>> > Should I assume that the latest Revision you have sent (I
>> believe this
>> > was Revision 1.5) is compatible with your statement here (about no
>> > requiring any language extensions) or do you plan to publish a
>> > different revision that you see as compatible with this statement.
>> >
>> > Please clarify.
>> >
>> > Thanks,
>> >
>> >  >And with some of the recent proposals we've been
>> discussing,  >all
>> > function declarations can be made via attributes which
>> >are part of
>> > both Verilog and VHDL. So if people are uncomfortable
>> >with pragmas,
>> > this is another approach that is fully consistent  >with existing,
>> > supported language features and requires no  >langauage
>> extensions as
>> > you suggest below.  >
>> >  >-- johns
>> >
>> >
>>
>> --
>>
>> 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                   \             \     \
>> Mgr., Acceleration Methodologies \             \________________
>> Mentor Graphics - MED             \_
>> 17 E. Cedar Place                   \   john_stickley@mentor.com
>> Ramsey, NJ  07446                    \     Phone: (201) 818-2585
>> ________________________________________________________________
>>
>
>