Re: Problem w/ Matrox Millenium

["John R Pierce" <pierce@scruznet.com>]

Brian Sassone <brians@Aureal.com> wrote...
> I'm seeing a problem when using one of our PCI controllers in conjunction
> with a Matrox Millenium graphics card.  It appears that the Matrox card is
> retrying (for long periods of time) a mem-write (from the CPU) to its 
> address space.  Our controller gets every other bus cycle and is trying to 
> master a memory-read from system memory.  We are also getting continually
> retried until we fail (meaning that our real time requirements simply aren't
> met.)  We are seeing somewhere in excess of 256 retries.

While I haven't worked with the Matrox, I know that a certain other popular
graphics chip family will generate hellaciously long retry cycles if improperly
programmed.  The chip vendor was telling everyone that they could throw data at
the FIFO just as fast as they wanted without worrying about fifo overruns as
the chip could consume data faster than the CPU could generate it.  Well, thats
just not true.  At 24 or 32bit/pixel, writing 32bit words of monochrome data
generates 32x4bytes of internal RMW memory cycles PER dword written... If you
did what the vendor suggested and REP MOVSD a large font glyph to the chip, you
would generate very long abort/retry cycles which would interfere with the
hosts interrupt latency, and even ISA dma cycles (like sound blaster audio). 
It took a fair amount of tricky tuning with a PCI bus analyzer to prevent this
from happening without impacting performance (in graphics, speed is everything,
products are made or broken by a few lousy winmarks...)  Earlier versions of
this unnamed vendors chips did not implement retry correctly, so were simply
generating WAIT states that could stretch for 100's of cycles, seriously
violating PCI timing specifications.  This, needless to say, was even worse.
-jrp
 
���