VUMA Proposal
`
`VESA®
`(Draft)
`Video Electronics Standards Association
`Pbont: (~8) 43S.0333
`21SO Nonb First Sa'eec, Suite 440
`.Sin Jcm, CA 9Sl31·20l9 .
`FAX: (Mla) 435-8225
`VESA Unified Memory Architecture
`Hardware Specifications Proposal
`Venion: l.Op
`· Document Revision: o.~p
`October 31, 1995
`Important Notice: This is a draft document ~m the Video Elcctronics Standards
`Association (VESA) Ynified Memory Alcbitecture Committee (VUMA). It is only for
`discussion purposes within the committee and with my otl;ler persoos or organizations
`that the committee has dele:rmincd should be invited to review or otherwise contribute to
`. it. It has not been presented or ratified by the VESA general membership.
`'
`
`Purpose
`
`To enable co~ logic ~ aiui VUMA de,vice designers to. desiSll VUMA ~eviees
`supporting the O~ed Memoey Alclli~.
`. .
`·
`·
`. .
`•
`
`•
`
`0
`
`Summary
`This docwneni .con~ a ~ecification for YuMA devices' hardware interface. It
`includes lpgical and electrical interface specifications. The BIOS protocol is dcsaibed in
`VESA docwnent YUMA VESA BIOS Extensions (VUMA-SBE) rev. 1.0.
`
`I •
`
`I o
`
`..
`
`......
`
`0
`
`•
`
`.·
`
`I
`
`' ' I I '
`i,, ' ,
`I
`'• h
`.
`.
`'
`
`Page 1 of 38
`
`• 0'
`
`:. · .. ··
`
`I
`
`'
`
`I
`
`I
`
`ZTE Exhibit 1025
`
`

`
`VUMA Proposed S
`
`:dard
`
`VESA Confidential
`
`Scope
`
`Because this is a dr8.ft document, it cannot be considered complete or accurate in all
`' respects althouab ev~ effort has been made to mjnimi::ze enors.
`
`lnteliectu·a l-Prope_rty
`
`0 Copyright 1995 - Video ElectroniCs Standards Association. .Duplication of this -
`document within VESA member companies for revieW pwposes is permitted. All other
`rights arc reserved.
`
`Trademarks
`
`All trademarks used in This document are the property of their respecth:e owners. _VESA.
`and VUMA are trademarks owned by the Video Electronics Standards Association.
`·
`
`, . · ..
`~ : ·
`
`I
`
`I
`
`'
`
`,', !. ,~ .
`' ' · ; ~ : .
`
`Patents
`The proposals and standardS-dev~loped and adopted by VESA are intenaed tCY promote
`uniformity and ~cono~~s 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 cannot. _ensUre that the adoption of a standard; the .u.se of a method ~l:te4 as a
`Standard: or the making, using, or selling of a product in compliance with the standard
`does not infringe upon the intellccrual. property rights (including patentS, ~. and
`copyrights) of others. VESA, therefore,- makes no wammties, expressed or implied, that .
`produ~ts confo~ing 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.
`
`. ..... .
`Page 2 of 38
`
`2
`
`Version. 1.0p, Rev. 0.4p
`
`. ... · .·· ···· ··
`
`0 .
`
`

`
`,.
`•,').
`'
`
`I
`
`t
`
`1
`
`,
`
`,' .
`.. ·:.
`·.· .....
`· .· ,. I
`
`·'
`
`VUMA. Proposed Stan~-- d
`
`) ESA Confidential
`
`·Support For This Speciflcatlon
`.
`TM
`.
`If you have a product that incorporates VUMA
`, 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 clari.ficati~o that you may require. All questions must be
`sent in writing to. VESA via:
`·
`
`(The following list is the preferred order for contactina VESA.)
`
`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.
`.
`.
`.
`This document would not have been possible without the effons of the members of the
`1995 VESA Unified Memory Arcllitecture Committee and the professio~ support ofthe
`VESAstaff.
`
`.
`
`Work Group Members
`
`Any industry standard requires information from many sources. The· following list
`. recognizes members of the VUMA Committee, which was responsible for ~mbining all
`of the industrY input into this proposal.
`
`Chairperson
`Rajesh Shalr.lcarwar
`
`Members
`Jonathan Claman
`Jim Jirgal
`Don Pannell
`Wall~~:c Kou
`Dctek Joluuon
`Andy Daniel
`Lone Npyen
`Roben Tsay
`Sunil Bhatia
`Peter Cheng
`:Alan Monnann
`;solomon Alemayehu
`;Lany A lchesky
`'Dean Hays
`
`Page 3 of 38
`
`OPTi
`
`S3
`YLSI Technology Inc.
`Sierra Semiconductor
`Wcacm Dtgilal
`Cypress
`Allimlee Semiconductor
`oalt Tedmolo&Y
`Pacific Micro Computing Int.
`Mc~rArc
`Sarnsung
`Micron
`Hi~.ac:hi America Ltd.
`MitSubishi
`Weitek ·
`
`3
`
`Version. 1.0p, Rev. 0.4p
`
`

