VUMA Proposed Stan;
`
`.1
`
`Confldentiai
`
`
`
`MREQ#isd:ivenhwfromdoekedge1Cmelogienmplesitaefivednciockedge3.
`Arbitercangivethebtlszightawaxsocorelogicdrivesall-sftissignalshighfromthe
`' same cioek edge. Core logic In‘-states-all the
`(W3 and tie) and drives
`MGNT# activefromclockedge4.VUMAdeviee-min MGN'I‘# active atclock edge
`Sandslzirtsdzivingthebusfi-cmtbesameedge;
`
`‘I'hesharedDR.AM signalsared:ivenbyVUMAdevicewi1enitistheownerofthe
`physica1sysnemmemmybm.VUMAdeficemIinquishesthcphysicalsysmmmemonr
`busbyde-assertingMREQ#.BusArbitergives1heb11sbaektoeoreIogicbyde-asserting
`MGNT#.A1so, asmemionedabove,beforecoreiogicstansdrivingti1e'bus, VUMA
`device should drive the sftfs signals high for one CPUCLK clock and tri-state them.
`VU1'v[Adcviceshoulda1sotri-stateallthesharedtfs signals.-'1'he'£loa1eonditiononthe
`busshouldbeforone CPUCLKclock,bet'oreeerelegiestartsd:ivingthebus. These
`activitiesareoverlappedtoimproveperformanceasshowninFigure 5-6.
`
`Figure 5-6 Bus hand ofi from VUMA device to core logic
`
`
`
`VUMAdeviced1ivesalls!tlssignalshighfi‘nmclockedge3.VUMAdeviee1ri-statesall
`shared signals (sftfs and us) and de-asserts"-‘B/£REQ# fi'om'eldci:' edge 4. Core logic
`samples MRI-3Q# inactiveonclockedge5.Corelogicdrivesa1lsharedsignalsand
`deasserts MGNT# fmm clock edge 5.
`
`5.3.2 DRAM Precharge
`
`25
`
`Version. 1.01:. Rein 0.44:
`
`Page 211 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 211
`
`

`
`VUMA Pmpmd 5%”
`
`lard
`
`. VESA Confidential
`
`Whmthephysicalsystemmemonrh1Lsishmdedofi‘fiummaeiogicwVUMAdevioeor
`fieeavusa,&nDRAMneedstohepmehargedbefo:ed:enewmstummchivingit.
`PmofthisprechargecanhehiddenhyovuleppihgflfihthenhiuafiohprotocoL As
`showninFig:m_:_5-5 and5_-6.a1l_theD_R.AM .control.si5nals (includin§R.AS# lines)are
`driven high forand tri-stated
`lines are tri-
`nmed,mflll1psonfl1osefines-ptfllthemmabgiulhighlhmfihefiinewmamagets
`theconflDLtheRAS#finesareakeadybeen'pmehargedformuCPUCLKclocks.Ihe
`restofthepreehnrgeneedstohetalnencat-e'hythenewmaster.
`
`.
`
`.
`
`1.VUMAdevieegetsthebusfiomeore1ogic-AsshowninFigute5-5,whenVUMA
`deviceg:tsthephysicalsysaemmunoryb1mucloekedge5,1heDRAM-hasbeen
`prechargedfortv-woCPUCI.KciocIcs.VUMAdevieen.eeds,~totake-eareoftherestofthe
`DRAMpmchmgeTIfispre:hargecanbeovu'lappedbyVUMAgiflice.oversomeofiB
`fictivity e.g.VTJMAdevicemaybenmningatadifl‘e:entcloc.lcthan1heCPUCLKclock
`andtheprechargecanheoverlapped withthesynchronizafion;ofMGNT#signal.VUMA£
`deviceeancalculatethcnumberofcIocksitneedstoprechaIgetheDRAMwiththe
`followingformula:
`
`No. orvuma device clocks for DRAM plrecharge - {RAS# Preehatge Time (tR.P) - (2 *
`cpucuc Clock Time Period)}i VUMA device Clock Time Period
`
`Example: cpu running at 55.55 MHz, WMA device runniog at so-MHz. 70115 Fast Page
`DRAM used.
`
`No. of VUMA device clocks for DRAM precharge = {$0135 - (2‘ 15115)}! 20115
`= {Z0115}! 20ns
`- 1 clock
`
`2. Core logic gets the bus-from VUMA device - As shown in Figure 5-6, when core logic
`gets the physical system memory bus" at clock 5, the DRAM has beetrprecharged for
`two CPUCLK clocks. core logic needs to take care of the rest of the DRAM preeharge.
`This precharge can be overlapped by core logic over some of its a:ctivity.e.g. driving of
`new row address. Core logic can calculate the number 51* clocks it needs to precharge the
`DRAM with the following formula:
`_
`_
`__
`-
`
`No. of CPU clocks. for DRAM precharge - {RAS# Precharge Time (IR?) - (2 * CPUCLK
`Clock Time Periocl)}f CPUCLK Clock Time Period
`_
`
`Eltample: CPU ntnning gt 66.66 MHz. VUMA devlee
`DRAM used.
`
`ex 50 MHz. 701:5 -Fast Page
`
`No. of CPU clocks for DRAM preeharge - {5Dns - (2“ 1Sns.)}! 15:15
`- {2Dns}/ 151:3
`- 2 clock
`
`35
`
`Version. ‘Lop. Rev. 0.41:
`
`Page 212 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 212
`
`

