·4
`'
`
`J;
`
`VUMA Proposal
`
`VESA®
`(Draft)
`·video Electronics Standards Association
`Phone: (408) 435-0333
`2150 North FirstS~ Suite 440
`FAX: (4o8) 435·8225
`San Jose, CA 95131·2029 .
`VESA Unified Memory Architecture
`Hardware Specifications Proposal
`Version: 1.0p
`· Document Revision: 0.4p
`October 31,1995
`Important Notice: This is a draft document fn:lm the Video Electronics Standards
`Association (VESA) pnitied Memory Architecture Committee (VUMA). It is only for
`. discussion purposes within the committee and with any other persons or organizations
`·that the committee bas determined 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 chipset· and VUMA device designers to design VUMA devices
`supporting the tJ~fied .Memory Ari:hitec:ture.
`
`'
`
`..
`
`·•
`,' · Summary .
`I
`'
`I
`
`.
`.
`This document contains a specification for VUMA devices' hardware interface. It
`includ~s l9gical and electrical interface.specifications. The BIOS protocol is described in
`VESA document VlJM..\ VESA BIOS Extensions (VUMA-SBE) rev. 1.0.
`
`'.
`',
`
`',.
`
`Page 1 of 38
`
` ZTE EXHIBIT 1025
`
`

