Subject: Re: Comments on DirectC
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Sep 26 2002 - 13:09:21 PDT
> From owner-sv-cc@server.eda.org Thu Sep 26 11:12:42 2002
>
> Alain,
>
> my reply follows each of your questions below.
>
> alain@tensilica.com said:
> > 1) is DirectC a language or an API (or both)? I didn't quite understand
> > the mechanism by which the preprocessor extracts C code from a Verilog
> > file.
>
> As donated, it is an API and a C preprocessor. The C preprocessor
> takes some Verilog'ish text (always, initial, @(expr)) and substitutes some
> appropriate C text.
> "always" & "initial" blocks become function definitions,
> "@(expr)" statements become function calls
>
> > 2) I liked some concepts such as the idea that Verilog modules could be
> > replaced by C modules transparently. This looks a lot like the FLI in
> > VHDL and it's a good thing. Is this extended to functions and tasks?
> > Ideally, the caller should not have to know whether it is calling
> > Verilog or DirectC: the function name should not change, for instance
> > (and adding "$" in front of a name is a change).
>
> It covers functions and modules, and yes, no renaming is necessary. The
> only thing that changes to replace a Verilog definition with a C definition
> is to change the definition, and similarly to change a C definition with
> a Verilog definition only the definition itself changes.
> This was one of the "hard" requirements for directC, that the usage of
> a function/module not change regardless of whether it is implemented
> as a Verilog function/module or a directC function/module.
>
> NOTE: "hard" requirement => has to be addressed, as opposed to a "soft"
> requirement.
>
> > 3) Regarding calling Verilog tasks from DirectC, is there any technical
> > reason why it can't be done (syntax, scheduling...)? Otherwise, I assume
> > we could add it at some point, since there is so much demand for it. And
> > it fits the idea above that C and Verilog modules and tasks could be
> > swapped transparently.
>
> Technically, the issues are very similar:
> in both cases you need a thread running the C code. This thread is suspended
> when waiting for simulation time or simulation events.
> - With DirectC you suspend on the functions that wait for simulation time
> and that wait for signals to change, and resume when the event occurs.
> - To invoke a Verilog task, you suspend on its invocation, resume when the
> task completes.
What kind of thread are you talking about? - a LWP thread (e.g. Posix thread)
or the "virtual" threads Verilog simulators normally use. If the C code
runs as a seperate LWP in order to maintain call stacks etc. then there is
a major implementation overhead, if you don't run it with a seperate call
stack it then there are major limitations on what the code can do.
Kev.
> > 4) I agree with the comment that DirectC should not reinvent the whole
> > PLI, especially the callback mechanisms.
>
> Thank you,
>
> Joao
> ==============================================================================
> Joao Geada, PhD Sr. Staff R&D Engineer Verif Tech Group
> Synopsys, Inc TEL: (508) 263-8083
> 154 Crane Meadow Road, Suite 300, FAX: (508) 263-8069
> Marlboro, MA 01752, USA
> ==============================================================================
This archive was generated by hypermail 2b28 : Thu Sep 26 2002 - 13:09:56 PDT