Subject: Re: DirectC: external modules vs. external/exported tasks
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Nov 06 2002 - 18:50:41 PST
> > From: "Andrzej Litwiniuk" <Andrzej.Litwiniuk@synopsys.com>
> > Subject: DirectC: external modules vs. external/exported tasks
> >
> >
> > IMO both sides of the external modules should be seen and considered
> > separately. The proposed C++ based realization of external modules,
> > i.e. cmodules, is just one of possible forms of a 'plug-in' for an external
> > module. The particular syntax, which combines Verilog-like constructs
> > with C++ code is not critical here. Possibly it can be replaced by plain
> > C++ code and some library.
> > What is the essence of this mechanism is the paradigm that synchronization
> > is based on module port events and that Verilog and non-Verilog components
> > communicate, synchronize and exchange data via ports.
> > Personally I feel that this is elegant a mechanism and fully in a spirit
> > of HDL. (I mean the Verilog side of external module interface. Wheteher
> > cmodule is palatable, is another story.)
> >
> > Question: is alternative mechanism needed?
> >
> I'd say that between SV (with the enhancements tabled in the EC committee) and
> SystemC, "cmodule" is redundant functionality. If you can cross-call the callee
> probably shouldn't worry about who the caller is.
>
> Kev.
You are right that within the space of C++ based HDL-s "cmodule" is redundant
functionality, definitely inferior to SystemC.
But we are not talking about HDL in C/C++.
We are talking about interface between SV and C/C++.
IMO external module is a powerful and convenient mechanism for connecting
"something" to SV. I don't care how it's implemented in C++.
Perhaps SystemC could be plugged-in as an implementation of external
modules?
I'm focusing on the SV side of the interface. And from that perspective
communication via ports seems natural and attractive.
Andrzej
This archive was generated by hypermail 2b28 : Wed Nov 06 2002 - 18:51:10 PST