Subject: Data Channels
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Jul 24 2002 - 10:58:44 PDT
[Just for discussion]
National Semiconductor's C++/Verilog simulation environment for
Information Appliances includes the concept of named data channels
through which C++ tests connect to Verilog test devices. We would
like to see support for a mechanism of this kind in SystemVerilog
so that we can move to using more standard tools.
The programming style we use can be considered as CSP (Communicating
Sequential Processes - http://www.afm.sbu.ac.uk/csp/) which has been
previously implemented in languages like Occam. It is also a good
approach for "communication driven" design.
Pipes and sockets used in Unix are similar to data channels
and it is desirable that the System Verilog data channels
behave similarly. Channels in Occam are also associated with a
"protocol" which indicates the packet size, for Unix pipes the
protocol is simply "char" (8 bits), and for SystemVerilog we
would probably want "bit" (1 bit) as the minimum. The channel
itself is basically a FIFO of unlimited depth.
Channels are usually awkward to set up because the read and write
ends are in different contexts. Since most data in Verilog is
globally visible that problem is already solved, so the syntax
and semantics can be quite simple e.g.:
module foo;
channel byte chp[1:0]; // declare a channel pair carrying
// byte size packets
byte data;
always @(clock) chp[1] <= 1'b00011000; // write (to bar)
always @(chp[0]) // data ready ?
data = chp[0];
...
module bar;
byte data;
always begin
data = foo.chp[1] // get data from foo - blocks if
// not ready
foo.chp[0] <= some_func(data); // send reply
end
...
The example just overloads the @(<event>) syntax to test if
a channel has data - Unix/C uses the "select" function. Additional
semantics are that you can't write or read below the packet size
(in this case 8 bits), but you can write or read more and it will
all be sent/received - e.g. in the module foo above the we could
say:
always @(clock) chp[1] <= 32h'12345678;
- and four bytes will be sent. The order of the bytes may be host
dependent in that case but should not be for this:
packed struct {int i;} pckd;
pckd.i = 32h'12345678;
chp[1] <= pckd.i; // 8'h12 goes first
A "blocking assign" to a channel would block until the channel is
empty. Reading from a channel also blocks when the receiving data
type size exceeds the available data i.e. the process will hang if
it tries to read an int off a byte channel which doesn't have at
least four bytes in it.
Comments appreciated,
Kev.
-- National Semiconductor 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Wed Jul 24 2002 - 11:01:10 PDT