On 1/2/07, Dieter <[EMAIL PROTECTED]> wrote:
> > > 115200 bps is ~ 14 k/s. At that speed, a full 256Mb ram dump would
> > > take approximately 5.2 hours.
http://en.wikipedia.org/wiki/UART
lists speeds up to 2764800 bps. If we can use 2764800 bps that drops the
time for 256 MiB to a tad less than 13 minutes. Does this require a
magic UART? We'd definitely want one with a large FIFO. I assume we'd
want a short, good quality cable.
We can't go any faster than what a typical PC workstation will
support. Or for that matter, what a serial bus can handle for signal
integrity.
If we can get a PC's UART to support HDLC/SDLC, then we can squeeze
out a few more % throughput, but the REAL gain will be from clever
compression. Even more of a gain will come from not blindly
downloading the whole trace.
In my experience, I've been able to narrow down the interesting parts
of traces to a range of only a few thousand cycles or less. Too many
cycles, and it's just too much for the human brain to handle. In that
case, you need some high-level analysis, and some of that can be
implemented in the tracer.
Seriously, if you detect a hangup (at which point, the bus activity
typically comes to a halt, but not always), then all you need is the
last few hundred to a few thousand cycles. Another use for the tracer
is to identify a performance problem, and even then, you still need
only a few thousand cycles.
Perhaps on the serial version, we should restrict the trace size to,
say, 64k cycles. How long would that take to download?
> > Or... assuming the case that the board under test locked up the machine,
> > would it be possible to protect this RAM from being cleared on reboot,
> > and then upload it to the test computer via PCI?
>
> Egad. We can supply external power, but I'm not sure if that would
> send power to the host computer when it's off, causing trouble.
Are we expecting to lock the machine up sufficiently that the reset
and front panel power buttons don't work, requiring turning off
the power supply (or pulling the power cord)?
I've had that happen before, yes.
If not, the RAM could
be powered from the 5V standby.
It COULD be, but at the moment it isn't, and I'm not sure if it can be
done easily. We're just going to have to accept the fact that some
aspects of this product will be suboptimal. If there's an actual
demand for it, we can make a follow-on product that does all sorts of
neat stuff. But by then, PCI will be dead. This is a now-or-never
sort of project.
We're just going to have to be very clever about how we suck data
through that serial port.
Can we safely assume that the board under test will not screw up the
PCI bus until we talk to the board?
No. Why does it matter?
If there is really wierd stuff happening on the PCI bus, can the OGD
ignore commands from the PCU bus and be controlled solely from the RS-232?
Of course. It's not a PCI device. It's a PCI snooper. As long as it
has power, it'll operate as we've programmed it to. The idea is to
have the tracer controlled entirely through the serial port.
There may indeed be some use for having the tracer inject signals onto
the PCI bus, but for the most part, all of the PCI signals are always
_inputs_ to the tracer.
Maybe what we need to do is physically cut all power traces from PCI
to the rest of the PCB so that the board can be powered ONLY through
external means. I'm not an analog engineer, but I THINK that as long
as the ground is common, we'll be able to measure signals properly.
Doing it this way, you could indeed physically remove the tracer form
the test machine and still retain a trace in memory. But with the
power traces cut, I'm not sure if we still have the option of
injecting signals or using PCI to download a trace.
--
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)
