Subject: RE: Data Channels
From: Stuart Swan (stuart@cadence.com)
Date: Mon Jul 29 2002 - 14:40:32 PDT
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.
// 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...)
This archive was generated by hypermail 2b28 : Mon Jul 29 2002 - 14:42:51 PDT