`
`
`
`
`
`Thu01/02/2003 |[Netlist 3.0 released
`Sat 01/11/2003
`||[16:41 Ron White]
`We havethe reset block working correctly now. The target PC boots and the R400 chip is responding to configuration reads and writes.
`
`Operations to non-pei configuration registers fail. We are investigating the problem.
`Wed 01/15/2003 ||[15:23 Ron White]
`‘Thanks to Gabe, we found another mistake in the Star memory models we created for the R400. ‘The models are fixed and we are
`recompiling. We'll test it after supper.
`
`
`
`
`
`
`
`
`
`[22:42 Ron White]
`At least some ofthe R400registers are working in the latest IKOS compile. (BIOS scratch and VGA) Wewill test the registers more
`extensively tomorrow moming. The next step is to get the memoryinterface to work.
`
`Is it worth having a BIOS guystart his work on a second R400setup ifthe memory is not working yet ?
`|}[10:48 Gabriel Abarca]
`Thu 01/16/2003
`rank Hering wasjust suggesting Ronthat the best wayofgetting an operational MC and memorypadsfor IKOS wasto get the RT'L we use
`for regression and compile in into IKOS. Ron was saying he would like to try the idea, as this would give him boththings in one shot.
`
`Please correct me if] am wrong, but | believe the most stable path to get the good MC and pad RIT. models
`
`is: /proj/crayola vol3 nobackup‘mun regress/cravela sim chip 247 linux rtl/devel
`||[10:00 Liang Shen]
`Fri 01/17/2003
`Jac/Jamesstaried playing with IKOS (register access) lo prepare for BIOS bringup and found VGAis not cnabled in the current setting. Ron's
`
`team is going te tum VGA on shortly.
`Mon 01/20/2003||[11:52 Ron White]
`We have a VGA enabled R400 database that can be used for beginning the R400 BIOS work. Damon or I can demo the database whenever
`it is convenient.
`
`[15:00 James Huang]
`
`Continue verifying register access and noticed someare read/write ok, some are not.
`||[12:26 Gabriel Abarca]
`Tue 01/21/2003
`The intention ofthis e-mail is to have a seript for IKOSto initialize MC-MH.I cut and pasted the init sequence from ourchiplevel tests, took
`oul comments and clock related sequences and putil in the document below. I highlighted in bold blue the register wriles I think are needed.
`When registers were writlen several times, I only highlighted the last lime, assuming only one write is needed.Is that right?
`
`I would appreciate ifyou can reviewthis andtell us is something is missing or is not needed.
`Wed 01/22/2003 ||[12:39 Jae Chong]
`I have done the following test before IKOShad to shut downfor wiring ofthe lab.
`VGA wasenabled.
`
`The following VGArelated registers work properly with proper default values and read/wrile
`VGA_MEMWRITEPAGEADDR(Ox38)
`WGA MEM READ PAGE ADDR(Ox3C)
`VGA SEQUENCER RESET CONTROL(0x304)
`'WGA_MODE_CONTROL(Ox308)
`'WGA_SURFACEPITCILSELECT(Ox30c)
`I'WGA_MEMORY_BASEADDRESS(0x310)
`'VGA_DISPBUF1SURFACEADDR(0x318)
`VGA_DISPBUF2_SURFACE_ADIR(0x320)
`VGA_HDP_CONTROI.(0x328)
`
`All BIOSscratch registers work line initially, but sometimes stop werking alicr some otherregister read/writes.
`
`The following registers do not work properly:
`BUS_CNTL(0x30)
`BUS_CNTL1(0x34)
`CONFIG_CNTL(Oxe0)
`
`ATI Ex. 2087
`IPR2023-00922
`Page 1 of 69
`
`ATI Ex. 2087
`
`IPR2023-00922
`Page 1 of 69
`
`ATI Ex. 2087
`IPR2023-00922
`Page 1 of 69
`
`

`

