Subject: Re: Data Channels
From: Dave Kelf (davek@co-design.com)
Date: Thu Jul 25 2002 - 05:55:14 PDT
Hi Kevin
I think this is one of the primary functions of interfaces and we have
several customers using them just for this purpose
Dave
At 10:58 AM 7/24/2002 -0700, 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
______________________________
Dave Kelf
VP Marketing
Co-Design Automation, Inc.
Tel: 1 877 6 CODESIGN ext 404
Mobile: 1 617 571 9883
Fax: 1 781 662 2281
Email: davek@co-design.com
Web: www.co-design.com
www.superlog.org
Latest News:
http://www.co-design.com/news/index.htm
"Faster, Smarter Verilog"
______________________________
This archive was generated by hypermail 2b28 : Thu Jul 25 2002 - 05:58:03 PDT