`
`VUMA Proposed stam.
`
`.1
`
`;EsA cor-rfldantlal
`
`5.4 Synchronous DRAM
`
`Synchronous DRAM support is optional for both lcorelogic and VUMA device. Various
`SynehmnousDRAMsupportscenariosareasfol1ows:
`
`1. Core logic does not support Synchronous DRAM - Since core logic does not strpport,
`Synchronous DRAM, there would not -be u1y'S'y'nehronous DRAM is the physical
`systemoryandhencewhetherVUMAdevicesupponsSynchronousDRAM or
`not is inelevant.
`
`2. Core logic. supports Synehronom DRAM - When core logic supports Synchronous
`DRAM, VUMAdevicemayormaynotbe'supponingiLWheti:eroorelogicand
`VUMAdevicesupponSynchtonousDRAMornotshould'beuansparenttothe
`operating systemandapplieatiom programs. Toachievethe
`systemBIOS
`needs to findout ifbothcorelogicandVUMA=device support"this_feamreandsettl1e
`systemappmptiateiya1booL1he-foflowingalgofithmexplainshowitcanbe
`achieved. The algorithm is only included to explain the feature. Refer to the latest
`VUMAVESA BIOS Extensions forthen:1ostnpdatedBIOS calls:
`'
`
`a.Read<VUMABIOSsignan.tresI:'ing(tefertoVUMAVESABIOS
`E.xtensions)>. Check if VUMA device supports Synchronous DRAM.
`b. If VUMA device does not support Synchronous "DRAM, do not assign
`Synchronous DRAM banks for Main VUMA Memory. Assign Main VUMA
`Memory to Fast Page Mode or EDO bank. Also, ifmntiliary VUMA Memory is
`assigned by operating system to Synchronous DRAM banks, do not use it. Either
`repeat the request for Auxiliary VUMA Memory till it is assigned to Fast Page
`Mode or EDO bank or use some alternate method.
`
`c. If VUMA device supports Synchronous DRAM, read < VUMA BIOS signature
`string (refer to VUMA VESA BIOS Extensions)> to find out ifVUMA device
`supports multiple banks access.
`d. If only single bank access supported on VUMA device, exit, as the Main
`VUMA Memor'yandAtndiiaryVUMAMemo1'ybankisfixed.
`e. If multiple banks access is supported and if the CS# for Synchronous DRAM
`bank is supported on VUMA device. assign the Main VUMA Memory to obtain
`the best possible system performance and t.
`
`5.4.] Programmable Parameters
`
`Synchronous DRAM: have trarious prograrninable paiimnetm. Core logic programs
`Synchronous DRAM parameters to obtain_" " the best possible
`The most eficient
`wayforVUMA devicetoprogramits DRAMcontrolleristomnkeaBIOSealltofind
`
`27
`
`I
`
`Version." 1.0p. Rev. 0.4;»
`
`Page 213 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 213
`
`