`
`
`RBBMCNTL(xec)
`RBBMSOFT_RESET(Oxf0)
`RBBMSKEWCNTL(Oxf4)
`CONFIGMEMSIZE(Osf8)
`VGA_RENDER_CONTROI(0x300)
`MM_INDEX write works bul read docs not work
`
`BUS_CNTL, CONFIGCNTLare some ofthe registers that must be working before anything else.
`]/[12:38 Ron White]
`Fri 01/24/2003
`The R400 Buscontrol register problemis fixed. The bug was due to a bad rom controller stub model that broke the R400 readbackchain.
`
`
`
` Tue 02/25/2003
`
`
`
`We have another database that is ready to be used for the BIOS work.It's time for a more exhaustive R400 registertest. ‘he new RTL
`memory controller database will be tried after lunch.
`
`[14:58 Ron White]
`The RTL memorycontroller IKOS database is nel working in-circuil. Memorycontroller register ops are workingbulthere is ne activity on
`the RAS/CASlines aflerinitializing the memorycontroller. In addition, there seemsto be a naming mismatch belween the RTL MC pads and
`
`the RTL MC in the netlist. We are investigating further.
`Wed 01/29/2003 ||[16:33 Ron White]
`The R400 memory controller is alive and Bei is checking the waveformtiming. Once sheis satisfied with the timing andtells us howto change
`
`the memoryinit script, we will plug in our RAM chips andsee ifthey work.
`||[13:49 Ron White]
`Tue 02/04/2003
`
`Colin and Damonhad to compile around some broken hardware yesterday. Theywill be trying the RAMsat the end oftoday.
`|/[11:21 Gina Seto]
`[spoke to Brian | .eblane in marl. Hetells methat he will check in the final version ofthe register test today before lunch. | will probablytake
`some time this afternoonand try simulating it on the emulator. I'hen it should be ready to go for IKOS.
`
`Thu 62/06/2003
`
`The register test tests specitic blocks - so those blocks that IKOS is support can be tested individually.
`
`[11:34 Colin Stewart]
`We have some good news. We have a working database where the memorycontroller is almost working. This is with real DRAM chips
`attached and using the script that Bei sent us. Memory writes work and the reads are almost working. The problem withthe readsis that the
`data strobes are not delayed properly. This is a problem that we have seen before in previous chips and knowhowto work around. We are
`
`hworking on a compile and hopeto test something tomorrow.
`||[13:29 Colin Stewart]
`Fri 02/07/2003
`‘The firstmemory channel seems to be working properly now. Channel M0 seemsto be working properly but channel M1 has some bits that
`
`are failing. We are investigating this to sec if itis something wrong with ourtarget board. Channel M2 and M3arenot currently connected.
`Mon 02/17/2003 ||[16:15 Ron White]
`We have debugged the newin-cireuil target card (2 problems) and we nowhave a single channel of R400 memory working in the IKOS lab.
`
`We have to recompile tonight but we (optimistically) expect to have the hardware for 4 memorychannelsavailable tomorrowaround noon.
`Wed 02/19/2003 ||[13:26 Ron White]
`We have 4 channels working nowbut we also have minor refresh problem. Brian LeBlanc is using the setup this aftemoon. We'll debug the
`refresh issue tomorrow,
`Thu 02/20/2003
`||[11:52 Colin Stewart]
`We have increased the speed ofthe system and we now have 4Mb of memorypassingthe refresh rate test. Since the test takes a while we will
`try testing more memorylater but we have more confidence that the memory is working well. Wearestill using the ikos box for one more small]
`experiment and will be releasing it soon.
`|/[08:15 Brian [Leblanc]
`[ran the register tests overnight onthe partial Ikes netlist. There are still problems in the diagnostic itself, but | do believe that the values
`
`reported in the lollowinglogs (log file lolder) are valid. The CP blocktest caused a hang, this is nol very bad considering, the black is not
`entirely populated in this netlist.
`
`It is important to rememberthat the test is based on the currentregister specification, and the netlist is based on the register specification asit
`Iwas from December 23. There have been manychangesto registers in that time. Due to problems with the tools that extract the register
`information for the diagnostics,itis no possible to get the correct register information to matchthis netlist. This will hopefullynot be an issue on
`future netlists.
`
`[17:39 James Huang]
`Wetried followings on IKOS 30M today:
`- Video memory R/W through MM INDEX verilied.
`- Created a VGA modepreset script file, all VGA. surlace/(GRPH/Control registers are set correctlyaller running the seript.
`- Run VGA modesetcore, the system hangsup.
`- Access VRAM through VGAaperture, R/Wseemsnot working.
`Tomorrow's work:
`
`ATI Ex. 2087
`IPR2023-00922
`Page 2 of 69
`
`ATI Ex. 2087
`
`IPR2023-00922
`Page 2 of 69
`
`ATI Ex. 2087
`IPR2023-00922
`Page 2 of 69
`
`

`

`-Find out why VGA mode set hangs.
`-Find out why VGA apertureis not accessible.
`-Go through the VGA preset sequence with Gabriel to see ifthere is anything missing or wrong there.
`Wed 02/26/2003||[08:57 Brian Leblanc]
`[have spentthe evening debugging the diagnostics environment. | have found some inconsistencies between the emulator and ikes paths that
`are taken in the diagnostics. ‘here are still several so for unexplained issue | will have to debug.
`
`[16:56 Gina Seto]
`Before running a diag displaytest, ] needed to ensure that we were reading/writing to the DCPblock registers properly. Since the r4 register
`test results was showing a large numberofregisters in the DCP notpassing, I examined someofthose registers individually using db 128. For
`example, J tried writing to DIGRPI]PRIMARYSURFACEADDRESS:
`
`[17:27 James Huang]
`I still can't understand completely today what makes VGA modeset hang. But one problemhas been known,after enable MC and VGA
`preset, accessing VRAMvia VGAaperture will makeit hang. I can reprothat consistently by:
`
`1. Power up IKOS 30M.
`2. Run Bet_Fix5.db followed by PreVGA.db,whichset both MC and VGAsurface, HDP,controlete.
`3. Enable VGA memory access from CPU.
`4. Launch Debug, and type -d a000:0 command, systemfreezes nght away.
`
`The problem has been reported and showed to Gabricl.
`
`- aperbase=e0 120000
`- #=0
`- mmr1844
`Read MM Reg 0_ 1844 (c0126110): 00000000
`- mmw1844 12345678
`Write MM Reg 0 1844 (60126110): 12345678
`- mmr 1844
`Read MM Reg 01844 (e01261 10): 00000000
`‘The write did not work.
`Gabriel and Damon just came byto capture a waveformofthe memorywrite, and Gabriel will be looking at it.
`
`
`Besides this problem,it seems to methat stack was over flown when executing VGA modeset, reason is unknown yet. Thu 02/27/2003
`
`
`||[12:41 James Huang]
`-Can't read registers correctly after write to them, which confirms what Gina found yesterday.
`-In the current simulation environment, CPU register BP must be 0. Once it changes to non zero, Bies code will be screwed up right away. But]
`it's not acceptable to us because Bios does use BP for many cases.
`
`[18:34 Gabriel Abarca]
`Stephen Bagshawfoundthat the reasonofthe register problemis that we are accessing registers before the display clock generatoris
`programmed,so this defaults to using the crystal clock Lor display, and the crystal clock is not Loreed to run in IKOS.
`
`We do not want to ask for changes in the BIOS sequences, there should not be suchrestriction, so ifthis is not going to delay the bring up of
`the 4.0 netlist, we would like to modify the netlist 3.0 so that this chip level signalis also forced to PCI clock: IO_DC_xtalin
`
`[19:09 Stephen Bagshaw]
`‘T'o further comment on Gabriel's suggestions:
`
`Based on whatI'm seen from some IKOS waveforms,it seems that since the pixel clocks for both display controllers are not running on
`IKOS,accesses to certain "special" registers that require data to be resynchronized from the pixel clock domain to the clock domain of the
`registers (core clock) cause the chip to gel into a state where it would nol accept further regisler operations (basically a register cycle complete
`signal Gwhat wecall a "ready" signal) never gets sent acknowledging the end of the register cycle for this "special" read or write operation. The
`R400 hardwarethat handles register cycles has some "timeout"circuitry that happensifthis register cycle complete signal is not received. This
`is what is happening on IKOS when people see that register reads of a register that has just previously been written with a value always retum
`a valueofall 0s.
`
`‘The temporary workaround would be to make a small script that is run after the R400 chip boots on IKOSto programthe pixel clocks of
`beth display controllers to be rmmning. As Gabriel mentioned below,in the current IKOSnetlist, the pixel clocks default to be connected to the
`XTALIN input efthe chip. In the current IKOSnetlist, this XTALIN input ofthe chip is not connected to the clock. As a result, the
`resynchronization logic for these "special" register reads and regisler wriles does not occur properly and the chip gets into a condition whereit
`will timeoul on anyregister cycles.
`
`The correct workaround, as Gabriel mentioned,is for Ron's IXOS groupto connect the "IO_DC_xtalin" pin to a clock signal and recompile
`the R400 netlist 3.0 netlist. In the real chip this pin will always be hooked up to a clockoscillator or clock crystal. After this newnetlist is
`compiled, there should be no need for the temporary workaround mentioned above.
`
`
`
`ATI Ex. 2087
`IPR2023-00922
`Page 3 of 69
`
`ATI Ex. 2087
`
`IPR2023-00922
`Page 3 of 69
`
`ATI Ex. 2087
`IPR2023-00922
`Page 3 of 69
`
`

