Subject: Re: Data Channels
From: Steven Sharp (sharp@cadence.com)
Date: Fri Jul 26 2002 - 16:19:51 PDT
>That would depend on what you mean by modern. HDLs are essentially
>light-weight multi-threaded programming languages, and the only non-HDL
>language of that type I know is Occam, and it has data channels like those
>I described built into the language. The "channel" is a basic building block
>for
>CSP style programming, and CSP is probably the best hardware/software
>design style for large systems (we discussed it at a TCC meeting at HDLCon
>earlier this year).
I don't know much about Occam, but my understanding is that it was designed
specifically for programming arrays of Transputers. Transputers have
communication channels hardwired into the CPU. With a communication channel
accessible as a basic operation on the processor, it isn't surprising that
it is accessible as a basic operation in the language.
In SystemVerilog, a channel would be an abstract data type implemented in
software. There is no reason that it should be treated differently from
any of the other abstract data types that someone might want to use. The
language should provide the building blocks to build arbitrary abstract
data types. Then you can build your channels, and someone else who wants
something different can build that instead.
>The internal NSC implementation in C++/Verilog we already have is unwieldy
>and inefficient, I'd like to have a better solution.
Can you explain why it is unwieldy and inefficient? And why building it
into the language would make it somehow more wieldy and efficient? The
same information has to be provided at the interface either way, and the
same operations have to be performed in software either way. Why would
having it built in make a difference? Is this due to some awkwardness and
inefficiency in the C++/Verilog interface, which the C interface group might
be able to tackle?
I don't see where an abstract data type written in SystemVerilog and
using tasks/functions/methods would be any more unwieldy than your proposed
solution that overloads some other syntax.
Where you are suggesting:
> > always @(clock) chp[1] <= 1'b00011000; // write (to bar)
you could use:
always @(clock) channel_write(chp[1], 8'b0001100);
or in PLI:
always @(clock) $channel_write(chp[1], 8'b0001100);
Where you are suggesting:
> > always @(chp[0]) // data ready ?
> > data = chp[0];
you could use a blocking read task:
always
channel_read(chp[0], data);
or if you don't like a blocking interface, use a couple of separate routines:
always wait(channel_ready(chp[0]))
data = channel_read(chp[0]);
It doesn't look any more unwieldy to me, and it won't get mistaken for a
normal read or write of a simple variable. If you want some way of sending
multiple packets in a single call, you need some way of passing arbitrary
sized parameters to a task (e.g. pointers or variable-sized arrays).
I'm sure that there are plenty of variations on how to do this. The
nice thing is that the user can implement whatever variation is desired,
instead of being stuck with a predefined built-in version. It keeps the
language definition simpler, while giving the user full flexibility.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2b28 : Fri Jul 26 2002 - 16:21:59 PDT