`
`
`
`
`
`
`
`
`‘
`
`Purpose
`
`‘
`
`
`
`
`VUMA Proposal
`
`
`
`
`
`
`
`
`
`
`
`VESA®
`.
`(Draft)
`
`
`
`
`.’Video Electronics Standards Association 1W
`
`
`
`
`
`
`
`
`2150 North First Street. Suite 440
`Phone: (408) 435-0333
`r
`‘
`
`
`
`
`
`
`
`.San Jose, CA 95131-2029 .
`FAX: (408) 435-8225
`
`
`
`
`
`VESA Unified Memory Architecture
`
`
`
`
`Hardware Specifications Proposal
`
`Version: 1.0p
`'
`
`
`Document Revision: 0.4p
`
`
`October 31, 1995
`
`
`
`
`
`
`
`
`
`
`Important Notice: Thisis a draft document from the Video Electronics Standards
`
`
`
`
`
`
`
`
`
`
`Association (VESA) Unified Memory Architecture Committee ('VUMA). It'is only for
`
`
`
`
`
`
`
`
`
`
`
`discussion purposes within the committee and with any other persons or organizations
`
`
`
`
`
`
`
`
`
`
`
`
`
`that the committee has determined should be invited to review or otherwise contribute to
`
`
`
`
`
`
`
`
`
`
`
`
`
`it. It has not been presented or ratified by the VESA general membership.
`
`‘To enable core logic chipsetand VUMA device designerstodesign VUMA devices
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`r rsupporting the UnifiedMemory Architecmre. .
`
`
`
`
`
`
`l “ Summary.
`
`
`
`75 This document Contains a Specification for VUMA devices’ hardvIare interface. It
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`includes logical and electrical interfacespecifications. The BIOS protocol is described in '
`
`
`
`
`
`
`
`
`'1‘ VESA document VUMA VESA BIOS Extensions (VUMA-SBE) rev. 1.0.
`
`
`
`
`Page 1 0f 38
`
`'
`
`HTC-LG-SAMSUNG EXHIBIT 1025
`
`
`
`Page 1 of 38
`
`HTC-LG-SAMSUNG EXHIBIT 1025
`
`

`

`VUMA Proposed S fizdard
`
`
`
`
`‘
`
`y
`
`y;
`
`u"
`
`VESA Confidential
`
`
`! Scope
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`.i Because this is a draft document, it cannot be considered complete or accurate in all
`
`
`
`
`
`
`
`
`
`
`l "respects although every efi'ort has been made to minimize errors.
`
`‘
`
`
`Intellectual-Property
`
`
`' c Copyright 1995 - Video Electronihs Standards Association. Duplication of this -
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`‘ document within VESA member companies for review purposes is permitted. All other
`
`
`rights are reserved.
`‘
`
`Trademarks
`
`All trademarks used in this document are the property of their respective owners.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`and VUMA are trademarks owned by the Video Electronics Standards Association.
`
`,VESA.
`
`Patenis .
`
`The proposals and standards developed and adopted by VESA are intended to promote
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`uniformity and economies of scaletn the video electronics industry. VESA strives for
`
`
`
`
`
`
`
`
`
`
`
`
`
`standards that Will benefit both the industry and end users of video electronics products.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`VESA carmot' ensure that the adoption of a standard; theuse of a method described as a
`
`
`
`
`
`
`
`
`
`
`
`
`
`standard: or'the making, using, or selling of a product in compliance with the standard
`
`
`
`
`
`
`
`
`
`
`
`does not infringe upon the intellectual property rights (including patents, trademarks, and
`
`
`
`
`
`
`
`
`
`
`
`copyrights) of others. VESA, therefore, makes no warranties, expressed or implied, that .
`
`
`
`
`
`
`
`
`
`
`
`
`products conforming to a VESA standard do not infringe on the intellectual property
`
`
`
`
`
`
`
`
`
`
`
`
`
`rights of others, and accepts no liability direct, indirect or consequential, for any such
`infringement.
`
`Fia'tje'z of 38 '
`
`2
`
`
`
`
`Version. 1.0p, Rev. 0.4p
`
`._ -‘~—--——«——-—« «m...
`
`Page 2 of 38
`
`

`

`
`
`VUMA, Proposed Stand...d
`
`
`
`
`jESA Confidential
`
`
`
`
`
`‘Support For This Specification
`
`If you have a product that incorporates VUMATM,you should ask the company that
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`manufactured your product for assistance.
`If you are a manufacturer of the product,
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`‘VESA can assist you with any clarification that you may require. All questions must be
`
`
`
`
`
`
`i sent in writing to VESA via:
`‘
`
`
`
`
`
`
`
`
`
`
`j (The following list is the preferred order for contacting VESA.)
`
`‘
`
`.
`
`l
`
`
`
`
`
`
`
`VESA World Wide Web Page: www.‘vesa. org
`
`‘ (408) 435-8225
`Fax:
`' VESA
`Mail:
`
`
`
`2150 North First Street
`
`[Suite 440
`
`
`
`‘ San Jose, California 95131-2029
`
`'
`
`'
`
`'
`
`'
`
`Acknowledgments.
`
`(
`
`I,
`
`-
`
`This document would not have been possible without the cflhm of the members of the
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`1995 VESA Unified Memory Architecture Committee and the professional support ofthe .
`iVESAstafi‘.
`
`
`
`'Work Group Members
`
`rAny industry standard requires information fi-om many sources. The following list
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`recognizes members of the VUMA Committee, which was responsible for combining all
`
`
`
`
`
`
`of the indusrry input into this proposal.
`
`Chairperson
`
`‘Rajesh Shaltkarwar
`
`.
`
`,
`
`OPTi
`
`S3
`
`
`
`VLSl Technology lnc.
`
`Sierra Semiconductor
`
`Western Digital
`Cypress
`
`Alliance Semiconductor
`
`Oak Technology
`
`
`
`Pacific Micro Computing lnc.
`
`Mentor Are
`Samsung
`Micron
`
`
`Hitachi America Ltd.
`Mitsubishi
`Weitek '
`
`Members
`
`Jonathan Claman
`
`
`Jim Jirgal
`
`Don Pannell
`
`Wallace Kou
`
`Derek Johnson
`
`Andy Daniel
`
`Long Nguyen
`
`Robert Tsay
`
`Sunil Bhatia
`
`Peter Cheng
`
`:Alan Mormann
`
`jSolomon Alemayehu
`
`;Larry Alchesky
`
`iDean Hays
`
`Page 3 of 38
`
`
`
`
`7 Version. 1.0;). Rev. 0.4p
`
`Page 3 of 38
`
`

`

`:VUMA Proposed St:
`
`
`
`
`‘ard
`
`'
`
`VESA Confidential ‘
`
`
`
`Revision History
`
`mama/ism 0.1p _
`
`
`
`
`_
`
`t
`‘
`Revision 02p
`
`
`
`
`
`Added sync DRAM nippo'rt
`
`Electrical Section
`
`p
`Boot Protocol,
`Reformatteddocmnent
`
`
`,
`
`.
`
`-
`
`Sept 21 ‘95
`
`
`,
`
`
`
`Oct 5 ‘95
`
`
`
`.
`
`'
`RevisionOJp'
`
`
`
`
`
`
`Graphics controller replaced with VUMA device '
`
`
`
`MD[n:0] changed to Us ,
`.
`-
`
`
`
`Modified Aux Memory description
`
`
`
`
`
`
`Added third solution to Memory Expansion Problem ‘
`
`
`
`
`
`
`Synch DRAM burst length changed to 2/4
`
`
`
`
`
`
`Modified all the bus hand off diagrams
`
`
`
`
`Added DRAM Driver Characteristics section
`
`
`Revision 0.4p
`Sync DRAM Burst Length changed to 1/214
`
`
`
`
`
`
`
`
`
`
`DRAM controller pin multiplexing added
`
`
`
`Changed AC timing parameters
`'
`
`Oml§‘95
`
`
`
`
`
`Oct 19 ‘95
`
`Page 4 of 38 ‘
`
`4
`
`
`
`
`Version. 1.0p. Rev. 044p
`
`Page 4 of 38
`
`

`

`
`
`
`
`VUMA Proposed Standa. -
`
`
`
`
`'
`
`.
`
`
`" 35A COnfidenfial
`
`.
`
`TABLE OF CONTENTS
`
`
`
`
`
`
`
`m5
`
`
`
`
`
`
`
`
`
`
`‘J 4 2.1 SIGNAL TYPE DEFINITION...............................................................................................7
`
`
`
`
`
`22 ARBITRATION SIGNALS..................................................................................................7
`
`
`
`
`
`2.3 FAST PAGE MODE, EDO AND BEDO DRAMS...............................................................7
`
`
`
`
`
`
`
`
`
`2.4 SYNCHRONOUS DRAM................................................................................................... 8
`
`
`
`
`
`3.0 PHYSICAL INTERFACE
`.-.”-mmmmmmmw....8
`
`
`
`
`
`
`
`3.1 PHYSICAL SYSTEMMEMORY SHARING ........................................................
`........9
`
`
`
`
`
`3 2 MEMORY REGIONS........................................................................................................ 10
`
`
`
`
`
`
`
`3.3 PHYSICAL CONNECTION .................
`....................................................... 11
`
`
`
`
`I.
`I124
`‘II
`1:;1
`
`1
`
`s 1.0 mobvcnON WWW' . j. . . ‘
`
`
`
`
`
`4'0 ARBITRATIONmmmmfigflomwou-OIm-nuoualz
`
`
`
`4.1 ARBITRATION PROTOCOL......................
`................12.
`
`
`
`
`
`
`
`
`
`4.2 ARBITER ................................................................................................................ Z...... 12
`
`
`
`4.3 ARBITRATION EXAMPLES.....................................................................
`............... 15
`
`
`
`
`
`4.4 LATENCIEs ...........................
`......................................................................... 18
`
`
`
`5.0 MEMORY MRFACE..............................;.....................mmmmmls
`
`
`
`
`
`............. 19
`5.1 MEMORY DECODE .............................................................................
`
`
`
`
`5.2 MAIN VUMA MEMORY MAPPING................................................................................20
`
`
`
`
`
`
`
`
`
`
`
`
`..................23
`. 5.3 FAST PAGE EDO AND BEDO
`
`
`
`
`
`
`5.4 SYNCHRONOUS DRAM.................................................................................................27
`
`
`
`5.5 MEMORY PARITY SUPPORT-.................................32
`
`
`
`
`
`
`
`5.6 MEMORY CONTROLLER PIN MULTIPLEXING ..................................................................32
`
`
`
`6.0 BOOT PROTOCOL......... ....................L..
`.....32
`6.1 MAIN VUMA MEMORY ACCESS ATBOOT........."..........33
`
`
`
`
`
`
`
`
`
`
`
`
`6..7 RESET STATE
`..............34
`
`
`
`
`
`7.0 ELECTRICAL SPECIFICATION......................
`......35
`
`,......‘..................
`
`
`
`7.1 SIGNAL LEVELS ...............................................................'.............................................35
`
`
`
`
`
`
`
`7.2 AC TIMING .....................................................................35
`
`
`7.3 PULLUPS ................................................................................'.......................................37
`
`
`
`
`
`
`7.4STRAPS......37
`
`
`
`
`7.5 DRAM DRIVER CHARACTERISTICS ...............................................................................37
`
`Page 5 of 38
`
`‘5
`
`
`
`
`
`
`Version. 1.09. Rev. OAp
`
`
`
`
`
`
`
`Page 5 of 38
`
`

`

`
`
`p
`
`_
`
`‘ évumpmpmd Sta, Us“! .
`
`
`
`
`
`v
`
`'
`
`, VESA~ConfldenfiaI
`
`
`‘
`
`l
`
`,
`
`‘
`
`ii?
`
`y
`
`‘3‘!
`3
`
`i
`
`i
`
`‘
`
`i 1.0 IntrOduction
`
`
`2,
`
`
`
`
`
`
`. The concept ofVESA Unified Memory Architecture (VUMA) is to share physical system
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`‘ memory (DRAM) between system and an external device, a VUMA device; as shown in
`
`
`
`
`
`
`
`
`
`b Figure 1-1. A VUMA device'could be any type. of controller which needs to share
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`physical system memory‘(DRAM) with system and directly access it. One example of a
`
`
`
`
`
`
`
`
`
`
`
`
`VUMA device is graphics controller. In a VUMA system, graphics controller will
`
`
`
`
`
`
`
`
`
`
`
`
`
`incorporate graphics fi‘ame bufi‘er in physical system memory (DRAM) or in other words
`
`
`
`
`
`
`
`
`
`
`
`
`
`VUMA device will use a part of physical system memory as its flatne bufle‘r, thus,
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`sharing it with system and directly accessing it. This will eliminate the need for separate
`
`
`
`
`graphics memory, resulting in cost savings. Memory sharing is achieved by physically
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`3 connecting core logic chipset (hereafter referred to as core logic) and VUMA device to
`
`
`
`
`
`
`
`
`
`
`
`the same physical system memory DRAM pins. Though the current version covers
`
`
`
`
`
`
`
`
`
`
`
`
`sharing of physical system memory only between core logic and a motherboard VUMA
`
`
`
`
`
`
`
`
`
`
`
`
`device, the next version will cover an expansion connector, connected to physical system
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`‘ memory DRAM pins. An OEM will be able to connect any type of device to the physical
`
`
`
`
`
`_ system memory DRAM pins throughthe expansion connector.
`'
`,
`
`,
`
`
`the discussion in the
`Though a VUMA device could be ‘any type of controller,
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`specifications emphasizes a graphics coimoller as it will be the first VUMA system
`implementation.
`a
`
`
`
`
`
`
`Figure 1-1 VUMA System Block Diagram
`
`:5
`
`PCI Bus
`
`
`
`
`
`
`
`
`
`
`
`
`2.0 Signal Definition
`
`
`
`Page 6 of 38
`
`; 6
`
`Version. 1.0p. Rev. 0.4p
`
`
`
`
`Page 6 of 38
`
`

`

`t
`‘I.
`.
`.H
`l‘
`l Mi“
`at
`‘
`‘n
`
`x
`
`VUMA Proposed Standat
`
`
`
`2.1 Signal Type Definition '
`
`
`
`
`in
`
`
`
`
`
`
`
`
`Input is a standard input-only signal.
`
`.
`
`‘ dut
`
`
`
`
`
`
`
`Totem Pole Output is asstandard active driver
`
`
`in
`
`
`
`Tri-State is a bidirectional, em input/output pin.
`
`
`
`
`
`
`
`‘
`
`SA Canfidenfia|
`
`
`
`sltls'
`
`
`
`
`
`
`
`
`
`
`
`
`
`Sustained Tri-stat'e is an active ‘low or active high tti-statc signal owned and
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`driven by one and only one agent at a time. The agent that drives an s/t/s pin
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`active must driVe it high for at least one clock before letting it floateA pullup is
`
`
`
`
`
`
`
`
`
`
`
`
`required to sustain the high state until another agent drives it. Either internal or
`
`
`
`
`
`
`
`
`
`
`
`
`external pullup must be provided by core logic. A VUMA device can also
`
`
`
`
`
`
`optionally provide an internal or eirternal pullup.
`
`
`
`2.2 Arbitration Slgn‘als
`
`MREQ#
`
`'
`
`Moms
`
`
`in
`
`
`out
`
`in
`
`
`out
`
`MREQ# is outfor VUMA device and in for core logic. This '1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`signal is used by VUMA device to inform core logic that it
`
`
`
`
`
`
`
`needsto access shared physical system memory bus.
`
`MGNT# is out for‘core logic and in for VUMA device. This
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`signal is used by core logic‘to inform VUMA device that it can
`
`
`
`
`
`access” shared physical system memory bus.
`
`‘CPUCLK
`
`
`in
`
`
`CPUCLK is driven by a clock driver. CPUCLK is in for core logic,
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`VUMA device and synchronous DRAM.
`
`
`
`
`
`
`
`
`2.3 Fast Page Mode, EDO and BEDO DRAMs
`
`RAS#
`
`CASln:0]#
`
`. WE#
`
`. 0E#
`
`i.
`
`iii Page 7 of 38
`
`
`s/t/s
`
`
`sIt/s
`
`s/t/s
`
`
`
`
`
`
`
`
`
`
`
`
`
`Active low row address strobe for memory banks. Core logic will
`
`
`
`
`
`
`
`
`have multiple RAS#s to support multiple banks. VUMA device
`
`
`
`
`
`
`
`
`
`
`could have a single RAS# or multiple RAS#s. These signals are
`
`
`
`
`
`
`
`
`
`
`shared by core logic and VUMA device. They are driven by
`
`
`ctn'rent bus master.
`‘
`
`
`
`
`
`
`
`
`
`
`
`Active low column address strobes, one for each byte lane. In case
`
`
`
`
`
`
`
`
`
`
`
`of pendurn-class sySt‘ems n is 7. These signals are shared by core
`
`
`
`
`
`
`
`
`
`
`logic and VUMA device. They are driven bycurrent bus master.
`
`
`
`
`
`
`
`
`
`
`
`
`s/t/s j Active low write enable. This signal is shared by core logic and
`
`
`
`
`
`
`
`VUMA‘ device. it is driven by current bus master.‘ '
`
`
`
`
`
`
`
`
`
`
`ActiVe low output enable. This signal exists only on EDO and
`
`
`
`
`
`
`
`
`
`
`“ BEDO. This signal is shared by core logic and VUMA device.
`
`7
`
`‘
`
`.
`
`‘ Version. 1.0p.lRev. 0.4p
`
`
`
`
`,
`
`Page 7 of 38
`
`

`

`VUMA. Proposed s:
`
`
`
`
`iard
`
`.
`
`‘VESA Confidential
`
`
`
`mum;
`
`alt/s
`
`
`
`
`MDIn:O]
`
`
`t/s
`
`
`
`
`
`
`
`. It13 driven by current bus master.
`Multiplexed memory address. These signals are shredby core
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`logic and VUMA device. They are driven by ctnrmt bus master.
`
`
`
`
`
`
`
`
`Bi-directional memory data bus. In case of pentium-class systems
`
`
`
`
`
`
`
`
`
`
`
`
`11 is 63. These signals are shared by core logic and VUMA device
`
`
`
`
`
`
`They are driven by current bus master..
`
`
`
`, 2.4 Synchmnous DRAM ,
`
`
`: CPUCLK
`
`
`
`
`cm:
`
`
`sit/s
`
`
`" icsa
`
`
`s/tls
`
`
`RAS#
`
`
`. CAS#
`
`
`was
`
`§MA111:01
`
`
`
`:DQMlnzfl]
`
`
`s/tls
`
`s/t/s
`
`
`
`
`s/t/s
`
`
`s/t/s
`
`out
`
`
`l MDln:0]
`
`
`
`t/s
`
`
`
`
`
`
`
`
`
`
`
`CPUCLKisthemasterclockinput(referredtoasCLKin'
`
`
`
`
`
`
`
`
`synchronous DRAM data books). All DRAM input/ outputsignals
`
`
`
`
`
`
`' arereferencedtotheCPUCLKnsmg edge
`
`
`
`
`
`
`
`
`
`
`
`CKE determines validity of the next CPUCLK. IfCKEis high, the .
`
`
`
`
`
`
`
`
`
`
`next CPUCLK-rising edge is valid; otherwise it is invalid. This
`
`
`
`
`
`
`
`
`
`
`signal also plays role in entering power down mode and refi'esh
`
`
`
`
`
`
`
`
`
`
`‘ modes. This signal is shared by core logic and ,VUMAdevice.
`
`
`
`
`
`It is driven by current bus master.
`
`
`
`
`
`
`
`
`
`
`
`
`CS# low starts the command inputgcycle. CS# is used to select a
`
`
`
`
`
`
`
`
`
`bank of Synchronous DRAM. Core logic will have multiple CS#s
`
`
`
`
`
`
`
`
`
`to support multiple banks. VUMA device could have a single
`
`
`
`
`
`
`
`
`
`
`
`CS# or multiple CS#s. These signals are shared by core logic and
`
`
`
`
`
`
`
`
`VUMA device. They are driven by sin-rent bus master.
`
`
`
`
`
`
`
`
`
`
`
`Active low row address strobe. This signalLS shared by core logic
`
`
`
`
`
`
`
`
`
`and VUMA device. Itis driven by current bus master.
`
`
`
`
`
`
`
`
`
`
`Active low column address strobe This Signalis shared by core
`
`
`
`
`
`
`
`
`
`
`logic and VUMA device. Itis driven by current bus master.
`
`
`
`
`
`
`
`
`
`
`
`Activelow write enable. This signal is shared by core logic and
`
`
`
`
`
`
`
`
`VUMA device. It'is driven by current bus master.
`
`
`
`
`
`
`
`
`Multiplexed memory address. These signals are shared by core
`
`
`
`
`
`
`
`
`
`
`‘ logic and VUMA device. They are driven by current bus master.
`
`
`
`
`
`
`
`
`
`
`
`I/O bufi'er control signals, one for each byte lane. In case of
`
`
`
`
`
`
`
`
`
`
`pentium-class systems 11 is 7. In read mode they control the output
`
`
`
`
`
`
`
`
`
`buffers like a conventional 01?.# pin. In write mode, they control
`
`
`
`
`
`
`
`
`
`
`
`the word mask. These signals are shared by core logic and VUMA
`
`
`
`
`
`
`
`.device. They are driven by current bus master.
`
`
`
`
`
`
`
`
`Bidirectional memory data bus. in caseof penfium-class wstems
`
`
`
`
`
`
`
`
`
`
`
`
`n is63.These signals are shared by core logic and VUMA device.
`
`
`
`
`
`
`They are driven by current bus master. ‘
`‘
`
`M h
`
`3.0 Physical‘lnterface
`
`
`
`Page 8 of 38
`
`3
`
`
`
`
`Version. 1.0p. Rev. 0.4;:
`
`Page 8 of 38
`
`

`

`
`
`VUMA Proposed Stands .
`
`
`
`
`I
`
`28A Confidential
`
`
`
`
`
`
`‘3. 1 Physical System Memory Sharing
`
`
`
`
`
`
`
`
`
`Figure 3-1 depicts the VUMA Block Diagram. Core logic and VUMA device are
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`. physically connected to the same DRAM pins. Since they share a common resource, they
`
`
`
`
`
`
`
`
`
`
`
`need to arbitrate for1t. PCI/VL/ISA external masters also need to access the same DRAM '
`
`
`
`
`
`
`
`
`
`
`
`
`resource. Cdre logic incorporates the arbiter and takes care of arbitration amongst various
`
`
`
`contenders.
`‘
`
`
`Figure 3-1"VUMA Buick Diagram ‘
`
`
`
`
`
`
`Host Addr 5: CM!
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Host Data Bus
`
`
`Physical
`System
`”GWEN
`(DRAM)
`
`
`
`
`.'
`(31111011.! A1111
`
`VUMAMumory
`
`
`
`
`
`Memory Data Bus
`
`-
`
`d
`
`‘As shownin Figure 3-1, V'UMA device arbitrates with core logic for access to the shared.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`physical system memory through a three signal arbitration scheme viz. MREQIS, MGNT#
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`[and CPUCLK. 14121301118 asignal driven by VUMA device to core logic and Moms15
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`a signal driven by the core logic to VUMA device. MR.EQ# and MGNT'# are active low '
`:iinsignais driven andsarnpled synchronous to CPUCLK common to both core logic and
`
`
`
`
`
`
`
`
`
`
`
`
`
`WW device1
`1
`'Core logic is always the default owner'and OWnership will be transferred to VUMA
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`' device upon demand. VUMA device could return ownership to core logic upon
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`‘ completion ofits activities or park on the bus. Core logic can always preempt VU'MA
`
`
`
`device from the bus.
`
`Page 9 of 38
`
`9
`
`
`
`
`Version. 1.0p, Rev. 0.41:)
`
`Page 9 of 38
`
`

`

`
`
`'VUMAIProposed st" lard
`
`
`
`
`'
`
`
`VESA Confidential
`
`.
`
`.
`
`‘
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`’ VUMA device needs to access the physical system memory for difi'crent reasons and the
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`1 level of urgency ofthe needed accesses varies. lfVUMA device15 given the access to the
`
`
`
`
`
`
`
`
`
`
`
`
`% physical system memory right away, every time it needs, the CPU performance will
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`suffer andas it may not be needed right away by the VUMA device, there would not be
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`. any improvement in VUMA device performance. Hence two levels of priority are defined
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`‘ viz. low priority and high priority Both priorities are conveyed to core logic through a
`
`
`single signal,MREQ#.1
`
`‘ 3.2 Memory-Regions
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`As shown in Figure 3-1, physical system memory can contain two separate physical
`
`
`
`
`
`
`
`
`
`
`
`. memory blocks, Main VUMA Memory and Auxiliary (Aux) VUMA Memory. As cache _
`
`
`
`
`
`
`
`
`
`
`
`
`‘ coherency for Main VUMA Memory. and Auxiliary VUMA Memory is handled by this
`
`
`
`
`
`
`
`
`
`
`
`
`standard, a VUMA device can access these two physical memory blocks without any
`
`
`
`
`
`
`
`
`
`
`
`. separate cache coherency considerations. Ifa VUMA device needs to access other regions
`
`
`
`
`
`
`
`
`
`
`
`of physical system memory, designers need to take care of cache coherency.
`
`-
`
`-
`
`
`
`
`
`
`
`
`
`
`
`
`Main VUMA Memory is programmed as non-cacheablc region to avoid cache coherency '
`
`
`
`
`
`
`
`
`
`
`
`
`
`overhead. How Main VUMA Memory15 used depends on the type of VUMA device;
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`e.g., when VUMA devicets a graphics controller, main VUMA memory will be used for
`
`Frame buffer.
`
`.
`
`.
`
`‘
`
`
`
`
`
`
`
`
`
`
`
`
`
`Auxiliary VUMA, Memory is optional for both core logic and VUMA device. If
`
`
`
`
`
`
`
`
`
`
`supported,
`it can be programmed as non-cacheable region or write-through region.
`
`
`
`
`
`
`
`
`
`
`
`
`
`Auxiliary VUMA Memory can be used to pass data between core logic and VUMA
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`- device without copying it to Main VUMA- Memory or passing through a slower PCI bus.
`
`
`
`
`
`
`
`
`
`
`This capability Would have significant advantages for more advanced devices. How
`
`
`
`
`
`
`
`
`
`
`
`Auxiliary VUMA Memory is used depends on the type of VUMA device e.g. when
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`. VUMA device'151 a3D graphics controller, Auxiliary VUMA memory will be used for
`
`texture mapping.
`
`“ When core logic programs Auxiliziry 'VUMA Memory area as non—cacheablc, VUMA
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`device can read from or write to it. When core logic programs Auxiliary VUMA Memory
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`area as write through, VUMA device can read from it but can not write to it.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Both core logic and VUMA device have an option of either supporting or not supporting
`
`
`
`
`
`
`
`
`
`
`the Auxiliary VUMA Memory feature. Whether Auxiliary VUMA memory is supported
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`or not should be transparent to an application. The following algorithm explains how it is
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`made transparent. The algorithm is only included to explain the feature. Refer to the latest
`
`
`
`
`
`
`
`
`
`VUMA VESA BIOS Extensions for the most updated BIOS calls:
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`31. When an application needs this feature, it needs to make a BIOS call, <Report VUMA
`
`Page 10 of 38
`
`10
`
`I
`
`
`
`
`Version. 1.013. Rev. 0.4p
`
`.
`
`.
`
`_
`
`Page 10 of 38
`
`

`

`
`
`VEIUMA Proposed Stands ,
`
`
`
`'
`
`'
`
`SSA Confidential
`
`
`-;
`
`
`
`- core logic capabilities (refer to VUMA VESA 1310s Extensions», to-find out 1: core
`
`
`
`
`
`
`
`
`
`
`
`
`
`logic supports the feature.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`2. If core logic does not support the feature, the application needs to use some alternate
`method.
`3. Ifcore logic supports the feature, the application can probably use it and should do the
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`following:
`'
`
`a. Request the operating system fora physically contiguous block of memory of required -
`
`
`
`
`
`
`
`
`
`
`
`
`size:
`b. Ifnot successfultn getting physically contiguous block ofmemory ofrequired size, use
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`some alternate method.
`c. If successful, get the start address ofthe block ofmemory.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`to
`:1. Read <VUMA BIOS signature string (refer to VUMA VESA BIOS Extensions)>,
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`find out if VUMA device can access the bank1n which Auxiliary VUMA Memory has
`‘
`
`been assigned.
`.
`e. If VUMA device can not access that bank, the application needs to either retry the
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`procedure from “step a” to “step c” till it can get Auxiliary VUMA Memory in a
`I
`
`
`
`
`
`
`
`
`! VUMA device accessible bank or use some alternate method.
`" . f If VUMA device can access that bank, make a BIOS call function <Set (Request)
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`VUMA Auxiliary memory (refer to VUMA VESA BIOS Extensions», to ask core 4
`
`
`
`
`
`
`
`
`
`
`
`
`
`logic to flush Auxiliary VUMA Memory block of the needed size from the start
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`address from “step c” and change it to either non-cacheable or write through. How a
`
`
`
`
`
`
`
`
`
`core logic flushes cache for the block of memory and programs it as non-cacheable/
`
`
`
`
`write throughisimplementation specific.
`‘
`
`
`
`
`'g. Use VUMA Device Driver, to give VUMA device the Auxiliary VUMA Memory
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`parameters viz. size, start address from “step c” and whether the block should be non-
`
`
`
`cacheable or write through.
`‘
`
`1'
`
`E‘E‘E
`
`’
`
`E
`
`'
`
`‘
`
`1
`
`3.3 Physical Connection ‘
`
`
`
`
`
`
`
`
`
`
`
`A VUMA device can be cemented in two Ways:
`
`,
`
`,
`
`El VUMA device can only access one bank of physical system membry--VUMA device
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Eis connected to a single bank of physical system memory. In case of Fast Page Mode,
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`jEDO and BEDO VUMA device has a‘ Single RAS#. In case of Synchronous DRAM
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`VUMA device has a single CS#. Main VUMA memory resides in this memory bank. If ‘
`
`
`
`
`
`
`
`
`
`
`
`
`
`supported, Auxiliary VUMA Memory can only he used if it is assigned to this bank.
`
`E2.. VUMA device can access all of the physical system memory - VUMAdevice has as
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`many RAS# (for Fast Page Mode, BBQ and BEDO)/CS# (for Synchronous DRAM) lines
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`as core logic and is connected to all banks of the physical system memory. Both Main
`
`
`
`
`
`
`
`
`
`
`
`
`VUMA memory and Auxiliary VUMA Memory (if supported) can be assigned to any
`
`memory bank.
`-
`
`Page 11 of 38
`
`ll
`
`“
`
`
`
`
`Version. 110p, Rev. 0.4p
`
`Page 11 of 38
`
`

`

`
`
`
`VUMA Proposed se” and
`
`
`
`.
`
`
`vasn Confidential
`
`
`4.0 Arbitration
`
`
`
`4.1 Arbitration Protocol
`
`
`
`
`
`
`
`
`
`
`
`
`There are three signals establishing the arbitration protocol between core lch and
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`VUMA device. MREQ'# signal is driven by VUMA device to core logic to indicate it
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`needs to access the physical system memory bus. It also conveys the level of priority of
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`the request. MGNT#13 driven by core logic to VUMA device to indicate that it can
`
`
`
`
`
`
`
`
`
`
`
`access the physical system memory bus. Both MREQ# and MGNT# are driven
`
`
`synchronous to CPUCLK.
`..
`
`5As showntn Figure 4.1, loW'level priority is conveyed by driving MREQ# low, A high -
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`ilevel priority can only be generated by first generating a low priority request. As shown
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`in Figure 4-2 and Figure 4-3; a low levelipriority is converted to a high level priority by
`
`
`
`
`
`
`
`
`
`
`
`‘ driving MREQ# high for one CPUCLK clock and then driving it low.
`
`' Figure 4-1 Low Level Priority ,
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` [7
`
`cpucm
`MREO’
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`',4°2 Arbiter
`
`The arbiter, housed in core logic, needs to understand the arbitration protocol. State
`
`
`
`
`
`
`
`
`
`
`
`
`
`_12
`
`
`
`
`Version. 1.0;). Rev. 0.4p
`
`‘ Page 12 of 38
`
`Page 12 of 38
`
`

`

`
`
`r
`
`.
`
`VUMA Proposed Siam.
`
`
`
`
`.d
`
`.
`
`)ESA Confidential
`
`
`'1 Machine for the arbiter is depicted in Figure 4.4. As shown in'Figure 4.4, the arbiter State
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`,Machine is ruched with PCI__Reset. Explanation of the arbiter is as follows:
`
`1. HOST State- The physical system memory busrs with core logic and no bus request
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`from VUMA device'rs pending.
`’
`' 2. Low Priority Request (LPR) State - The physical system memory bus is with core logic
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`and a low priority bus request firm: the VUMA device ispending.
`'
`.
`
`‘
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`5 3. High Priority Request (HPR) State- The physical $316!!! memory bus is with core
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`logic and a pending lowpriority bus request has turned into a pending high priority
`
`bus request.
`.
`‘
`.
`' 4. Granted (GNTD) State-Corelogichas relinquished the physical systemmemory bus
`
`
`
`
`
`‘
`to VUMA device.
`.
`5. Preempt (PRMT) State- The physical system memory bus isowned by VUMA device,
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`however, eOre logic has requested VUMA device to relinquish the bus and that request
`
`is pending
`
`i '
`
`“i“
`
`‘
`
`'
`
`
`
`
`
`Figure 4.4 Arbiter State Machine
`
`
`PCLRSW
`
`
`
`
`
`
`
`
`
`
`
`
`
`‘ MREQtt=r
`
`
`
`
`
`
`
`" Note:
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`1. Only the conditions which will cause a transition from one state to another have been
`
`,
`
`Page 13 of 38
`
`13
`
`‘
`
`
`
`
`Version. 1.0;), Rev. 0.4p
`
`Page 13 of 38
`
`

`

`EVUMA Proposed St:
`
`
`
`
`‘ ard
`
`'
`
`
`VESA Confidential
`
`
`
`
`
`
`
`
`
`
`
`
`noted. Any Other condition will keep the state machine in the current state.
`
`
`
`4.2.1 Arbitration Rules ‘
`
`'
`
`'
`
`
`
`
`
`
`
`
`
`
`
`
`1 l. VUMA device. asserts MREQ# to generate a low priority request and keeps it asserted
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`until the VUMA device obtains ownership of the physical system memory bus through
`
`
`
`
`
`
`
`
`
`
`
`
`
`the assertion of MGNT#,unless the VUMA device wants to either raise a high priority -
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`request or raise the priority of an already pending low priority request. In the later
`case,
`
`a. If MGNT# is sampled asserted the VUMA device twill not deassert Manors.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Instead, the VUMA device will gain physical system memory bus ownership and
`
`
`
`
`
`
`
`
`
`
`
`maintainMREQ# asserted until it wants to relinquish the physical system memory_
`
`bus.
`
`1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`5 b. If MGNT# is sampled deasserted, the VUMA device will deassert MRBQ# for one
`
`
`
`
`
`
`
`
`
`clock and assert it again irrespective of status of MGNT#. After reassertion, the
`
`
`
`
`
`
`
`
`
`
`
`
`
`VUMA device will keep MREQ# asserted until physical system memory bus
`
`
`
`
`
`
`
`
`
`
`
`ownership is transferred to the VUMA device through assertion of MGNT# signal.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`32. VUMA device may assert MREQ# only for the purpose of accessing the unified
`
`
`
`
`
`
`
`
`
`
`‘ memory area. Once asserted, MR.EQ# should not be deasserted before MGNT#
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`assertion for any reason other than raising the priority of the request (i.e., low to high).
`
`
`
`
`
`
`
`
`
`
`
`
`. No Speculative request and request abortion is permitted. If MR.EQ# is deasse‘rted to
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`raise the priority, it should be reasserted in the next clock and kept- asserted until
`
`
`
`: MGNT# is sautpled asserted.
`‘
`
`tu'. Once MGNT#is sampled asserted by VUMA device, it gains and retains physical
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`system memory bus ownership until MREQ#'lS deasserted.
`
`'
`
`
`
`
`
`
`
`
`
`
`
`
`4. The condition, VUMA device completing its required transactions before core logic
`
`
`
`
`
`
`
`
`
`
`
`
`needing the physical system memory bus back, can be handled in two ways:
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`a. VUMA device can deassert MREQ#. In response, MGNT# will be deasserted in the
`
`
`
`
`
`
`
`
`
`
`
`
`next clock edge to change physical system memory bus ownership back to core
`logic '
`b. VUMA device can park on the physicalsystem memory bus. If core logic needs the '
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`physical system memory has it should preempt VUMA device.
`
`5. In case core logic needs the physical system memory bus before VUMA device
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`releases it on its own, arbiter can preempt VUMA device from the bus. Preemption is
`.
`
`
`
`
`
`
`
`
`
`
`signaled to VUMA device by deasserting MGNT#. VUMA device can retain
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`ownership of the bus for a maximum of 60 CPUCLK clocks after it has been signaled
`
`14
`
`
`
`
`Version. 1.0p. Rev. 0.4p
`
`Page 14 of 38
`
`
`
`Page 14 of 38
`
`

`

`
`
`
`VUMA Proposed Stancard
`
`t
`
`,
`
`"
`
`
`
`WESA Confidential
`
`to preempt. VUMA device signals release of the physical system memory bus by
`
`
`
`
`
`
`
`
`
`
`
`
`
`deasserting MREQ#.
`~
`‘
`
`6. When VIMA‘dc-vice deasserts MREQ# to transfer busy ownershipback to core logic,
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`either on its‘ “own or because (if a