`

`Fri 02/28/2003
`
`|/[10:39 Minghua Zhu]
`Only the following registers in CRTC need PCLK running in order to read correct value back without RBBMIF timeout.
`
`DxCRITCSTATUSPOSITION
`DxCRITCSTATUSFRAMECOUNT
`DxsCRTC STATUS VF COUNT
`DsCRTC STATUS HV COUNT
`
`DCPis running off SCLK and de not have this requirement. So DCPregister like DIGRPH_PRIMARYSURFACEADDRESScan be
`accessed correctly even when PCLKis off. Please try on these registers.
`
`[10:59 James Huang]
`I tried registers below, none of them can read back properly with "18Feb_1400_net3_VLE30M_5.03_...debug.vmw". Someofthem seem
`to work with "8Febr400_net3_VILE30M_5.03_...renus.vmw" though: VGA_SEQUENCER_RESET_CONTROL.
`WGA_RENDER_CONTROL. VGA_MEMORY_BASE_ADDRESS, VGA_SURFACE_0_BASF,
`WGA DISPBUF2 SURFACE ADDR, DIGRPH PRIMARY SURFACE ADDRESS, D2GRPH PRIMARY SURFACE ADDRESS,
`VGA SURFACE 1 BASE, VGA DISPBUF1 SURFACE ADDR. DIGRPH SECONDARY SURFACE ADDRESS,
`D2GRPILSECONDARY_SURIFACE_ADDRESS, VGA_SURF'ACE_0_SIZE, VGA_SURFACE_1SIZE, VGA_SURI'ACE_0_INI‘O,
`'WGA_SURFACE_1_INFO
`
`Also,all ofthese MC registers can't read back correctly after programming them with the current vmww,although the programming seems
`effective since we canaccess frame bufferafter.
`
`On the other hand,all seratch registers function well.
`
`[11:38 Damon Tohidi]
`We have a second R400 setup available on VLESMfor the BIOSgroup.
`
`[16:57 James Huang]
`I justtried thisVLESM. Nor VGAregisters neither ext. registers (except Bios Scratch register) are accessible. Scratch register and VRAM
`access seems fine.
`
`[17:03 Colin Stewart]
`The VLESM and the VLE30Mare based on the samenetlist.
`
`[17:13 James Huang]
`I think so too. WhatI did was: launch Debug after running bei_fix5.db , and read 3C3, which should be the IO base address of the ASIC, but
`it gave me "TTall the time. A few other VGA registers read same thing, while VGAis enabled byset "VGA Disable" to "Z".
`
`[18:38 Gabriel Abarca]
`‘The IKOSnetlist fix for the registeris being compiled over the weekend
`Mon 03/03/2003 |][11:12 Colin Stewart]
`The fixed database for the 30M with the IO DC xtalin clock tied to PCICLK,is ready.
`It is located: net/../0O2Mar1400net3VLE30M_5.03_...debug.vmw.
`Tue 03/04/2003
`|/[14:28 Brian Leblanc]
`I have beentrying out the 5Mand have had difficulties, even more so than on the 30M with all the register writes and reads.I havelogfiles in
`file:‘ma_bleblanc/ikos/logs for runs each ofthe systems. The directories are labeled for which IKOS box and whichnetlist was used, 3_0_0
`referring to the netlist without the clocks added in.
`
`[18:11 Gabriel Abarca]
`Colin is working on porting the fix he did in the 30M to the 5M.The display registers Gina and T tried a few moments ago, which were broken
`before. work nowin 30M.So porting that to the 5M will help. Also there may be register issues in the 5M duc to the blocks we stubbed.
`
`
`
`
`
`Colin is working onthal too. Wed 03/05/2003 ||[13:52 Gina Seto]
`
`INadisplay yet but I was able to run the palette read/write test. on IKOS. Both the test for the standard palette and the PWLpalette passed.
`Thedetails ofthe test are in the attached word file PaletteRWTest.doc - ifyou have any questions aboutthe test please ask.
`
`In addition,I ran a quick sanitytest on db128:I tumed onautofill, checked that it completed, then read a fewlut values. The values I checked
`read back correctly:
`- aperbase=e0 120000
`- #0
`- mmr 1928
`Read MM Reg 0_ 1928 (c01264a0): 00000000
`- mmw1928 1
`Write MM Reg 0 1928 (¢01264a0): 00000001
`- mmr 1928
`Read MM Reg 0_ 1928 (e01264a0): 00000002
`- mmr 1925
`
`ATI Ex. 2087
`IPR2023-00922
`Page 4 of 69
`
`ATI Ex. 2087
`
`IPR2023-00922
`Page 4 of 69
`
`ATI Ex. 2087
`IPR2023-00922
`Page 4 of 69
`
`