`
`~· ~ .. :·. :·.
`'.
`.· \,:'
`~:
`
`• i• I
`
`·vuMA Proposed St
`
`·ard
`
`VESA C~nfldentlal
`
`. Revision History
`
`Initial Revision 0.1 p .
`
`Revision 0.2p
`Added~ DRAM suppoit
`Electrical Section
`Boot Protocol . .
`Reformatted ·doc:umenl
`
`Sept. 21 '95
`
`Oct5 '95
`
`. ..
`... '
`
`Revision 0.3p
`Gtaphias controller ~laced with VUMA device
`MD[n:OJ c1:laDgcd to tJs· . .
`Modified Aux Memory description
`Added tbird solution to Memory Expausion Problem
`Synch DRAM burst length changed to 214
`Modified all the bus hand off diagrams
`Added DRAM Driver Ciwacteristics section
`
`Revisio~ 0.4p
`Sync DRAM Burst Lenp changed to 112/4
`DRAM controller pin multiplcxina added
`Chanaed AC tUning parameters
`
`Oct 1~ '95
`
`Oct 19 '95
`
`·I I
`
`I
`
`I
`
`Page 4 of 38
`
`4
`
`Version. 1.0p, Rev. 0.4p
`
`

`
`VUMA Proposed Standa.-
`
`lSA Confidential
`
`TABLE OF CONTENTS
`/·';-_ ·:.: l.OINTRODUcrlONI~~----------~-
`:···.~- ;;~ , i 2.0 SIGNAL DU1NITION ,
`
`6
`2.1 SIGNAL TYPE DEFINlTJON ............................................................................................... 7
`2.2 ARBrntATION SIONALS ..... ___ ., _____ ...... --·-··--· .. ·-·--·--·-·---·· ........... 7
`2.3 FAST PAOE MoDE, BnO AND Bmo DRAMs ............................................................... 7
`2.4 SYNCHRONOUS DRAM. .................................................................................................. 8
`3.0 PHYSICAL INTERFACE--·-------------·8
`3.1 P!iYSICAL SY!i1EM MEMORY SHAJUN0 ................................................................. -.......... 9
`3.2 M.EMORY REGIONS ....... : ................................................................................................ ! 0
`3.3 PHYSICAL CoNNEcnoN ........................................ :··-.................................................... 11
`4.0 ARBITRATION
`·--ll
`4.1 ARBrntATION PRoTOCOL ........................................................................... '" ................ 12
`4.2 ARBJTE:R ......................................... ~ ..... ~ ................................................................ : ...... 12
`4.3 -ARBITRATION ~ ................................................................... : .......................... 15
`4.4 LATENCIES ........................... , .............. ~ ......................................................................... 18
`
`5.0 MEMORY INTERFACE.----·-·---·-------19
`.
`.
`5.1 MEMORY DECODE ........................................................................................................ 19
`5.2 MAIN~ MEMORY MAPPIN0 ......... ~: ....................................................... : ............ .20
`5.3 FAST PAGE EDO AND BEDO ........................................................... '" ...... : .................. 23
`5.4 SYNCHRONOUSDRAM ................................................................................................ .27
`5.5 MEMORY PARlTY SUPPORT ........................................................ .,. ................................ .32
`5.6 MfMOR Y CONTROLLER PIN MUL TIPLEXINO ................................................................ .32
`:
`6.0 BOOT PROTOCOL--... ..;,....____________
`...32
`
`'
`
`6.1 MAIN VUMA MEMORY kCCESS AT BOOT .......................................... ._ ...................... 33
`6.2 RESET STATE ................... : ... ; ............. : ............................. " ... :.: ...................... ; .............. 34
`7.0 ELECTRICAL SP-ECIFICATION.. ........ -
`•• -
`... _ .. ___
`--35
`7 .) SIGNAL LEVELS ............................................................... · ................................. : .......... .35
`1.2 AC TIMINO .................................................................................................................. JS
`7.3 PUl.LUPS ............................................................................... .-...................................... .3 7
`7.4 STRAPS ........................................................................................................................ .37
`7.5 DRAM DRIVER CHARACJB.ISTICS .............................................................................. .37
`
`Page 5 of 38
`
`s
`
`Version. 1.0p, Rev. 0.4p
`
`

`
`I '
`1
`I
`
`~
`
`; .... 1.0 IntrOduction
`,:. ,:, .. ·
`.':: ·, . The concept of.VESA Unified Memory Architecture (VUMA) is to share physical system
`.. · memory (DRAM) between system and an extemal device, a VUMA device; as shown in
`Figure 1-1. A VUMA device ·could be any type. of controller wbich needs to share
`physical system memory (DRAM) with system and dirwtly access it. One example of a
`VUMA !ofevice is srapbics controller. In a VUMA system, graphics comtroUer will
`incotparate graphics frame buffer iD 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 witl;l system and clircctiy accessing it This will eliminm the need for separate
`. graphics memory, resulting in cost savings. Memory sharing is achieved by ph)'sically
`: coMecting core logic chipset (hereafter rcfeiTed to u cere logic) and YUMA device to
`: the same physi·cal system memory DRAM pins. Though the current version covers
`sharin~ of physical system memory only between core lo!Pc and a motherboard VUMA
`device, the next version will cover an expansion COIUlector, connected to physical system
`memory DRAM pins. An OEM will be able to conncc:t any type of device to 1he physical
`.. system mcmo,.Y DRAM pins through.the.expansion connector.
`
`•
`
`:
`I
`
`: VUMA ·proposed Sb
`
`·ard
`
`VESA -eonftdantiaJ
`
`•'
`
`. ·,
`'
`'
`
`.
`
`·Though a VUMA device could be any type of controller, the discussion· in the
`specifications emphasizes a graphics coinrolJer as it will be the first YUMA system
`implementatioiL
`
`Fieure l-1 VUMA System Block Diaeram
`
`PCI Bus
`
`CPU
`
`wu.
`DM4ce
`~·~
`
`.
`
`.2.0 Signal Definition
`
`Page 6 of 38
`
`6
`
`Version. 1.0p, Rev. 0.4p
`
`·, .
`
`

`
`.
`
`.·· .
`
`I
`
`' I •
`
`'
`~' ; , '
`.
`'
`. ' · i ·
`: . : VUMA Proposed Standal
`
`,·· .
`. ..
`. ·
`
`SA Confide a
`
`...
`
`2.1 Signal Type Definition
`
`in
`
`Input is a ~dard input-only signal.
`
`out Totem Pole Output is a .standard active driver
`
`t;s
`
`Tri-State is a bi-directional, tri-state input/outPut pin.
`
`s/tls · Sustained Tri-state is an active low or active high tri-state signal owned and ···
`driven by one and !)nly one agent at a time. The agent that drives an sltls pin
`active must drive it high for at least one clock before lettini it float. A pwlup is
`required to sustain the high state until another agent drives it. Either internal or
`cxtema1 pullup must be provided by core Josie. A VUMA device can also
`optionally provide In internal or eXternal pullup.
`
`2.2 Arbitration Signa~
`
`.1\lREQ#
`
`MGNT##
`
`in
`ou.t
`
`MREQ# is out for YUMA device arid in for core logic. This
`signal is used by YUMA device to inform core logic that it
`needs to access shared physical system memory bus.
`
`in MONT# is out for. core logic and in for YUMA device. this ·
`sisnai is used by core logic to infonn VUMA device that it can
`out
`access' shared physical system memory bus.
`
`CPUCLK
`
`io
`
`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#
`
`CAS(u:OJN
`
`WE#
`
`OE#
`
`s/tls Active low row address mobe for memory banks. Core logic will
`have multiple RAS#s to suppon multiple banks. VUMA device
`could have a single RAS# or multiple RAS#s. These signals are
`shared by eo~ Iogie and VUMA device. They are driven by
`current bus master.
`·
`sltls Active low colwrin address strobes, one forea.c;h byte lane. In case
`of pentium-class systems n is 7. These signals are shared by core
`logic:; and VUMA device. They are driven by current bus. master.
`sltJs Active !ow write enable. This signal is shared by core loaic and
`VUMA device. It is ·driven by current bus master.'
`s/tJ.s Active low output enable. This signal exists only. on EDO and
`BEDO. This signal is sbared by core logiC and VUMA device.
`
`: ~ . ,.
`'
`.
`'
`.. ' ( ··,
`.,-: ~;·. :Rage 7 of 38
`
`7
`
`. Version. 1.0p, Rev. 0.4p
`
`·; I :.
`.
`.
`.
`. · . .
`
`

`
`i'l . , .
`. . ,.
`; . ·, :
`
`C•
`
`·•
`
`j·
`
`!
`
`VUMA. Propoaad St
`
`iarcf
`
`VESA Confidential
`
`: MA(ll:OJ
`
`~ MD{a:O)
`;
`
`. It is driven by curm:rt bus master.
`litis Multiplexed memory address. These .signals ~ shared by core
`logic and VUMA device. They are driven by cUm:zn bus mut.cr.
`Bi-dircctiooal memory data bus. In case ofpentimn-class systems
`n is 63. These signals are shared by core logic and VUMA device.
`They are drivc:a by c:mrcnt bus master •.
`
`t/s
`
`. 2.4 Synchronou• DRAM .
`
`.
`
`:CPUCLK
`
`CKE
`
`litis
`
`· CS#
`
`sltJs
`
`RAS#
`
`. CAS#
`
`WE#
`
`litis
`
`sltls
`
`s/tls
`
`;MA(ll:O)
`
`slt/s
`
`:DQM(u:O)
`
`sltJs
`
`CPUCLK is the master clock input (referred to a CLK In
`synchronous DRAM dala boob). All DRAM iDputl output.~pals
`are referenced to the CPUCLK rima edge.
`CK'E determines validity of the next CPUCLK.If CKE is hish, the
`next CPUCLK.-risiq edge is valid; otherwise it is iDvalid. This
`·
`sign81 also plays role in e:atering power down mode IIDd reUesh
`· modes. This sipl is shared by cote logic aDd VUMA device.
`It is driven by cumut bus master.
`CS# low starts the command input· cycle. CSN is used to scl'cct a
`bank ofS)'DClir9nous 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 loaie aud
`VUMA device. They are driven by CUITent bus master.
`Active low row address strobe. This signal is shared by core logic·
`and VUMA device. It is driven by current bus master.
`Active low column address strobe. This signal is sbired. by core
`logic and YUMA device. It is driven by current b~ master.
`Active.lew Wl'll~•..!"~"' This signal is shared by core logic and
`VUMA d~ It is driven by current bus master.
`Multiplexed memory address. These signals are shared by core
`logic and 't"UMA ~vice. They are driven _by c~t bus master.
`110 buffer control signals, one for each byte lane. In case of
`pentium-class systems n is 7. In read mode they eontrol the output
`. buffers like a conventional OE# pin. In write mode, they CDntrol
`the ward mask. These signa1s are shared by core logic and VUMA.
`. device:~ llC driven by current bus master.
`·
`Bi-directiooal memory da1a bus. In Cl$e. of pentium-class systems.
`n is'63. These signals are shared by core logic aDd VUMA device.
`They· are driven by cW'l"CClt bus master •
`
`.. · . '
`.·."' .
`·'
`
`MD(n:OJ
`
`tis
`
`, 'I
`
`. '
`...
`·.· ..
`~:: ~ . ·: ..
`. "··
`.:. ··.·,
`' :~:I
`. . : 3.0 Physicallnte.rface
`
`Page 8 of 38
`
`8
`
`Version. 1.0p, Rev. 0.4p
`
`

