Subject: Re: Data Channels
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Tue Jul 30 2002 - 10:24:33 PDT
Michael McNamara wrote:
> Kevin Cameron x3251 writes:
> > > From owner-sv-ec@server.eda.org Mon Jul 29 14:16:51 2002
> > >
> > > Kevin-
> > >
> > > Some comments below... (My comments in blue).
> > >
> > > BTW - I propose that everyone use plain text for email
> > > discussions -- makes it much more straightforward to read & post
> > > replies. Strange formatting below is due to original HTML
> > > formatting of email.
> > >
> > > Stuart
> >
> > >> So a SystemC channel is more like a subclass of module than the
> > >> pipe-like channel I was thinking of.
> > >
> > > Yes, but the intent (similar to SystemVerilog "interfaces") is
> > > that users then model the specific communications mechanisms they
> > > desire using the basic channel construct.
> >
> > But it still doesn't look much like what you get from Unix pipe &
> > socket calls.
>
> My comments are in black ascii on a white background (at least as I
> type them; (YCMV) your colors may vary :-)
>
> I've kind of been waiting for this to be stated by some one.
>
> What the SV-CC guys are working on is essentially exposing the C
> library natively to Verilog. There are definiatly details to be
> hashed out (how do you deal with a pointer returned from a C library
> call, other than treat it as a handle?).
>
> However within the framework being described, and using pass by
> reference, it seems to me that you can call a lot of accept(2),
> bind(2), connect(2), getprotoent(3), getsockname(2), getsockopt(2),
> ioctl(2), listen(2), read(2), recv(2), select(2), send(2),
> shutdown(2), socketpair(2), write(2) directly from SystemVerilog.
If we are going to bring in the "Direct C" stuff then most of those
calls shouldn't be to difficult to use if SV arrays follow C packing and
alignment rules for equivalent data types - or you do some smart type
casting. The problem from an implementation perspective is that a direct
call to some of them (e.g. read, write) can block indefinitely and hang
your simulation if it isn't really multi-threaded, so you probably want
to push the handling for those calls down into the simulation kernel where
the handling of SIGIO interrupts and selects can be invisible to the user.
C calls use descriptors which are just integers, you could use the C calls
fairly directly to get those and then bind them to the channel type I
previously suggested, e.g.:
channel byte pipe2c; // SV
int fd[2];
initial begin
pipe(fd); // C system call
$bind(pipe2c,-1,fd[1]); // associate pipe2c with unix pipe write end
// and disable read
$setup_other_end(fd[0]); // PLI to user Unix code
pipe2c <= 16'h1234; // guaranteed non-blocking write to pipe in SV
...
pipe2c = 16'h5678; // suspends only this SV process if write blocks
// in Unix
...
Just a thought,
Kev.
This archive was generated by hypermail 2b28 : Tue Jul 30 2002 - 10:29:48 PDT