`
`vum Proposed sax ml
`
`. VESA Confidential
`
`om1hepa:m%eorclogichasdecidedmdpmg1'a|nilsDRAMoonunflerwi1hthe.
`samepm-mnetus.Altunamly,VUMAdevieeoouldpmgmnisDRAMcomuHcrwith
`omorafldifluunpm-mneters. lfVUMAdevicepmgrunsitsDRAMconnol1erwi1l1any
`difi'er¢ntpmanmus,hisVUMAd¢vice’srcsponm‘bfli1ymmpmg:amSym1numus
`DRAMbackwith_fl1e-ofiginalpflfimfitfiaabefomdmephysinlsymmmemaiyhmis
`handedofitocorclogic. InoIherwords,VUMAdeVin&~isfi'eetochangeanyora1lof1he
`para:neters,btnthechangcshoI1ldbcu-anspazenttocmtlogic.
`
`How core logic progpams vuinns pamueezgand how VU1v‘£A-device could inquire them
`is as follows:
`-
`'
`-
`
`.l.BurstLengfl|- Bm'stLengthcanbeprog1'ammedas1,2ar4.VUMAdevioeneeds
`IaomakeaBIOS_call<RemmMemarySpeedType(refertoVUMA
`VESA BIOS.Exn:nsions)> to find outthe Bust Length.
`2.CASLatency- AsCASlatcncydep:ndsanth:speedofSynchrunansDRAMused'
`andt.heciockspeed,.1hisst.Indarddoesnotvmn1iofixthis
`pa:a:n:ter.Core1o_gic.-progralnsthispammetertoanappmpziate
`valuz.VUMAdeviceneaistomakeaBIOScall<Rm:rnMcmory
`Speed Type (1-cferto VUMA VESA BIOS Ext:nsions}> to find out
`theCASlatency.
`3. Burst Ordering-Most efliciant Burstordenhgdependsuponthetypeof CPUused.
`VUMAdsviceneedsto'makeaBIOScall<Rctu:nMemorySpeed
`Type(refcrtoVUMAVESABIOSExt:nsians)>tnfindoz.1tth
`Burstorder.
`'
`
`5.4.2 Protocol Description and Timing
`
`AlltheDRAMsigna1sare-sharedbyeorclogic.andVUMAdeviee.Theym'ed1ivenby
`currentbusmaster.WhencorelogicandVUM.Adevieeha:1doverthe.bustoeachother.
`theymustdriveallthesharedsftlssigna15highforonI:CPUCLKc1ackand~th:nui-slate
`thcm.A1so, they should tri-stateallthesharedt/s signals.
`
`SynchronousDRAMsuepmchmgedbypechuge¢ommmd.Wh:nfl::physica1systan
`muno1ybusishsndedofi'&omcomlogicmVUMAdeviceorvicea-vu3a,fl:eDRAM
`prechargehasnmoptions:
`I
`_
`.
`'
`
`1.-Pmchargeboththe.ii1tema1banks.befomhandeofi'=.I}fisisasimplecasewhueboth
`theh1terna1banksofthcacfivesynchmmusDRAMbankmep:edm-gedmdthenfime
`busishandedofi‘.
`.
`-
`
`-
`
`2.RequesfingMastermodpsthephysica1systunmunoxyh:sudsynchrumusDRAM
`imunalbanksneednmbeprecharged-hfl:is_caseth:ruquesfingmastumwpsthe
`DRAMaddmssandmmoIsigna1smu=ck.the.9pmpggesinthehmmaIbanksofthe
`acfives)mchmnousDRAMbank.Theintanalbanksof1heacfiVesyndnunousDRAM
`
`23
`
`Version. 1.0p, Rev. 0.4]:
`
`Page 214 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 214
`
`

`
`VUMA. Proposed stam .1
`
`__
`
`)Es_A Confidential
`
`uenotprechargedwhenthephysicalsystemmemnrybusishanded-ofi‘mthe'
`mquesfingmastenlfmededthemquesfingmenunkescaeofprechugeafiugetfing
`thephysicalsystemmernotybus.
`'
`
`Both core logic and VUMA ‘device have an option of either-implementing or not
`impiemenfingDRAMmooprfeanneWhetha-corelogicandVUMAdevicesuppon
`DRAMn1oopornotshouldbersnsparunmflreoperatingsysmmandappfica1ign
`programs. To echievetheu'nnspuency,systemBIOS-mdVUMABIOS'needto findout
`ifboth'com1ogicandVUMAdwiumpponfiisfianncmdsctfi1e§ysmmappropfiamiy
`atboot.ThefoHowingalgofithmarplainshowitcanbeaehieved.Thealgofithmisonly
`includedtoexplainfl1efeamre.Referto1helstestVUMAVESABIOSEnensionsforthe
`mostupda1edBIOS calls:
`
`1. System BIOS reads <VUMA BIOS signature string (referto VUMA VESA BIOS
`Exzensions)>, tofindo1nifVUMAdevicecansnoopthephysiealsystem:ne1norybus.
`2.Ifno, Systernfllospmgmmscoieiogictoprechargesynein-anousDRAMbeforebus
`hand-off.
`
`3.Ifyes, SystemBI0Spmg1'amscorelogicnottopreehargesynchrunmrsDRAMbefore
`bus hand-off.
`
`4. V'U'I\r1ABIOSmakaca1L<F_~¢Pon_VUMA-core logic (refertoVUMA
`VESA BIOS E.xtensions)>,
`to find out ifcore logic can snoop the physical system
`memory bus.
`’
`S. Ifno, VUMA BIOS p1fograms'VUMA device to precharge synchronous DRAM before
`bus hand-ofi'.
`
`6. If yes. VUMA BIOS programs VUMA device not to preeharge synchronous DRAM
`beforebushand-off.
`
`None, only one, or both of core logic and VUMAI-device can sujiport this feature. When
`only oneof1hemsupponsthisfearmemerno1yprech:rgewfllbeasymmeuicali.e. there
`will be precharge before hand-ofi‘ one ivay and no precharge the other way.
`
`5.4.2.1 Non-Snoop Cases
`
`The sharedDR.A.M signals are drivenby core logic when it istheownerofthephysical
`sys1emmemorjrbus.VUMAdevicereques13thephysicalsystunmunorybusby
`assenmgMREQ#.BusArbher3nnsthebusbyassadngMGNT#.Also,befmeVUMA
`device starts driving theib-us‘, core logic should drive all the shared sitls signals high for
`one CPUCLK clock and triestete them. Core logic should also tri-stateall the shared tis
`signals. The tri-state condition on the bus should be for one CPUCLK clock, before
`VUMAde\&cestamdfifingthelms.1heseacfivifiesmeoVerlappedtoimpmve
`- performance as shown in Figure 5-7. Since VUMA device does not
`DRAM
`snoop feann-e, DRAM is precharged before heading off the physical system‘ ory bus
`as shown in Figure 5-7.
`.
`"
`
`29
`
`Version. 1.01:. Rev. O.4p
`
`Page 215 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 215
`
`

