FW: PPB inability to separate VGA/MONO cycles

["Thomas C. Block" <thomas_block@nine.com>]

Video guys -

I sent the attached email to the Intel AGP folks detailing a problem with VGA/Mono decode in the AGP chipset.  I'd be interested in any comments you all might have about this.  Please feel free to distribute to other interested parties who may have an opinion.

Thanks in advance, 

Tom



----------
From:  Thomas Block
Sent:  Tuesday, December 17, 1996 2:03 PM
To:  Baxter, Brent; Rasmussen, Norm
Cc:  Comins, Todd; Epler, John; Thomas Block
Subject:  PPB inability to separate VGA/MONO cycles

Brent and Norm -

This email message is about a current limitation with the PCI-PCI Bridge (PPB) that will be inherited by AGP chipsets as they implement PPBs to front-end the AGP bus.  Further, the ramifications of this problem are heightened for the AGP PPB case relative to a generic PPB.  Finally, I present a proposal for maintaining current PC compatibility in the AGP/PPB.

As you are probably aware, the evolution of MDA-CGA-EGA-VGA resulted in the ability of VGA and monochrome controllers to coexist in a PC.  In fact, this coexistence is used extensively today for debugging:  main application running through (S)VGA controller and debugger (SOFT-ICE, CodeView, etc.) running through monochrome adapter.

The memory and I/O resource split is as follows: 3Bx I/O to mono, 3Cx-3Dx I/O to VGA, B0000-B7FFF memory to mono, A0000-AFFFF and B8000-BFFFF memory to VGA.  However, having said that, let me also say that VGA can do mono emulation and does that emulation through 3Bx and B0000-B7FFF.  (VGA mono emulation is done when the VGA controller ascertains that there is not a mono adapter in the system, and the user requests mono text mode 7.)

The mono adapter (which lives behind subtractive decoders on the ISA bus) hard decodes 3Bx and B0000-B7FFF.  The VGA has two decode control registers, one for I/O, the other for memory.  They are:

    I/O: 3C2 (write) / 3CC (read) bit 0, if 0 decode 3Bx, if 1 decode 3Dx (power-on default is 0)
    Memory: GR6 (3CE index 6, 3CF data) bits 3:2
            00b: decode A0000-BFFFF (power-on default)
            01b: decode A0000-AFFFF
            10b: decode B0000-B7FFF
            11b: decode B8000-BFFFF

The PPB, through its VGA Enable bit, absolutely decodes 3Bx-3Dx and A0000-BFFFF.  Therefore, in today's systems, if a VGA exists behind a PPB, concurrent monochrome access (through subtractive decoder to ISA bus) is not possible.  There is no protocol to redirect master aborts of mono cycles back upstream so they can be picked up by the subtractive decoder.

I do not think this is a big problem for generic PCI PPBs since the user that wishes to do monochrome monitor debugging is probably on bus 0 with his VGA, or at least can relocate his VGA there.  The only problem might be a "video-down" implementation that is behind a PPB (do any of these exist?).  Since PPBs have been around for several years now and this limitation is just now being understood, I think it is fair to say that the generic PCI PPB case is not a problem.

However, with AGP/PPB, there are several problems.  Given that the AGP graphics device is also the only VGA device (a proposition that I think will be true for most AGP systems), then the AGP/PPB (as currently designed) will break concurrent monochrome display adapter access.  This will be a big problem for many people, not the least of which will be all of the AGP video vendors that will be trying to debug their software.  It is true that there are other debug configurations, such as serial port link to another system, etc., but I would estimate that most people are very reliant on monochrome debug capability.  Another possible multi-monitor debug environment would be another VGA, but this would only be applicable to those AGP vendors that have a non-SVGA accelerator implementation and certainly would not work for debugging AGP/VGA.  I think the lack of monochrome debug access is probably the biggest problem.

As I see it, if the AGP/PPB has the VGA Enable bit enabled, it can have three different implementations regarding mono cycles: absolute decode of all mono cycles (current PPB capability), absolute rejection of all mono cycles, or dynamic decode/reject of all mono cycles (i.e., shadow/snoop the AGP/VGA 3C2/3CC and GR6 registers).  I believe that the last implementation (shadow/snoop the VGA decode registers) is the only one which will guarantee complete PC compatibility.  The problem with the first implementation (absolute decode) is detailed above (i.e., no concurrent monochrome access).

There are two potential problems with the second implementation choice (absolute rejection of all mono cycles).  All of today's VGA implementations utilize a derivation of the original IBM/Quadtel VGA core and core BIOS.  The power-on value of the VGA core 3C2/3CC register bit 0 is 0, meaning that the VGA chip initializes as a monochrome decoder, not a VGA decoder.  There is quite a bit of code in the VGA BIOS that ascertains the existence of a monochrome adapter and flips the 3C2/3CC bit 0 state in the process.  Not allowing monochrome cycles to reach the AGP/VGA core, when it is prepared to receive them, may very well break VGA BIOS initialization and/or subsequent mode sets.  (I will try to get more data on what exactly will happen in this case.)  The second problem with an AGP/PPB doing absolute rejection of mono cycles is that VGA modes 7 (text) and F (graphics) will not work, since they are driven by 3Bx cycles.  Obviously, VGA test programs (such as DMU, etc.) will fail.  Many graphics and system vendors incorporate these tests into their qualification processes.  Both of these problems have the potential to force video vendors to rewrite their VGA BIOS.  Since the goal of AGP is to piggy-back on today's current PCI configuration scheme in order to achieve minimal system re-work, an implementation of AGP/PPB that forces VGA BIOS changes would be counter to that goal.

The only correct choice, in my view, would be for the AGP/PPB chipset implementation to shadow the 3C2/3CC bit 0 and the GR6 bits 3:2.  If the VGA Enable bit is set, then all accesses to the aforementioned bits should be snooped and the shadow registers updated accordingly.  The PPB VGA decoder (3Bx-3Dx, A0000-BFFFF) should be modified to act on the state of the 3C2/3CC and GR6 shadow registers.  If AGP is going to allow the VGA component, it should implement it fully in the interest of compatibility.

Number Nine has experience with this particular VGA decode problem.  An early implementation of our Imagine Series 128-bit accelerator utilized an ISA bridge to which we connected an external VGA chip.  We could not meet the PCI decode latencies for VGA in that configuration and thus had to implement shadow registers (3C2/3CC, GR6) in the host bus interface.

I hope you will consider this request for an AGP/PPB design clarification and make sure that the appropriate chipset design groups understand the problem.  Please let me know if I can provide any further information.

Thanks, Tom



 
Thomas Block
Number Nine Visual Technology Corporation
18 Hartwell Ave.
Lexington, MA  02173
617-674-8666
thomas_block@nine.com
http://www.nine.com
¤`	P