`
`·.·· . ..
`~!' .
`I ,• ,J .. ',
`.. •'
`
`•
`
`II'
`
`:
`
`VUMA Proposed Stand•
`
`iSA Confidential
`
`· 3.1 Phyalc;al System Memol'}' Sh•rlng
`
`fiaurc 3-1 depicts the VUMA Block Diagram. Con: logic and VUMA device are
`. fhysically cc)m1ec:tM to the same DRAM pius. Since they share a common resource, they .
`~ced to arbitrate 'for it PCIIVLIISA cxtcmal mastm also need to access the ~c DRAM
`resource. Care lope~rporates the arbiter and~ can: of arbitration amonpt various
`contenders.
`
`Flpre 3-1 VUMA Block Dtqnm
`
`PCI Bul
`
`.
`o.s.
`UM\oty
`
`....
`.
`As shown in Figure 3-1·, VUMA d~ce arbitrat,es with core loll~ fc $CCSS to the shared
`physical system m~oty tJu:oup a tbrce signal arbitration scheme viz, MREQfl, MGNT#
`: < and CPUCLK. MREQ# is a sigDal driven by VUMA device to core loiic and MONT# is
`• a signal driven by the core I9Sic to VUMA device. MREQ# and MONT# are active low
`.. :,·>: signals driven ancf· sampled ·syhchronous to CPUCLK common to both core logic and
`.
`. · .. i'-' '•VUMA devi~. ·
`
`:' I . I
`
`· 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 of its activities or park on the bus. Core logic can always preempt VUMA
`device from the bus.
`
`Page 9 of 38
`
`9
`
`Version. 1.0p, Rev. 0.4p
`
`

