[Open-graphics] A really good immediate use for OGD1: PCI bus analyzer

[André Pouliot]

For the pci bus analyzer why try to get all the signal to show as a 
waveform?

The card could just decode the stream of data on the pci bus and forward 
that to the user on the form of address + data in an ascii file. For 
some people it's a lot simpler if we provide that with some setting to 
capture on some address range.

For debugging the pci bus at signal level it could be a future extension.


Timothy Miller wrote:
> On 12/31/06, Jack Carroll <mykrowatt at comcast.net> wrote:
>> On Sun, Dec 31, 2006 at 09:17:47PM -0500, Timothy Miller wrote:
>> > On 12/31/06, Tim Schmidt <timschmidt at gmail.com> wrote:
>> > >On 12/31/06, Tim Schmidt <timschmidt at gmail.com> wrote:
>> > >> Easy to program, easy to use.  No GUI needed.
>> > >
>> > >Which, of course, doesn't mean someone couldn't write a GUI...  just
>> > >that they'd be writing it to a semi-standardized terminal interface
>> > >instead of blasting raw serial data over the line.
>> >
>> > We could make a human-readable mode, and we could use VT100 codes in
>> > order to display it nicely.  But I don't know how you'd do a good job
>> > of displaying readable waveforms in a terminal window.
>>
>>         It would have to be in a graphic format.  There must be a 
>> zillion
>> formats that can describe a waveform compactly enough to be sent over 
>> a slow
>> serial line.  PNG, PDF, EPS, SVG...  Most of them are sent as files, 
>> so they'd
>> probably have to be transferred using HTTP, FTP, Kermit, or the 
>> like.  That
>> gets us away from the link model of a text terminal, though.
>
> I don't know of any web browser that support HTTP over a serial line.
> Sounds like what you're suggesting is a networked device that contains
> an embedded web server.
>
> While this is indeed an interesting idea, let's not let feature creep
> let us lose sight of producing a working product.  The first goal
> should be to develop the simplest thing that works well.  Being able
> to analyze PCI bus activity in the most straightforward way possible
> is the important thing.  In order to make the design tractible, we
> need to keep the Tracer design as simple as possible.  Embedding a web
> server is not simple.  Producing and encoding an image in hardware is
> even less simple still.  If we don't employ the KISS principle to an
> extreme degree, we won't make progress as a project.
>
> In case you're worried about it, we're not at risk of confining
> ourselves into a box by not thinking ahead.  We have every opportunity
> to redesign things completely when we decide to.  The most important
> thing to do right now is find the shortest path to a working product.
> The SHORTEST path.  That means we should have the simplest protocol
> for controlling the tracer and the quickest solution to an end user
> application.
>
> Don't forget that this "excessive" pragmatism is not really natural to
> me.  I LIKE these ideas.  And I look forward to the day when we have
> cash flow and money for research and tinkering with wild ideas.  But
> the fact is, this project is a painfully slow mover right now, and I
> absolutely do not want to slow it down any further.  If I didn't
> expect to run into some sort of show-stopper bug (it always happens!)
> that would require watching PCI transactions, then I wouldn't even
> bring up the Tracer, because it's a distraction.  Distractions are
> VERY VERY BAD.
>
>>         Maybe the simplest way would be to just pack up the stored 
>> binary
>> data so it could be sent as ASCII characters, and let the display PC 
>> handle
>> the conversion to a displayable format.  That takes a lot less logic 
>> on the
>> PCI analyzer board, and puts the complicated logic into software 
>> where it's
>> easier to implement.
>
> I completely agree.  And we don't really need to "pack up" the data.
> Like I say, you can download a screenful plenty fast enough.  The end
> application just needs to request data on demand from the tracer.
>