`
`VUMA Proposed S
`
`:dard
`
`VESA Confidential
`
`Scope
`
`Because this is a dr8ft document, it ca.a.not be considered complete or accurate in all
`I ·respects although evr:ry effort bas been made to minimi:u errors.
`
`lntellectu.al · Prope.rty
`
`. Duplication of this ·
`C Copyright 1995 - Video Electronics Standards Association.
`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 respecti~e owners. VESA.
`and VUMA are trademarks owned by the Video Electronics Standards Association.
`
`Patents
`
`I
`
`II I .
`
`',1,
`
`I,
`
`I
`
`The proposals end standardS· dev~loped and adopted by VESA are intended tCY promote
`uniformity and econorD.i~s of scale' in the video electronics industry. VESA strives for
`standards that Will benefit both the industry and erid users of video electronics products ..
`'!.: ··~
`· · ! I, i · VESA cannot. ensure that the adoption of a standard; the _qs.e of a method desCJiQ.e4 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
`produ~ts confonning 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.
`
`2
`
`Version. 1.0p, Rev. 0.4p
`
`. --·------.----····--.....
`
`Page 2 of 38
`
`

`
`-~
`
`VUMA Proposed Stanc._. d
`
`iESA Confidential
`
`·Support For This Specification
`.
`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 clarificati9n that you may require. All questions must be
`sent in writing to· VESA via:
`·
`
`,•
`
`. (The following list is the preferred order for contacting VESA.)
`
`VESA World Wide Web Page: www.vesa. org
`Fax:
`( 408) 435-8225
`VESA
`Mail:
`2150 North First Street
`Suite 440
`San Jose, California 95131-2029
`
`Acknowledgments
`
`' . ,•
`
`' '
`
`"
`This docwnent would not have been possible without the efforts of the members of the
`1995 VESA Unified Memory Architecture Committee and the professio~ support of the
`. VESA staff.
`
`'
`
`.
`
`'.!,
`
`'
`' I
`
`'
`
`.
`
`' .,
`
`·Work Group Members
`
`· Any industry standard requires information from many sources. The following list
`. recognizes members of the VUMA Committee, which was responsible for ~ombining all
`· of the industry input into this proposal.
`
`Chairperson
`
`Rajesh Shakkarwar
`
`OPTi
`
`Members
`Jonathan Claman
`Jim Jirgal
`Oon Pannell
`Wallace Kou
`Derek Johnson
`Andy Daniel
`Long Nguyen
`Robert Tsay
`Sunil Bhatia
`Peter Cheng
`:Alan Monnann
`;solomon Alemayehu
`;Larry Alchesky
`:Oean Hays
`
`53
`VLSI Technology Inc.
`Sierra Semiconductor
`Western Digital
`Cypress
`Alliance Semiconductor
`Oak Technology
`Pacific Micro Computing Inc.
`Men~or Arc
`Samsung
`Micron
`Hitachi America Ltd.
`Mitsubishi
`Weitek ·
`
`3
`
`Version. 1.0p, Rev. 0.4p
`
`Page 3 of 38
`
`

`
`-
`
`I
`
`:vuMA Proposed St
`
`'ard
`
`VESA Confidential
`
`. Revision History
`
`Initial Revision 0.1 p .
`
`,
`Revision 0.2p
`Added sine DRAM support
`Eledri~ Section
`Boot Protocol
`Refonnatted .d~cument
`
`II
`
`,··
`
`',1,
`:1
`'' .
`
`r,
`
`r'
`
`I
`
`.,,·,'
`I',.
`1•r
`r
`,.
`I ' II./
`
`Revision 0.3p
`Graphics controller replaced with VUMA device
`MD[n:O] changed to tJs· . .
`Modified Aux Memory description
`Added third solution to Memory Expansion Problem
`Synch DRAM burst length changed to 2/4
`Modified all the bus band off diagrams
`Added DRAM Driver Characteristics section
`
`Revisio~ 0.4p
`Sync DRAM Burst Length changed to 112/4
`DRAM controller pin multiplexing added
`Changed AC timing parameters
`
`Sept 21 '95
`
`Oct 5 '95
`
`Oct 19 '95
`
`Oct 19 '9S
`
`4
`
`Version. 1.0p, Rev. Oo4p
`
`Page 4 of 38
`
`

`
`.,...,.........,..._---------------------;---:---------.--···--·.
`
`VUMA Proposed Standa.-
`
`JSA Confidential
`
`·TABLE OF CONTENTS
`
`1.0 INTRODUCTION-~----------~----6
`6
`I 2.0 SIGNAL DEFINITION ......... --..... ,. .. ,_ ......... ________ ,,, .... - ..... ~ ....................................... , ____ ............... ..
`
`2.1 SIGNAL TYPE DEFINmON ................................................................................................ 7
`2.2 .ARBI1'RA TION SION.ALs •••••••••••••••••••••••••••••••••••••••••••••••••••·••••••••••••••••••••••••••••••••••••••••••••••• 7
`2.3 FAST PAGE MODE, BnO A.ND BEDO DRAMs ............................................................... 7
`2.4 S'YNCJ.mONOUS DRAM ...••...........•....•..•...........................................•.••..................•........ 8
`
`'
`
`1•11
`
`' I
`,,,
`I • ,,
`i~·:
`
`.. ----·----·"· ........ ------····8
`3.0 PHYSICAL INTERF ACE ............... -
`3.1 PHYSJCAL SvsnM.MEMORY SHARING ......................................................... , ................... 9
`3.2 MEMORY REOIONS •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• l 0
`3.3 PHYSICAL CONNECTION ••••••••••••••••••••••••• :. •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 11
`............ ____ ,., .................. 12
`4.0 .ARBITRATION ...................... - ......... ~ ..................... 1111
`4.1 .ARBI"TR.A noN PR.OTOCOL •••••••••••••••••••••••••••••••••••••••••••••••••• ~ ............................................. l2
`4.2 .ARBITER ••••••••••••••••••••••••••.•.•.••••••.•••••••••••••.••••.••.•••••••.••••••••••••••••••••••••••••••••••••••••••••••••••• 12
`4.3 'ARBITRATION EXA}w{PLES ................................................................................................. l s
`4.4 LA T'ENCIES ···························~··············~·········································································18
`5.0 l\1EMORY INTERFACE ........ -·--·-·· .... ~ ............ - .... ·--·------1~
`5. I MEMORY DECODE ................................................................................................................ 19
`5.2 MAIN VU"MA. MEMORY MA.PPIN0 ............ ~···············································"·······"·"··········.20
`5.3 FAST pAGE EDO AND BEDO .................................................................... ~ .................. 23
`5.4 SYNCHRONOUS DRAM .. , ................................................................................................. 27
`5.5 MEMORy pARITY SlJPPORT ............................................. ~ .................. ~················ .. ················32
`5.6 MEMORY CONTROLLER PIN MULTIPLEXIN0 ................................................................. 32
`6.0 BOOT PROTOCOL •• ~················· .. ~~-································ .. ••••••••••••• .......................... .32
`6.1 MAIN 'VUivlA MEMORY ~CCESS AT BOOT ................................................ ~· .......... ·~ ........... 33
`.
`6.2 RESET STATE ••••••••••••••••••• ~ ••• ~ ••••••••••••••••••••••••••••••••••••••••••••.•••• ~ •• ~ ••••••••••••••••••••• ~ .............. '!'34
`7.0 ELEcrRICAL SP·ECIF'ICATION. ......................................................................... .35
`7.1 SlGNAL LEVELS ...................................................................................................... ~ •••••••••• 35
`7.2 AC TIMING ......................................................................................................................................... 35
`7.3 PULLUPS ..................................................... ~ ......................................................................... 37
`7.4 S-rRAPS ..................................................................................................................................... 37
`7.5 DRAM DRIVER CHARACTERlSTICS ............................................................................... 37
`
`,
`
`.
`
`.
`
`,
`
`I
`
`5
`
`Version. 1.0p, Rev. 0.4p
`
`Page 5 of 38
`
`

