> What we need to focus on first are the human factors. Assuming we
> have managed to get a trace into the display computer (all of it or
> the right pieces on demand), what does a human need to see, and how
> can we best help him/her to see it and understand it?
Phase one - get something useful done quickly
CLI
output choices:
plain ASCII waveform
table of 1s and 0s
Create library with functions to handle "demand paging",
checksum verification, etc. to be reused by GUI version.
Phase two - add output as PostScript
Phase three - GUI
X11 for *BSD, Linux, OS-X, Solaris
Rio window for Plan 9
text labels for the traces
user can arrange which traces to display, in what order
markers
search
buttons to
zoom
scroll left-right, up-down
scroll to marker1, marker2, ...
output PostScript of current display
output config file to recreate current display
switch to a different config file
edit config file (launch $EDITOR) (not essential)
switch to a different dataset (not essential)
Phase four - add smarts
Add a text "trace" that describes activity "read, "write"
Compare simulation output with actual output.
If display is color, paint good portions green,
bad portions red (style and color can be set in
config file).
Look for simple faults like line stuck high or low,
lines shorted together.
Phases 2,3 & 4 could be mostly done in parallel by different people.
Phase 2 shouldn't take long once phase one is done.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
