On 1/5/07, Dieter <[EMAIL PROTECTED]> wrote:
> > 1) a data gatherer on the OGD1 itself
> >
> > 2) a program to control the data gatherer and upload data
> >
> > 3) a program to display the data
> >
> > In most cases, 2 and 3 will run on the same machine, but if someone
> > needs to work remotely, 2 would run on the support machine with the
> > RS-232/USB/Ethernet/whatever link to the test machine, and 3 would
> > run on the machine with the display. 3 can run standalone using
> > data from a regular disk file. Assuming we need to use demand paging
> > of the data, we need for 3 to be able to talk to 2. And it would
> > be convenient if the user could start a new test run directly from 3.
> > We need a protocol for communication between 1 and 2.
> >
> > specify trigger condition
> > specify capture window start and stop times relative to trigger
> > specify which signals to capture
>
> I think we would usually capture them all. The best you could do is
> shave off a few bits.
I'm not familiar with the signals on the PCI bus. Would it always be
necessary to look at the data bits, or would the control lines be
sufficient in most cases? If you can eliminate 32 or 64 signals
then the data would upload faster. And potentially allow storing more
samples in memory.
For the protocol, there are times when some of the signals don't
matter. But from the POV of the tracer, everything is important.
There just aren't enough signals for this to be a major issue. If
we're in a tracer mode where we're capturing only valid transactions,
then we'll ignore all of the idle time completely and report only the
transfers. But that can actually make the data volume larger if you
specify an address along with the data for every transfer.
> We should look at VCD format to see if it serves our purposes well.
> If so, then someone could use GTKwave to view the same data.
What is VCD in this context? Somehow Video Compact Disc doesn't seem right.
I believe it stands for Value Change Dump.
> > We need a protocol for communication between 2 and 3.
> >
> > Same needs as protocol between 1&2?
>
> No. I think it should be an API, not a protocol. Just a set of function
calls.
2 and 3 might be running on different machines.
Why? Don't reinvent X11. If you want the support machine separate
from the display, run the app on the support machine and point its
DISPLAY at your X server.
It occurs to me that it would be nice to have a way to select a sample
and export that into a config/setup/rc file and make it the trigger
for the next run.
Yeah. Makes sense. Use "make trigger from sample", and then save the
trigger to a .trig file or something.
--
Timothy Miller
http://www.cse.ohio-state.edu/~millerti
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