`
`-~-
`
`VUMA Proposed St.
`
`lard
`
`VESA Confidential
`
`' VUMA device needs to access the physical system memory for difi'emrt reasoas and the
`: level of urgency of the needed accesses varies. IfVUMA device is given the access to the
`1 physical system memory right away, ev~ time it needs, the CPU per!onnance will
`: suffer and·as if may not be needed right ·away by the VUMA device, there would not be
`. any improvement in VUMA ckvice performance. Hence two levels of priority aze defined
`· viz. low priority .and high priority. Both priorities are conveyed to core. logic throush a
`single signal, MREQ#.
`·
`
`· 3.2 Memory-Regions
`
`As shown in Figure 3-1. physical system memory can contain two separate physical
`memory blocks, Main VtlMA Memory and Auxiliary (Aux) VUMA Memoey. ~ cache .
`· coherency for Main VUMA Memory and Aux.iliazy VUMA Memory is handled by this
`standard, a VUMA device can access these two physical memory bloclcs without atly
`separate cache coherency considctations. If a VUMA device needs to access other regions
`of physical systrem memory, designers need to take can: of cache coherency.
`
`Main VUMA Memory is programmed as non--cacheable region to avoid cache coherency ·
`overhead. How Main VUMA Memory is used depends on the type of VUMA device; ·
`e.g., when VUMA. device is a graphics controller, main VUMA memory will be used for
`Frame buffer.
`·
`
`Auxiliary YUMA Memory is optional for both core logic and VUMA device. If
`~pponed, it can be programmed as non·cacheable region or 'Nlite·through region.
`Auxiliary YUMA Memory ~ be used to pass data betwcet_~ core logic .and VUMA
`device without copying it ·to Main VUMA Memory or passing throuah 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 VUM.A deVice e.g. when
`VUMA device is: a 3D gr.aphics controller, Auxiliary vuMA memory will be used for
`texture mapping.·
`· ·
`·
`·
`·,
`
`! :-.. : . .
`o
`
`•
`
`I
`
`. ·. · ·' When core logic programs Auxili~ VUMA Memory area as non-cacbcablc, YUMA
`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.
`·
`
`B9th core logic and VUMA device have an option of either supporting or not supporting
`the Auxiliary YUMA 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
`YUMA VESA BIOS Extensions for the most updated BIOS calls:
`
`· _1. When an app,lication needs this feature, it needs to male~ a BIOS call, <Report YUMA
`
`Page 10 of 38
`
`I
`. · -- -· ·~---·· ··- --· --··· · · '
`
`'
`
`.--. ... -._...·-- -.....
`
`10
`
`Version. 1.0p, Rev. 0.4p
`
`

`
`\
`
`VUMA Proposed Stand~o
`
`·1' -core logic capabilities (~fer to VUMA VESA BIOS Extensions)>, to· find out if core
`logic supports the feature.
`2. If core logic does not support the feature, the application ·needs to use some altemate
`method.
`3. If core logic supports the feature, tbe application can pr.obably use it and should do the
`· following:
`·
`
`.·
`L Request the operatina system for Jl physically contiguous block of memory of required ·
`size."
`b. If not SUC(:essiW in aeumg physically contiguous block of memory of required size, usc
`some alternate method.
`c. If successful, get the start address of the block of memory.
`d. Read <VUMA BIOS signatUre string (refer to VUMA VESA BIOS Extensions)>, to
`: find out if YUMA deyicc can access the bank in which Auxiliary vt1MA Memory has
`. been assigned.
`.
`c. If VUMA device can not access that bank, the application needs to either retry the
`1 procedure from ."step a" io "step ·c" till it can aet Auxiliary VUMA Memory in a
`. VUMA device accessible bank or Wle some altemate method.
`·
`f. If YUMA device can acce!s that bank. make a B'IOS call function <Set (Request)
`· ·; VUMA Auxiliary memory (refer to VUMA VESA BIOS Extensions)>, to ask core
`logic to flush A-uxiliary VuMA M~ory block of the needed size from the start
`address from · .. step c .. and change it to either lion-cacbeable or write through. How a
`(..... :.
`core logic flush~ cach~·for the block of memory and programs it as non-cacbeable/
`' ' ',:
`write through is ·implementation specific.
`: ·.•. ·1:: ·.
`·.: · i' . : g. Use YUMA DeVice Driver, to give VUMA devic;e th~ Auxiliary VUMA Memory
`parameters viz. size, start address from "step· c" and whether the block should be non·
`cacheab.le or write through.
`
`;
`
`•
`
`f
`
`3.3 Physical Connection
`
`A VUMA device can be connected in two ways:
`
`:1. VUMA device can only access one bank of physical system memory • VUMA device
`~s connected to a single bank of physical system memory. In case of Fast Page Mode,
`:EDO and BEDO VUMA device has a single RAS#. In case ~f Synchronous DRAM
`Vl1MA device has a single CS#. Main VUMA memory resides in this memory bank. If ·
`'supponcd, Auxiliary VUMA Memory can only be used if it is assigned to this bank.
`l
`.
`2. VUMA device can access all of the physical system m.emory • VUMA ~vice has as
`many RAS# (for Fast Page Mode, EDO and BEOO)/CS# (for Synchronous DRAM) lines
`as CQre logic and is connected to all banks of the physical system memory. Both Maio
`VUMA memory and Auxiliary VUMA Memory (if supported) can be assigned to my
`memory bank.
`
`Page 11 of 38
`
`11
`
`Version. 1.0p, Rev. 0.4p
`
`- ~··.
`
`

`
`VUMA Proposed Stl afd
`
`VESA Confidential
`
`4.0 Arbitration
`
`4.1 Arbltnltlon Protocol
`
`There are three si&nals establishing the arbitration protocol between co~ lo&ic and
`VUMA device. ~ s.ignal is driven by VUMA devic:c to core lolf~ to indi~ it
`needs to access the physical system memory bus. It also conveys the llvel of priority of
`the request. MGNTN is driven by core logic to VUMA device to iDdiCIIle that it can
`access the physical system memory bus. Both MREQ## IDd MOND ce · driven
`synchronous to CPUCLK.
`
`.AJ shown in Figure 4-1, low·level priority is conveyed by drivina MRBQ* low. A bfab ·
`·tcvel priority cab only be acnerated by first gencra!ina a low priority n:quat. JU sbown
`m Fisure 4-2 and ~i~ 4-3,· a low level priority is converted to a biab level priority by
`drivina MREQIII high for one CPUCI.J( clock and tba drivina it low.
`
`·. ' . '
`.
`.· .
`
`Fipre 4-1 Low Level Priorf9' .
`: , I
`
`:2
`
`. : 3.
`
`CPUCU<
`
`.
`. : ..
`
`.
`:a
`
`.
`:.
`
`;
`
`:7
`
`; I
`
`.
`;,
`'
`
`, I
`
`·>
`... , . '
`' •.
`;
`:'!
`...
`..
`'
`' 1.: ·.
`•• I•
`
`''
`
`MREQII
`
`Figure 4-2 Hi&b Level Priority
`
`CPVCU<
`
`MREQII
`
`CPUCU<
`
`. 2
`
`.'
`· 3
`
`. 4
`
`:5
`
`: e
`
`>r
`
`.
`:.
`
`:r--\
`! MREQJ - ; \ ,
`i
`~. ---------------
`~--------------~.
`1
`I
`
`· 4.2 Arbiter
`
`.The arbiter, housed in core logic, needs to understand the IIJ'bitratioo protocol. State
`
`12
`
`Version. 1.0p, Rev. 0.4p
`
`Page 12 of 38
`
`

`
`··~
`
`VUMA Proposed StanL. . d
`
`IESA Confidential
`
`·: Machine for the arbiter is depicted in Figure 4.4./u 3hown in.Figurc 4.4, the arbiter State
`: Machine iS rcsctU:d with PCI_R.cset. Explanation oftbe mbiter is u follows:
`
`: 1. HOST State • 'Ibc physical system memory bus is with core logic and no bus request
`from VUMA device is pending.
`
`· 2. Low Priority R.cquest (LPR) State • The physical system memory bus is with core logic
`·
`and a low priorlly bus request 1iom tbe VUMA device i.s.pc:Ddins.
`
`: 3. High Priority Request (HPR) Stale • The physical system memory bus is .wi~ core
`logic and a pelldiq low priority bus request has tumed into a pendina hi&h priority
`bus request.
`·
`·
`
`.• .• ..
`
`· 4. Granted (GN'rD) State ~ Core logic has relinquished tbe physical system memory bus
`to VUMA device.
`· ·
`S. Preempt (PRMI) State· The physical system memory bus is· owned by VUMA device,
`however, core losic bas requested VUMA device to relinquish the bus and tha1 request
`is pending.
`
`Figure 4.4 Arbiter State MachiDe
`
`PC1_RST1J
`
`>I
`.. ...
`
`.
`
`,i'
`
`·:. ·, ..
`
`'
`
`' ' I t
`
`Note:
`
`I. Only the conditions which will cause a transition from one state to another have been
`
`Page 13 of 38
`
`Ve~ion. , ,Op, Rev. 0.4p
`
`

`
`.. .
`
`:vuMA Proposed St. ard
`
`VESA Confidential
`
`noted. AIJ.y other condition will keep the state machine in the current state.
`
`.
`
`'
`
`4~1 ArbiiratiDD Rv.let
`
`·'
`·':
`•,I
`
`I l l
`
`I
`
`I
`
`;'' ·{·,
`.. ,. :
`· ··
`
`· : 1. VUMA device. asserts ~Q# to generate a low priority ~u= and bcps i\ asserted
`until the VUMA deVice obtains ownership of the physical system memory bus through
`the assertion ofMONTN; unless the VUMA device wmts to either raise a high priority
`request or raise. the priorit). of an already pendio& low priority reqUest. In the later
`ease,
`a. if MONT# is sampled asserted the VUMA device will oot deaslcrt MREQ#.
`Instead. the VUMA device will aam physical system memory bu$ ownership and
`maintaizlMREQ# ~ 'Uiltil it wapts to reliDqui3h the physical system memoty .
`bus.
`
`b. If MGNTN is sampled deasscrtcd, the VUMA device will Cleassert MREQ# for one
`clock and assert' it again inespectivc of status of MONTN. Aft1:r reasscrtion, the
`VUMA device will keep MREQ# asserted JlDtiJ physical system memqry bus
`ownership is transferred to the vuMA device through assertion ofMGNT# signal.
`.
`' '
`:2. VUMA device may assert MREQ# ooly for the pUipose of accessina the unified
`memory area. Once asserted. MREQ# should not be deasserted before MGNT#
`assertion for any reason other than raising the priority of the request (i.e., low to high).
`No speculativ;e request and request abortion is permitted. If MREQ# is dcasserted to
`raise the priority, it should be r=sserted in the next clock and kept· asserted until
`MGNT# is sampled asserted.
`
`3. One~ MGNT# .is sampled asserted by VUMA device, it gains and retains physical
`system memory bus owne~hip until MREQ# is deasserted.
`·
`
`4. The condition, VUMA device completing its required transactions before core logic
`needing the physical sy'stem memory b~ back, can be handled in two ways:
`a. VUMA device can deassen MREQ#. In rcsP<>nse, MGNTN will be d.ea.ssertcd in the
`next clock edge to change physical system memory bus ownership back to core
`logic.
`b. VUMA device can park on the physical-system memory bus. If core logic needs the
`physical system memory bus, it should preempt VUMA device.
`
`S. In .case core logic needS the physical system memo!')' bus before VUMA d.evi~
`releases it on its o~ arbiter can preempt VUMA device from the bus. Preemption is
`signaled to VUMA device by deassertiDg MONT#. VUMA device c:an retain
`ownership of the bus for a maximum of 60 CPUCLK clocks after it bas been signaled
`
`14
`
`Version. 1.0p, Rev. 0.4p
`
`Page 14 of 38
`
`

`
`' .
`
`VUMA Proposed Stant..:.t'd
`
`iESA Confidential
`
`to preempt VUMA device signals release of the physical system memory bus by
`deasserting MR.EQ#.
`
`6. When VUMA device deasserts i\iREQ# to transfer bus ownership, baclc to core logic,
`either on its :own or because of a preemption request, it .should keep MREQ#
`deasserted for. at leaSt t\vo clOcks of recovery time before asserting it agai.tt to raise a
`request
`
`4.3 Arbltratlon Examples
`
`1. Low priority request. and immediate bu.s release to VUMA devtee
`
`••. ,i "
`
`•' ', ., .', .
`
`• • II .• I
`
`•
`
`.•
`
`Rbif
`
`2. Low priority request and .immediate bus release to VUMA device with preemption
`where removal ofMGNTI# andi removal ofMREQI# coincide
`
`' '
`
`l.t3NT# - - - - - - - . \ . . . . - - - - - - . . J
`
`A~eter sute ___ R~&;;;,+;....__m
`
`am
`
`x
`
`HOST
`
`3. Low priority request and immediate bw release to YUMA device with preemption
`where MREQ# is removed after the curr~nt transaction because of preemption
`
`Page 15 of 38
`
`\5
`
`Version. 1.0p, Rev. 0.4p
`
`

`
`VEsA Confidential
`
`.:
`
`I
`
`CJ'UCLK
`
`MREQf
`
`Albtw Stlill
`
`:~
`
`4. Low priority request aad delayed b1JI releue to VUMA device
`:,
`:5
`:7
`:.
`:a
`:e
`
`CPUCL.K
`
`·: 1
`
`: 2.
`
`:.
`
`MREOII
`
`t.CJNIW
`
`luaOwn•
`
`..
`
`@,Lie:
`
`'Aibter St•
`
`l&T ·
`
`X
`
`P!!O vumpwa P!Q §Cie!='e
`GAM
`I
`¥
`
`RCiT
`
`ttiR
`
`5. High priority request and immediate bus release to VUMA device
`
`:1
`
`:.
`
`:a
`
`CP\JCL.K
`
`MREQJ
`
`MGNTI
`
`Bus Own.-
`
`l:lbter Stile
`
`l!cn !!!i" ~ WM.t.&Vco
`HOI' m
`. gNfb
`XAMT
`6. High priority request aad immediate bus release to VuMA device with
`: . pret:mptiou where MGNT# and MREQ# removal coincides.
`
`16
`
`Version. 1.0p, Rev. 0.4p
`
`••
`
`I
`
`.
`
`o .•
`
`.
`
`. '
`
`Page· 16 of 38
`
`.•'
`
`

`
`,· , I
`
`.• ,i
`· : 'i--
`'· · ,
`
`' •
`
`'
`
`I
`
`. ~
`
`. VUMA·Propoaed Stann
`
`.J
`
`.. ESA Confidential
`
`CPUCU<
`
`MGNT•
`
`' lua Own•
`·;
`
`eae §lc
`
`X::::S:::X--~,..:;QIL(=.;::;&:=•-~-P!2E) C&efOilc
`ttds!f. · ·Ue!:X-...;..~ _ _.... "''l!ijrr1Nfb"""".;---;..--\x"'-"!1Ad5,. ... , __
`.
`.
`..
`'
`'
`...
`7. High priority nquest ad immediate ·bw release to VUMA device with
`preemption wbere MREQ## is nmoved· after the CUrl"'eDt trlllaad:ioa b.-use of
`preemptiou.
`·
`.
`
`: 1
`
`:a
`
`:3
`
`: ..
`
`:5
`
`.: 8
`
`:7
`
`:e
`
`:I
`
`CPUCL.K
`
`M REQJ
`
`MGNTI
`
`;'--.;._;/
`
`' Bus Own•
`
`Alb l et Slate
`
`~a~~c ~ to:IX ZSMica ~ e&ep+c
`.;,.§, ~ PMiif
`Heist
`X
`
`8. High priority request and one clock delayed bw rele.se to YUMA deviee
`
`CPUCL.K
`
`MREOII
`
`MG NTI
`
`· • · Hizb priority request and . oue clock delayed bus release to VUMA devi~e with
`precmpdoa where MREQ# aad MGNT# removal do DOt coiocide
`.
`
`..
`
`•' i
`'• #
`
`.
`
`. .. ·
`
`,·
`
`..
`
`' .. ~
`
`:
`
`..
`:·
`.,,, '
`• · • \' 1
`·~ I
`. : ( , '
`' .
`.
`
`Page 17 of 38
`
`\7
`
`Version. '1 .0p, Rev. 0.4p
`
`!
`
`

`
`• •
`
`!
`
`· .
`. · ·.
`' . .
`,.
`I
`•
`
`'•
`•
`
`.·
`
`· VUMA Proposed Sb ard
`
`VESA .Confidential
`
`CPUCU<
`
`MREC»
`
`' MG~t --~--~--~:\___j~--~--~----~-----------
`. .
`Ius Own• =::;:· !!J&~Qi!iit;=:Jps!LXC!!ii:~.==~VD~iliX[l!!ts;:;l~ .. ~:;::~~~[• ~.C::J:lCilf!l•!l;UIOI!iic=
`Estc~C)·~~)·::::~'!*"!C::::~)C::!kl~·~,:::
`
`10. Hip priority nquest ud delayed bus releue to VUMA device
`
`; 4.4 Latencies
`
`; I. High Priority Request- Worst case latency for VUMA.device to receive a grant after
`generating a. 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.
`·
`
`. 2. Low Priority Request - ~o worst ~c latency number bas bec:o ~tined by this
`specification for low priority request. VUMA devices should incorporate some
`mechanism to avoid a low priority request bei.ns starved for an umwonabl~ time. The
`mcchani~m i:s implcmcDta\ion specific and not covered by the Jt.aDdard. 0= simple
`. reference solution is as follows:
`
`' .
`' .
`,.
`
`I
`. !
`
`VUMA dcvi~ incorporateS a programmable timer. The timer value is set at the boot
`time. The timer gets l~ad~ ~ a low priority request is g~ When the timer
`times out, the low prio~ request is conv~ to a high priority request.
`
`I
`
`I
`
`•
`
`. · ..
`:·. ,.
`!
`. ,, ..
`·: ;:: '; · 3. Preemption Request to VUMA device· - Worst ease latency for VUMA device to
`relinquish the physical ~stem memory bus· after receiving a preemption request is 60
`
`I ' ' t
`
`I
`
`I - -
`
`Page 18 of 38
`
`18
`
`Version. 1.0p, Rev. 0.4p
`
`

`
`. , . ,
`
`0
`
`•
`
`1
`
`I
`
`i '
`
`t
`
`•
`
`.
`
`.. -.·· .
`.' 1.',
`' • : .
`'
`'
`'
`
`VUMA Proposed Stanc.
`
`J
`
`. 'ESA Confidential
`
`CPU eLK clocks, i.e •. a&r core logic requests VUMA device to reUDquish the physical
`system memory bus. VUMA device does not need to relinquish the bus riJbt away and
`can keep the bus for up to 60 CPUCLK clocks.
`
`Design engin~ should ~e in to consideration the above latencies for deciding FIFO
`sizes.
`
`: 5.0 Memory Interface
`
`The standard supports F~ Page Mode, EJ;>O, BEDO .IDd Synchronous . DRAM
`technologies.
`
`DRAM refresh for the pbysical system memory including Main VUMA Memory and
`Auxiliary YUMA Memory is provided by core logic durlni normal u well as suspend
`state of operation.
`
`If VUMA device uses only a portion of its address space as Main YUMA Memory or
`Auxiliary YUMA Memory, it sbould.drive unused upper MA addr~s lines high. ·
`
`5.1 Memory Decode
`
`, The