Subject: Channel Proposal
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Aug 08 2002 - 09:45:57 PDT
Since we've been discussing this for a while I thought I'd have a go at an actual proposal.
Proposed text for LRM:
Section X
Channels
X.1 Introduction (Informative)
Channels provide a mechanism for modeling abstract data flow around a design. A channel
behaves like a first-in first-out (FIFO) stack of unlimited depth, any block can read and
write to it the same way as it would a register except that each write is independent and
queues a packet of data for reading later. Channels are declared with a "protocol" type
which dictates the size of packet used in the FIFO, but it can also be viewed as just a
stream of 1s and 0s (and possibly Xs and Zs) since no hardware implementation is implied.
Channels also provide a simple asynchronous bridge into other programming environments.
X.2 Channel Syntax
channel_declaration ::== channel protocol list_of_variable_identifiers
protocol ::== data_type
X.3 Channel Operations
A channel supports both blocking and non-blocking writes. The blocking write blocks when
the FIFO is not empty, but does not preempt non-blocking writes, non-blocking writes are
queued on the FIF0 immediately. This example code will write the sequence of values 1,2,3,4
to the channel and wait until another block reads them, the block reading the channel will
receive the sequence 1,2,3,4.
channel int chan1;
always @(clock1) begin : block_w
chan1 <= 1;
chan1 <= 2;
chan1 <= 3;
chan1 = 4; // wait for channel to empty
end
int data_in[0:3];
always @(clock2 and data) begin : block_r
data_in = chan1; // read four ints
end
Reading a channel blocks until there is sufficient data in the FIFO to satisfy the request. Using
the channel identifier in an event expression allows testing that at least one packet of data is
available. A channel event (data becoming available) is only true for one expression at a time
until the data is consumed.
A write of less data than the packet size will be padded with zeros for 2-value types and padded
with Xs for 4-value types, the valid data is sent first. A read of less than the packet size will be
filled from the first arriving data and the rest of the packet will be discarded. A write of more
data than the packet size is broken up into multiple packets, no data is discarded. When the type
being written can be automatically cast to the protocol type the cast will be applied, for instance
a byte written to a int channel will be extended to int size (4 bytes) and that value will be written
to the channel rather than the byte value followed by zero fill.
The type of the data being written to the channel should match the protocol at the bit level, if the
protocol is a bit based type only bit based types (2-value) can be used, if the protocol is logic based
(4-value) then either bit or logic based types can be written. Similarly, only logic based types can be
read from the channel if it has a logic based protocol, and both can be read from a channel with
a bit based protocol. If the channel protocol is a complex type that uses both logic and bit based
types then the data written and read must be of the protocol type.
A non-blocking assignment to a channel with a delay is executed after the delay as would the
equivalent register assignment.
X.4 Posix Interoperability
File descriptors used in Posix compliant operating systems are equivalent to one end of a byte
channel, the following system task will bind a channel to file descriptors rather than using the
simulator's internal FIFO mechanism.
bind_channel ::== $bind_channel(channel_identifier,read_file_descriptor,write_file_descriptor)
Posix systems use the file descriptors 0, 1 and 2 are used for standard input, output and reporting
errors respectively, the input and output can be bound to a channel with the following code.
channel byte stdio;
initial begin
$bind_channel(stdio,0,1);
stdio <= "Hello World\n";
end
Valid Posix file descriptors are positive integers, so a negative integer indicates that the
read or write end of the channel is disconnected.
channel byte stderr;
initial begin
$bind_channel(stderr,-1,2); // no read on error channel
end
It is an error to read from or write to a disconnected channel. Writing to or reading from a channel
associated with a closed file descriptor will block indefinitely (unless the write is non-blocking).
There is no buffering of data by the simulator on writes unless they are non-blocking and the descriptor
is not ready in which case the buffered data will be flushed as soon as the descriptor is ready. Data
being read from a file descriptor is buffered up to one packet so that the event mechanism works the
same as for regular SystemVerilog channels.
The channel binding can be changed at any time.
Only channels with protocols which are bit based types and multiples of byte in size can be bound
to file descriptors.
-----------
Notes:
For those unfamiliar with Unix, the standard way to set up communication between two processes
is to have a parent process create pipes then fork - it becomes two processes sharing the pipes -
and then the applications are execed and inherit the pipes. If one process is the simulator you can
pass it the pipe file descriptor numbers for use with $bind_channel with plus-args. If you want to
use sockets (machine to machine) a parent process can open the connections before execing the
simulator and pass the socket file descriptor with a plus-arg.
Kev.
-- National Semiconductor 2900 Semiconductor Drive, Mail Stop A1-520, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Thu Aug 08 2002 - 09:48:43 PDT