`
`VUMA Proposed Sta ml
`
`.- VESA Confidential
`
`Figures-7 Bushandoflfrom _Core
`
`or-ucu<
`
`
`
`MR.EQ# is driven low fi-om clock edge 2. Core logic samples it active on deck edge 3.
`Arbitercangivediebusrightaway, so corelogicgivesprechargecoinmandto DRAM
`from the same clock edge. Core logic drivesall theahared sftfs signals high Eon: clock
`edge 4. Core logic tri-states all the shared signals (sftfs and tie) and drives MGNT# active
`fi'omcloekedgeS.VUMAdeviocsan1plesMGNT#acfivcatclockedge6andst£u'ts
`driving the bus fromthe same edge.
`'
`
`ThesharedDRAMsignalsaredrivenhyVUMAdevicewhenitistheownerofthe
`physical system memory bus. VUMA device relinquishes the physical system memory
`bus by de-asserting MREQ#. Bus Arbiter gives the bus baekto core logic by de-asserting
`MGNT#. Also, as mentioned above, before core logic starts driving the bus, VUMA
`device should drive all the shared sft/s signals high for one CPUCLK clock and tri-state
`them. VUMA device should“ also tri-state all the shared tls signals"; The float condition on
`the bus should be for one CPUCLK clock, before core logic starts driving the bus. These
`activities are overlapped to improve
`as shown in Figure 5-8. Since core logic
`does _not support DRAM snoop feature, DRAM is precbarged before handing ofi' the
`physi.cal'systern'n1en1ory bus as shown in Figure 5-8.
`_
`‘
`
`Figure 5-8 Bus hand offfrom VUMA device to Core Logic
`
`
`
`VUMAdetdccgivesprechargewmmmdfiomdockedge3.Itdrivesa11.sbm'edsMs
`signals high from clock edge 4. It tri-states all shared signals (sftls and tfs) and de-asserts
`
`30
`
`'
`
`Versiori. 1.op. Rev. 0.4;:
`
`Page 216 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 216
`
`

`
`Vl_JMA Proposed Shndrri
`
`"EBA Confidential
`
`MREQ# fromclockedge s. Core_logicsar_nples MREQ#ioactiveonciockedge 5. Core
`logicdrivesallsharedsigna!sanddeassertsMGNT#fi'omclocl:edge6.
`
`5.4.2.2 Snoop Cases
`
`'l'hesl:aredDR.AM'signalsaredrivenbycorelogicwhenitistheownercfthephysieal
`systen1memor'ybusVUMAdevicerequststhephysia|laystemcrybusby
`asserting MR‘:-3Q#. Bus Arbiter grants the bus byuserting MGNT#. Also, before VUMA
`devioestartsd1ivingthebus,oore_logicshouldd1'ivealltbeshared:/tfssiytalshighfor
`oneCPUCLKdoekandni-smtemuncomlogicshouldalsoui-smmaflthesharedfis
`signnls.'I‘heIri-stateconditiononthebusshouldbeforoneCPUCLKclock.before
`VU'MAdev1ce' sta1'ts'drivingd1ebns.'I'hesec1:tivifiesareoverlappedtoitnprove
`~ performance as shown in Figure 5-9. Since VUMA devicesuppcrts DRAM snoop
`feature, core logic does not precharge DRAM before handing of the physical system
`memory busasshcwninfigure 5-9.
`
`rigms-snug handoflfi-omeorelogictoVUMAdeviee
`
`J 2
`Z 1
`is
`14
`is
`27
`is
`:9
`arm '\_r‘\J"\_/‘N./‘\_/—\_/‘\.r\_r'\_/*\_
`
`WEGI‘ '' ' '
`
`
`
`
`cm
`-
`Signals
`' u.
`
`'“
`
`.
`.
`.
`.
`h
`_5,-9..., __
`
`.
`-
`
`. .
`-
`
`MR.EQ# is driven low from clock edge 2. Core logic samples it active on "clock edge 3.
`Arbiter can give the bus right away and since VUMA device supports DRAM snoop
`feature, core logic drives all the shared s_/tfs signals high from the e clock edge. Core
`logic tri-states all the shared signals (sftfs and tfs) and drives MGNT# active fi'om clock
`edge 4. VUM.Ad.evice samples MGN'l'#'activeatc_iock edge 5 andstartsdrivingthebus
`from the same edge.
`"
`
`1hesbaredDRAMsignalsare_dtivenbyVUMAdevicewhenitistheom:erofthe
`physical system memory bus. VUMA device
`the physical syste.m memory
`bus by de-asserting MREQ#. Bus Arbiter ‘gives
`to corelogic by de-asserting
`MGNT#. Also, as mentioned above, before core ‘logic starts driving the bus, VUMA
`device should drive all the shared sftls signals high for one CPUCLK clock and tri-state
`them. VUMA device should also tri-state all the shared t/s signals. The float condition on
`the bus should be for one CPUCLK clock. before core logic starts driving the bus. These
`activities are overlapped to improve performance as shown in Figure 5-10. Since core
`
`31
`
`Version. 1.0p, Rev. 0.4p
`
`Page 217 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 217
`
`

`
`VUMA Proposed St:
`
`‘ard
`
`.
`
`VESA confidential
`
`not
`logic supports DRAM snoop feanne,
`handing ofi' the physical system memory bus as shownin Figure 5-10.
`
`DRAM before
`
`.
`
`Figure 5-10 Bus hand ofl’ from VUMA device to core logic
`
`
`
`VUMA device drives all shared s/t/s signals high fi'om clock edge 3. It tri-states all shared
`signals (s/t/s and t/s) and de-asserts MR.EQ# from clocl; edge 4. Core logic samples
`MREQ# inactive on clock edge 5. Core logic“ drives‘ all
`signals and deasserts
`MGNT# from clock edge 5.
`
`5.5 Memory Parity support
`
`Memory Parity support is optional on both core logic and VUMA device. If core logic
`supports parity it should be able to disable parity check for Main VUMAiMemory and
`Auxiliary VUMA Memory areas while parity check on the rest or the physical system
`memory is enabled.
`A
`
`5.6 Memory Controller Pin Multiplexing
`
`but are
`The logical interfaces for Fast Page, EDO and BEDO DR.AMs are very
`significantly different than that of Synchronous
`If motl1er%.l;oard designers Want
`to mix difierent DRAM technologies on the samemother board,‘core logic
`have to
`multiplex DRAM control signals. The meaning of a multiplexed signal will
`on the
`type of DRAM core logic is accessingat a given time. If a
`supports
`multiple hanks access
`of
`DRAM technologies, it
`also have;to
`multiplex DRAM ‘ccntrolpsignals. Bourooro logic and
`devices have to have
`same multiplexing scheme. The appropriate JEDEC standarclshould beefollowed for
`multiplexing scheme.
`
`d.0 Boot Protocol
`
`32
`
`Version. 1.01:. Rev. O.4p
`
`Page 218 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 218
`
`