`

`Lastly, I tried runningabasic displaytest (640x480, 8bpp) butthe test fails and hangs. I need to investigate this more.
`
`Read MM Reg 0_ 1925 (e0 126494): 00000000
`- mmrl925
`’Error- Invalid command
`- mmr1925
`Read MM Reg 01925 (20126494): 00401004
`- mmr 1925
`Read MM Reg 0 1925 (60126494): 00802008
`- mmr 1925
`Read MM Reg 0_ 1925 (e0 126494); 00c0300e
`- mmr 1925
`Read MM Reg 0_ 1925 (e0126494): 01004010
`- mmr 1925
`Read MM Reg 0_ 1925 (e0126494). 01405014
`
`[17:40 James Huang]
`Still trying to bring up VGA mode 3 on 30M.A lot of progress have been modeinlast two days:
`- Reading and writing to VGAregisters like Sequencer, Graphics, Attribute, CRTC and General are verified OK within Bios code;
`- VGA modeset sequenceis verified;
`- Programmingto other extended registers (Bios serateh/Grph_surfacex/Memory_Base/HDP...) that used to bring up VGA mode are verified;
`- Understood whyBios code would fly away whenone routine inside Kiesgets called, it has nothing to do with IKOS or Netlist.
`
`However, aceess to VGA host aperture still hangs up the system. ] don't know ifil's caused by missing steps in SWorthenetlist is nol good
`enough yet. Once this one gets solved and display capture is ready, we should be able to bring up the firstVGA mode with CRT on Crayola.
`
`[18:39 Gabriel Abarca]
`Mahendra found anissue with a MDITIIQX] and/or TLATNTSCAX12cell whichis being investigated, this can be the VGA problem.
`|/[11:04 Brian Leblanc]
`I have loggedoffthe Ikos box. I was debuggingthe register test using indexed accesses and writing and reading using 8/16/32 bit accesses.
`The tests produced the expected results for the 3.0 netlist and the programis starting to look pretty good.
`
`
`
`
`
` Thu 03/06/2003
`
`[have not removed registers from thetest that are failing, whetherthey fail forreal reasons ornet list issues is not important for now. [ vall start
`looking at the register failures scriously once the 4.0 or 4.1 net list 1s available.
`
`I still need to debug the defaults and endian tests.
`
`[15:25 Gina Seto]
`INodisplayyet.
`
`- reran palette rw test on the 3.0.1 database. tests passed.
`- Fixed the hang (bugin shell) and attempted to nun a basic displaytest: 640x480, 8bpp indexed mode.
`- Durning the test, | checked a bunch ofregisters and these have been written as expected (see list below)
`- The program writes to the frame buLler, then waits for a transition in V BLANK.It hangshere. (15 minutes+).
`- Colin will be making a newdatabase based on 3.0.1 that will allow me to do display captures
`
`
`
`Registers written:
`IIDP_TB_START = Oxf0000000
`FBSTART= 0xf0000000
`FBSIZE = 0x0
`DIGRPH_CONTROT, ~ 0x0
`IDIGRPH_ENABLE — 0x1
`DIGRPH PRIMARY SURFACE ADDRESS — 0xf0000000
`DIGRPH X START —Ox0
`DIGRPII_X_END = 05280
`DIGRPILY_START = Ox0
`DIGRPH_Y_END = 0x1e0
`DICRTC_CONTROL = 0x101
`DICRTC_H_TOVAL =0x340
`DICRTC_H_SYNC_A = 0x870000
`DICRTC._H_SYNC_B — 0x870000
`DICRTC_HBLANKSTARTENT) — 0x880308
`DICRTC V TOTAL — Ox1fd
`DICRTC V SYNC A —0x30000
`DICRTC_V_SYNC_B = 0x30000
`DICRTC_V_BLANK_START_END = 0x1c01fe
`IDACA_ENABLE= 0x1
`
`[18:09 Colin Stewart]
`A database with the fixed display clock and data capture for the 30M is available.
`
`ATI Ex. 2087
`IPR2023-00922
`Page 5 of 69
`
`ATI Ex. 2087
`
`IPR2023-00922
`Page 5 of 69
`
`ATI Ex. 2087
`IPR2023-00922
`Page 5 of 69
`
`

`

`
`
`Ifthe pixel clock was defaulting to the crystal clack, and the crystal clock was nel running, it maynot be possible to ever have the pixel clock
`run. This is a well knownissue with our clock source switching anti-glitch circuils. Both the current and future clock sources must be running in
`order to switch sources.If either one is not running,then the clock source switch hangs.
`Mon 03/10/2003 ||[12:29 Gina Seto]
`INo properdisplayyet. Progress:
`
`- I was able to configure the pelk so that PCLK_CRTC1 and PCLK_DACA would be alive:
`EXTL_PPLLREFDIV_SRC = 0x0 (xtalin)
`EXTPPLL_POSTDIVSRC = 0x0 (extemal source, input of reference divider)
`EXT1_PPL.POST_DIV— 0x0 divided by onc)
`PCLK CRTC1 CNTL:PCLK CRIC1 CLK SRC — 0x2 (extemal clock)
`
`I found thatsetting PCLK_CRTC1CLK_SRC to 0 (mainpixel clock 1) would render PCLK_CRTC|to be always low.
`Anybodyinterested can look at the waveforms:
`gina_pllsettings.wave, PCLK_CRTC1CLKSRC =0
`gina_vblankshappening.wave, PCLK_CRTC1_CLK_SRC =2
`
`- | beganto see hblank and vblanktransitions (-4 seconds for vblank to transition high). With the capture on,I ran the basic displaytest (640,
`480, 8bpp indexed mode). The resulting capture was a red sercen or sometimes a block ofbeige. The resulting checksum (R,G,Bonly)also
`did nol match myreference checksum.
`
`I've attached ourdiagtest log (r4disp.log) in case anybody is interested (please ignore the "MODE NOT AVAILABLE"warnings, i am
`investigating our shell code).
`Tue 03/11/2003
`|/[11:52 Brian Leblanc]
`I have finished runningthe register tests on the 30M for today. I have found andfixed the issue that was causing the hang when testing the MC
`
`Damonis making the clock fix (driving the 4 PsPLL_DCCG_oclelkx outputs ofthe PLL with PCICLK)so that we do not have this problem:
`| found that setting PCIL.K_CRTC1_CILK_SRCto 0 (main pixel clock 1) would render PCLK_CRITC1 to be always low.
`‘Then we will be able to set PCLKCRITIC] CLKSRC to 0
`
`[12:54 Brian Leblanc]
`Is there anyprogress on getting this netlist running?
`
`ATI Ex. 2087
`IPR2023-00922
`Page 6 of 69
`
`
`
`block.I still am having issues with the program while testing the VGA block that cause a hang.I believe this to be a test programissue. Wed 03/12/2003 ||[11:04 Gabriel Abarca]
`
`/net‘sunfs8/sunfs8_nobackup6/local_user/ikose/r400/
`O6Mar1400net3_VLE30M_new_board_daccapture.vmw
`Tri 03/07/2003
`||[06:40 Brian Leblanc]
`I have finished mytesting for the night. ‘he register defaults and endiantests ran well. There were errors, butas | said yesterday, I will not be
`debugging specific registers onthis net list. | had a couple ofhangs, and I will be locking at mylogs and debugging themnext.
`
`[14:50 Paul d'Entremont]
`Tests (R4Amem)failing basic write tests, memoryread back miscompares.
`
`Tests hangafter displayingtest status array with a status of FAIL.
`
`Stubbing outtests to a bare test of
`
`PGIWORD test_A (FEST)MODULE*test)
`5v
`// setup default stars variables
`TESTsctuptmstart((&prev_result, &sereen_error, &crror, &abort, test),
`
`screen_error = TEST_PASS;
`sprintf(msg, " error BAAADDDDD:‘n"),
`TEST_setstderr (&screen_error, &error, prev_result,test, 0, 0, msg);
`
`// setup status variables for exit
`TESTsetuptmend(prev_result, abort, &error, test),
`
`retum(error),
`
`} i
`
`kes hangsatafter Fail status; commentoutcall for TEST_setstderr, result status ofPass, ikos does not hang.
`
`[15:14 David Glen]
`‘This maysolve the issue, so pleasetryit.
`
`ATI Ex. 2087
`
`IPR2023-00922
`Page 6 of 69
`
`ATI Ex. 2087
`IPR2023-00922
`Page 6 of 69
`
`

