RE: SCE-MI 2.0 Software Side Independent of HDL Language

I agree with all of Per's points here.

I would farther so as to make the binary compatibility
requirement even tighter:

- binary compatibility, of user proxy models,
    for given platform (i.e. gcc/OS/platform combo),
    portable across:
  - HDL languages on the HDL side
  - Vendor implementations

A lot of work has been done to insure this is the
case in SystemVerilog DPI - even to the point
of one significant re-design of the API
(deprecated "DPI" became "DPI-C").

As for naming, again, it is all how you view 
the initials "sv". It is far simpler to observe
binary compatibilility and make the initials
"re-interpretable", i.e.:

sv means "SystemVerilog"

    or

sv means "SCE-MI Verilog"

    or

sv means "SCE-MI VHDL"

than to come of with different sets of prefixes for
the same thing purely for the sake of asthetics.

So many things are made simpler by taking this viewpoint.

-- johnS


-----Original Message-----
From: owner-itc@eda.org on behalf of Per Bojsen
Sent: Thu 7/21/2005 10:32 AM
To: itc@eda.org
Subject: SCE-MI 2.0 Software Side Independent of HDL Language
 
[Adding to the email.  See 4th paragraph and on.]

Hi,

we touched on this in last weeks meeting briefly, but I'd like to
make sure this becomes a requirement for the 2.0 standard: The software
side of a SCE-MI 2.0 application *must* be independent of the HDL
language used to implement the hardware side.  This is currently true for
SCE-MI 1.1 and it is important to carry this forward.  John Stickley added
that we should strive towards the stronger goal of binary
compatibility as well, i.e., the user should not have to recompile his
software side when he switches HDL language assuming the hardware side
expressed in the two HDL languages are equivalent.

I'd like to further strengthen this to say that SCE-MI 2.0 should
be defined such that if the user constrains himself to a certain
subset of SCE-MI 2.0 on the software side it will be possible to
run this software side *unchanged* on any compliant SystemVerilog
simulator.  This would allow people to write and test SCE-MI 2.0
applications on any SystemVerilog simulator as long as they
restrict them self to what I called `a certain subset'.  This subset is,
of course, the DPI subset of SCE-MI 2.0.

On this latter thing, source code compatibility is a must.  Binary
compatibility is nice, but it is not clear how easy this is to
support.

This requirement to have source code compatibility with SystemVerilog
is what leads to the adoption of the sv*() API.  Matt suggested to
use a different naming convention for these functions, but if we do
this, the software side of a SCE-MI 2.0 application cannot run on a
regular SystemVerilog simulator without either replacing the SCE-MI
versions of these functions with the sv*() ones.  This can
be done using one of the following methods:

  1) Direct textual substitution;
  2) Macro substitution;
  3) Linking to a special wrapper library.

(1) implies a change to the source code, which violates the
requirement to run the source code unchanged; (2) also implies a
change to the source code as the macros will have to be added;
(3) has the problem that such a library would not be supplied
by the SystemVerilog simulator, so the user would have to come
up with it on his own.

If I understood Matt's proposal correctly, it was merely to
rename to sv*() functions to, say, SceMi*(), and not to add or
change their functionality.  Given that, I do not understand
what is gained by changing those function names.  I'd like to
understand this better.  On the other hand, we lose the ability
to run the software side unchanged on any SystemVerilog
simulator.

Joseph from ST said in his email last week something to the
effect that ST does not want the sv*() functions to be required
for VHDL.  I'd like to understand what the reason for this
objection is.

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




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