Re: gEDA-user: Tools for timing diagrams for digital signals

[Steve Wilson <steve-at-NOSPAMspiketech_dot_com>]

Andrew Bardsley wrote:

>On Wed, 12 Feb 2003 steve@spiketech.com wrote:
>
>Interesting points.  I still disagree though, the fact that a timing
>diagram implies by the placement of events relationships between
>signals which may not exist.  Timing diagrams are often ambiguous about
>sets of transitions for which there is no required ordering but one
>is often present in common usage.  I probably have a skewed view here
>as I don't generally work with clocked circuits.
>
Well, I almost exclusively work with clocked circuits.  Perhaps that is 
the largest reason for a difference of opinion.
At the same time you point out that timing diagrams CAN be ambiguous.  
Yep - but when they are used to illustrate relationships that are 
described in other terms as well, then they are pretty much ONLY a 
benefit.  As they say - one picture = 1000 words ;-) (Amazying that all 
pictures can be stored in just 2000 bytes - assuming 2 bytes = 1 word ;-)

Seriously, I'd use timing diagrams to illustrate exactly what you are 
saying they might convey, i.e. a required ordering or dependancy. My 
favorite example would be describing bus handshaking for instance.  You 
have a compelled ordering of events.  The request occurs, followed by an 
acknowledge, followed by data, followed by an end-of-data strobe.  A 
picture of such compelled events is fairly documentary in nature.  It 
gets the point accross with the minimum amount of effort.

>
>  
>
>>Timing diagrams still serve a place in my design bag of tricks.
>>    
>>
>
>Agreed, I usual used them to expand particular examples of interfaces
>but I prefer to specify interfaces in other ways.
>
>Actually, from a GTKWave point of view, being able to annotate with
>causal-relationship arrows (either by hand or from a textual/graphical
>spec) would be quite cool and very handy for visualising relationships
>between signals in real communications (or example communications acting
>as specs.).
>
I see two different applications here - one of which already has some 
support, the other which is more along the lines similar to the product 
"Timing Designer."  We can already add labels and comments to our traces 
using GTKwave if memory serves.  You can't draw connective arrows 
between waveforms on the drawing area though (If I understand what you 
are talking about).  At the same time there is a definite place for a 
program that can create waveforms effiiciently just for documenation 
purposes. Heck - something that could be edited in a word document or at 
least included as a graphic would be the use for such a tool.  I suspect 
you can get by with some of the vector graphic tools - but something 
that was build to display waveforms in particular, allow annotation as 
you mentioned, and could include values in a "pretty" manner within the 
waveform would be of utility.

Go look at ANY SDRAM spec - a tool that would help create such 
documentation would be what I'm talking about. Imagine a tool that could 
have the relationships entered and create the table for you to enter 
values into as well.  That would certainly speed someone's work up for 
them!. 

Steve Wilson

>Hmm, I should prob. think about this.  My main interest in GTKWave has
>always been in adapting it to show request-acknowledge channel
>communications for my own tools.  I've begun to thing recently of
>extending this to show abstracted-from-signals channel comms. in the
>generated circuits from my tools.  Perhaps arrow annotation would be
>good for that.
>
>What do you think?
>
>- Andrew 
>    __________________
>___/Dr Andrew Bardsley\_________________________________________
>University of Manchester Dept. of Computer Science  Amulet Group
>Research Associate bardsleyATcs.man.ac.uk  Tel: +44 161 275 6844
>Snail: Room IT302, Man. Uni., Oxford Rd, Manchester, M13 9PL, UK
>
>
>  
>