Subject: Re: Data Channels
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Jul 26 2002 - 15:42:29 PDT
Stuart Swan wrote:
> Kevin-
>
> Some answers & comments below.
>
> -Stuart
>
> Kevin wrote:
>
> > Thanks for the info. I was actually wondering if VCC used an CSP like constructs- maybe
> > inherited from SDL?
>
> VCC is similar to SystemC 2.0 in that its underlying simulation engine supports
> a general discrete event similation engine with a discrete time (as do Verilog & VHDL).
> Also VCC is similar to SystemC 2.0 in that specific models of computation such
> as CSP, Kahn Process Networks, Static Dataflow, etc., can be relatively easily layered
> on top of the underlying discrete event model.
>
> BTW- from your description of what you're doing, it sounds to me like you're using
> a Kahn Process Network MOC (strictly speaking), rather than CSP.
I'll take your word for it :-)
> > I'd like to get some kind of channel construct into SystemVerilog with a view to bridging
> > between SystemC, SystemVerilog and other environments, it's a clean way to communicate
> > between threads (a lot cleaner than what we have to do for mixed signal), and greatly
> > simplifies using parallel processing for simulation (directly shared data always gives you race
> > conditions that are hell to debug).
>
> I agree completely with the above...
>
> > Got any suggestions on syntax/semantics? - I just put up what I thought was the simplest
> > implementation that would be usable.
> > Kev.
>
> If you squint, the "interfaces" construct in SystemVerilog 3.0 is sort of similar to
> SystemC channels. But you have to do a lot of work to understand the two & what their
> differences are in order to draw any real conclusions.
>
> To start with, the terms are different and confusing. As a rough approximation, the
> following terms identify similar constructs in SystemC 2.0 & SystemVerilog 3.0:
>
> SystemC 2.0 SystemVerilog
> ----------- -------------
> channel interface
> interface modport
> event verilog events
I'd probably agree with that, as someone else pointed out there isn't really a whole lot
of difference between an interface and a module in SystemVerilog - from my perspective
an interface is just an object-oriented version of a module, and you can also look at a
module definition as being like a C++ class definition (Cynapps implemented stuff that way).
So a SystemC channel is more like a subclass of module than the pipe-like channel
I was thinking of.
> Interestingly, in SystemC 2.0 the channel construct is literally a "typedef"
> for the module construct, which means that the two are equivalent and interchangeable.
> This dramatically simplifies the language and introduces a great deal of modeling power.
>
> For example, a channel in SystemC can have embedded modules, and can implement interface
> methods that convert abstract transactions modeled as function calls
> into low-level signal interactions with such
> embedded modules. I don't believe this is possible with SystemVerilog "interfaces".
>
> I'm still trying to figure out some of the specific characteristics of SystemVerilog
> "interfaces" and such. As can be expected, when you dive into the details they are
> quite different from SystemC channels. It's not even clear to me at the moment
> whether each instantiation of an interface in SystemVerilog truely represents
> a unique instance with instance-specific data, as occurs with module instantiation.
>
> I've written up some questions/issues related to SystemVerilog interfaces and provided
> them to the committee. There has been some discussion on some of these points and I still
> need to go thru the discussion and respond...
>
> At this point, I don't think it makes sense to introduce a new, separate "channel"
> construct into SystemVerilog. I think it is probably better to clean up the existing
> "interface" -related constructs.
Cleanup is the BC committee's job, the EC committee is for enhancements (no?).
The kind of design flow I'm looking to support is one where IP designers use
interfaces to describe how to talk to their block, and the system-level designers
can plug them together using channels between the interfaces for the major
(point-to-point) data transfers to gather information on throughput requirements
and latency limits etc. before commiting to particular bus structures - a synthesis
tool could map abstract channels into shared physical channels (probably described
by a hiearchy of interfaces) once the requirements are known.
Are there any face-to-face meetings in the schedule where we can discuss
this round a white-board?
Kev.
-- National Semiconductor 2900 Semiconductor Drive, Mail Stop A1-520, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Fri Jul 26 2002 - 15:44:37 PDT