`
`•
`
`: VUMA ·proposed Sb
`
`·a..q
`
`I VESA Confidential
`
`•
`
`t
`
`,!, , · 1.0 Introduction
`
`I
`
`'
`
`' I
`
`I
`
`11,! l '
`I' •'
`· .. :!·,:
`
`. The concept ofVESA Unified Memory Architecture (VUMA) is to share physical system
`· memory (DRAM) between system and an extcmal device, a VUMA device; as shown in
`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 ~evice is graphics controller. In a VUMA system, graphics controller will
`incorporate graphics frame buffer in physical system memory (DRAM) or in other words
`VUMA device will use a part of physical system memory as its !rattle buffer, 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
`· coMecting core logic chipset (hereafter refemd to as core logic) and VUMA device to
`. the same physical system memory DRAM pins. Though the CUlmlt version covers
`sharing of physical system memory only between core logic and a motherboard YUMA
`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 mcmor:Y DRAM pins through.tbe.expansion connector.
`
`· Though. a VUMA device could be ·any type of controller, the discussion · in the
`specifications emphasizes a graphics conttoller as it will be the first VUMA system
`implementation~
`
`Figure 1·1 VUMA System Block Diagram
`
`~
`
`CPU
`
`Core Logic
`
`..
`
`-
`
`.2.0 Signal Definition
`
`PCI Bus
`
`,
`
`Physical
`System Me1'1'101)'
`(CRAM)
`
`WMA
`CeYice
`t•&:t'Uftea
`WI If)
`
`6
`
`Version. 1.0p, Rev. 0.4p
`
`Page 6 of 38
`
`

`
`:··:.I
`
`,'
`
`J,
`
`I I
`'
`,1'
`'\',,',,
`,11
`,II'
`
`1
`
`, . 'VUMA Proposed StandaL
`
`·2.1 Signal Type Detlnltlon
`
`.. ~.
`;
`
`If,.
`
`SA Confidential
`
`in
`
`Input is a standard input-only signal.
`
`out
`
`Totem Pole Output is ~ .. 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 s/tls pin
`active must drive it high for at least one clock before letting it float A pilllup is
`required to sustain the high state until another agent drives it. Either internal or
`extemal pullup must be provided by core logic. A VUMA device can also
`optionally provide In internal or external pullup.
`
`2.2 Arbitration Slgnal.s
`
`/
`
`MREQ#
`
`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.
`
`MONT# is out for core logic and in for VUMA device. This
`signal is used by core logic to infonn vt1MA 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,
`YUMA device and synchronous DRAM.
`
`2.3 Fast Page Mode, EDO and BEDO DRAMs
`
`RAS#
`
`CAS(n:O)#
`
`WE#
`
`OE#
`
`s/tls Active low row address strobe for memory banks. Core logic will
`have multiple RAS#s to suppon multiple banks. VUMA device
`could have a single R.AS# or multiple RAS#s. These signals are
`shared by core logic and VUMA device. They are driven by
`cmrent bus master.
`sltls Active low column address strobes, one for each byte lane. In case
`of pentium-class systems n is 7. These signals are shared by core
`logi~ and VUMA device. They are driven by current bus master.
`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.
`
`s/t/s
`
`s/t/s
`
`·'
`
`,.
`
`I
`I
`
`'
`
`I
`
`1', ••
`
`7
`
`. Version. 1.0p, Rev. 0.4p
`
`Page 7 of 38
`
`

