Subject: Re: Data Channels
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Jul 24 2002 - 17:46:42 PDT
> From simond@co-design.com Wed Jul 24 16:48:51 2002
>
> > channel byte chp[1:0]; // declare a channel pair carrying
>
> in verilog style this declares an array of byte channels - both of them,
> chp[1], and chp[0] are identical and there is no precedent in verilog of
> having a difference between different [], except ripple...
>
> thus it appears what you are suggesting as the solution is inconsistence
> with all prior verilog art.
>
> did I misunderstand or were you suggesting that?
Not sure what you mean by that, it's not much different to saying
"reg [7:0] chp[1:0]". Except that the reg is a fifo, so writes queue
up data for future reads.
> probably better to stick to requirements, and leave syntax of solution
> until requirement is agreed.
The requirement is just for a (named) bi-directional pipe, the syntax
I offered was only a suggestion to demonstrate the usage - I was
assuming the bridging to C/C++ would be tackled later in the CC
committee.
> have you studied systemC - is this what they have?
I downloaded a copy and had a quick look for similar things. There
was a "channel" class, but it didn't appear to do much.
Kev.
> Simon
>
> At 10:58 AM 7/24/2002, Kevin Cameron x3251 wrote:
>
> >[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 - 17:48:27 PDT