Subject: RE: Data Channels
From: Stuart Swan (stuart@cadence.com)
Date: Mon Jul 29 2002 - 14:14:05 PDT
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.
Cleanup is the BC committee's job, the EC committee is for enhancements (no?).
Yes, I guess so. But my impression is that its hard to separate the work that is intended for each
of the subcommittees, and the subcommittees are still in a state of confusion
about their actual goals. And it seems to be the same set of people in each of the subcommittees anyway.
The kind of design flow I'm looking to support is one where IP designers use
interfaces to describe how to talk to their block, and the system-level designers
can plug them together using channels between the interfaces for the major
(point-to-point) data transfers to gather information on throughput requirements
and latency limits etc. before commiting to particular bus structures - a synthesis
tool could map abstract channels into shared physical channels (probably described
by a hiearchy of interfaces) once the requirements are known.
Both the SystemC channels and SystemVerilog interfaces were designed with this use-model in mind.
(Though I'd argue that SystemVerilog "interfaces" have some flaws (e.g. inability to embed modules within an interface) that
prevent them from fully reaching this goal.)
In fact, the design flow you seek above argues against hardcoding the kind of "monolithic/hardcoded" "channel" construct that you
originally proposed for SystemVerilog. For example, one might want a version of a FIFO channel that simply works like a primitive
FIFO, another version that gathers statistics to enable the designer to analyse his system level design, another version which enables
communication delays thru the FIFO to be modeled, etc. Each of these should implement a common set of interfaces (SystemC
terminology) or "modports" (SystemVerilog terminology), so that they can be easily and safely swapped during design analysis and
refinement. Your monolithic FIFO channels wouldn't be able to do this.
Are there any face-to-face meetings in the schedule where we can discuss
this round a white-board?
Don't know.
Kev.
--National Semiconductor
2900 Semiconductor Drive, Mail Stop A1-520, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Mon Jul 29 2002 - 14:17:01 PDT