Subject: $sv-ec Re: Channel Proposal - Requirements
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Mon Sep 30 2002 - 14:06:22 PDT
Most of the requirements for channels were given in an earlier e-mail:
http://www.eda.org/vlog-pp/sv-ec/hm/0117.html
Mostly National needs an SV mechanism to replace what we already
do in our C++/Verilog test environment. It also addresses how to connect
test/simulation tools that handle different domains e.g. Matlab/SPW for
modelling system-level data flow and processing, which can be useful for
RF/Wireless design and verification (my dept. at National).
From a synthesis perspective channels allow data flow to be described in a
point-to-point manner across clock domains which enables communication-driven
synthesis (of busses etc.). Currently there is no simple mechanism to reliably transfer
data across clock domains in SV/Verilog, and trying to trace signals through stacks
of synchronizers is not my favorite debugging task.
Channels are a lower-level approach to the testbench donation's "mailbox"
mechanism. Adding references to the possible protocols supported by
the channel mechanism allows it to provide the same functionality as a
mailbox. Currently mailboxes are created dynamically and channels are static.
Regards,
Kev.
Subject: Re: Channel Proposal
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Aug 19 2002 - 15:47:49 PDT
Just to recap, the specific (NSC) requirement the proposal addresses is the replacement
of a large junk of simulator backplane code written in C++ that uses the equivalent of
data channels to pass messages between Verilog modules and C++ tests. It does that by
a) creating abstract data channels in SV and b) allowing them to be bound to Unix pipes
so that the C++ environment can be brought up seperately from the simulator, and C++
test processes can be autonomous for easy simultaneous debugging.
The pipe/channel bridge to external programs is not dependent on PLI, and can be
used to access other external programs that can talk to standard-io, fifos (see Unix
mkfifo), sockets etc. That could include hardware accellerators and emulators as
well as tools like Matlab, SPW etc., or just more SV simulations (for CSP style
parallel processing).
Within SV the data channel mechanism can be used to describe asynchronous data flow
between different parts of a circuit and/or testbench. This is useful for a variety
of tasks:
Unsized FIFOs - minimal coding for top-down design.
Asynchronous or
Self-Timed design - channels can be used reliably between clock domains and
(future) synthesis tools can implement the handshaking/
synchronizing hardware.
This is particularly important for low-power design where
you only want to clock/power the logic when absolutely
necessary (when there is data to process). [Dig out your
DAC '99 Cogency handouts for an example]
Bus synthesis - multiple channels would be mapped into actual busses
according to data-flow measurements from the individual
channels and channel attributes.
Note: while the basic mechanism is asynchronous it is possible perform psuedo
synchronous operations if you use the blocking read/writes and the right protocols,
that limits how much data ever gets into a channel.
Kev.
This archive was generated by hypermail 2b28 : Mon Aug 19 2002 - 15:51:08 PDT
This archive was generated by hypermail 2b28 : Mon Sep 30 2002 - 14:07:22 PDT