`
`VUMA Proposed Stan
`
`:d
`
`VES_A Confidential
`
`6.1 Main VUMA Memory Access at Boot“
`
`In unified memory architecture, part of the physical system memory is assigned to Main '
`VUMA Memory. The
`operating
`are . not aware of unified memory
`architecture. Also, some of the existing operating systems size memory themselves. This
`poses a problem as the operating systems after sizing the total physical system memory,
`will assume that they could use all of the memory and might overwrite Main VUMA
`Memory. The solution to this probl is explained below:
`
`.
`
`As shown in Figure 6-1, the solution to this problem is to disable core logic access to
`Main VUMA Memory area at boot time. In that case even if operating system, sizes the
`memory, it will find only (total physical system memory - Main VUMA Memory) and
`will not be aware of the Main VUMA Memory existence. This will avoid operating
`~ system ever writing to the Main VUMA Memory area. If VUMA device supports.
`multiple banks access, it can access total physical system memory all the time. If VUMA
`device supports single bank access, it can access the bank of Main VUMA Memory all
`the time.
`
`If VUMA device is a graphics controller, it needs a special consideration. Video screen is
`required during boot and since core logic can not access the Main VUMA Memory, it can
`not write to it. The problem is solved by programming the graphics controller into a
`pseudo legacy mode. In this mode graphics controller treats Main VUMA Memory
`exactly the same way as in non. unified memory architecture situations i.e. as if it has its
`own separate frame bufier. So now, the total system looks just like a non unified memory
`architecture system and this mode is called as pseudo legacy mode. Core logic performs
`accesses to video through legacy video memory address space of A000:0 and B00020.
`These accesses go on the PCI bus. Graphics controller claims these cycles. Graphics
`controller still needs to arbitrate for the physical system memory bus. After getting the
`bus, graphics controller performs reads/writes to
`VUMA Memory (frame buffer).
`After the system boots, it is still in the pseudo legacy mode. When operating system calls
`display driver, the driver programs core logic to allowaccess to Main VUMA Memory
`and switches the system from pseudo legacy mode to unified memory architecture.
`
`In the case of other type of VUMA devices, device driver needs to program core logic to
`allow access to Main VUMA Memory.
`
`Figure 6-1 Pseudo Legacy Mode
`
`33
`
`Version. 1.0p, Rev. O.4p
`
`Page 219 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 219
`
`

`
`VUMA Proposed Sta
`
`ard
`
`. VESA confidential
`
`scram‘
`
`
`
`'1'hefol1owi.ngalgorithmsumsupthebootprocessii1thecaseofVUMAdevicebeing a
`graphicsccntroller:
`
`'
`1. System BIOS sizes the physical system memory.
`2. System BIOS reads the size of Main VUMA Memory at previous boot (where this
`valueisstoredisSystemBIOSdependeu1,butmedstobeinsomesortofnonvulatile
`memory).
`3. System BIOS programs its internal registersiao reflectthattotal memory available is
`[total physical system mory(fi'om step I) - Main VUMA
`at previous boo
`(fromst=p2)l-
`'
`4. System boots and operating system calls display driver.
`5. Display driver makes a System BIOS call; <EnablelDisable Main VUMA Mory
`(refer to VUMA VESA BIOS Extensions)>, to progrm core logic internal registers to
`reflect that it can access total physical system-memory.
`6. Display driver switches VUMA device to unified memory architecture mode.
`
`Even though core logic can not access Main VUMA Memory till the time display driver
`enables it, core logic is responsible for Main VUMA Memory refresh.
`
`VUMAdeviceshouldcIaimPCI-MasteraccessestoMsinVUMAMemoryfill display
`driver enables core logic access to that area. Core logic shouldclaim PCI-Master accesses
`to Main VUMA Moryafter display driverenables core logic access Iothatarea.
`
`5.2 Reset Stats
`
`0npoweronrueLbothcorelogicandVUMAdevicehavetheirImifiedmetnory
`architecture capabilities disabled. MR.EQ# is dc-asserted by VUMA device and MGN'l'#
`is dc-asserted by core logic. System BIOS can detect if VUMA device suppers unified
`memory architecture capabilities by reading <VUM.A BIOS signature string (refer to
`VUMA VESA BIOS Extensions)>.
`
`34
`
`Version. ‘Lop. Rev. 0.4;)
`
`Page 220 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 220
`
`

`
`7.0 Electrical Spoci”-ation
`
`7.‘! Signal Levels
`
`levels fo;'tI1earbitra1ion signals only. DRAM
`This section
`signal1evelsdependonthetypeofDRAMusedmdheneeoannotbespecifiedbythe
`
`MREQ#
`
`MGN'I'#
`
`CPUCLK
`
`output
`input
`
`output
`input
`
`output
`input
`
`7.2 AC Timing
`
`5v 'I'I'L or 3.31: LVTI1.
`Sv TTL for 51: bufi'er, 5v tolerant LVTIL for 3.3? l:Iufi'er
`
`Sv 'I'I'L or 3.31: I..V’I'I'L
`Sv "TIL for Str bums‘, Sv tolerant LVTTL for 3.3V buffer
`
`5v 'I'I'L or 3.31: LV'I'I'L
`5v TIL for Sv bu:fl"er, Sv tolerant LVTII. for 3.31: buffer
`
`This section describes the AC timing parameters fiorthe ubitration signals only. DRAM
`Actirning paramete1sdependonthet}'peofDRAMusedandhencecannotbespecified
`bythestanda:d.BothMREQ#areMGNT#timingparamete1sa:ewithrespectto
`CPUCLK rising edge.
`
`MR.EQ#
`
`output
`
`_
`‘input
`
`MGNT#
`
`output
`
`input
`"
`
`- 10 ns
`tClk to Out (max)
`- 2 ns
`tClk to 011: (min)
`SetuptimetSU(m.in)-3ns
`-Hold time}!-I (min)
`- 0 ns
`
`- 10 ns
`tClIt to Out (max)
`- 2 as
`ICE: to Ont (min)
`SetuptimetSU(min)-3 us
`Holdtimet!-I(min)
`-Ons
`
`crucuc
`
`output
`
`clock frequency (max) - 66.66 MHz
`
`7.2.1 Timing Budget
`
`A1-nargin forsignal fl:'ghttimeandc!ockskewisaddedtothetimingpatan1eters.:!:2nsis
`allowed for the total of CPUCLK skew and signal flight time. Worst ease timing budget
`calculations for setup and hold time are as follows:
`'
`
`35
`
`Version. 1.05:. Rev. 0.4p
`
`Page 221 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 221
`
`

`
`VUMA Prop-md 5|:
`
`art!
`
`' V234 ‘confidential
`
`7.2.1.1 Wont use for Setup t'ime_
`
`Figure?-I showsmewo£s:case'£orsemp1sm;.:cikmou;fligmimeandc1ockskew
`haveconvexgedtoredueeavailablesemptime.
`
`Figure 7-1 Worst eneefor setup time '
`
`Drier Output
`
`Receiver Iran
`
`Sarroing CFLICLK
`
`[tCI.Kto0ut(max)+f1ighttime+tSU(min)+nega1iveCPUCLKskew]sCPUCL1(
`period i.e. 15n.s@66.66MI-Iz.
`_
`[10:15 + flig.httime+ 3ns +nega1:ive CPUCL.Kskew] s I5ns
`[flight _time + negative CPUCLK skew] 5 2:5
`
`7.2.1.2 Worst case for Hold time
`
`Figure 7.2 shows the worst case for hold time. zcik to out and clock skew have
`converged to reduce availahie hold time. Positive fligln time number helps in this case
`andhenceitisa.ssI.nnedtobezero.
`-
`
`Figure 7-2 Wont ease for hold time
`
`DliVlt_Ol.lDlI.
`Rnniver raw!
`
`Snuplag CPUCLK
`
`36
`
`Version. 1.0p. Rev. o.4p
`
`Page 222 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 222
`
`

`
`WI’-‘IA Proposed Sh:
`
`.111
`
`'vssA Confidential
`
`[posmve" crUcLIcst:ew+:H(min)]sucLxuoom(m:n)" ‘
`[positiveCPUCLKskew+0ns]S 2m
`positiveCPUCLKsk:ws2ns
`-
`
`7.3 Puflups
`
`Aflsfflssignusmedfilmtipswsmmintheinacfivssummfilhiomeragmtdrivesmem.
`Corelogichas:oprovidepullI:psfarallti1esv'tfssiy:als.VUMAdevicehasasoptionof --
`providing pullups on-some of the sftls signals. Alltfs signals need pulldnwns. Core logic
`hasmprofidepufldowmforali:h:fissigndsVUMAdsviéehuasopfionofprofiding
`pu1mowmmthefissignflsP1mupsandpufldowmmu1d'eifl1uhehncmalmthcchips
`orextcrnalonboard.
`
`Corelogicisresponsibie1_‘orpull_nps on_DRAMAcldress lines.
`DRAM Addr¢ss-
`DRAM control signals - Cor: logic is responsible for
`an DRAM control signals.
`VUMAdcvinehasm?optinnofprovidingpullupsonthem.
`Coniogicisrcspom:1'b1eforpull<i_ov.rnsonDRAMda1abus.
`VUMAdev-icehasasoption ofprnviding puiidownsonthem.
`
`DRAMDataBns-
`
`Pullupsandpulldownsareusedm
`signalsancihenceneedtobeweak. Rncommencledvaluefnrupulillpsmadpulidowns is
`betweenfllkohmandflokohm.
`'
`.
`
`7.4 Straps
`
`As some VUMA devices and con: lngic chips use DRAM data bus for straps, DRAM
`data bus-needs to be assigned for straps for difiemm controllers. The assignment of
`DRAM Data Bus for straps is as follows:
`‘
`
`VUMA device on Mothnrboani
`MD [0:19]
`MD [20:55] Reserved
`MD [55:53] Car: Logic
`
`Allthesnapsncedtobeplfllupsoflokohm.
`
`i'.5 DRAM Driver characteristics
`
`LoadingplaysauificslioleinDRAM'a§¢¢8sfimhg._hcaseofPCmothwboufisend
`‘ususcanecpmdfiieadsfingmanoryofasysmmby-addinggmaSIMMsHence,
`typicaIIythetota1DR.AM signal loadingisnotoonstantanglroouldvarysignificanfly.
`BothCoreLogicandVU1§/mdcvicemustbeablctodiivethemasdmiimloadthatthe
`
`37
`
`I
`
`Version. 1.0p, Rev. 0.4;:
`
`Page 223 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 223
`
`

`
`VUMA Proposed Sh
`
`‘ard
`
`.
`
`VESA Confidential
`
`motherboard -designs DRAM
`system motherboard is designed to accommodate. In
`signal loading can be excessive (on the orda of lO00pF for some signals)‘ and hence care
`must be taken for DRAM driver selection. Some general guide for DRAM driver.
`design are as follows:
`W,
`p
`«
`
`Slew-rate controlled drivers are recommended. Drivers with selectable current drive (such
`as 8/16 mA drivers) may be used. This can reduce overshoot and undershoot associated
`with over-driving lightly loaded signalsand can prevent excessive rise and fall time delay .
`due to not providing enough current drive on heavily loaded signals.
`
`As shown in Figure 7-3, buflers may be placed on the systemgmotherboardp to reduce the
`per signal loading and/or provide larger drive strength capabilities. DRAM Write Enable
`and DRAM Address signals are typically the most heavily loaded signals. Column
`Address Strobe signals may also become overloaded when more than two DRAM banks
`are designed into a system. 'I'l'L or CMOS bufi'ers,(typicalIy 244 type) may be used to
`isolate and duplicate heavily loaded signals on a per bank basis.
`244 type buifers
`typically have very good drive characteristics as well and can be used to drive all of the
`heavily loaded DRAM control signals if the Core Logic and/or VUMA device has
`relatively weak drive characteristics. If external bufiers are used, the bufier delays should
`be taken in to timing considerations.
`
`Figure 7-3 Optional Bufiers for DRAM Signals
`
`PCI Bus
`
`W
`Cora Logic
`
`‘
`
`.
`
`(._2:’_':_
`
`g
`
`VUMA
`
`Wider DRAM devices offer reduced system loading on some ofthe control signals. x4
`DRAMS require four times the physical connections on RAS, MA» (Address), and write
`enables as x16 DRAMS. The reduction in loading can be significant Ifthe
`has
`control over the DRAMs which will be used in the system, the DRAM width should be
`chosen to provide the least loading.
`
`33
`
`Version. 1.Dp, Rev.
`
`Page 224 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 224
`
`

`
`VESA®
`
`VUMA I Proposal
`
`(Draft)
`Video Electronics Standards Association
`
`1150 North First Street, Suite 440
`San Jose, CA 95131-2029
`
`.
`
`Phone: (408) 435-0333
`‘FAX: (408) 435-8225 '
`
`
`
`VESA Unified Memory Architecture
`VESA BIOS Extensions (‘VUMA-SBE)
`‘
`r
`r
`r Proposal _
`
` Version: 1.0
`
`
`
`
`
`Document Revision: 2.2p
`November 1, 1995
`
` Important Notice: This is a draft documt from the Vi_deopEIectronics Standards
`Association (VBSA) Unified Memory Architetitzne Committee (VUMA). 1: is only for
`
`discussion purposes within the committee and with any‘ other persons or _orga.nizafions
`that the committee has determined should be invited to review or otherwise contribute to
`it.
`It hm not been presented or ratified by the VESAigene1-al membership.
`’
`
`
`
` Purpose
`
`
`wilhoul specific knowledge or direct hardware access.
`
`To allow the video BIOS and other GUI specific software to control the VUMA hardware
`
`
`
`Summary
`
`
`This document contains a specification for a system and video BIOS interface, VUMA-
`SVBE. The VUMA-SVBE interface will allow the video BIOS and other GUI specific
`
`software to comrol the VUMA hardware without specific knowledge or direct hardware
`access. The hardware protocol is described in VESA document VUMA 1.0.
`I
`
`
`
`Page 225 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 225
`
`

`
`VUMA Proposed Sh. Jard
`
`VESA oonfiaontial
`
`scope
`
`Becauselhisisadrafi-dounnem.itmmmbeoonsiduodcomplmoracmnteinafl'
`mspectsalthoughevcryeiforthasbeenmademmixfinxizzeenm-s.
`
`Intellectual Property
`
`o Copyright 1995 -' Video Electronics Standards Assooiafion. Duplication of
`document within VESA mombercompaniesforretriewpmposes is pormittod. All other
`rights arc reserved.
`'
`
`' Trademarks
`
`All uademarks usedinthisdocumentarcthepropenyoftheirrespectiveowncrs. VESA
`a.ndVUM.Aaretradema.rhs ownedby‘ti:eVidooEiocl:'onicsSta.ndarrisAssocia1ion.
`
`Patents
`
`The proposals and standards developed and adopted by VESA are'in1c.nded to promote
`uniformity and economics of scale in the video elscn-onics industry. VESA strives for
`standardsthatwil] bcnefitbothltheindnisuyaiidedduscnsofvidoodocuonicsproducts.
`VESA carmotenmnethé1theadopfionofgs1_::idud;fl1euseofame$boddoom'bodasa
`standard: or the making. u;ing.'q1t.se1lJ_'ng ofa product in',_oompliance_ with the standm-d
`does not infringe upon the
`(including patents, utdomarks, and
`cop_\'1'igl-us) of others. VESA, thereforfimakes no
`or implied, that
`products conforrning to a VESA standard do not in:&inge on tho intoiloctual property
`rights of othcrs. and accepts no liability direct.
`or consequential. for any such
`infringemcnt.
`7
`
`3
`
`Version. -‘Lop, Rev. 2.29
`
`Page 226 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 226
`
`

`
`’VUMA Proposed Standai...
`
`T
`
`T VESA confidential
`
`Support For This Specification
`
`If you have a product that incorporates VUMATM, you should ask the company that
`manufactured your product for assistance.
`If you are a manufacturer of the product,
`VESA can assist you with any clarification thatyou 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.ve.ra. org
`
`Fax:
`
`Mail:
`
`Acknowledgments
`
`(408) 435-8225
`
`VESA
`
`2150 North First Street
`Suite 440
`
`San Jose, California 95131-2029
`
`This document would not have been possible without the efforts of the members of the
`1995 VESA Unified Memory Architecture Committee and the professional support of the
`VESA staff.
`
`Work Group Members
`
`Any industry standard requires information from many sources. The following list
`recognizes members of the VUMA Committee, which was responsible for combining all
`of the indust‘r_v input into this proposal.
`
`VUMA Chairperson .
`
`Rajesh Shakkarwar
`
`OPTi
`
`Software work group Members
`
`Tim Crawford
`Phil. Mummah
`Josh Grossman
`Christopher Rhodes
`
`,
`
`Work group leader. Cirrus Logic
`Phoenix Technologies
`53. Inc.
`Award Software
`
`3
`
`Version. 1.op, Rev. 2.2p
`
`Page 227 of 280
`
`Petitioners HTC & LG — Exhibit 1002,
`
`Petitioners HTC & LG - Exhibit 1002, p. 227
`
`

`
`VUMA Proposed Sta
`
`ltd
`
`«
`
`.
`
`v5s_A cgmfidgnfiag
`
`Revision History
`
`Initial Revision
`Rev .7
`Rev .3
`
`1
`
`1
`
`Aug 14 '95
`Aug 24 '95
`Aug 28 95
`
`Rev .9
`
`Aug 28 '95
`'
`V
`AddednsmwomF.modificdkmesndmovedsornennsimipfimsranovere£aa:oes
`tomhndnuVUM.Ammory,r:aovedflne§onfixunVUMAnanay,modified
`speedltype function
`
`Rev 1.0
`AddodVU'MAdevioeDRAMnlPPOrLSDRAMpu':meie::infimc:ion6
`
`Revl.1
`
`1
`Add items to Boot sequence
`Remove ufunczion all mdeiexnedupothasv
`
`1
`Rev 1.2
`Add changes suggested in previous
`
`'
`
`«
`
`Rev 1.3
`Added 32 bi1VF. Idd:dAnxflnIdifllIS.Ad&d I6 bixproteaedmode UF.
`Modified seveni ftmctions
`
`Rev 1.4
`Modified assumptions. issiis. updated some Emotions.
`’
`
`Rev 1.5
`Modified the able ofcomam
`
`Rev 1.6
`Minor modificauons to assumptions
`
`Rev 1.7
`Changes to assumptions. dc goals.
`Made cnzges in some functions per discusion I! last comrninee meeting.
`~
`.
`-
`.
`Made changes to how memory is reported. funes 1 & 6. Modified ROM sigmnire.
`
`Rev 1.8
`
`1
`Rev 1.9
`Modified funcuon 6 and assumptions. Other minor typos fixed.
`
`*
`Rev 2.0
`Modified Assumptions C. J. L. N. Added Issumptions O. P. Q. R. Removed issue 4.
`Added error code 5. 6. Changed unit oirnernory in ROM signsnoe fiom 1K to 64K
`Modified register definition in function 0.1.2. 6. and 7. Other minortypos fixed.’ '
`
`Sept 3 ‘95
`
`Sept11'95
`
`Sept 22 *95
`
`Sept 29 '95
`
`Oct 6 '95
`
`Oct 6 '95
`
`Oct 10 '95
`
`Oct 16 '95
`
`‘
`Oct 18 '95
`
`'
`
`»
`
`Oct 18 '95
`
`Oct 23 ‘95
`
`Rev 2.