eberard@ajpo.sei.cmu.edu (Edward Berard) (10/15/89)
Earlier, I had asked for some information on _general_ references for
timing diagrams. Here are the three responses I received.
-- Ed Berard
(301) 353-9652
------------------------------
John J. Cupak, Jr. (decvax!savax!cupak@ucbvax.Berkeley.EDU) wrote:
Ed -
I'm attempting to offer Ada software support to systems/hardware
engineers here at Sanders. In the process of helping hardware, since
they seemed to have a hard time understanding software, I thought I
do some reading on hardware systems design. I came across a set of
texts which discuss data-element transfer rates and
processor/process sizing. The texts are:
B. A. Bowen and W. R. Brown
VLSI Systems Design for Digital Signal Processing
Signal Processing and Signal Processors
Prentice-Hall, Inc.
Englewood Cliffs, NJ
Volume 1: 1982, Volume 2: 1985.
Volume 2 discusses the timing/sizing on page 200. Incidently, Volume 2
uses Ada as a concurrent process language! Intersting to see this in a
hardware book!
Regards.
John J. Cupak, Jr., CCP
Ada Technology Group
Sanders Associates, Inc.
95 Canal Street / NCA1-2232
P.O. Box 2004
Nashua, NH 03061-2004
(603) 885-2134
-------------------------------------
Gerald Karem (karam@sce.UUCP) wrote:
Actually Ed i'm suprised you mention Buhr and (2.) as that is what
he uses timing diagrams to describe!
["(2.)" refers to the use of timing diagrams to describe concurrent
situations.]
Timing diagrams are most popular in hardware design; e.g. chip
signal specifications. Since most hardware systems are very
concurrent (every chip is a concurrent element), it stands to reason
that the same approach works for concurrent software.
For hardware references, a book on HW design would probably talk about
timing diagrams. for SW, Ray's [R.J.A. Buhr's] new book (*there is an
extensively revised version, seen onlt to a few here at Carleton* not
the one floating about recently) will describe his use of TD in SW.
-----------------------------------
Jeff Barr (visix!jeff@uunet.UU.NET) wrote:
I don't know of any _general_ references for timing diagrams that are
strictly software related. The are a necessary tool for hardware
design ("address lines are valid and then a read cycle is initiated")
to show critical timing relationships.
Part of the standard hardware-related symbology includes some arrows
between timed components to illustrate 2 special relationships:
1. Event A must reach a certain state for Event B to be
initiated.
2. Event A reaching this state initiates Event B.
The hardware doesn't usually enforce these relationships, it just
fails to work as advertised when they are not true within a certain +-
error tolerance (If only software had an "error tolerance" ;-)).
I have used timing diagrams when building complicated multi-process
software systems. They are usful in real-time systems to understand,
for example, why the main event processing loop takes too much time,
or why it is impractical to perform certain tasks on every go-round of
the event loop.
------------------------------------
Thanks to all who replied.
-- Ed