`
`1'',11
`
`I
`
`'
`
`I
`,.
`
`(
`'
`
`I I ' '
`I
`
`I
`
`··,1
`Ill',','
`
`I
`
`11'.1
`I ' 1''
`
`I
`
`· VUMA Proposed St
`
`iard
`
`VESA Confidential
`
`! MA(ll:O)
`
`i :MD[n:O]
`i
`
`It is driven by current bus master.
`sltls Multiplexed memory address. These signals~ shared· by core
`logic and VUMA device. They are driven by cim=t bus master.
`Bi-directional memory data bus. In case of pentium-class systems
`n is 63. These signals are shared by core logic and VUMA device.
`They are driven by current bus master ...
`
`tis
`
`2.4 Synchronous DRAM .
`
`;CPUCLK
`
`CKE
`
`RAS#
`
`. CAS#
`
`WE#
`
`; MA[ll:O]
`
`: DQM(o:O]
`
`MD(n:O]
`
`I '
`
`1
`1
`
`I
`
`in
`
`CPUCLK is the master clock input (refmed to as CLK. in ·
`synchronous DRAM data books). All DRAM input/ output~gnals
`. are referenced to the CPUCLK rising edge.
`sJtls CKE determines validity of the next CPUCLK. If CKE is high, the
`next CPUCLK rising edge is valid; otherwise it is invalid. This
`sign&I also plays role in entering power down mode and refresh
`·modes .. This signal is shared by core logic and VUMA device.
`It is driven by cum:nt bus master.
`s/tJs CS# low starts the command input cycle. CS# is used to sereet 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 cmrent bus master.
`Active low row address strobe. This signal is shared by core logic·
`and VUMA device. It is driven by current bus ~·
`Active low column address strobe. This signal is shared by core
`logic and VUMA device. It is driven by current bus master.
`Active .low 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 ~d VUMA device. They are driven .bY curm1t bus master.
`I/0 buffer control signals, one for each byte lane. In case of
`pentium-class systems n is 7. In read mode they control the output
`. buffers like a conventional OE# pin. In write mode, they control
`the word mask. These signals are shared by core logic and VUMA.
`. device. They arc driven by current bus master. .
`Bi-directional memory data bus. In case of pen1i~-class systems.
`n is 63 .. These signals are shared by core logic and VUMA device.
`They are driven by current bus master. ·
`
`s/tls
`
`sltls
`
`sltls
`
`s/t/s
`
`s/tls
`
`tis
`
`';r·'.i,
`!:·::
`
`1 '
`
`,'
`1•1 r '
`I.'·'
`1!1 1
`
`rlr
`
`1
`1'
`
`' 3.0 Physical Interface
`
`8
`
`Version. 1.0p, Rev. 0.4p
`
`Page 8 of 38
`
`

`
`VUMA Proposed Stand;. .
`
`~SA Confidential
`
`· 3.1 Physic;al System Memory Sharing
`
`Figure 3-1 depicts the VUMA Block Diagram. Core logic and YUMA device are
`. fhysically connected to the same DRAM pins. Since they share a common resource, they .
`need to arbitrate for it PCIIVLIISA extcmal masters also. need to access the same DRAM
`resource. Care logic· incorporates the arbiter and takes care of arbitration amongst various
`contenders.
`
`Figure 3-l VUMA Block Diap-am
`
`Host Addr & Cnrt
`
`CPU
`
`PCIBus
`
`MGNTt
`
`VWA
`Device
`(l,g.~o
`ConO'at•>
`
`Physical
`Systam
`Memory
`(DRAM)
`
`o.s.
`Mamory
`
`Data Bus
`
`I
`
`''
`'11·•,',1
`'
`I
`I
`1 1
`' , ,
`I ' ~~~
`
`1,
`
`.,,
`
`';
`
`I
`
`I'
`
`'
`
`•
`
`•
`
`•
`
`•
`
`· As shown in .Figure 3·1, VUMA de~ce arbitrates with core logic for access to the shared.
`physical system memory throuih a ~ signal arbitration scheme viz. MREQ#~ MONT#
`: .and CPUCLK. MREQ# is a sigrial driveri by VUMA device to core logic and MGNT# is
`.'
`' .. ',,: a signal driven by ~c core l.~gic to VUMA device. MREQ# and MONT# are active low
`;'. : 'i'· ·,, signals driven and· sampled synchronous to CPUCLK comri1on to both core logic and
`, ·,: (,:
`'··VUMAdevt'ce ·
`·
`·
`·
`.
`'' ',
`
`',.
`· Core logic is always the default owner ·and oWnership will be transferred to VUMA
`device upon demand. VUMA device could retmn ownership to core logic upon
`completion of its activities or park on the bus. Core logic can always preempt YUMA
`device from the bus.
`
`9
`
`Version. 1.0p, Rev. 0.4p
`
`Page 9 of 38
`
`

`
`· VUMA Proposed St
`
`tard
`
`VESA Confidential
`
`, VUMA device needs to access the physical system memory for different reasons and the
`·level of urgency of the needed accesses varies. IfVUMA device is given the access to the
`i physical system memory right away, evr::ry ti:.tne it needs, the CPU perfomumcc will
`: suffer and· as 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 def]ned
`viz. low priority .and high priority. Both priorities are conveyed to core. logic through a
`single signal, M:REQ#.
`
`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. If a YUMA 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 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 VUMA. Memory is optional for both core logic and VUMA device. If
`~upponed, it can be pro~ed as non-cacheable region or wtite·through region.
`Auxiliary VUMA Memory can be used to pass data betweel) core logic and YUMA
`· device without copying it to Main VUMA Memory or passing through a slower PCI bus.
`This capa'Dility would have significant advantages for more advanced devices. How
`' Auxiliary VUMA Memory. is· used depends on the type of YUMA deVice e.g. when
`VUMA device is: a 3D graphics controller, Auxiliary VUMA memory will be used for
`texture mapping.·
`·
`·
`·
`
`I
`
`',(1
`
`' I
`
`'
`
`When core logic programs Auxiliary VUMA Memory area as non-cacheablc, VUMA
`device can read from or wnte to it. When core logic programs Auxiliary VUMA Memory
`area as write through, YUMA device can read from it but can not write to it.
`
`I
`
`' ... ".....
`
`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:
`
`· l. When an application needs this feature, it needs to make a BIOS call, <Report YUMA
`
`10
`
`Version. 1.0p, Rev. 0.4p
`
`Page 10 of 38
`
`

`
`VUMA Proposed Stand~
`
`.!SA Confidential
`
`-core logic capabilities (refer to VUMA VESA BIOS Extcrisions)>, to· find out if core
`logic supports the feature:
`2. If core logic does not support the feature, the . applicati()n needs to use some alternate
`method.
`3. If core logic supports the feature, the application can p(Obably use it and should do the
`· following:
`·
`
`L Request the operatina system for .11. physically contiguous block of memory of required
`size.·
`b. If not successful in getting physically contiguous block of memory of required size, use
`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 device can access the bank in which Auxiliary VUMA Memory bas
`been assigned.
`.
`c. If VUMA device can not access that bank, the application needs to either retry the
`I procedure from "step a" to "step ·c" till it can get Auxiliary VUMA Memory in a
`! VUMA device accessible bank or use 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 Extensions)>, to ask core
`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 flush~ each~ ·for the block of memory and prograJllS it as non-cacheable/
`write through i~ implementation specific.
`g. Use VUMA Device Driver, to give VUMA device th~ Auxiliary VUMA Memory
`parameters viz. size, start address from "step c" and whether the block should be non(cid:173)
`cacheahle or write through.
`
`..
`
`I
`
`\
`
`I
`
`t
`
`~~~~.·,, ·
`
`•
`
`1
`
`!•r
`•
`I ' ~~~
`
`·1
`
`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
`fis 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 of Synchronous DRAM
`VUMA device has a single CS#. Main VUMA memory resides in this memory bank. If
`supported, Auxiliary YUMA Memory can only be used if it is as5igned to this bank.
`
`2. VUMA device can access all of the physical system m.emory • VUMA d~vice has as
`many RAS# (for Fast Page Mode, EDO and BEDO)/CS# (for Synchrono1lS DRAM) lines
`as core logic and is coimected 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.
`
`11
`
`Version. 1.0p, Rev. 0.4p
`
`'I• I
`
`Page 11 of 38
`
`

`
`·\
`
`YUMA Proposed Sa arct
`
`VESA Confidential
`
`4.0 Arbitration
`
`4.1 Arbitration Protocol
`
`There are three signals establishing the arbitration protocol between core logic and
`VUMA device. MRB~ s.ignal is driven by VUMA device to core logic to indicate it
`needs to access the physical system memory bus. It also convers the level of priority of
`the request. MONT# is driv= by core loaic to VUMA device to indicate that it can
`access the physical system memory bus. Both MREQ# and MONT# are · driven
`synchronous to CPUCLK.
`
`:AJ shown in Figure 4-.1, low' level priority is conveyed by driving MREQ1# low. A high ·
`level priority can only be generated by first generating a low priority request. As shown
`:m Figure 4-2 and Fi~ 4-3, a low level priority 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 Priori~ .
`
`.
`
`: 1
`
`:,·',t,
`
`I
`I
`'
`~ , , I
`
`I
`1
`
`•
`
`'
`
`t
`
`I I ' '
`1
`''
`'(· ',,
`!11
`II'.
`
`1
`
`CPUCI.K
`
`MREO#
`
`I
`
`: 2
`
`.•
`
`Figure 4-2 High Level Priority
`
`CPUCLK
`
`MREC» ~'--..J/
`
`;\..__ __ _ _ _ _ __ _ __ _ _ _
`.
`.
`.
`.
`.
`.
`.
`.
`.Figure 4-3 A Pending. Low Level Priority converted to a High Level Priority
`.
`.
`.
`.
`.
`: ..
`:s
`:7
`
`2
`
`3
`
`CPUCLK
`..
`!
`1
`j MREQ# --;\,
`~--------------~
`!
`i
`
`6
`
`:\
`
`· 4.2 Arbiter
`
`The arbiter, housed in co~ logic, needs to m1derstand the arbitration protocol. State
`
`12
`
`Version. 1.0p, Rev. 0.4p
`
`Page 12 of 38
`
`

`
`'; ~:
`;
`
`VUMA Proposed Stanc.
`
`. d
`
`JESA Confidential
`
`·: Machine for the arbiter is depicted in Figure 4.4. As shown in'Figure 4.4, the arbiter State
`. Machine is rcsetted with PCI_Rcset. Explanation of the arbiter is as follows:
`
`• 1. HOST State- The physical system memory bm is with core logic and no bm request
`· from VUMA device is pending .
`..
`· 2. Low Priority Request (LPR) State • The physical system memory bus is with core logic
`and a low priority bus request &om the VUMA d.cvi= is .pending.
`
`• 3. High Priority Request (ln'R) State ·The physical system memory bus is .wi$ core
`logic and a pendinalow priority bus request has turned into a pending high priority
`busrequest
`·
`
`,.
`' I
`
`I
`
`'
`
`11,1
`1•1
`II•
`
`'
`
`',
`
`1
`
`· 4. Granted (GNTD) State ~ Core logic bas relinquished the physical system memory bus
`to VUMA devi~e.
`
`S. Preempt (PRM'I) State - The physical system memory bus is owned by VUMA device,
`however, core logic bas requested. VUMA device to relinquish the bus and that request
`is pending.
`
`Figure 4.4 Arbiter State Machine
`
`MREC1=1
`
`Note:
`
`1. Only the conditions whibh will cause a transition from one state to another have been
`
`Version. 1.0p, Rev. 0.4p
`
`Page 13 of 38
`
`

`
`I
`
`'
`
`'1,1
`
`I
`
`,'
`',' I' ,I
`,1'1
`'
`1
`'• 11,
`
`: VUMA Proposed Su ard
`
`VESA Confidential
`
`noted. Any other condition will keep the state machine in the current state.
`
`(
`
`'
`
`4.2~1 Arbitration Rules
`
`I
`
`1
`
`( ,.
`
`.
`
`• 1. VUMA deVice. asserts ~Q# to generate a low priority ~quest and keeps it asserted
`until the VUMA deVice. obtains ownership of the physical system memory bus through
`the assertion of MONT#, .uDless 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 will not deasscrt MREQ#.
`Instead, the VUMA device will aain physical system memory buS ownership and
`maintailtMREQ# as~erted until it wants to relinquish the physical system memory.
`bus.
`
`· b. If MGNT# is sampled dcasserted, the VUMA device will deassert MREQ# for one
`clock and assert' it again iirespectivc of status of MGNT#. After reassertion, the
`VUMA device will keep MREQ# asserted JJlltil physical system memqry bus
`ownership is transferred to the VUMA device through assertion ofMGNT# signal.
`
`!
`..
`:2. VUMA device may assert MREQ# only for the purpose of accessing the unified
`memory area. Once asserted, MREQ# should not be deasserted before MONT#
`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 MREQ# is dcasserted to
`raise the priority, it should be reasserted in the next clock and kept asserted until
`MGNT# is sampled asserted.
`
`3. Once MONT# is sampled asserted by VUMA device, it gains and retains physical
`system memory bus owne~hip until MREQ# is deasserted.
`
`4. The condition. VUMA dcvic;:e completing its required transactions before core logic
`needing the physical system memory btis back, can be handled in two ways:
`
`. ,
`
`a. VUMA device can deassert lvm.EQ#. In resPonse, MGNT# will be deasserted in the
`next clock edge to cb.a:.nge 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 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 MONT#. 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
`
`1-·- -.
`
`Page 14 of 38
`
`

`
`i.
`
`VUMA Proposed Stant...;.ld
`
`IESA Confidential
`
`to preempt. VUMA device signals release of the physical system memory bus by
`deasserting :MR.EQ#.
`
`1'',1,
`
`' I
`
`'
`
`6. When VUMA ·device deasserts MREQ# to transfer bus ownership I back to core logic,
`either on its, ·own or because of a preemption request, it ,should keep MREQ#
`deassened for at leaSt tWo clocks .of recovery time before asserting it again to raise a
`request.
`
`4.3 Arbitration Examples
`
`1. Low priority request. and immediate bus release to VUMA device·
`
`CPUCL.K
`
`MREQ#
`
`Bus Owner· - - - - . - - - - -
`COre!Jii•c
`
`~ ~loat ~ vutlA ow•c:e ~ 'i)lt ~
`X
`X
`c~ I
`lJR'H5
`Rt'i!'l'
`---~---....1
`
`AJt)ter State
`
`COrti.OgC.
`
`RI5Jr
`
`2. Low priority request and ~mmediate bus release to VUMA device with preemption
`where removal ofMGNT# and removal ofMREQ# coincide
`
`CPUCL.K
`
`MREO#
`
`MGNT#
`
`Bus Owner
`
`CareLOOIC
`
`Arbter State
`
`Ri5!'f'
`
`2
`
`·3
`
`.s
`
`·6
`
`·9
`
`X ~laat K \1uMA Oet•m X"Tbat .. X
`:x
`).( LPR X
`
`~m'O
`
`I
`
`COre LQ;c.
`
`RdSf
`
`3. Low priority request and immediate bus release to VUMA device with preemption
`where MREQ# is retnoved after the· current transaction because of preemption
`
`\5
`
`Version. 1.0p, Rev. 0.4p
`
`Page 15 of 38
`
`

`
`I',!,
`
`I ' I
`
`I
`I
`
`I
`
`I l l ' I
`I I
`,I
`,1,,
`i'·
`
`'
`
`I
`
`VUMA Proposed·Sta ud
`..
`:2
`
`: 1
`
`CPUClK
`
`:3
`
`'~ ;
`
`\IES~ Confidential
`
`: ..
`
`:a
`
`:e
`
`:7
`
`:a
`
`: 8
`
`UREQJ
`
`MGNI't
`
`: Bus Owner
`
`COfiL021C
`
`AlbterState
`
`'
`18'1'
`
`~ 'I oat ~ Qijf:AA 5ii•ca ~ ~bat ~
`~ r:~ ¥ ~RTI5 l<
`II!!!
`X:
`
`'
`
`co;; l.opc
`
`Rl5£
`
`4. Low priority request nd delayed bus release to VUMA device
`: ..
`:7
`:3
`
`·: 1
`
`: 2.
`
`CPUCL.K
`
`I
`
`I
`
`15
`
`I
`
`le
`
`:8
`
`MREC»
`
`MCJNI't
`
`Bus Owner
`
`I
`
`' '
`
`f!iire~i•c
`I
`
`Albl.,.Stale
`
`·HOS!;.
`
`'
`
`x:
`
`~ Aiat -~ 20MA~tcl ~ ~- ~ C£•fi'c :
`¥
`2!!
`X
`
`ltRT15
`
`I
`
`'
`RZIIJ'
`
`I
`
`'
`
`'
`
`·s. Uigh priority request and immediate bus release to VUMA device
`:2
`:3
`: ..
`:s
`:a
`:a
`
`: 1
`
`CPUCL.K
`
`'
`17
`
`:a
`
`MREQ# ~ 'I
`MGNT#
`
`:\
`
`'I
`
`Bus Owner
`
`Cere LOg•c: X ~I oat
`
`WMAL)ihtca
`
`X ~I oat
`
`j
`
`'
`&ire1.02•c:
`
`~~· : X
`·x [JI~ X
`
`Arbler State
`
`ROJI!'
`
`Mtc
`6. High priority nquest and immediate bus release to VUMA deviee with
`. preemption where MGNT# and MREQ# removal coincides.
`
`I
`
`Re!IJ'
`
`----·- ·-- --.
`
`,!
`
`i
`
`I 1
`
`1
`
`I
`
`I
`I
`
`16
`
`Versiort 1.0p, Rev. 0.4p
`
`Page 16 of 38
`
`

`
`. ,I
`
`I
`
`I : I
`
`'
`II
`
`I
`
`..
`
`. VUMA Proposed Stan" J
`
`.)ESA Confidential
`
`CPUCU<
`
`MREC» ---;\
`
`t
`
`MGNTt
`
`:3
`
`:.
`
`~-------------------1
`:\
`
`Bus Owner
`
`Albter Stllll
`
`..
`
`ccn§tc ~ ,;~1 ~
`' .
`Rost.
`) CPM X
`.
`7. High priority request and immediate bus release to VUMA devi~e with
`preemption· where MREQ# is removed· after the current traasaetion bl!•use of
`preemption.
`·
`
`WMAf$lat
`
`dNTB
`
`~ l!iOit I
`.
`I
`
`core lotte
`
`Aeit
`
`:2
`
`1
`
`:3
`
`;\
`
`:5
`
`.: 8
`
`:7
`
`1
`
`:a
`
`:,
`
`CPUCU<
`
`MRECW ---:\
`MGNT#
`
`: Bus Owner
`
`ca~ !.p2•c
`
`Albler State
`
`R6!f
`
`~ FtO!t ~
`X em'" ~
`I CJIM
`
`ID'.iA£5Miat
`
`!Simi'
`
`.
`~ ~I oat ~ coreLijic
`.
`Rosf
`J
`
`8. High priority request and one clock delayed bus release to VUMA device
`
`. 1
`
`CPUCU<
`
`MREOII ----:\
`
`:2
`
`'I
`
`·3
`
`·4
`
`:s
`
`:e
`
`:\
`
`:a
`
`:s
`
`:7
`
`I
`
`MGNT#
`
`Bus OWner
`
`Albler Stile
`
`r!Ore LSIIIC
`
`.x FIOil .X
`HosT X I:JIM X HiSR X
`
`~DADftlat
`
`dN'Tb
`
`~ ~loa! X s.q;.c
`I
`
`Atilt
`
`· 9. High priority request and. one clock delayed bus release to vt1MA device with
`· preemption where MREQ# and MGNT# removal do not coincide
`
`Version. 1.0p, Rev. 0.4p
`
`i
`''
`
`,··.1,
`
`'
`
`, ..
`' I
`.,.
`I 1!·'1'
`,,
`
`1
`1:1
`
`I
`
`Page 17 of 38
`
`

`
`'
`
`'
`
`'.1,
`
`I
`
`'
`
`'
`
`1,1.'
`~~,'1 ,II
`I
`I ' 'II·
`
`VUMA Proposed Sb
`
`ard
`
`VESA .Confidential
`
`CPUCLK
`
`'MGNTt
`
`Bus Own•
`
`:\\,. ________ __,1
`
`aa .. §ic
`
`~ ~la~~c ~
`~ ~IIR ~ HPR X ·GNTDj
`
`v~tp; o;;~
`
`t ~1011 ~ carei..,IC
`Rtif
`)
`
`P@T
`
`A !titer StiM
`
`R~l'l'
`
`· 10. High priority request and delayed bus release to VUMA device
`.
`.
`: ..
`:5
`:e
`.
`.
`
`:3
`'
`
`:7
`'
`
`'
`
`·8
`
`:g
`
`CPUCLK
`MREQII ~ 'I
`
`'
`
`:\
`
`•/
`'
`
`MGN'rt
`
`Bus Own•
`
`9§1 Ljr;
`
`; A !titer Stile
`
`Hl5!T
`
`~ Llll!i X
`
`X i!~at ~ VUMA zs;;Cll ~ Float ~ COr•l.f191C ~
`.
`HiS!'f'
`);
`GR'ft5
`~
`
`HP~
`,.
`
`: 4.4 Latencies
`
`· 1. 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