Subject: RE: Data Channels
From: David Smith (david.smith@synopsys.com)
Date: Tue Jul 30 2002 - 10:10:33 PDT
Just to comment on the discussion. There are two different activities going on in this discussion thread. The first is talking through the definition of support for data channels and possible ways to support them. The second is exposing some of the concerns/issues with SystemVerilog interfaces.
As to what happens in which committees. The comment was made that there is confusion on what the various committees are chartered to accomplish. I do not share the confusion on what the overall charter of each committee is. I do have concerns on specific items where it is not always clear whether something is a clean-up of an existing capability (SV-BC) or adding new functionality (SV-EC). Unfortunately this clarity does not always come until some discussion and/or work is performed.
So, back to the two different activities. There is an item in the list of extensions (item 1) on data channels. It is not one that anyone has signed up to develop a proposal and champion. So, I am not sure where all of this great discussion is heading.
On the issue of clarifying the capabilities and deficiencies of SystemVerilog interfaces, this is clearly an item for the SV-BC and I encourage one and all to work with Cliff on this.
This has been a spirited discussion. Good stuff. It would be good to see a similar interchange on the Process Control, Pointers, FSM, Alias, Inferred Reg types, and OO (for which people have taken responsibility).
One of the action items for the next meeting is to prioritize the list of 12 outstanding items and decide which ones we are going to actually work on.
Regards
David
David W. Smith
Synopsys Scientist
Synopsys, Inc.
9205 SW Gemini Drive
Beaverton, OR 97008
Voice: 503.520.2715
FAX: 503.643.3361
Email: david.smith@synopsys.com
http://www.synopsys.com
-----Original Message-----
From: Stuart Swan [mailto:stuart@cadence.com]
Sent: Monday, July 29, 2002 4:53 PM
To: Kevin Cameron x3251
Cc: sv-ec@eda.org
Subject: RE: Data Channels
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 : Tue Jul 30 2002 - 10:18:10 PDT