Subject: $sv-ec Re: SV APIs (Assertion)
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Oct 02 2002 - 15:24:49 PDT
> From owner-sv-cc@server.eda.org Wed Oct 2 09:06:08 2002
> From: "Michael McNamara" <mac@verisity.com>
> To: "Kevin Cameron x3251" <Kevin.Cameron@nsc.com>
> Subject: Re: SV APIs (Assertion)
>
>
> > 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?
The DirectC donation covers calling the X library (as is) so there's
no immediate need to do that one, similarly Perl is available in
library form. However I see no reason why you would not want to be
able to write a small RTOS in SV, doing so would allow you to experiment
with hardware/software tradeoff in power/speed critical applications.
SV should be significantly better at handling highly parallel processing
than C once we add semaphores, and with references for creating complex
structures I'm not sure why I would need to program in C/C++ as part
of my Silicon design flow.
> 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.
If Verilog worked that well we wouldn't be doing this (adding structs,
unions, classes, 2-state variables, dynamic processes...). I'm no great
fan of SystemC so I'm definitely not trying to build it from the
other side.
> 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
I think you're asking for the same thing I want, but I think it's way
too late to use the API as the delineation of synthesizable HDL and the
test/system environment.
C/C++ software is often a significant part of a finished product, but they
are realy bad languages for describing large programs. The benefit of
providing most of the same functionality in SV in a "safer" form is that
it is easier to co-verify the hardware and software in either simulation
or using formal methods when the design is completely contained.
Regards,
Kev.
PS: From what I remember of X11 programming, the mechanisms for
communicating button clicks to call-backs are essentially event-driven
(through a variation of "select"), so re-implementing it in an event-driven
multi-threaded language like SV wouldn't be a bad idea :-)
This archive was generated by hypermail 2b28 : Wed Oct 02 2002 - 15:26:40 PDT