Subject: Re: Data Channels
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Jul 25 2002 - 10:22:17 PDT
Tom Fitzpatrick wrote:
>
> 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
Channels and interfaces are not the same thing. You can implement a FIFO
in Verilog if you want, but it isn't going to be very abstract, and since
we havn't added dynamic memory allocation it's difficult to manage the
"unlimited depth" aspect.
More below...
> > 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.
They are not linked other than by name - the "named" part in "named pipe".
Which element of the array is used in which direction is up to the user,
you just need two to make the link bidirectional. If you wanted to add
Out-Of-Band data (like Unix sockets) you could add more elements to the
array.
> 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
Yes, but it doesn't have the FIFO behavior. I had envisioned using channels
between interfaces and using that as a base for bus/communication synthesis.
> 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.
True, but tools then have to decipher the methods to work out what is going
on.
> 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.
Data channels are a good way to describe point-to-point data transfer in
a system level design prior to making decisions about which bus structures
to use, and also for bridging between languages. Channels are also
intrinsically asynchronous which allows you to decouple simulation on
channel boundaries for parallel processing (see CSP).
I think channels are a necessary complement to interfaces for system level
design.
Kev.
> > >
> > >
> > >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 - 10:31:34 PDT