`

`[12:56 Colin Stewart]
`The current status is the chip is stuck in reset and we are in the process of debugging the reset block.I'll send out a mail as soon as we figure
`out exactly what is wrong.
`[17:31 Gabriel Abarca]
`Colin and Damon compiled the netlist again with the workaround of agp_pci66 =). Register accesses seemed OK but the memoryfills do not
`work. We sawactivily in the outpul of mcO: me O.MC IO emd{2:0] was toggling. Bulthere were ne CAS/RASgoingtothe pads.
`
`Could we please get help debugging this?
`
`The directory in which to run vre is:
`/net‘sunfs8/sunfs8_nobackup6/local_user/ikose/r400/
`12Mar1400netlist4.1_lili_stub_fix_reset_bug.vmw
`
`The waveformis: mem_write_1000_55.wave/wavetorm100.vre
`
`[18:15 Gabriel Abarca]
`Actually Jie found that the reason we could not set PCLK CRTC1 CLK SRCto0 in netlist 3.0 was that there was a problem with clock
`gating ofthe pixel clocksat the time the netlist was produced (basically, CRTC_MASTER_EN needed the pixel clock runningandthe pixel
`clockto run needed CRTC_MASTER_EN).
`The software work aroundis to disable clock gating by doing PCLK_CRTC1_GATE_DISABLE = 1, PCLK_CRTC2_GATE_DISABLE =
`1, and maybe forthe other clocks too (IMDS, HDCP, DVO,DACA, DACB).
`‘This will be needed also for 4.0, as the fix has been donein thert! afterthat.
`
`||[16:57 Gina Seto]
`INo properdisplay yet - but we can capture a frame.
`
`Progress:
`
`1) Timing is ok
`
`As Gabriel noted before, the timingsignals are being generated properly. ‘he problem wasthat the display capture program wasnot expecting
`R400timing signals.
`
`Onprevious chips, the HSYNC signal would come belore the VSYNCsignal. On R400, HSYNC and VSYNC happen at the sametime.
`Thanks to Steve Bagshaw's solution, we made a workaroundin our code that forced the HSYNC to happen before the VSYNC (by
`programming newvalues to HSYNCBandforcing the DAC to use HSYNCB).
`
`We nowsee "clean" captures on the capture program. Althoughthe contents are wrong, at least the timing is correct. To see the last capture,
`hyou can go to:
`http://r400_30m_capt:5800/
`password: letmein
`(Note that the red line is vsyne.
`
`2) memorycontroller hang?
`
`-after running one display test, if1 try to write to the frame buffer at Oxf000000 with db 128,it hangs
`-after running one displaytest, if i run bei's fix, 1 am able write to the frame buffer at Oxf0000000 but wheni tryto read back Oxf0000000 with
`db 128,it hangs.
`
`hwe will be further investigating this.. although a memory problem was not unexpected.
`
`
`
`
`
`So the hardware fix I mention belowin the IKOSnetlist is not really needed. I does not hurt cither, we can leave the netlists as they are. Thu 03/13/2003 The instructions to look al IKOS wavelormsare:
`
`[18:58 Gabriel Abarca]
`As Gina mentions below,there is a memoryhang problem with slave reads (memory dumps) afler the displaytest. (this is netlist 3.0). The issue|
`is, a slave (hdp) read reaches as far as producing a pulse in signal
`umh/umh_read_bus_switch/umhdata_bus_router/imh_dbr_hi_cacheil ILMILRDCACIIEVALID butthe signal
`umbh/umh_read_bus_switchumhdata_bus_router/umhdbr_hi_cache
`ViHIMH_RDCACHEVALID/oMH_HI_SNDdoes not come,so there is no read forwarded to MC.
`
`‘The waveformis ‘net/sunfs8/sunfs8_nobackup6/local_user/ikose/r400/
`O6Mar_1400_net3_VILE30M_new_board_daccapturevmw
`?memory_hanggabricl.wave/wavetorm100.vre (instructions to see it are below).
`
`Is this a problem inherentin netlist 3.0?
`
`Would this also affect display(de) reads? Could this explain whythe contentof ourdisplayis corrupted? Or we need more waveform dumps
`to make sure? Ifthis is the reason then we probably have to wait to 4.1 to have a proper contentof display and be able to dump memoryafter
`display...
`
`ATI Ex. 2087
`IPR2023-00922
`Page7of 69
`
`ATI Ex. 2087
`
`IPR2023-00922
`Page 7 of 69
`
`ATI Ex. 2087
`IPR2023-00922
`Page 7 of 69
`
`

`

