On 1/1/07, Dieter <[EMAIL PROTECTED]> wrote:
Timothy> solution will be to use some device to watch the PCI bus activity and
Timothy> let us observe them.
Such an analyzer could also be useful to people reverse engineering
undocumented hardware.
Timothy> Later, we should consider figuring out how to do USB 1.1.
I'm not sure what you have in mind for this (USB analyzer?),
but if you are going to bother doing USB, doing both USB1 and USB2
would be the way to go.
I meant that we would replace the serial port with the USB port. This
wouldn't be a USB analyzer. It would be a PCI analyzer that uses USB
to communicate with the user workstation ("Display").
tonyb> Does anyone else have a preference for the gui platform?
X11 would seem to be the obvious choice. I don't know much about
GTK+ or its competators, but pick something that is as bug free as
possible, and portable to at least the BSDs, Plan9, OS-X, Linux,
Solaris, and to ILP32, LP64, big and little endian. Does Plan9 do X11?
I've used wxWidgets before, and I liked it. But if we use something
like Ruby or Perl with Tk, that's another way to make it portable.
I'd rather stay away from Java just because it's so much more
heavyweight, although no one's stoping someone from writing a Java
client for it.
tonyb> My guess is that there is an OG card,
tonyb> a trace card, and a video card in the system.
Don't assume a video card. Assuming X11 should be fairly safe.
The display may well be on a different machine. If the board
being analyzed is sufficiently buggy, the analyzer software
will need to be on a different machine.
The display is DEFINITELY on a different machine. Don't even bother
considering the case where you don't have two separate computers. For
one thing, you want to minimize the amount of irrelevant PCI traffic,
so if you want networking, for instance, make sure it's both built
into the chipset and that it's traffic doesn't appear on the PCI bus
(I've seen builtin NICs whose transactions appeared on the PCI bus).
One of the most common reasons to use a tracer is that you've
experienced a lockup, and you can't track it down. In X11 drivers,
I've done weird stuff where I printed to a log before every PCI
access, but even that isn't so great, because buffering may lose some
log entries. It's even worse if you're working with a kernel driver,
because it's very to trace those things in software up to the point
where you get a lockup.
tonyb> The serial port would
tonyb> send commands and receive status from the trace card.
And I assume, the data would also go across RS-232?
Yes.
tonyb> I think that there
tonyb> would be too much data to try to put the gui on the other end of the
tonyb> serial port.
You want the analyzer software, including the GUI, running on the
analyzer/support computer, not on the OGD card.
Exactly. All of the fancy complexity is in software, while the serial
protocol that you use to communicate with the tracer is dead simple.
tonyb> A starting point for the trace api would be:
tonyb> start trace
tonyb> stop trace
tonyb> define trigger
tonyb> enable trigger
tonyb> disable trigger
tonyb> trigger depends on trigger X being true
tonyb> get status
The ability to start/stop the trace with a time offset relative to the
trigger may be useful. The trigger time does not necessarily have to be
within the capture. (might not have enough memory)
Good point. Completely arbitrary stop, start, and trigger times would
be helpful.
Timothy> If
Timothy> every point in time requires, say, 8 bytes of memory, then with
Timothy> 256MiB, we can store 33 554 432 time periods. Is that enough?
You can have too little, but you can never have too much. It would be good
to have the ability to save only the signals of interest, to allow storing
more time samples.
In my experience, the two main modes are clock-oriented, and
transfer-oriented. I think there's also transaction-oriented. I'm
not sure what they all were, although intuitively, it seems to me that
we'd want to capture (a) every signal at every clock within the
capture timeframe, (b) every signal on every clock in which something
actually happens (idle times are deleted), and (c) every data
transfer. (c) is a little more abstract, because what you'd want to
report is what transferred to what address on what cycle, and that
includes addresses that are implied (because they're in the middle of
a burst).
The ability to start/stop the default display with an time offset relative
to the trigger is likely to be useful. (save a lot of scrolling)
We could have multiple triggers even, and we could provide buttons on
the GUI to let you skip to them. It's very valuable to be able to see
activity that preceeded and followed the trigger.
The ability to zoom in/out.
Yes, variable timescale is important. At certain zoom levels, we
could alter the way the diagram looks so that it makes the most sense.
For instance, data and addresses may not fit into their timeslots, so
don't bother to display them; just display something that indicates
whether or not the data is meaningful.
The ability to select which signals to display, and in what order.
The ability to search for a particular bit pattern. (perhaps
sequences of bit patterns?)
Yup.
Tha ability to have setup/config/rc files, and be able to switch
from one to another easily.
Will the hardware be able to detect anything other than a binary
signal level? Glitches, floating signal levels, etc.
It would be really nice to be able to do analog, but I don't think we
can do anything other than digital. If the I/O buffers have any
special abilities, we'll certainly use them, but I don't know what the
might be.
tim> The easiest interface (and arguably the most cross-platform) would be
tim> a simple terminal interface on the serial line. Fire up minicom or
tim> hyperterminal or whatever... to 8N1 @ 152000 and go.
tim>
tim> Easy to program, easy to use. No GUI needed.
The command interface could probably be CLI. While the data display
could also be text based, you can display a lot more data using
graphics, so the data display should probably be graphical.
Remember that 19200 bits/sec isn't very fast. I'd hate to slow it
down by using an ASCII interface. I'd also hate to require the logic.
On the other hand, before we have a GUI, we'll definitely need a way
to interact with and debug the device. Either we have a simple
text-based UI that translates between binary and ASCII, or we give the
device an ASCII mode. I don't really see a compelling reason why we
can't require an application, though, evne if it's text-based.
The fastest way to get something useful might be a CLI with
graphical data output via something like gnuplot. Get a bit
of experiance and figure out what features are needed,
then do the GUI version. For extra credit, have a button that
dumps the screen as PostScript. And a button to dump all the
raw data to a file on disk.
I think there are VT102 graphics characters that are top-line and
bottom-line (underscore) symbols, as well as several in between.
Worst case, we could even use _, -, and ^ characters. For multi-bit
signals (like the AD lines), we would insert an X or something like
that at transition points.
daniel> instantly ported to all OSes which
daniel> has a up-to-date browser (or can run firefox))
Firefox is NOT portable and is insanely buggy. :-(
Timothy> But you need real-time response from the UI for panning around in a
Timothy> graphical representation of the trace.
The OGD must capture the PCI data in real-time. The UI doesn't need to be
real-time. It would be good if the UI were fast enough to not be annoying,
but you don't lose data if it lags behind. ("real time" != "fast")
Right. The GUI just needs to feel fast to the user.
Timothy> I don't know how you'd do a good job
Timothy> of displaying readable waveforms in a terminal window.
It can be done in ASCII, but graphics would be better.
-------\_______/-------\_/---
----------\__/-------\_______
_/-\_/-\_/-\_/-\_/-\_/-\_/-\_
Timothy> I don't know of any web browser that support HTTP over a serial line.
That's what slip and ppp are for. But I don't think the web browser
interface is the way to go for this.
But SLIP and PPP are TCP/IP over serial, aren't they? I definitely
don't want to have to put a TCP/IP stack in the tracer.
I suggest making the part that lives in the OGD fairly simple and small.
Conserve memory for data storage since we will not be able to transfer
data over RS-232 in real time. Also, simple tends to be less buggy.
My thoughts exactly.
Question is what format to use for data transfer. Can we assume an
8 bit data path with hardware (e.g. RTS/CTS) flow control? If so,
then data transfers will be faster. Or do we need to allow for a
7 bit data path, and reserve control-s and control-q for flow control?
We're in complete control over this. We don't even need flow control.
We can know that the tracer's command buffer has a certain length,
and we never send more than that without checking for an acknowledge.
Similarly, as a receiver, we should not rely on buffering. The app
simply must be fast enough to receive the data and process it. Having
a dedicated thread for the serial I/O should do the trick. We can put
a checksum in the data packets to ensure that we got the whole thing
and got it right, and we can always request a resend if there's a
problem.
--
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)
