Subject: Re: SV APIs (Assertion)
From: Michael McNamara (mac@verisity.com)
Date: Wed Oct 02 2002 - 09:03:45 PDT
> Considering the functional overlap between SV, C & C++ there seems
> less need for programming extra functionality in C, hence less need
> for an API. If all the required functionality of C is supported in
> SV, then the issue is what APIs are need to make the compiled SV
> code portable between simulators (which takes me back to the topic
> of ELF libraries and routine naming conventions).
>
> It might be limiting in the short term, but I think it would make
> for cleaner more efficient applications in the long term.
>
> Kev.
Yes, but are we going to write an X library in SV? How about a perl
interpreter? Delay calculator? Operating system?
Let's us not create SystemC from the other side! We have something
that works very very well: Verilog. Let our vision be that we add
things to System Verilog to make it an even better language for
describing HDL, testing it, and so on; but recognize that it is
critical that we also build a very clean interface between System
Verilog and the C language.
Let us build an interface that allows us to link System Verilog code
to C libraries as if System Verilog was itself 'c' (or FORTRAN, or
Pascal, or C++, which all can link to C libraries in a clean, well
defined manner). This will bring all the power of a unified design
environment, while keeping the sythesizable HDL clearly delineated
from environment modeling. This combination will give us the most
powerful design environment at the lowest cost: without requiring the
design team to reimplement things like X and motif and TCL and perl
all in System Verilog. Instead they would just need to make the same
call they would make if they were programming in C.
-mac
This archive was generated by hypermail 2b28 : Wed Oct 02 2002 - 09:06:46 PDT