`- log in to any sun computer
`- set the display
`- source /proj‘ikose/.cshre_ikose5.03
`- ed net/sunfs8/sunts8_nobackup6/ocal_user/ikose/r400/
`O6Mar1400net3_VILE30M_new_board_daccapturevmw
`- wre
`Click on thw "Waveform"button and then OPEN ->> FILE in the wavelorm window
`Select memory_hanggabrielwave/waveform100.vre
`More instructions on seeing an IKOS waveform are in <http:/home.atitech.ca/hardware/emulationIKOS/vrehtm>
`Fri 03/14/2003
`/[14:34 GinaSeto]
`- IISYNCB and VSYNCBdoin fact comeat the same (as seen on waveform)
`- the original display capture problem (with IISYNCA and VSYNCA)mayhave been dueto the fact that the horizontal back porch was
`programmed to zero. Whenthe horizontal back porch was changed to 119, the display capture wasfine. | will investigate how the back porch
`came to be programmed to 0.
`
`[16:10 DamonTohidi]
`Colin and I tested the new R400 netlist 4.1 dalabase. Memory writes seem to work, however we'restill reading back zeros. On a read
`waveform, the data is on the bus goingin Loie and the strobes seem to be going into the pads ok, however the data never goes into the
`memory controller. We were tracing back the strobes throughthe 2x delay flop we putin to see ifthat was causing any problems and we came
`across the BYPASSsignal that goes into DELL6_TOP module. We notice this signalis high, therefore selecting not the DQSB going into the
`pads but the another inputto this module.I'm not sureifthis is what this signal is suppose to do or not but ifyou wouldlike to take a lookatit.
`Here's the location of the waveforms,
`
`/net/sun{s8/sunls8_noebackup6/local_user/ikese/r400/
`14Mar1400net4.115M_lilistubfixreset_bugmem_strbQSswap.vmw
`mem wr 1000 55aa55aa.wave
`mem_rd_1000_SSaa5Saa.wave
`Sat 03/15/2003
`|/[13:12 Colin Stewart]
`(On netlist 4.1) I have also captured a waveformfor the write to the Mode register. It is located in the samedirectory.It is called
`mem_MSR.wave.
`Mon03/17/2003 ||[14:31 Gabriel Abarca]
`(On netlist 4.1) Bob Bloemer and Bei Wangare night now looking at
`- Whythe DRAM seems to be set to CAS latencyof 2 instead of 3
`- A fix for the memoryinit seript
`
`
`
`possible to capture a complete sequence from powerupall the way to one write and one read? It could be in differentfiles if necessary. Tue 03/18/2003
`
`
`
`
`
`[14:33 Bei Wang]
`(On netlist 4.1) Here’s the updated script. I will look at the moderegister write waveform later.
`
`[14:35 Gabriel Abarca]
`(On netlist 4.1) Should we produce new waveformsbased on the change or should we wait for your analysis?
`
`[16:52 Damon Tohidi]
`(Onnetlist 4.1) We tried the new memory script andstill read back zeros. Did you want a particular waveformto look at?
`
`[18:31 Bei Wang]
`(On netlist 4.1) Bob and I looked al the maderegister set waveform. We don’t sce anything obviously wrong but we have some questions.
`
`1.) Does this waveform capture from time 0? Because weare seeing CKEstarting out as High, but by default it should start out as Lowforat
`least 200 usec until the init script sends the NOP with CKEhigh.
`
`2.) Whatis the PCICLK period? We find the Virsimtime scale kind ofdifficult to read.
`
`In addition, T modified the init seript again to follow Precharge All commands with some delay. I don’t feel that’s likely the cause since the
`same sequence workedLor the same type of DRAMSbefore in your earlier IKOS simulations. Bul give ila try if youlike. Also, would it be
`
`||[09:31 Colin Stewart]
`(On netlist 4.1) In answer to the questions.
`
`1) Nothis does notstart from time 0. The waveformstarts from the trigger pomt. In this case 20°ofthe data you see is before the tigger
`point 80° after. The moderegister set waveformis triggered when RAS=0 CAS=0 WE=0.
`2) PCICLKis running at 72Khz ‘Therefore the period is 14uS.
`
`Capturing the entire init sequenceis tricky because it takes so many clock eyeles because ofthe numberofregister writes. It would be casierif
`vou could give us a list ofwaveforms that you want. (ic CKE going high...).
`
`[11:24 Damon Tohidi]
`(On netlist 4.1) Wetried the newinit script and still reading back zeros. 1 captured a read, a write and MSR write ifyou wantto take a look.
`
`ATI Ex. 2087
`IPR2023-00922
`Page 8 of 69
`
`ATI Ex. 2087
`
`IPR2023-00922
`Page 8 of 69
`
`ATI Ex. 2087
`IPR2023-00922
`Page 8 of 69
`
`

