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