RE: SCE-MI 2.0 HDL Support (Re: Meeting minutes 050825)

Per,

I think that your email proposes some good principles which I mostly
agree with, a few I disagree with and some that require a bit of
clarification. Let me try to extract these principles into a list and
then comment. I hope this will help towards resolving the language
related issues on the table.

I rephrased 'old Verilog' to 'Verilog 2001' as I disagree with naming it
'old Verilog'.

- The choice of HDL should be transparent to the software side, i.e.,
the user should be able to use Verilog 2001, SystemVerilog, and VHDL
interchangeably without having to rewrite the software side 

[Shabtay] - Very important goal that should be attempted, but one that
cannot override the other principles. I expect that a modern reusable
transactor will be composed of proxy model and BFM pairs modeled in
coordination. If single SW side interface for all 3 languages could not
be created or if this will present too much of a tradeoff (mainly for
SystemVerilog users), I would support the notion of slightly different
SW side APIs for each HDL. 

Note: We should add the following principle to this discussion:

"- Transactors containing BFMs in different languages can co-exist in a
single verification environment."

- All three languages should have support for a function based interface
based on SystemVerilog DPI

[Shabtay] - Disagree. For example, a macro based approach easily
accomplishes HDL transparency. A function based approach may accomplish
that. The call is still open if "function-based approach which is based
on DPI" can be created in Verilog 2001 and VHDL.

- If we decide to add the new macros Cadence is proposing they should be
available in all three languages

[Shabtay] - Agree. But I'd like to emphasize that Cadence is not
insisting necessarily on its proposed macros. The macros represent a
manifestation of all principles on this page. If function-based API
would meet all principles, it could be considered instead of the macro
based approach.

- Avoid a hybrid approach

[Shabtay] - Disagree. There is merit in not holding technology progress
when new capabilities are being introduced to a newer language. DPI does
open an opportunity for using simple functional call for SystemVerilog.
We should aim for avoiding a hybrid if other principles would not be
sacrificed. We could end up choosing a macro based approach as the
common denominator for all languages and DPI only for SystemVerilog, or
may find a function-based API that meets all principles. The call is
still out.

- Use Infrastructure Linker for Verilog and VHDL and optionally for
SystemVerilog.

[Shabtay] - Agree. But this needs to be further elaborated to avoid
ambiguity. I would add that the Infrastructure Linker should not conduct
source to source translation with complete code regeneration. Having the
IL use standard design analysis technology (such as VPI) and create some
extra library that will be added to the source is acceptable. 
 
- SCE-MI 2.0 function interface extensions to `old' Verilog and VHDL
should be expressible entirely within the legal syntax of those
languages

[Shabtay] - Agree if you mean is that "SCE-MI 2.0 function interface
extensions to SystemVerilog, Verilog 2001, and VHDL should be
expressible entirely within the legal syntax of EACH language".


>-----Original Message-----
>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Per
Bojsen
>Sent: Thursday, September 15, 2005 6:30 AM
>To: itc@eda.org
>Subject: SCE-MI 2.0 HDL Support (Re: Meeting minutes 050825)
>
>Hi,
>
>I've previously commented on Zaiq's opinions on the support for `old'
>Verilog in SCE-MI 2.0.  Shabtay (Cadence) and Russ (Broadcom) also
>commented on VHDL.
>
>Zaiq supports the principle that the choice of HDL should be
>transparent to the software side, i.e., the user should be able
>to use `old' Verilog, SystemVerilog, and VHDL interchangeably
>without having to rewrite the software side.  This implies that
>all three languages should have support for a function based
>interface based on SystemVerilog DPI.  It also means, that if
>we decide to add the new macros Cadence is proposing they should
>be available in all three languages.  A hybrid approach where
>VHDL only has macro support and SystemVerilog and `old' Verilog
>only has the function based interface would lead to a HDL
>dependent use model that would probably lead to IP vendors avoiding
>support for SCE-MI at worst or dropping support for VHDL at best.
>
>When considering how HDLs are handled in SCE-MI it is important to
>observe that the HDL portion of a SCE-MI application is not seen
>directly by a simulator or synthesis tool.  It is processed by the
>infrastructure linker first.  With the introduction of support of
>SystemVerilog DPI we are trying to create a situation where the
>it is possible to run the SCE-MI application in a SystemVerilog
>simulator without requiring the infrastructure linker as long as
>the SCE-MI application is written within the strict DPI subset of
>SCE-MI 2.0.  However, for `old' Verilog, VHDL, and SystemVerilog
>where more than the DPI subset of SCE-MI 2.0 is used, the
>infrastructure linker is required.
>
>Having said that, Zaiq believes there are pragmatic reasons that
>the SCE-MI 2.0 function interface extensions to `old' Verilog
>and VHDL should be expressable entirely within the legal syntax
>of those languages.  Theoretically we are not restricted to legal
>syntax since the infrastructure linker could parse any syntax
>extensions we care to define and still ensure the output is
>acceptable to whatever synthesis tools and/or compilers will run
>after the linking phase.  But if we restrict ourselves to legal
>syntax implementors have more choice in terms of available
>third-party language parsers, etc.  So this is purely a pragmatic
>consideration.  John Stickley has pointed out several times that
>his proposals follow the legal syntax of each language so this
>issue should be easy to settle.  Shabtay's objection to supporting
>the function based interface in VHDL seemed to be rooted in this
>issue as well.  So hopefully we can come to an agreement quickly.
>
>Thanks,
>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
>
>