Subject: RE: Data Channels
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Jul 29 2002 - 15:24:08 PDT
> From owner-sv-ec@server.eda.org Mon Jul 29 14:16:51 2002
>
> Kevin-
>
> Some comments below... (My comments in blue).
>
> BTW - I propose that everyone use plain text for email discussions
> -- makes it much more straightforward to read & post replies.
> Strange formatting below is due to original HTML formatting of email.
>
> Stuart
>> So a SystemC channel is more like a subclass of module than the pipe-like channel
>> I was thinking of.
>
> Yes, but the intent (similar to SystemVerilog "interfaces") is that users then model the
> specific communications mechanisms they desire using the basic channel construct.
But it still doesn't look much like what you get from Unix pipe & socket calls.
>> Cleanup is the BC committee's job, the EC committee is for enhancements (no?).
>
> Yes, I guess so. But my impression is that its hard to separate the work that is intended for each
> of the subcommittees, and the subcommittees are still in a state of confusion
> about their actual goals. And it seems to be the same set of people in each of the subcommittees anyway.
I was considering this an enhancement since it's more of an addition than modification
of some existing construct.
>> 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.
>
> Both the SystemC channels and SystemVerilog interfaces were designed with this use-model in mind.
>
> (Though I'd argue that SystemVerilog "interfaces" have some flaws (e.g. inability to embed modules within an interface) that
> prevent them from fully reaching this goal.)
Easy enough to lift the restriction about sub modules.
> In fact, the design flow you seek above argues against hardcoding the kind of "monolithic/hardcoded" "channel" construct that you
> originally proposed for SystemVerilog. For example, one might want a version of a FIFO channel that simply works like a primitive
> FIFO, another version that gathers statistics to enable the designer to analyse his system level design, another version which enables
> communication delays thru the FIFO to be modeled, etc. Each of these should implement a common set of interfaces (SystemC
> terminology) or "modports" (SystemVerilog terminology), so that they can be easily and safely swapped during design analysis and
> refinement. Your monolithic FIFO channels wouldn't be able to do this.
I'm looking for a simple mechanism that creates an identifiable boundary where data crosses (asynchronously) from
one processing domain to another that can be used for bridging to C++ (Rosetta, Matlab, VHDL etc.) as well within
SystemVerilog. The mechanism I suggested should map easily into OS supported mechanisms like pipes and sockets and
therefore make that job easier. The ability to implement FIFOs other ways in pure SystemVerilog isn't relevent to
that goal.
> Are there any face-to-face meetings in the schedule where we can discuss
> this round a white-board?
>
> Don't know.
[Message #2]
> Kevin-
>
> A few more comments below...
>
> Stuart
>
>
>
>>> In SystemVerilog, a channel would be an abstract data type implemented in
>>> software. There is no reason that it should be treated differently from
>>> any of the other abstract data types that someone might want to use. The
>>> language should provide the building blocks to build arbitrary abstract
>>> data types. Then you can build your channels, and someone else who wants
>>> something different can build that instead.
>
>> It's not really a type, it's a primitive object like a buffer. You can build something
>> in SystemVerilog or C++ that looks similar, but you don't get the advantage of it
>> being a commonly understood abstraction.
>>
>> If it is handled by the simulation kernel directly then you can optimize the execution
>> e.g. doing the write/read rollover that the transputers did, or using some host-native
>> pipe mechanism or shared memory and you can make it MT safe for parallel
>> processing.
>>
>> I don't write my own "pipes" library when I'm programming for Unix, I don't see
>> why I should have to do it for SystemVerilog.
> The idea with "channels" in SystemC (and presumably with "interfaces" in SystemVerilog)
> is that a standard library of commonly used channels should be provided, and be supported
> by analysis & synthesis tools etc. For example in SystemC 2.0 the following channels are standardized
> and provided in the release : HW signals (including single driver & multiple drivers), FIFOs, mutexes,
> semaphores, & clock/timer. These all build upon the very generic "channel" construct, and yet they can
> be used as if they are built into the language.
Mutexes and semaphores would be buried in the channel construct if it is anything like a Unix pipe
rather than being built out of it - I think we're thinking of entirely different beasts.
> // text omitted
>
>> But you havn't supplied all the extra implementation code that my version
>> doesn't need (from a user perspective). Also the syntax I suggested is
>> deliberately polymorphic with respect to reg/wire data types so you can
>> swap from synchronous to asynchronous easily.
>
> By having related channels (systemc term) share common interfaces (systemc term)
> and by relying on C++ or Verilog implicit conversions, I believe you can achieve the easy
> channel-swapping that you seek. You don't have to dive right into defining some new construct
> with a specific syntax to achieve this -- the important part is to identify the commonality among
> the related channels and then make the commonality explicit via a shared common interface (perhaps
> only partly shared in some cases...)
Which existing construct in SystemVerilog has the asychronous behavior of a Unix pipe?
Kev.
This archive was generated by hypermail 2b28 : Mon Jul 29 2002 - 15:25:55 PDT