.
`
`i‘VESA® 1
`
`-
`(Draft)
`"Video Electronics Standards Association
`2156 North First Street. Suite 440
`San Jose. CA9S131-2029 .
`
`VUMA Proposal
`
`I
`
`Pilone: [1108] 435-0333
`FAX: €408} 435-8225
`
`-VESA Unified Memory Architecture
`Hardware Specifications Proposal
`Version: 1.0]:
`Document Revision: 0.49
`October 31, 1995
`'
`Important Notice: This is :1 draft document front the Video Electronics Standards
`Association (VESA) Unified Mory Architecture Committee (VUMAJ.
`It is only for
`discussion purposes within the committee and with any other persons or organizations
`thatthe cornrnittee has deter-rnined should be invited to review or otherwise connjbrrre to
`_it.
`It has not been presented or ratified by the VESA general membership.
`
`Purpose
`
`logic elripset and VUMA device
`"To enable
`supporting the Unified Memory
`
`to design VUMA devices
`-
`.
`
`_
`
`Surnrriary
`
`it
`devices’ hardware interface.
`-_ This docurneni lcontnins a specification for
`includes logical and electrical interface specifications. The BIOS protocol is described in '
`VESA document VUMA VESA BIOS Extensions (VUMA-SEE} rev. 1.0.
`
`Page 1 of 38
`
`
`
`Petitioners HTC & LG - Exhibit 1025, p. 1
`
`Petitioners HTC & LG - Exhibit 1025, p. 1
`
`

`
`: VUMA Proposed E I."-.dard
`
`'
`
`. H
`
`VESA Confidential
`
`_ Scope
`
`Because this is a draft document. it cannot be considered complete or accurate in all
`' "respects although every efibrt Em been made to
`errors.
`
`Intellectual - Property
`
`' 0 Copyright 1995 - Video Elecn-onics Standards fitssociafion. Duplication of this -
`' document within VESA. member companies for review purposes is permitted All other
`rightsnrcresenred.
`'
`
`Trademarks
`
`All trademarks used in this document are the property of their respectitite owners. _VESA.
`and VUMA are uudexnarks owned by the Video Electronics Standards Association.
`
`E
`
`Patents _
`
`, The proposals and standards-de_veloped and adopted by VESA are intended tcvpromote
`: uniformity and economies of scale‘ in the video electronics industry. VESA strives for
`standards that will benefit both the industry and end users of Video electronics products.-
`VESA cannotcnsnre that the adoption ofa standard; the_u,se ofa method describ_ed as a
`standard: orthe making, using, or selling of a product in compliance with theystandatd
`does not infringe upon the intellectual property rights (including patents, . and
`copyrights") of others. VESA, therefore; makes no warranties, expressed or implied, that
`products conforming to a VESA standard do not infi-inge on the i.ntellec1.'ual "property
`tights of others. and accepts no liability direct, indirect or consequential, for any such
`infringement.
`-
`'
`
`Page 2 of 33 M
`
`2
`
`Version. 1.09. Rev. 0.4;:
`
`. -.- ....--.._..-..
`
`Petitioners HTC & LG - Exhibit 1025, p. 2
`
`Petitioners HTC & LG - Exhibit 1025, p. 2
`
`

`
`VUMA_Proposod sume-.d
`
`JESA confidentlai
`
`‘Support For This Specification
`
`If you have a product that incorporates VUMAT”. Y0‘-I 5h°“1d 351‘ 15¢ comp‘!!! that
`'1-na:1ufaJ:tu.n:d your product for assistance.
`If you are a manufacturer of the product,
`VESA can assist_ you with any clarificafion that you may require. All questions must be
`sent in writing to VESA via:
`'
`
`Z (The following list is the preferred order for contacting VESA-3
`
`VESA World Wide Web Page: www.ve.ra.org
`Fax:
`(403) 435-8225
`Mail:
`VESA
`2150 Noni: First Street
`Suite 440
`'
`San Jose. California 95131-2029
`
`'
`
`'
`
`'
`
`- Acknowledgmai1ts__ _
`
`This document would not. have been possible without the ciforts of the members of the
`I995 VESA Unified Memory
`.-
`Architecture Committee and the professional suppon of the
`- VESA staff.
`
`'
`
`Work Group Members
`
`Any industry standard requires inforrnation from many sourocs. The following list
`recognizes members of the VUMA Committee, which was responsible for pombining all
`of the industry input into this proposal.
`
`Chairperson
`Rajesh Shaldtarwar
`
`Members
`Jonathan Clarnan
`
`Jim Iirgal
`Don Pamell
`Wallace Kou
`Derek Johnson
`Andy Daniel
`Long Nguyen
`Robert Tsay
`Sunil El-maria
`Perer Chang
`;Alsr1 Mormann
`§So|omon Alemayehu
`-|La.rry Alchesky
`Dean Hays
`
`Page 3 of 38
`
`.
`
`_
`
`DPTi
`
`I
`83
`
`VLSI Technology Inc.
`Siam Semiconductor
`Western Dlgiml
`Cypress
`Alliance Semiconductor
`Oak Technology
`Pacific Micro Computing 111:.
`Mentor Arc
`Samsung
`Micron
`Hitachi America Ltd.
`Mitsubishi
`Weirek
`
`3
`
`Version. 1.(lp. Rev. 0.4::
`
`Petitioners HTC & LG — Exhibit 1025, p. 3
`
`Petitioners HTC & LG - Exhibit 1025, p. 3
`
`

`
`?vun.1A Proposod so
`
`‘ard
`
`VESA Conflclontial
`
`Revision History
`
`man Rovision o.1p .
`
`.
`Revision 0.21:
`Added sync DRAM suppoit
`Electrical Section
`'
`
`_
`Boot Protocol
`Rofonnaltod-document
`
`-
`
`Sept 21 '95
`
`0!?! 5 '95
`
`'
`
`Revision 0.31:
`Gm.phic3oont:oflcrreplacodu'i1hVUMAdevicc '
`MD[n:0] chmodto t!s'
`_
`.
`-
`Modified Aim Manon: dosu-iption
`Added third solution to Memory Expansion Problem
`Synch DRAM bum length changed to 2'4
`Modified all the bus hand ofldiaglnms
`Added DRAM Driver Charactelistics section
`
`.
`
`Oct 19 ‘95
`
`*
`
`Revision 0.41:
`Sync DRAM Burst Lcngth changed to 1:214
`DRAM controller pin multiplexing added -
`Changed AC timing promoters
`
`Oct 19 ‘95
`
`‘
`
`Version. 1.Up. Rev. 0.4p
`
`Petitioners HTC & LG - Exhibit 1025, p. 4
`
`Petitioners HTC & LG - Exhibit 1025, p. 4
`
`

`
`QUMA Proposed Slandaml
`
`I
`
`"
`
`-"SA Ctinfidential
`
`TABLE OF CONTENTS
`
`
`
`
`
`' 1.0n~rmo'pUcrioN " I ' . '
`
`nun‘
`'
`7.?
`2.0 SIGNAL nE1fiNn'1oN..__._..
`------------------------7
`. 2.1 SIGNAL TYPEDEPDIFHON ........................................................
`2_2 Ap_an-mnon s1cm_u_.s._..........
`.........
`..............................................?
`2.3 FAST PAGE Mona, EDD ANDBEDO
`2.4 Svncimonous
`
`3.0 PHYSICAL mm1u=AcE.........
`
`
`
`....s
`
`3.1 Puvszcm. SYSTEM Mawgoav
`3.2 Mmoiw
`1 0
`3,3 P1.{y51cA1,1
` unu-n-nu-nuuu--u
`4.0 ARBITRATION
`
`4.1 Amarfmnow Pnorocm...............................................................
`.._............... 12
`
`
`4.2 Aruarran
`4.3 AR.BITR.ATION
`
`4.4
`5.0 MEMORY INTERFACE
`
`
`
`
`5.1 Manon? Dacona
`5.2 MAIN VUMA Mmoav
`. 5.3 FAST PAGE EDO mun BEDO
`5.4 SYNC!-IRONOUS
`5.5 MEMORY PARJTY surroxr
`5.6 MEMORY CONTROLLER Pm MULTIPLEXING
`0.0 BOOT P1iorocoL.....,............_;_..........................................._..32
`
`
`
`..2
`
`6.1 mm VUMA MEMORY Access A?acm
`6.2 R5551"
`7.0 ELECTRICAL SPECI1i'ICATION........._..................._.....__.......35
`
`7.1 SIGNALLEVELS
`7.2 AC
`.
`
`
`
`7.4STRAPS
`7.5 DRAMDRIVER
`
`Page 5 of 38
`
`5
`
`Version. ‘Lop. Rev. 0.4p
`
`Petitioners HTC & LG — Exhibit 1025, p. 5
`
`Petitioners HTC & LG - Exhibit 1025, p. 5
`
`

`
`ivumn-pmpma so “are -
`
`-
`
`. VESA-Confidential
`
`1.o Introduction
`
`1
`
`.
`
`. The concept of-V.'ESA. Unified Memory Architecture (VUMA) is to share physical system
`' memory (DRAM) between system and an externni device, a VUMA device; as shown in
`Figure 1-1. A VUMA device‘couid be any type. of controller which needs to share
`physical system mcm,o:'y'('DR_AM] with system and directly access it. One example of a
`VUMA device is grapiiics controller. In a VUMA system, graphics controller will
`incorporate graphics frame hufiier in physical system memory (DRAM) or in other words
`VUMA device will use a part of physical system memory as its frame buffer. thus,
`sharing it with system and directly accessing it This will eliminate the need for sepamtc
`graphics memory. resulting in cost savings. Memory sharing is achieved by physically
`"connecting core logic chipeet {hereafier referred to as core logic) and VUMA device to
`the same physical system memory DRAM pins. Though the current version covers
`-shadng of physical system memory only between core logic and a motherboard VUMA
`device, the next veision 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 through.theexpansion connector.
`'
`.
`
`_
`
`the discussion‘ in the
`"Though a VUMA device could be any type of controller,
`specifications emphasizes a graphics controller as it will be the first VUMA system
`impiementaiion;
`
`Figure 1-1 VUMA System Block Diagram
`
`Pclaus
`
`
`
`Physical
`Systemhl
`(DRAW
`
`2.!) Signal Dofiniiion
`
`Page 6 of 38
`
`5
`
`Version. ‘Lop. Rev. 0.4ip
`
`Petiti0ners'HTC & LG — Exhibit 1025, p. 6
`
`Petitioners HTC & LG - Exhibit 1025, p. 6
`
`

`
`IVUMA Proposed Startdai
`
`2.‘! Signal Type Definition
`
`in
`
`Input is a. standard input-only signal.
`
`out
`
`Totern Pole Output is a___standa.rd active driver
`
`Confidential
`
`slut
`
`Tri-State is s bi-directional, 1ri—state ioputfoutput pin.
`Sustained rri-suite is an active low or active high tri-state signal owned and
`driven by one and only one agent at at time. The agent that drive: an skis pin
`active must drive it high for at least one clock before letting it floet._A ptillup is
`requinrd to sustain the high am: until another agent drives it. Either internal or
`extemnl pullup _ntu_st be provided by core logic. A VUMA device can also
`optionally provide an internal or external ptlllup.
`
`2.2 Anlu'tration Signals
`
`M.REQ#
`'
`
`MGNT#
`
`in
`out
`
`in
`out
`
`MREQ# is out for VUMA device and in for core logic. This".
`signal is used by VUMA device to inform core logic that it
`needs to access shared physical system memory bus.
`
`MGNT# is Outforcore logic and in for vuiwt device. This
`signal is used by core logic to inform VUMA device thstit can
`itccessshared physical system memory bus.
`
`ICPUCLK
`
`in
`
`CPUCLK is driven by a clock driver. CPUCLK is in for core logic,
`VUMA device and synchronous DRAM.
`
`’
`
`I‘
`
`2.3 Fast Page Mode, E00 and BEDO DRAM:
`
`RAS#
`
`sltfs Active low row address strobe for memory banks. Core logic will
`hsve 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 V'U'MA device. They are driven by
`current bus master.
`
`_CAS[n:{l}#
`
`sltls
`
`,wE#'
`
`0E#
`
`sills
`
`slfls
`
`Active low coluntn address strobes, one for each byte lane. in case
`of pentiurn-class systems it is 7. These signals are shared by core
`logic and VUMA device. They are driven bycturcnt bus master.
`Active low write enable. This signal is shared by con: 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.
`
`ll.
`
`:.lfPage7of38
`
`7
`
`Version. ‘Lflp. Rev. 0.4::
`.
`_
`_
`____.
`.
`
`.
`
`..
`
`Petitioners HTC & LG - Exhibit 1025, p. 7
`
`Petitioners HTC & LG - Exhibit 1025, p. 7
`
`

`
`§VUl.'lA. Proposed st
`
`-larll
`
`VESA confidential
`
`‘
`= M.A{11:0]
`}
`:;1\v£DIn:0]
`-
`
`-
`'
`. Itisdr-ivenbyotnreanbusmaster.
`Iftis Multiplexed memory address. These signals are shared by
`1ogicandVUMAdevice.Theymedrivenbycunen1lrusmsste:.
`Bi-directional memory data bus. In case ofperrtiurn-class systems
`nis63.'I'hesesignalsaresharedbycorelogicandVUMAdevice.
`They are drivcnbycurrentbustnustetz.
`
`ifs
`
`. 2.4 Synchronous DRAM ,
`
`:CPUCLK
`
`'
`
`CKE
`
`fl
`
`.
`- CS#
`
`RAS#
`
`C.-!tS#
`
`WE#
`
`-
`
`-
`
`Q MA[1l:{l]
`'
`j DQM{n:ll]
`3
`
`.
`
`MD[n:0]
`.
`
`in
`
`-
`
`CPUCLKisthen:asterclockinput(referredtossCLKin
`synchronous DRAM dale books). All
`input! outputlsignnls
`are referenced to the CPUCLKrising edge.
`'
`sitls CICEdetern:inesvalidityofthenextCPUCLK.IfCI{Eishigh,the‘
`next CPUCLK-rising edge is valid; othwwise itis invalid. This
`signal also plays role in entering power down mode and refiesh
`‘modes. This goal is shared lsyoore logic
`It is driven by current bus master.
`CS# low starts the comrnamd input-cycle. 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 9} single
`CS# or multiple CS#s. These signals are shared by core logic and
`VUMAdevice. Theyaredriven byotrrentbtzsmaster.
`sftfs Active low row address strobe. This signal is shared by cote logic‘
`and VUMAdevioe. ltisclrivenby c1.u'rentbusn1sste_r'.
`this Active low column address strobe. This signal is shared by core
`logic and VUMA device. it is driven by current bus master.
`sltfs Active low mite enable. This signal is shared by core logic and
`VUlvl.Adevice.Itisfiv-enbycttrrentbusmsster.
`sftfs Multiplexed memory address. These signals are shared by core
`:
`logic and VUMA device. They are driven by current bus master.
`sit}: U0 bufier control signals, one for each byte lane. In case of
`pentiun:-class systems :1 is 7. In read made they control the output
`.bufi'ers like a conventional OE# pin. In write mode, they control
`thewordn1ask.ThesesignalssresharedbycorelogicandVUMA.
`device. They are driven by current bus master.
`-
`.
`Bi~direetionsl memory data bus. in case ofpentitun-class systems.
`nis63.Tl1esesignalssreshsredbycorelogicaudVUMAdevice.
`They-are driven by current bus master.
`'
`
`sftls
`
`tfs
`
`-
`
`_
`
`I.
`
`_:
`
`3.0 Physical Interface
`
`Page 8 of :i8
`
`3
`
`Version. 1.0:). Rev. 0.4p
`
`Petitioners HTC & LG - Exhibit 1025, p. 8
`
`Petitioners HTC & LG - Exhibit 1025, p. 8
`
`

`
`VUMA Proposed Stand;
`
`.
`
`I 355 Cflflfiflfififiii
`
`‘3. 1 Physfceisystam Memory Sharing
`
`'
`
`«
`
`Figure 3-1 depicts the mm Block Diag1'a.m. Core logic and ‘vow. device are
`. ‘by.-fically connected to the same DRAM pins. Since they share a common resolute. lhc3'_
`need to arbitrate "for it. PCIIVUISA extemal masters nlsoneed to access the Sim‘: DRAM
`1'-gggm-cg, Cd;-e logicineorporazes the arbitex and taken care of ubiuafion amongst various
`contenders.
`
`Figure 3-1 VUMA mock Diagram:
`
`'
`
`Memory eat: am
`
`to the shared
`device arbitmies with core logic
`"As shown in Figure 3-1,
`physical system memory through a three signal arbitration scheme viz. MREQHH, MGN'i‘#
`and CPUCLIL M‘.REQ# is _a signal clriveti by VUMA device to core logic and MGN'1'# is
`-a signal driven by the core logic to VUMA device. MREQ# and MGNT# are active low
`_
`'si_gn.a1s driven ancisampled synchmnous to CPUCLK common to both core logic and
`5
`device.
`'
`-
`
`.
`
`'
`
`I
`
`.':'C'ore logic is always the default ownerand ownership will be transferred to VUMA
`' device upon demand. VUMA device could return ownership to core logic upon
`completion of its activities or park on the bus. Core logic can always preempt VUMA
`device Erorn the bus.
`-
`I
`'
`
`Page 9 of 38
`
`9
`
`Version. 1.0p, Rev. 0.4;)
`
`Petitioners HTC & LG - Exhibit 1025, p. 9
`
`Petitioners HTC & LG - Exhibit 1025, p. 9
`
`

`
`Z VtJMA.Propoaed St N
`
`lard
`
`I
`
`VESA Confidential
`
`'VUMAdeviceneedsmmcessfliephysimJs3emmmemmyfordiEu~mtreasmssndthe
`level ofurgencyoftheneededaccessesvaries. IfVU1vlAdeviceisgiventheaceesstothe
`§physicaIsystemmemoryfighzaway,eveiyfimehneedstheCPUpetfcrmnncewfll
`sufi'erend'a.sitmaynotheneededrightawayhytheVUMAdevioe,thercwouldnotbe
`. any improvernentinVUMAdevice performance. Hencetwolevels nfpri01'i1}' In defined
`oi; pow priority and high
`Both priorities are conveyed to core. logic through a
`single sigoa.I.MR.EQ#.
`'
`
`-
`
`' 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 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. It’: 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-cacheable region to avoid cache coherency‘
`overhead How Main VUMA Memory is med depends on the type of VUMA device;
`e.g., when VUMA device is a graphics controller. main VUMA memory will he used for
`Frame buffer.
`’
`.
`
`Auxiliary VUMA Memory is optional for both core logic and VUMA device. If
`supported,
`it can be programmed as non-cacheabie 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 it slower PCI bus.
`This capahility 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 is; a 3D graphics controller, Auxiliary 'VUl\-_1A memory will he used for
`texture mapping.
`"
`'
`
`v
`
`In
`
`- When core logic programs Auxilisry IVUMA Memory area as non-cacheahle. VUMA
`device can read from or write to it. When core logic programs Atociliary VUMA Memory
`area aswrite through,VUM.Adevice canread fiomitbtrtcannotwriteto 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" n-ansparent. -The algorithm is only included to explain the feature. Refer to the latest
`VUMA VESA BIOS Extensions for the most updated BIOS calls:
`
`_1. When an application needs this feature, it needs to make a BIOS call, <Report VUMA
`
`Pctge10 of 33
`
`I
`
`'
`
`13‘
`
`Version. ‘Lop, Rev. 0.4p
`
`-._'..-_.'.
`Petitioners HTC & LG - Exhibit 1025, p. 10
`
`Petitioners HTC & LG - Exhibit 1025, p. 10
`
`

`
`\l!LlP-‘IA Proposed Stands ,
`
`I
`
`-
`
`-
`
`.‘St_A Confidential
`
`- core logic capabilities (refer to VUMA VESA BIOS Exterisions)>, tevfind out if core
`'
`logic supports the feature.
`=
`2. if core logic does not support the feature, the application needs to use some altetnste
`method.
`-
`
`3. If core logic supports the feature. the application can probably use it and should do the
`'
`following:
`.-
`
`a. Request the operating system for} Pi-’0'5ically contiguous block of memory of required -
`
`b. If not successfitl in getting physically contiguous block ofmory of required size, use
`some alternate method.
`.
`.
`
`3'
`c. If successful. get the start address ofthe block of memory.
`to
`(1. Read <V'UMA BIOS signature string (refer to VUMA VESA BIOS Ex'tensions)>,
`findoutifVUMA device accessthe bank inwhichiittodliary VUMAMemoryltas
`been assigned.
`-
`.
`.
`4:. IfVUMAdevicecannotaccesstisatbank,theapplicationneedsto.eitherrenythe
`|
`procedure from _“stcp a“ to “step -c“ till it can get Auxiliary VUMA Memory in a
`' VUMA device accessible bank oruse some alternate method.
`-
`If VUMA device can access that bank, make a BIOS call function <Set (Request)
`VUMA Auxiliary memory {refer to VUMA VESA BIOS Extensiotis)>, to ask cote
`logic to flush Attxilisry VUMA Memory block of the needed size from the sun
`address from “step c"_a.nd change it to either zinc-ccciccabic or write through. How a
`core logic flushes cacheffor the block of my and programs it as non-cacheablef
`write through is"-implementation specific.
`'
`'
`_ g. Use VUMA Device Driver. to give VUMA device the.Auxilia.ry VUMA Memoxy
`parameters viz. size, start address from “step c" and whether the block should be non-
`cacheable or write through.
`'
`
`_
`
`'
`
`3.3 Physical Connection I
`
`A VUMA device can be connected in two ways:
`
`51. VUMA device can only access one bank of physical system memory - VUMA device
`is connected to a single bank of physical system memory. In case of Fast Page Mode.
`;ED(') and BEDO VUMA device has 3 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.
`
`'2. VUMA device can access all of the physical system memory - VUMA device has as
`many R.AS# {for Fast Page Mode, E130 and BEDO)!CS# (‘rcc Synchronous cum) lines
`as core logic and is connected to alt 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
`
`11
`
`'
`
`Version. 1.01:. Rev. 0.41:
`
`Petitioners HTC & LG — Exhibit 1025, p. 11
`
`Petitioners HTC & LG - Exhibit 1025, p. 11
`
`

`
`yum Proposed an ape!
`
`_
`
`vase confidential
`
`i4.D Arbitration
`
`-4.1 Arbitration Protocol
`
`There are three signals establishing the afiailration protocol between core logic and
`VUMAdevioe.MRBQ¥ai3nslisd1ivenbyVUMAdevioetoconlo§icmindica:eh
`needs to access the physical system mcxnory bus. It also conveys the level of priority of
`thercquesLMGNT#isdriva:hyeorelogictoVUMAdevicetoindica1ethat_itcan
`access the physical system memory has. Both MREQ# and MGNT# are ciziven
`synchronous to CPUCLK.
`'
`
`-As shown in Figure 4-1, low level priority is conveyed by driving MREQ# low. A high -
`flevelpriority canonly he generatedbyfirstguaeratingalowpzioritymquest. Asshown
`in Figure 4-2 and 1-figuge 4-3.": low leveipxiority is converted to a high level priority by
`;driving MREQ#highforoneCPUCLKcloekandthendn'vingit1ow.
`
` Figure4-lLowLevel Priority
`
`'
`
`'.
`
`'
`
`1'1
`
`' ' '
`
`II‘:
`
`is
`
`"
`
`'
`
`’
`
`is
`
`-
`
`-1'
`
`32
`
`»3
`
`S4
`
`C5
`
`I5
`
`.'1
`
`.'g
`
`.'g
`
`°""°'“"
`
`CPUCU‘
`
`* 4.2 Arbiter
`
`The arbiter, housed in core logic, needs to understand the arbitration protocol. State
`
`. Page 12 of 38
`
`|_
`
`Petitioners HTC & LG h-.‘]'3>,d-1iibit“.'1”(n)M_2“5, p. 12
`
`_ 12
`
`Version. 1.Dp. Rev. 0.45:
`
`Petitioners HTC & LG - Exhibit 1025, p. 12
`
`

`
`I vum Proposed sum.
`
`.d
`
`_
`
`IE$A corifldential
`
`1 Machine for the arbiter is depiexeei in Figure 4.4. As mm in‘Figure 4.4, the arbiter State
`, Machine is teamed with PCI__Reset. Explanation of the arbiter is as follows:
`
`Z 1. HOST State - The physical system morjr bus is with care logic and no bus request
`3
`from VUMA device is pending.
`
`I" 2.LowPfiafi:yReqnest(LPR)State-Ihephysicalsystemmemoqrbusiswizhenrelogie
`3
`andaiowprioriIybuneqi:eetfiumtbeVUMAdeviceis.pending.
`
`3. High Priority Reques: (I-IPR)Sta1e - The physiml system memory bus is.v_.-it_h core
`logieendapaading-lowpeioritybusteqizcsthastnnnedintoapendinghigh_priorit}'
`busrequest.
`.
`'
`:-
`
`4. Granted (GNTD) Slate _- Core logic has relinquished the physical systemmcmnry bus
`:6 VUMA device.
`-
`.
`'
`'
`
`I" "
`
`5. Peeemp: (PRMT) State - The physical system memory bus isowued by VUMA device,
`however,eore IogichasrequestedVUMAdevieetnre1inqniahthehusandtbat1eques:
`is pending.
`
`Figure 4.4 Arbiter State Machine
`
`pc1_ns'nu
`
`
`
`' Note:
`
`I. Only the conditions which will cause a transition from one state to another have been
`
`Page 13 of 38
`
`13
`
`Version. ‘Lop, Rev. {Mp ~
`
`Petitioners HTC & LG - Exhibit 1025, p. 13
`
`Petitioners HTC & LG - Exhibit 1025, p. 13
`
`

`
`§VUMA Proposed St:
`
`I nrd
`
`VES_A confidential
`
`noted. Any other condition willltcepthe state machine indie current state.
`
`4.2.1 Arbitration Rules
`
`'31.VUMAdevice.asserts MR._‘iQ#to generateslowpriority requestandkeeps it asserted
`ImfiltheVUMAdeviceobuinsmmershipofthcphysicalsynunmemoryhusthmugh
`theassertionofMGNT#,'tml'es3theVUMAtlevieewsntstoeitherl'aiseahigh'priot'ity -
`request or raisethe priority of an already pending low_pr-iority request. In the later
`case,
`'
`'
`'
`2
`
`a. if MGN'i'# is sampled asserted the VUMA device ‘win not desssert MREQ#.
`Instead, the VUMA device will gain physical system memory bus ownership and
`rnaintair:LMREQ# asserted until it wants to relinquish the physical system memory
`bus.
`
`in. If MGNT# is sampled densse-rted, the VUMA device will desssert MREQ# for one
`clock and assert it again irrespective of status of MGNT#. Alta‘ reassertion. the
`VUMA device will keep MIREQ# asserted until physical system mory bus
`ownership is transferred to the VUMA device through assertion ofMGNT# signal.
`
`. VUMA device may assert MRI-JQ# only for the purpose of accessing the‘ unified
`memory area. Once asserted, MR.EQ# should not be densserted before MGN'1"#
`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. lfMR.EQ# is deasserted to
`raise the priority.
`it should be reasserted in the next clock and kept asserted until
`MGNT# is sampled asserted.
`
`us"
`
`. Once MONT-# is sampled asserted by VUMA device, it gains and retains physical
`system memory has ownership until MZREQ# is deasserted.
`
`. The condition, VUMA device completing its required transactions before core logic
`needing the physical system memory bus back, can he 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.
`'
`-
`-
`.
`h. VUMA device can park on the physical-system memory bus. Ifcore logic needs the '
`physical system memory bus. it should preempt VUMA device.
`
`. In case core logic needs the physical system rnory bus before VUMA device
`releases it on its own, arbiter can preempt VUMA device fiom the bus. Preemption is
`stgnaled to VUMA device by deasserting MGNT#. VUMA device can retain
`ownership of the bus for _a maitimurn of 60 CPUCLK clocks after it has been signaled
`
`Version. 1.Dp. Rev. 0.4;:
`
`Page 14 of 33
`
`Petitioners HTC & LG - Exhibit 1025, p. 14
`
`Petitioners HTC & LG - Exhibit 1025, p. 14
`
`

`
`vuwt Proposed 5taru..'.rcl
`
`-
`
`Jase contra-ntiai
`
`to preempt VUMA device signals ‘release of the physical system mory has by
`dcasserting MREQ#.
`
`6. When VUMA device deasserts MIREQ# to transfer bus ownership [back to core logic,
`either on its ‘own or because of a preemption request.
`it should keep MR.EQ#
`deasserred forat least__tWo oiockzs of recovery time before asserting it again to raise a
`request.
`-
`'
`-
`
`4.3 Arbitration Examples
`
`1.. Low priority requestand immediate bus release to VUMA device-
`
`
`
`device with preemption I
`2. Low priority request and immediate bus release to
`where removal of MGNT# and removal of MR.EQ# coincide
`
`
`
`*“"""5"“
`
`3. Low priority request and immediate bus release to VUMA device with preemption
`where MREQ# is removed after the current transaction because of preemption
`
`Page 15 of 38
`
`15 _
`
`- Version. ‘1.Dp,Rev.Cr.4p
`
`Petitioners HTC & LG - Exhibit 1025, p. 15
`
`Petitioners HTC & LG - Exhibit 1025, p. 15
`
`

`
`\(E§A_confi&anflaI
`
`to \'rUMA° davice with
`5. High pun:-'i:y ngium ind inimedaaie bus’:-clan’:
`preemption where MGNT# and MREQ# nmoval coincides.
`
`' Page16of3B ’.
`
`15
`
`"
`
`'
`
`"
`
`Varsion._1.0p. Rev. 0.4;:
`
`*
`'
`‘
`"H
`Petitionerns HTC & LG — Exhibit 1025, p. 16
`
`Petitioners HTC & LG - Exhibit 1025, p. 16
`
`

`
`.VUM.A Proposed Starla
`
`.1
`
`.-‘ESA Confidential
`
`
`
`device with
`ind tuimediaie bus-release to
`7. High priority mines:
`preemption" where MZREQ# is removed after the current trulucfio be_o":use of
`preemption.
`‘
`
`'
`
`' 1!. High priority request undone clock delayed bus release to
`preemption where MIREQ# and MGNTH removal do not coincide
`
`device with
`
`Page 1? of 38
`
`'
`
`1'!
`
`Version. 1.0;). Rev. 0.4;:
`
`Petitioners HTC & LG - Exhibit 1025, p. 17
`
`Petitioners HTC & LG - Exhibit 1025, p. 17
`
`

`
`VUMA Proposed Sta
`
`ard
`
`.
`
`VESA -Cflflfidflflfill
`
`: 4.4 Lsrencies
`
`- I. High Priority Request - Worst case latency for VUMA=device to receive a grant after
`generating 3- high priority request is 35 CPUCLK clocks, i.e. after arbiter receives a
`high priority request from VUMA device, core logic does not need to relinquish the
`physical system memory bus right away and can keep the bus for up to 35 CPUCLK
`clocks.
`‘
`‘
`
`la) . Low Priority Request
`- No worst ccse latency number has been defined by this
`specification for
`low priority request. VUMA devices should incorporate some
`mechanism to avoid a low. priority request being sutrved for an mneasonshle time. The
`mechanism is implementation specific and not covered by the standard. 01:: simple
`reference solution is as follows:
`'
`'
`
`VUMA device incorporates a programmable timer. The timer value: is set at the boot
`time. The timer gets loaded when aiow priority request is generated. When the timer
`times out. the low priority request
`is converted to a high priority request.
`
`'
`
`_
`
`.
`
`-3. Preemption Request to vnM.at device‘ - Worst case. lntcncy for mm device to
`relinquish the physical system memory busafter receiving a preemption request is 60
`
`13
`
`Version. 1.Dp. Rev. 0.4;:
`
`Page 18 of 38
`
`Petitioners HTC & LG - Exhibit 1025, p. 18
`
`Petitioners HTC & LG - Exhibit 1025, p. 18
`
`

`
`HVUMA Proposed Stone
`
`.1
`
`..'E5A Cflfifidlfltifll
`
`the physical
`to
`CPUCLK. clocks, i.e. after corelogic requests VUMA
`system memory bus.VUMAdeviee doesnot needtorelmqmshthebusrightawayand
`can keep the bus for-up to 60 CPUCLK clocks.
`
`Design engineers should
`
`in to consideration the above latencies for deciding FIFO
`
`55.0 Memory Interface
`
`s
`
`The standard supports. Fast Page Mode, sno. BEDO_anr1 Synchronous DRAM
`technologies.
`‘
`-
`'
`--
`
`DRAM refresh for the physical system tncm'Dl'}’ including Main VUMA Memory and
`Auxiiiary VUMA Memory is provided by core logic during normal as well as suspend
`state of operation.
`
`HVUMA device usesonlyaportionofits address space as MainV'UMAMemory or
`Auxiliary VUMA Memory, it should drive unused upper MA address lines high.
`'
`
`5
`
`‘
`
`.
`
`5.1 Memory Decode
`
`The way CPU address is transiated in to DRAM Row and Column address decides the
`physical location in DRAM where a particular data will be stored. In the conventional
`_architeoture this could be implementation specific as there is a single DRAM controller.
`In unified memory architecture. multiple DRAM controllers (core logic resident and
`VUMA device resident DRAM controller) need to access the same dale. Hence. all
`DRAM controllers shouldfollow the same translation of CPU address into DRAM Row
`and Column address. The Iransiaiion isas shown in Table 5-1.
`
`"Table 5-1 Translation ofCPU address to DRAM Row and Column addresses
`
`-
`.
`‘Symmetrical x9,ic10.xl1,x'l2
`
`'. -ITEJEIIIIEIIEIIEJ
`'T
`
`A25
`A23
`A21 A20 A19 A18 A17 A16 A15 A14 A13 A12-
`
`
`
`
`
`
`-
`
`-_
`
`Asymmenical x8
`TEE]
`@_-1-
`
`
`
`
`
`W A
`
`symmetrical x9
`
`....Page 19 of 38
`
`19
`
`Version. 1.05:. Rev. 0.4p
`
`Petitioners HTC & LG — Exhibit 1025, p. 19
`
`Petitioners HTC & LG - Exhibit 1025, p. 19
`
`

`
`gvuws Prcmnaod at
`
`‘tans
`
`.
`
`.
`
`vEs_A Confidential
`
`Imslnmimnlmelxmmslmssmtlum
`
`Elial---EEIIEIIEEI
`
`A17. A16 A15 A14 A13 A12.
`
`
`
`Izzttlnzslmsmzslnmmsl
`
`
`EEIEI
`um
`
`
`
`
`
`
`
`
`
`
`'
`Asymmetrical x11
`XIEIEIIEEIIEEIEEIIEEILVIIIIEEIIEEIIEB
`@-E
`Ell
`
`'
`_
`--
`Synchronous I6Mb
`Zmmmnumltmmnlemummslmslltzn
`
`WZEI
`E
`
`
`
`
`
`
`5.2 Main VUMA Memory Mapping _
`
`(DRAM) is expanded, unified memory architectttse poses
`I When physicallsystem
`; a unique problem not existing on the conventional architcctuse. The pmhlem and three-
`: different solutions axe described below: -
`
`Problem: Main VUMA.- Memoty- needs to be mapped at the tap ofeicisting metnory for
`any given
`When physical system memory (DRAM) is expanded, this
`would cause a hole in the physical system memoryas shown in Figure 5-1. The
`example assumes an initial system with‘ single bank SMIB memory (IMIB
`allocated to Main VUMA Memtuy) expanded to 16MB meniory (IMB
`allocatedto Main VUMAMe-tnorg-') by addingshankoffilvlfl meu1ory.A.lIthe
`nttrnbers mentioned in this discussion are just examples and do not imply to be
`a pan of the standard.
`
`E
`g
`
`-
`
`Q Figure 5.-1 Memory Expansion Problem
`
`20
`
`Version. ‘l..Dp, Rev. 0.4;:
`
`page 2.0 of 33 ..
`
`.
`
`.
`
`.
`
`_
`
`___.__,
`
`_
`
`Petitioners HTC & LG - Exhibit 1025, p. 20
`
`Petitioners HTC & LG - Exhibit 1025, p. 20
`
`

`
`If VUMA Proposed Stan ..'d
`
`'
`
`‘V555 Cflflfldfiflfifll
`
`tau-1__
`
`W
`.
`m l**'°"""'"'°'* '
`711-1
`
`.
`
`BIHI1
`
`'
`
`.
`
`an-1
`m
`751-1
`
`
`
`.
`
`-Bani-:0
`
`Pb
`
`"
`
`Baokfl
`
`mu
`leals on than (NIH)
`’
`"'
`"
`Before Explnsbn
`
`__
`on
`Pi‘! his
`Bll'lD!y[fllNl}
`" al?.'r'?:....taa
`
`VESA
`problem. BIOS calls defined in
`Three solutions are suggested for
`BIOS Extensions support all the three solutions. The BIOS calls are designed in such a
`way that a VUMA device can find out which of the three solutions is impleuted by
`ear: logic and can eonfigure the VUMA device appropriately.
`
`'
`
`Solution 1:
`
`-
`
`.
`
`'
`-. _
`"_
`
`_
`'
`2'
`
`2 As depicted in Figure 5-2. core logic maps Main VUMA Memory" to snaddress beyond '
`core logic‘s possible physical system memory range. Main VUMA Memory is mapped
`non-contiguous to the o.s. memory. As shown in Figure 5-2, Main VUMA Memory is
`§ mapped from 1G to (1G+1_M-1) and '4’-:;:nce even if physical system memory is expanded
`i‘ to the maximtnn possible size, lime
`‘be no -hole in the memory. As shown in Figure
`Z 5-2. Bank 0 is split with-t_wo seps:-are l'tlss=.:‘z.-:. of memory with difierent starting addresses.
`If the VUMA device is a gi-a._:_._-.=..'*.-.iss oonttoller, and if it wants to look at Main VUMA
`Memory also as a PCI address space; it can allocate {different address
`what has
`2 been assigned by core logic (1 G in this example).
`
`Figure 5-2 Main VUMA Memory mapped non-contiguously
`
`-
`
`----Page 21 of 38
`
`21
`
`Version. ‘1.Up.'Rev. 0.4p
`
`Petitioners HTC & LG - Exhibit 1025, p. 21
`
`Petitioners HTC & LG - Exhibit 1025, p. 21
`
`

`
`.vuMA_Prapoud st:
`
`in-d
`
`VESA Confidential
`
`191-1
`
`5-nk 0 . w
`
`nu-1
`
`'m.—1 '
`
`am 0
`
`pi-mini; ugrrlfixlgtrrggnlflfllin I
`
`Physical
`
`_ Solution 2:
`
`on
`IDHAIII
`
`,
`
`'
`
`; As depicted in Figure" 5-3. more logic maps Main VUMA Memory to the top of man’.
`2 Main VUMA Memory is mapped contiguous to the 0.8. memory. As shown in Figure 5- '
`-' =3, Main VUMA Memory is mapped from 15 M to(16M—1). As shown in Figure 5-3,
`' Bank 0 is split with two separate biocks of memory with di.fi'erent starting addresses.
`
`- Figure 5-3 Main VUMA Memory mapped cuutiguuusly ‘
`
`BCFIK1
`
`15M-‘I
`
`OM
`
`Sank 0
`
`.
`
`-
`
`u
`
`OM
`
`'"'*='*:...='s:'