Subject: RE: Data Channels
From: Tom Fitzpatrick (fitz@co-design.com)
Date: Thu Jul 25 2002 - 06:41:24 PDT
Hi Kevin,
I just wanted to expand on Dave's comment a bit. My comments are embedded.
-Tom
> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]On
> Behalf Of Dave Kelf
> Sent: Thursday, July 25, 2002 8:55 AM
> To: Kevin Cameron x3251
> Cc: sv-ec
> Subject: Re: Data Channels
>
>
> 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
As Simon mentioned, this syntactically is an array of byte-sized channels,
but there is no clear indication (or requirement) of how the elements of
this array are linked, if at all.
You could do something similar to this with an interface:
interface channel #(parameter type t = bit);
t data; // data is of bit type by default
...
endinterface
channel #(byte) chp[1:0]; // array of two byte-sized interfaces
> > byte data;
> >
> > always @(clock) chp[1] <= 1'b00011000; // write (to bar)
always @(clock) chip[1].data <= 1'b00011000;
> >
> > 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.
All of this functionality could be achieved with appropriate "write" and
"read" methods in the channel interface, without having to overload any
existing syntax.
It would, of course, be up to the SV-CC to come up with an appropriate way
of having C/C++ interact with the SystemVerilog interface to achieve the
specific functionality you want, but on the SystemVerilog side of things, I
believe that there is already enough there to do what you want.
> >
> >
> >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 - 06:43:38 PDT