Subject: RE: Data Channels
From: Stuart Swan (stuart@cadence.com)
Date: Mon Jul 29 2002 - 16:53:04 PDT
Kevin-
Still more comments on channels/fifos...
Stuart
> >
> > 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.
Doesn't look like UNIX pipes in terms of syntax or semantics?
I don't think that we'll achieve a similar syntax to UNIX pipes
within SystemVerilog, nor would we want to. I don't see why one
couldn't have some specialized channels (aka SystemVerilog "interfaces")
that behave just like UNIX pipes...
>
> I was considering this an enhancement since it's more of an
> addition than modification
> of some existing construct.
Well, I think for SystemVerilog "interfaces" to be truely useful,
some number of standardized "interfaces" need to be created, such
as FIFOs, semaphores, etc. That belongs to the EC doesn't it?
>
> Easy enough to lift the restriction about sub modules.
Perhaps. I haven't heard the same from other people on the committee,
and there are a number of more arcane issues which are yet to be
discussed/resolved.
>
>
> I'm looking for a simple mechanism that creates an
> identifiable boundary where data crosses (asynchronously) from
> one processing domain to another that can be used for
> bridging to C++ (Rosetta, Matlab, VHDL etc.) as well within
> SystemVerilog. The mechanism I suggested should map easily
> into OS supported mechanisms like pipes and sockets and
> therefore make that job easier. The ability to implement
> FIFOs other ways in pure SystemVerilog isn't relevent to
> that goal.
>
>
Maybe it's not relevant to your specific goal, but its very useful
in a lot of scenarios.
But let's take your specific co-simulation
scenario above: A C++ testbench is hooked to a SystemVerilog simulator
and they communicate via FIFOs. In the end, the FIFOs have to be implemented
somewhere. Perhaps they are implemented somehow in SystemVerilog, perhaps
in your C++ testbench, perhaps within some interface code between the two.
Now in this co-simulation scenario I still could imagine the desirability of being able to
configure FIFOs on the co-simulation boundary in some of the following ways:
- Specify that some FIFOs should have specific maximum sizes.
- Specify that some FIFOs can grow without bounds.
- Log the data flowing thru certain FIFOs into an output file
- Maintain statistics about data flowing thru certain FIFOs.
- Have some FIFOs model communication latency, perhaps in a statistical manner.
- Have some FIFOs work exactly like UNIX pipes (with all the strange signal semantics, blocking factors, etc.)
- etc.
The question then becomes whether you want to hardcode all such possible features
that you can think of into such a FIFO (potentially making
most instances of the FIFO unnecessarily inefficient), or whether you want to provide
some way to swap a specifialized FIFO implementation that conforms to a standard FIFO
interface that does exactly what you need when you need it. I prefer the latter approach.
And that is exactly the motivation behind SystemC channels/interfaces (and
I think SystemVerilog "interfaces"/"modports").
This archive was generated by hypermail 2b28 : Mon Jul 29 2002 - 16:54:56 PDT