`

`/net‘sunfs8/sunfs8_nobackup6/local_user/ikose/r400/
`17Mar_r400_net4.1_30M_lilistub_fix_reset_bug_mem_strbQSswap.vmw
`
`mem_wr_55_aa-wave!
`mem_rd_55_aa.wave/
`mem MRS ing.wave!
`
`
`
`and we will send the results shortly. Wed 03/19/2003||[13:32 Colin Steward]
`
`
`
`Something we came across while doing these triggers was that once the pe is booted (before we run the memoryinit script) RASB, CASB.
`WEBand CSBare all zero.I'm not sureif this is allowed ornot butit seems odd that the chip selects are active before memoryscript is ran.I
`captured a waveform if you'd like to take a lookat that as well.
`RASCASWCBzero_at_pwrup.wave/
`
`[11:35 Bob Bloemer|
`(Onnetlist 4.1) As long as CKEis low,the state ofthe other controllines shouldn't matter. We need to verify that the contrellines go to their
`inactive state before CKEis sct. Is that captured in your power up waveform?
`
`We are slarting to look al the first three.
`
`[12:06 Damon Tohidi]
`(Onnetlist 4.1) The power up waveformwastriggered before we ran the memory init script. I captured a waveform of CKE going from zero
`to one during memory initialization here,
`
`MOCKE0to_1l.wave/
`
`[13:41 Bei Wang]
`(On netlist 4.1) There appears to be two problems:
`
`1.) DRAMis programmed to have CL=3, butit’s behaving as CL=2. We don’t knowwhy thatis and will continueto look atthat.
`
`2.) There is a logic bug in the pad module for read strobe. When we programfor “Send write data on yelkfall” mode in init, it affects the read
`strobe, whenit really shouldn’t. This mode is nermallyofffor simulation,butit’s turned on for IKOS becauseofthe type of DRAM