Verde Linux Board Production Suite v12.07.

31

Version 12.07.31
October 16, 2012

Copyright © Advanced Micro Devices, Inc.

INTRODUCTION ..................................................................................................................................................... 5
OVERVIEW ............................................................................................................................................................. 5
COVERAGE ............................................................................................................................................................. 5
DEVICES SUPPORTED ............................................................................................................................................. 5
TEST HIERARCHY .................................................................................................................................................... 5
SUITE REQUIREMENTS ........................................................................................................................................... 5
SUITE INSTALLATION ............................................................................................................................................. 5
SUITE USAGE.......................................................................................................................................................... 6
TOOLS .................................................................................................................................................................... 6
DC (APPLETS SUITE).......................................................................................................................................................6
Introduction..........................................................................................................................................................6
Test DC003: Dolphin in water .......................................................................................................................................... 6
BD (COLOR BLENDER (CB) SUITE) ....................................................................................................................................8
Introduction..........................................................................................................................................................8
Test BD003: cb_dual_src_with_mrt ................................................................................................................................. 8
Test BD007: cb_fast_clear ................................................................................................................................................ 8
Test BD008: cb_fmask_decompress ................................................................................................................................ 9
AY (COMMAND PROCESSOR (CP) SUITE) .........................................................................................................................10
Introduction........................................................................................................................................................10
Test AY004: cp_async_pred_prim_occl_hint_bool_pm4 .............................................................................................. 10
BE (DEPTH BUFFER (DB) SUITE).....................................................................................................................................11
Introduction........................................................................................................................................................11
Test BE035: db_stencil_compare ................................................................................................................................... 11
EC (GRAPHICS CORE (GC) SUITE) ...................................................................................................................................12
Introduction........................................................................................................................................................12
Test EC010: r8xx_RAT_exports_pm4_01 ....................................................................................................................... 12
Test EC015: r8xx_rendertarget_32k_pm4_01 ............................................................................................................... 12
BG (SCAN CONVERTER (SC) SUITE).................................................................................................................................13
Introduction........................................................................................................................................................13
Test BG053: 60 2D Lines, varying slope, Bresenham control value 0x55, line .............................................................. 13
Test BG265: sc_zero_scissors_01 ................................................................................................................................... 13
BP (TEXTURE ADDRESSER (TA) SUITE).............................................................................................................................14
Introduction........................................................................................................................................................14
Test BP011: tp_prt_missing_triangle ............................................................................................................................. 14
Test BP013: tp_sample ................................................................................................................................................... 14
Test BP014: tp_tests ....................................................................................................................................................... 15
BN (TEXTURE CACHE (TC) SUITE) ...................................................................................................................................16
Introduction........................................................................................................................................................16
Test BN011: tc_render_to_texture_color ...................................................................................................................... 16
Test BN012: tc_render_to_texture_depth_stencil ........................................................................................................ 16
BU (VERTEX GROUPER TESSELLATOR (VGT) SUITE) ...........................................................................................................17
Introduction........................................................................................................................................................17
Test BU041: vgt_gs_stress_pm4_08 .............................................................................................................................. 17
Test BU082: This test verifies the VGT stream out capabilities, it streams out the vertex id for a strip of input
vertices ........................................................................................................................................................................... 17
Test BU300: vgt_eox_pm4_01 ....................................................................................................................................... 18
DP (DISPLAY OUTPUT SUITE) .........................................................................................................................................19
Introduction........................................................................................................................................................19
Test DP899: Autodetecting display output visual test .................................................................................................. 19
CN (HORIZON SUITE) ...................................................................................................................................................20
 Introduction........................................................................................................................................................20
Test CN001: Horizon Tests.............................................................................................................................................. 20
AK (MEMORY CONTROLLER SUITE) .................................................................................................................................21
Introduction........................................................................................................................................................21
Test AK010: Write mask (CP) ......................................................................................................................................... 25
Test AK109: VM Combo (CP-IB, 2D Blit, CP-DMA, Display, HDP) .................................................................................. 25
Test AK308: Horizontal Blt Walkbit ................................................................................................................................ 26
Test AK309: Horizontal Blt Walkpat ............................................................................................................................... 26
Test AK311: Horizontal Blt Randbit................................................................................................................................ 26
Test AK312: Horizontal Blt Randmask ........................................................................................................................... 27
Test AK321: Random Blt Walkpat .................................................................................................................................. 27
Test AK368: Vertical line ................................................................................................................................................ 27
Test AK401: SLT functional ............................................................................................................................................. 28
Test AK403: Board functional......................................................................................................................................... 28
Test AK404: Board stress ................................................................................................................................................ 28
Test AK600: Memfa testing ............................................................................................................................................ 29
EF (MVP SUITE) .........................................................................................................................................................30
Introduction........................................................................................................................................................30
Test EF003: Link Integrity Test ....................................................................................................................................... 30
Test EF004: AFR Manual ................................................................................................................................................. 30
Test EF006: SFR Manual ................................................................................................................................................. 31
PK (PM4 PLAYER SUITE) ..............................................................................................................................................32
Introduction........................................................................................................................................................32
Test PK006: 3DMark06: Canyon Flight ........................................................................................................................... 32
Test PK014: DirectX SDK: SubD11 .................................................................................................................................. 32
PMD (CPL-CHIP PERVASIVE LOGIC) ...............................................................................................................................33
Introduction........................................................................................................................................................33
Test PMD004: Golden Settings....................................................................................................................................... 33
Test PMD011: DPM ........................................................................................................................................................ 33
Test PMD013: Thermal Protection ................................................................................................................................. 34
Test PMD015: Fan Control ............................................................................................................................................. 35
SAM (SECURE ASSET MANAGEMENT (SAM) SUITE) ..........................................................................................................36
Introduction........................................................................................................................................................36
Test SAM001: SAM Basic Functionality. ........................................................................................................................ 36
Test SAM002: SAM basic instruction/command processing and AM32 microprocessor instruction verification....... 37
Test SAM008: SAM Crypto DMA encryption/decryption. ............................................................................................. 37
DF (UNIFIED VIDEO DECODER (UVD) SUITE) ....................................................................................................................40
Introduction........................................................................................................................................................40
Test DF011: H264/VC1 Bitstream Tests ......................................................................................................................... 40
VCE (VIDEO COMPRESSION ENCODING) ..........................................................................................................................41
Introduction........................................................................................................................................................41
Test VCE100: H.264 bit-stream encoding from memory ............................................................................................... 41
Test VCE300: Basic wireless display ............................................................................................................................... 42
Test VCE301: Wireless display elementary stream (video only) ................................................................................... 42
AG (PCI EXPRESS SUITE) ..............................................................................................................................................43
Introduction........................................................................................................................................................43
Test AG020: PCIE link quality test .................................................................................................................................. 43
AJ (PCIE PHY SUITE)....................................................................................................................................................45
Introduction........................................................................................................................................................45
Test AJ015: PCIE PHY Dynamic Link Speed Switching Test (Bridge Initiated) ............................................................... 45
Test AJ018: PCIE PHY Dynamic Link Width Switching Test (Up/Down Config) ............................................................. 46
APPENDIX A - AGT ............................................................................................................................................... 49
APPENDIX B - ATIFLASH ....................................................................................................................................... 52
APPENDIX C - TSERVER USER PARAMETERS ......................................................................................................... 53
APPENDIX D - HOW TO MOUNT A USB KEY IN LINUX ........................................................................................... 54
Introduction
The purpose of this document is to specify the overall functionality and test definitions for the AMD Board
Production Suite.

Overview
The AMD Board Production Diagnostic Test Suite is designed for internal and external customers to be used on a
manufacturing line. This test suite assumes a working ASIC which contains functional/stress tests for validating
external connections/components (such as bus interfaces, display connectors, memory, and power), latency
incurred by external connections/ components to the GPU internal functionalities, and workmanship. The test
suite uses the Exit on First Error reporting method and will display the test result on the screen as well as generate
a error reporting log file. The test suite is not intended to be used for looping. The test suite has three options for
testing. (1) Quickmfg - runs a fixed series of tests. (2) Extmfg - provides the option to append additional testing to
the quickmfg series of tests. (3) Sit test - runs system integration tests.

Coverage
The Board Production Suite covers: Memory, 3D, Chip pervasive logic, UVD, PCIE, VCE, SAM and MVP

Devices Supported
 Verde

Test Hierarchy
Automated Tests (quickmfg) PCIE Stress Tests, Memory Controller tests, Horizon tests, 3D Stress tests, PM4 Play,
Virtual Memory tests, Dynamic Power Manager, UVD Stress tests, Video Compression Encoding tests, Secure Asset
Management ,CTF.

Suite Requirements
Hardware Requirements:
Motherboard: Recommended PCIe 3.0 Motherboard or PCIe 2.0 Motherboard with PLX card which supports 64-bit
Processor
CPU: Recommend 64-Bit Processor. Minimum AMD Athlon 64, Intel Core2 Duo
System Memory: Recommend 2GB (Minimum 1GB for 1 GPU under tes, plus 512MB additional for each additional
GPU)
Storage Device: 8GB or larger free space (Hard Driver Recommended, but can use a USB Key)
Input Devices: Keyboard, Mouse, Monitor
Software Requirements:
Ubuntu 10.04 32/64-bit Linux Server or Desktop Edition (Can do Kernal updates if required for hardware support)
Linux Swap Partition of at least double the memory size (i.e. 4GB recommended)
AMD Linux GPU Diagnostic Test Suites (Board Production Diagnostic Test Suite)

Suite Installation
 Download the Board Prod Diagnostic Test Suite from the ORC at
http://secure.amd.com/site/partner_orc/Home/default.aspx
 If the system used for downloading is not the test system, copy the diagnostic suite over to the test system
using an external USB key or drive. See Appendix for instructions on how to mount a USB flash drive in linux.
 Extract the diagnostic suite using the command tar xvfz suitename.tar.gz
 (Optional) Delete the .tar.gz suite file to save hard drive space.
 Please use the original tool with the suite to do the diagnostics, any other tool copied to this suite is not
verified and could cause potential issue.

Suite Usage
There are four typical use cases for the AMD Board Production Diagnostic Test Suite. Note:The suite doesn't
support looping. If you want to do loop, it is requested to reboot the system between loops.
1)TEST TYPE: Quick Manufacturing Test
 HOW: Type ./tserver -boardtest=quickmfg2 or ./tserver -boardtest=quickmfg
 WHAT: Executes several general test blocks with default options and specified guardband (varies from GPU to
GPU). Set to Exit without pause on error. -quickmfg is for PCIE Gen3 motherboard, -quickmfg2 is for PCIE Gen2
motherboard. You could set margin by typing ./tserver -boardtest=quickmfg -suitemargin= x pct, x pct.
2)TEST TYPE: Extended Manufacturing Test
 HOW: Type ./tserver to configure the test, and then type ./tserver -boardtest=extmfg to execute
 WHAT: Executes a custom set of tests (which can include all of the tests in the Quick Manufacturing Test) in
addition to several external tests Guardband is optional (i.e. can add standard guardband margins, or no
guardband). and the error reporting method is not fixed (i.e. can chose to exit, pause, or continue on error).
3)TEST TYPE: Individual Test Execution
 HOW: SET CLOCKS, RUN TEST
 WHY: In case of a test failure during extmfg or quickmfg, it may be useful to verify repeated test failures
4)TEST TYPE: System Integration Test
 HOW: Type ./tserver -boardtest=sitquick/sitvisual/sitfan/sitxfireb
 WHAT: Executes system integration test option. Set to Exit without pause on error

Tools
There are several useful tools which are included with the AMD Board Production Diagnostic Suite. Specific flags
and tool usage can be found in the Appendixes at the end of the document.
 TServer
 AGT
 ATIFLASH

DC (Applets Suite)
Introduction
The TGL Applets suite is a set of tests that are meant to imitate simple rendering applications or "applets". These
provide a larger and more realistic workload and data set than our smaller, feature directed, tests.

Test DC003: Dolphin in water

This test renders a fairly complex scene, consisting of a dolphin model in water, using vertex and pixel shaders.
Coverage
This test covers vertex shaders, pixel shaders, vertex fetching, and manipulation, textures, scan conversion, depth
buffering, fog effects, and color buffer writes to memory.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation DC003.001: dolphin

BD (Color Blender (CB) Suite)
Introduction
The Color Blender (CB) suite tests the functionality of the CB block. The CB is responsible for blending the pixel
color values and outputting the final pixels to the frame-buffer. The CB can be used for writing compute data to
memory through the RAT export functionality. The CB also does the processing required for Anti-aliasing.

Test BD003: cb_dual_src_with_mrt

This is a new feature in CB block of the Southern Islands for multiple surfaces that can be rendered to in a single
state. The MRT stands for Multiple Render Target.
Coverage
This test covers the multiple surfaces rendering of hardware feature in CB block specifically, in addition to testing
3D hardware engine.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation BD003.001: cb_dual_src_with_mrt

Test BD007: cb_fast_clear

When a buffer is cleared, every pixel will have the same color. As long as the clear color is known through a
register setting, only a single bit is necessary to signify that every pixel in a region of the buffer is the clear color.
This allows clears to be extremely fast. The CB supports fast clearing the color surface. This is achieved by only
clearing the CMask bits associated with each tile in the surface.
Coverage
This test covers the fast_clear hardware feature in CB block specifically in addition to testing 3D hardware engine.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation BD007.001: cb_fast_clear

Test BD008: cb_fmask_decompress
This feature decompresses the fmask surface so that it may be read by other clients like texture.
Coverage
This test covers the fmask_decompress hardware feature in CB block specifically in addition to testing 3D hardware
engine.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation BD008.001: cb_fmask_decompress_2AA

AY (Command Processor (CP) Suite)
Introduction
The Command Processor suite tests the functionality of the CP block. The Command Processor is the front end of
the 3D pipeline. It fetches command packets which it parses and executes. The executed commands control the 3D
pipeline.

Test AY004: cp_async_pred_prim_occl_hint_bool_pm4

This test uses Z pass data to determine whether primitives are occluded and should be drawn.
Coverage
This test covers command packet fetching/parsing/execution from the primary ring buffer by drawing some simple
geometry through the 3D pipeline, so some basic 3D pipeline features are used. This test specifically tests the
predicated execution functionality based on occlusion of the object and a boolean hint.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation AY004.001: cp_async_pred_prim_occl_hint_bool_pm4

BE (Depth Buffer (DB) Suite)
Introduction
The Depth Buffer (DB) suite tests the functionality of the DB block. The DB is responsible for the depth testing and
for the features in the hardware that speed up that processing.

Test BE035: db_stencil_compare

This test validates the Depth Buffer hardware features STENCIL_COMPAREFUNC, STENCIL_COMPAREVALUE,
STENCIL_COMPAREMASK, and ENABLE.
Coverage
This test covers the stencil compare hardware features in DB block specifically in addition to testing 3D hardware
engine.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation BE035.001: db_stencil_compare_enable_01

EC (Graphics Core (GC) Suite)
Introduction
This is the Graphics Core suite for Southern Islands. The tests here test are mostly dealing with shader
configurations that span multiple blocks. Shader exports, shader processors, interpolation, and compute streams
are amongs the most examined features in this here block.

Test EC010: r8xx_RAT_exports_pm4_01

This is a graphics core test for testing random access target shader exports.
Coverage
Memory Export to Render Target - Scatter to RAT.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation EC010.000: Basic mem export to random access target. Tests the STORE_RAW
instruction. 1 color buffer, 1 RAT buffer

Test EC015: r8xx_rendertarget_32k_pm4_01

This is a graphics core test for validating the address range for rendering.
Coverage
Resource Size Modifications.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation EC015.000: Eight stippled lines starting from the borders and corners of the
render target. The x and y fixed-point vertex positions can be verified in the
clipGa_alg.dmp and SuScan.dmp. Fixed-point range is increased to S.15.8. Not able to
test 32768 since vertices got created outside the render target. SC is not clamping it.
Change it to 32766.
BG (Scan Converter (SC) Suite)
Introduction
The Scan Converter suite tests the SC block in the 3D pipeline. This block is responsible for conversion from the
geometry domain to the screen space, pixel domain. It takes the incoming geometric data, and scan converts it.
The SC is responsible for enforcing the raster rules.

Test BG053: 60 2D Lines, varying slope, Bresenham control value 0x55, line
This test validates the Bresenham control value.
Coverage
This test covers the Bresenham control value in SC block specifically, in addition to testing 3D hardware engine.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation BG053.001: sc_bres_cntl_tgl_01

Test BG265: sc_zero_scissors_01

This is a zero scissor test in SC block.
Coverage
This test covers the zero scissor feature in SC block specifically, in addition to testing 3D hardware engine.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation BG265.001: sc_zero_scissors_01

BP (Texture Addresser (TA) Suite)
Introduction
The Texture Addresser (TA) suite tests the functionality of the TA block of the texture pipe. The texture pipe
consists of TA and texture data (TD) blocks. The TA fetches texels (texture pixels) and vertices from memory
requested by a shader program through the shader core. The TD takes the returned texels and filters them to
generate pixels to return to the shader core. The TA and TD interface to memory through a texture cache (TC)
which tries to limit the overall memory requirements.

Test BP011: tp_prt_missing_triangle

This test draws four overlapping triangles using partially-resident textures.
Coverage
This test covers partially-resident textures (PRT) functionality by using vertex and pixel shaders with a simple
procedural texture. It also uses the basic functionality of the rest of the 3D pipeline in order to render the result
image to memory.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation BP011.001: tp_addr64_triangles

Test BP013: tp_sample

This is a texture pipe test for sampling such as MIPMAP.
Coverage
This test covers the texture pipe sampling, in addition to testing 3D hardware engine.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation BP013.001: tp_sample_d_2Dtex

Test BP014: tp_tests
This is a texture pipe test. This test generates tp block complex cross product tests.
Coverage
This test covers the tp block complex cross product, in addition to testing 3D hardware engine.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation BP014.001: cross_degamma_norm_FMT_8_8_8_8

BN (Texture Cache (TC) Suite)
Introduction
The Texture Cache (TC) suite tests the functionality of the TC block. The TC caches both texture and vertex read
data from memory. It provides these read return data to the shader core.

Test BN011: tc_render_to_texture_color

This test uses the render-to-texture feature with a color buffer.
Coverage
This test covers texture mapping using a color buffer as a texture, vertex shaders, pixel shaders, MSAA, and color
buffer writes to memory.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation BN011.003: tc_render_to_texture_uncompressed_2aa

Test BN012: tc_render_to_texture_depth_stencil

This test uses the render-to-texture feature with a depth buffer.
Coverage
This test covers texture mapping using a depth buffer as a texture, vertex shaders, pixel shaders, MSAA, and color
buffer writes to memory.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation BN012.001: tc_rtt_depth_d16

BU (Vertex Grouper Tessellator (VGT) Suite)
Introduction
The Vertex Gatherer and Tessellator suite tests the VGT block in the 3D pipeline. This block is responsible for
assembling all of the vertex data for the rendering. As the name suggests it is also used for the creation of new
vertices through tessellation, or through the geometry shader. It also supports instancing.

Test BU041: vgt_gs_stress_pm4_08

The test sends 1k DRAW packets. Each draw call with 1 point inside. The gs doesnt modify the format of input and
outputs points as well.
Coverage
This test stresses the geometry shader functionality by using Vertex, Export, Geometry, and Pixel shaders. More
vertices are output than are input, so vertex creation through the geometry shader is tested. It also uses the basic
functionality of the rest of the 3D pipeline in order to render the result image to memory.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation BU041.001: vgt_gs_stress_pm4_08

Test BU082: This test verifies the VGT stream out capabilities, it streams
out the vertex id for a strip of input vertices
This test stresses the streamout functionality in the VGT.
Coverage
The test uses vertex and pixel shaders. This streams vertex IDs out to memory, so this verifies vertex ID generation
and the streamout functionality together. It also uses the basic functionality of the rest of the 3D pipeline in order
to render the result image out to memory.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation BU082.001: vgt_stream_out_01

Test BU300: vgt_eox_pm4_01
This test draws two sets of nine quads using DX11 tessellation.
Coverage
This test covers DX11 tessellation functionality by using local (as vertex), hull and vertex (as domain) shaders. It
also uses the basic functionality of the rest of the 3D pipeline in order to render the result image to memory.
Fail Case
The test will fail if the CRC of the rendered image does not match the CRC of the expected golden image. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation BU300.010: vgt_eox_pm4_10

DP (Display Output Suite)
Introduction
The display output (DP) suite tests the functionality of the various display output blocks on the GPU. These include
DAC (a.k.a VGA), DVI/HDMI, LVDS, and DisplayPort, in various configurations depending on the GPU and board
design.

Test DP899: Autodetecting display output visual test

This test is intended for verifying the display outputs on a graphics board by way of visual inspection.
CN (Horizon Suite)
Introduction
The Horizon suite is a stress test which behaves similarly to a typical 3D application. The stress generated by an
individual test is dependent on the graphic scene on which the test is based.

Test CN001: Horizon Tests

This test has many variations. Each variation uses a specific scene that is designed to work the 3D hardware in a
specific way. To add more dimensions to the testing, each variation may also differ in other aspects such as:
number of frames, test duration, display resolution, and error checking.
Coverage
The 3D features tested in a horizon test include: Vertex, pixel, and compute shaders (control flow - loops, global
and local predication), dx9 and dx10 style constants, global data sharing, local data sharing, memory
exports/imports, alpha blending, texture processing, depth testing, video memory, power state switching, vertex
and pixel processing, coherency checking.
Fail Case
The test will fail if the CRC of the rendered frame does not match the CRC of the expected golden frame. This could
be caused by a bad 3D pipeline, bad memory, a bad board, or a bad electrical supply.

Variation CN001.003: Scene 5 SKULLS Vertex Fetch Stress - 500 frames.

Variation CN001.007: Scene 65 RANDOM OBJECTS Eng Clock Stress - CRC checking.

Variation CN001.008: Scene 4 SPACESHIPS + BUSES Balanced Stress - CRC checking. 30

second timeout.
AK (Memory Controller Suite)
Introduction
The memory diagnostic tests are used in external diagnostic suites to validate the memory between the GPU
memory controller and memory chips on the board. The tests use different test patterns and graphics engines to
generate different noise levels in the memory interface and DRAMs.
There are two important groups of memory tests (BLIT tests and CB tog tests) that will be described in this section
rather than test by test. This is because the tests are very closely related, and in addition, tests in these two groups
are often leveraged by other memory tests.
Group 1: BLIT tests [AK301-AK330]
The main purpose of this group of tests is to use bit BLITs to stress the memory interface from the ASIC to the
memory chips. The BLITs can be further grouped based on two types of variations:
1. Data pattern used (e.g. Colorbar, Walkbit, Walkpat, Maskpat, Randbit, and Randmask)
2. Direction or movement of the BLITs (e.g. Horizontal, Diagonal, Random)
The data patterns are used primarily to test the data lines. The direction or movement of the blits, (i.e., the source
and destination coordinates of the blits) are mostly designed to test the address lines.
There are five subgroups of BLIT tests to cover all BLIT direction and data pattern variations.
Group 1A: Moving BLIT tests [AK301-AK306]
1. The data pattern is drawn on the upper left quarter of the display. This pattern is then moved down, right,
up, left, then diagonally
2. Data patterns tested: Colorbar, Walkbit, Walkpat, Maskpat, Randbit, and Randmask

Group 1B: Horizontal BLIT tests [AK307-AK312]

1. The data pattern is moved side to side multiple times
2. Data patterns tested: Colorbar, Walkbit, Walkpat, Maskpat, Randbit, and Randmask

Group 1C: Diagonal BLIT tests [AK313-AK318]

1. The data pattern is moved diagonally across the display area
2. Data patterns tested: Colorbar, Walkbit, Walkpat, Maskpat, Randbit, and Randmask

Group 1D: Random BLIT tests [AK319-AK324]

1. A pattern which is a quarter of the display resolution in dimension is moved to a random destination
within the display resolution's perimeter
2. Data patterns tested: Colorbar, Walkbit, Walkpat, Maskpat, Randbit, and Randmask

Group 1E: Full Memory BLIT tests [AK325-AK330]

1. These tests will move the data pattern diagonally down the entire video memory
2. Data patterns tested: Colorbar, Walkbit, Walkpat, Maskpat, Randbit, and Randmask

A description of the six data patterns used in the blit tests follows.
1. Colorbar

The lower half contains the primary (red, green, blue) and complementary (cyan, magenta, yellow) colors in their
full intensity (0xFF for 32bpp) while the upper half are about half the maximum intensity (0x9E for 32bpp). There
are also the black and white colors and shades of gray.
2. Walkbit

This pattern is intended to generate SSO pattern operations. In the presence of a DBI signal (i.e., GDDR4), it will
make the DBI signal toggle instead. Without a DBI signal (as is the case internally in the ASIC), this pattern will
generate SSO on all bits most of the time.
3. Walkpat
This pattern will generate SSO patterns even with the presence of a DBI signal. However, not all bits will be doing
SSO at the same time but rather the data bits with SSO operations will shift temporally as the pattern walks down
vertically.
4. Maskpat
This pattern is composed of a foreground and a background color. This pattern is intended to be used for color
compare blits to transfer only the foreground color. As such, this is a good pattern to test the write mask (byte
enable bits) when transferring data.
5. Randbit
This pattern is also intended to generate SSO operations like the walkbit pattern. Basically, it contains data with a
single bit randomly turned or data with single bit randomly turned off. The sequence of whether it is a single bit on
or single bit off data is also in pseudo-random order.
6. Randmask
This pattern is similar to the Maskpat pattern. The only difference is in the sequence of the foreground and
background colors which is in pseudo-random order.
Group 2: CB Tog tests [AK347-AK366]
CB Tog is a set of memory tests which uses the 3D engine to perform BLIT operations. These tests are more
stressful than CP, DMA or CPU operations.
Group 2A: CB tog wr (write) [AK347-AK350]
1. Draw patterns using 2D PaintMulti operations. The draw is not done in a single draw operation but rather
in multiple strips
2. The pattern drawn is transferred to a temporary buffer using a single 2D BitBltMulti operation
3. This pattern in the temporary buffer is then checked by xor-ing it with the original patterns using another
2D PaintMulti operation. This should clear (set to zero) the data unless there are anomalies
4. The xor-ed data are then transferred to a result buffer using another 2D BitBltMulti operation, this time
or-ing it with the destination pattern. This way, all anomalies will be or-ed together

Group 2B: CB tog rd (read) [AK351-AK354]

 These tests are similar to CB tog wr tests. The difference is that the pattern is transferred to the temporary
buffer using multiple 2D BitBltMulti operations with smaller dimensions. The main objective is to do more
read operations in the test

Group 2C: CB tog rmw (read-modify-write) [AK355-AK358]

 These tests are similar to CB tog wr tests. The difference is that there are read-modify-write operations in
between steps 1 and 2

Group 2D: CB tog copy [AK359-AK362]

 These tests are similar to CB tog rmw tests. The difference is that instead of read-modify-write operations,
copy operations are performed

Group 2E: CB tog mask [AK363-AK366]

 These tests are similar to CB tog rd tests. The difference is in step 2. That is, the pattern is transferred to the
temporary buffer using a bunch of multiple 2D TransBitBlt operations. The main objective is to check the write
mask bit

Test AK010: Write mask (CP)

This test is similar to the Write Mask (HDP) test except it uses the CP DMA to do the byte, word, and dword data
transfer. It exercises the write mask bits or data mask commands for GDDR5.
Fail Case
Fail if any error in the resulting data

Variation AK010.001: 1024x768 @ 32bpp

Test AK109: VM Combo (CP-IB, 2D Blit, CP-DMA, Display, HDP)

This test performs 2D/3D Blits to and from VM aperture with the command processor's pm4 packets also in VM
aperture. The 2D/3D blit operation is similar to (and is based on) the Moving BLT Colorbar [AK301.6] tests. This test
also performs transfers to and from VM aperture using CP DMA and HDP aperture.
Fail Case
Fails if data checks fail.

Variation AK109.003: Snoop/NonSnoop Toggle

Test AK308: Horizontal Blt Walkbit
For a test description, please refer to the section in the Introduction entitled: Group 1B: Horizontal BLIT tests
[AK307-AK312]
Fail Case
The test pattern that is used in the blits is preserved throughout each blit movements within the tests. As such, the
test patterns as well as background are checked for consistency at the end of the test.

Variation AK308.006: 1024x768 @ 32bpp

Variation AK308.007: DRMDMA:1024x768 @ 32bpp

Test AK309: Horizontal Blt Walkpat

For a test description, please refer to the section in the Introduction entitled: Group 1B: Horizontal BLIT tests
[AK307-AK312]
Fail Case
The test pattern that is used in the blits is preserved throughout each blit movements within the tests. As such, the
test patterns as well as background are checked for consistency at the end of the test.

Variation AK309.006: 1024x768 @ 32bpp

Test AK311: Horizontal Blt Randbit

For a test description, please refer to the section in the Introduction entitled: Group 1B: Horizontal BLIT tests
[AK307-AK312]
Fail Case
The test pattern that is used in the blits is preserved throughout each blit movements within the tests. As such, the
test patterns as well as background are checked for consistency at the end of the test.

Variation AK311.006: 1024x768 @ 32bpp

Variation AK311.007: DRMDMA:1024x768 @ 32bpp

Test AK312: Horizontal Blt Randmask
For a test description, please refer to the section in the Introduction entitled: Group 1B: Horizontal BLIT tests
[AK307-AK312]
Fail Case
The test pattern that is used in the blits is preserved throughout each blit movements within the tests. As such, the
test patterns as well as background are checked for consistency at the end of the test.

Variation AK312.006: 1024x768 @ 32bpp

Test AK321: Random Blt Walkpat

For a test description, please refer to the section in the Introduction entitled: Group 1D: Random BLIT tests
[AK319-AK324]
Fail Case
The test pattern that is used in the blits is preserved throughout each blit movements within the tests. As such, the
test patterns as well as background are checked for consistency at the end of the test.

Variation AK321.005: 1024x768 @ 16bpp

Variation AK321.006: 1024x768 @ 32bpp

Test AK368: Vertical line

Many vertical lines (width=1) with a height of 0x90 are drawn sequentially from left to right throughout the whole
width of the display area. The lines are drawn using random ROP parameters with the previous line as the source
and multiples of a pattern data (0x19fb73d5) as the brush or paint data. The whole width of the surface where the
lines are drawn is then copied to another surface using 2D BitBlt operation with invert source ROP.
This process is repeated thousands of times until a memory-based checksum is calculated and compared to an
expected value.
Fail Case
Fail if the checksum of the resulting data mismatches the reference checksum

Variation AK368.005: 1024x768 @ 16bpp

Test AK401: SLT functional
This test does a basic sanity check to the full video memory. A pass in this test means that the GMC can correctly
complete basic read and write transactions for the whole frame buffer (FB). This test is based on Fill Memory test
(AK001) except that it does not exercise all the addressable memory, instead in skips every 65 dword address.
Fail Case
Fail if any data mismatch found in sequential check or reverse-sequential check.

Variation AK401.001: 1024x768 @ 32bpp

Test AK403: Board functional

This is a basic memory test. It fills full memory with sequential 32-bit values, inverse of sequential 32-bit values,
and a few content 32-bit patterns. It reads back the full memory content to check for errors after each fill. The fills
are done by simple DMA. No 2D or 3D engine is involved. It intends to catch workmanship issue, stuck memory
cells, and memory configuration issue.
Fail Case
Readback of memory content contains errors after any memory fills.

Variation AK403.001: Non-AGP: 1024x768 @ 32bpp

Test AK404: Board stress

This is a memory interface stress test. It does stressful mix of memory reads and writes of stressful data patterns.
To achieve a very high level of stress, 3D engine is used to generate tight sequences of memory read/write mix. It
intends to catch signaling issues on the memory interface.
This test is a combination of the following Moving Blit tests:

 AK301.6 Colorbar
 AK305.6 Randbit
 AK302.6 Walkbit
 AK303.6 Walkpat
 AK306.6 Randmask

The major difference is that these tests are first run multiple times without checking the result. The purpose of this
step is to pre-saturate the MC clients rather than starting from an idle state. Afterwards, the actual tests are then
run and results are checked.
Fail Case
The test pattern that is used in the blits is preserved throughout each blit movements within the tests. As such, the
test patterns as well as background are checked for consistency at the end of the test.
Variation AK404.001: Qualification

Test AK600: Memfa testing

This is a memory failure analysis test. It does a stressful mix of memory reads and writes of stressful data patterns
and intends to determine the problematic memory channels as well as DRAMs.
Coverage
Read and writes paths to DRAM, DRAM chips
 Client read/write logic (basic and stress)
 Data paths and FIFOs electrical (connectivity and stress)
 ASIC to DRAM electrical connectivity

Pass Case
The connectivity between the board's ASIC and DRAMs are good.
Fail Case
The connectivity between the board's ASIC and DRAMs may have issues. The failure analysis personnel should also
ensure there is acceptable noise in the power supplies.

Variation AK600.001: using 3D engine

EF (MVP Suite)
Introduction
Multi-VPU (MVP) leverages the processing power of multiple AMD graphics processors running in parallel to
achieve maximum 3D graphics performance. Fundamentally MVP works by combining rendered, uncompressed
digital video data from two different sources to generate a final 'mixed' output. In this way each graphics device in
the system can share the load and generate a partial image which is combined by the MVP circuitry. There are
three approaches to MVP:
 Alternate Frame Rendering (AFR): Allows each device in the system to render an entire frame and then choose
which device will drive the output that the user will see. The software will alternate or 'switch' between each
device in the system so that while one device is displaying the current frame, the others are rendering
subsequent frames. At any given time the MVP mixer will be driving either its own pixel data or pixel data
from the upstream device. There are three sub-modes for AFR: AFR Driver, AFR Manual and AFR Automatic.
These sub-modes define how the circuitry decides which path to choose.
 Split Frame Rendering Mode (SFR): In Split Frame Rendering each frame is split up among the devices and the
final image is composed of all the individual images.
 Blanking Region Synchronization: In either SFR or AFR modes, the synchronization of pixel switching or back
buffer flipping (or both) takes place during the blanking region. The hardware can be setup to synchronize at
the end of a line (HSYNC) or the end of the current frame (VSYNC).

Test EF003: Link Integrity Test

The MVP link uses either the 12-bit DDR or 24-bit SDR Digital Video Output (DVO) interface. This test determines
the maximum operational frequency across the DVO interface.
Fail Case
These tests check the link integrity across the DVO interface at the maximum clock speeds.

Variation EF003.006: Link Integrity Test 12-Bit DDR Bundle B (Board Manufacturing) @
1024x768,32

Test EF004: AFR Manual

This test draws two different patterns on each device. The first pattern is the RGB Bars which is drawn on the
'front' buffer. The second pattern is the pseudo-random data pattern. Both patterns are overlaid with the
mutually-exclusive black pattern, which is dependent on the devices location in the chain. The test cycles the pixel
source through all the devices. For HSYNC and VSYNC testing, the surface is also flipped before the pixel source
switch. Each pattern is drawn on the bootup device at the start of the test before MVP is enabled to generate the
reference CRCs. After each pixel switch the test compares the MVP output against the reference.
Fail Case
CRC's mismatch.
Variation EF004.001: AFR Manual 12-Bit DDR (Bundle A, No Flip)

Variation EF004.002: AFR Manual 12-Bit DDR (Bundle B, No Flip)

Variation EF004.003: AFR Manual 12-Bit DDR (Bundle A, VSYNC)

Variation EF004.004: AFR Manual 12-Bit DDR (Bundle B, VSYNC)

Variation EF004.018: AFR Manual 24-Bit DDR (One Clock, Bundle A, VSYNC)

Test EF006: SFR Manual

Similar to the AFR tests, this test draws two different patterns on each device. The first pattern is the RGB Bars
which is drawn on the 'front' buffer. The second pattern is the pseudo-random data pattern. Both patterns are
overlaid with the mutually-exclusive black pattern. Since each device has a mutually-exclusive black pattern drawn
over top of the underlying image (RGB Bars and Pseudo-Random Data), the result is the underlying image itself.
The test will draw the full images first to generate the expected CRC, then patterns are drawn on each device and
SFR Manual is enabled. The CRC is read at the output of the master and checked against the reference.
Fail Case
CRC's mismatch.

Variation EF006.003: SFR Manual 12-Bit DDR (Bundle A, VSYNC)

Variation EF006.004: SFR Manual 12-Bit DDR (Bundle B, VSYNC)

PK (PM4 Player Suite)
Introduction
The PM4 player plays back the contents of a PM4 trace file that was captured from the production graphics driver
as it was rendering a 3D application. The PM4 trace contains command packets for drawing geometric primitives as
well as graphics resources such as textures, vertex buffers and shader programs stored in binary format. The player
reads the graphics resources from the PM4 trace and uploads them into system and video memory. It then reads
the command packets from the PM4 trace and submits them to the GPU where they are processed by the graphics
core to re-create a scene from the 3D application. The PM4 player suite contains one test per captured 3D
application and one variation per supported GPU variant in each test.

Test PK006: 3DMark06: Canyon Flight

This test is captured from the Canyon Flight graphics test of the 3DMark06 Direct3D 9.0c benchmark.
Coverage
This test stresses primarily the shader core, texture pipe and depth buffer.
Fail Case
This test will fail if the actual CRC of any rendered frame does not match the corresponding expected CRC. A failure
could be caused by a defective GPU graphics core or memory controller, defective graphics board components
(e.g. memory chips, voltage regulators), or a defective power supply.

Test PK014: DirectX SDK: SubD11

This test is captured from the SubD11 Direct3D 11.0 sample application in the Microsoft DirectX Software
Development Kit (SDK).
Coverage
This test stresses primarily the vertex grouper tessellator and shader core.
Fail Case
This test will fail if the actual CRC of any rendered frame does not match the corresponding expected CRC. A failure
could be caused by a defective GPU graphics core or memory controller, defective graphics board components
(e.g. memory chips, voltage regulators), or a defective power supply.
PMD (CPL-Chip Pervasive Logic)
Introduction
The Power Management Discrete (PMD) suite deals with all things related to saving power and Chip Pervasive
Logic (CPL) functionality.

Test PMD004: Golden Settings

Latest known good configuration values for numerous blocks. These values are kept in one header file for each
ASIC, and updated periodically. The values are written once during initialization.
Coverage
These tests will verify golden settings.
Pass Case
Writing the golden settings is the most important thing here. The dumping is mainly informational, and the
verification is not 100% because of read-only bits, and other issues.

Variation PMD004.003: Write Golden Setting

Pass Case
Always passes.
Fail Case
None.

Test PMD011: DPM

The purpose of Dynamic Power Management (DPM) tests is to validate the dynamic switching of clock and voltage
settings at the board level. This is normally accomplished by running some 3D and Memory tests while switching
and logging the DPM states.
Coverage
This test covers the following areas:
 Activity monitor - microcontroller that measures how active the ASIC is
 System Management Console (SMC) - microcontroller responsible for setting clocks and voltage based on DPM
state
 SMC Firmware (FW)
 Interrupts to SMC
 DPM state transitions
 Ultra Low Voltage (ULV) mode
 ULV mode usage (tracked by SMC soft registers)
Variation PMD011.018: Reset State Counters
Initializes the DPM state switching counter (resets the DPM state counters to zero). The test will send a message to
the System MicroController (SMC) to tell it to clear the Dynamic Power Management (DPM) state transition
counters. There are three counters, one each for low, medium, and high transitions.
Fail Case
Always passes unless the SMC is not started or does not respond.

Variation PMD011.019: Get State Counters

The test reads the SMC's private memory to retrieve the DPM state transition counters. There are three counters,
one each for low, medium, and high transitions. The three DPM counters will be returned to the user and
displayed. In order for this test to be effective, it is required that some type of GPU activity has occurred to create
non-zero state counts. The suggested approach is to run some 3D (Horizon) or memory tests to generate activity.
Fail Case
Total DPM state counts don't exceed threshold, SMC doesn't respond, or no GPU activity occurred.

Test PMD013: Thermal Protection

This test ensures that the Thermal Critical Temperature Fault (CTF) feature is working properly. The purpose of the
CTF feature is to shut down the system in case the GPU temperature has reached levels that are dangerous for the
GPU to operate. The feature is tested by artificially introducing and verifying the CTF condition using GPIO pin
GPIO19. The board is expected to hang after the CTF test is run; additionally, an LED will be turned on if this test is
executed on a board where CTF is actually connected to the voltage regulator on the board. The system should be
restarted after this test is run, therefore, it is recommended that this test be run at the end of any test suite.
Coverage
This test covers:
 Thermal sensors
 CTF interrupt
 Thermal event
 Maximum temperature func
 Temperature range reset
 Artificial Temperature change using offset
 Get Temperature Via SMBUS
Variation PMD013.011: Detect at least one bad TMON
Pass Case
TMONs all show as good..
Fail Case
At least one TMON shows as bad.

Test PMD015: Fan Control

This test validates the correct operation of the fan in regulating the asic temperature.
Coverage
Fan operation

Variation PMD015.003: Fan Drive Output (FDO) Equation Dynamic

This test changes the asic temperature and then restores the original temperature. The PWM (equation dynamic)
calculates the FDO based on asic temperature.
Fail Case
Diag fails if FDO is not as expected or changing temperature is not successful.
SAM (Secure Asset Management (SAM) Suite)
Introduction
Secure Asset Management (SAM) unit is a collection of hardware blocks responsible for accelerating various
security algorithms. The purpose this suite is to verify each blocks of hardware for their correct functionality.
Hardware blocks or capabilities that this suite verifies are as follows:
- Basic operations (FWV, mem-to-mem copy, etc.)
- Basic AM32 instructions (SRBM register access, MLA, Montgomery exponentiation, big number multiplication, all
instuctions user app, etc.)
- Crypto Engine (DMA, ODD, etc.)
The tests will either pass or fail if the block exists, and if the intended block does not exist the test will skip.
Note: When SAM FWV has failed, system has to be power cycled before SAM FWV can pass again.

Test SAM001: SAM Basic Functionality.

SAM1.* tests verify the basic functionality of SAM unit.
Coverage
Following SAM features/functionality are tested:
- FWV
- Memory to memory copy (with and without prefetch)
- Secure Memory
- Kernel controlled reset mechanism (SAM soft-reset and SRBM induced soft-reset)
- AM32 hang detection and protection mechanism

Variation SAM001.006: SAM Memory to Memory Copy

Pass Case
This test passes when SAM succeeds in copying from one memory region to another.
Fail Case
This test fails when SAM failed to copy from one memory region to another.
Test SAM002: SAM basic instruction/command processing and AM32
microprocessor instruction verification.
SAM2.* tests load secured and signed user application that runs various AM32 instructions for verification.
Coverage
Following SAM features/functionality are tested:
- Loading and validation of secured and signed user application
- Loading and validation of secured and signed user application after forced corruption of application
- Loading and validation of secured and signed user application and comparing results to the expected ones(GOLD).

Variation SAM002.003: Running of All_Instructions SAM user Application and

comparing output to the GOLD results.
Pass Case
This test passes when user application successfully loads and validates, or the output results match the expected
golden results.
Fail Case
This test fails when user application failed to load and validate, or the output results mismatch the expected
golden results.

Test SAM008: SAM Crypto DMA encryption/decryption.

SAM8.* tests verifies DMA mode of Crypto Engine.
Coverage
Following SAM features/functionality are tested:
- ECB
- CBC
- CTR
- CTR-AMD
- XTS
- Bypass

Variation SAM008.001: SAM crypto DMA ECB encryption.

Pass Case
This test passes when the encrypted result matches the expected golden result.
Fail Case
This test fails when the encrypted result does not match the expected golden result.
Variation SAM008.002: SAM crypto DMA CBC encryption.
Pass Case
This test passes when the encrypted result matches the expected golden result.
Fail Case
This test fails when the encrypted result does not match the expected golden result.

Variation SAM008.003: SAM crypto DMA CTR-Standard encryption.

Pass Case
This test passes when the encrypted result matches the expected golden result.
Fail Case
This test fails when the encrypted result does not match the expected golden result.

Variation SAM008.004: SAM crypto DMA BYPASS encryption.

Pass Case
This test passes when the encrypted result matches the expected golden result.
Fail Case
This test fails when the encrypted result does not match the expected golden result.

Variation SAM008.005: SAM crypto DMA CTR-AMD encryption.

Pass Case
This test passes when the encrypted result matches the expected golden result.
Fail Case
This test fails when the encrypted result does not match the expected golden result.

Variation SAM008.006: SAM crypto DMA ECB decryption.

Pass Case
This test passes when the decrypted result matches the expected golden result.
Fail Case
This test fails when the decrypted result does not match the expected golden result.
Variation SAM008.007: SAM crypto DMA CBC decryption.
Pass Case
This test passes when the decrypted result matches the expected golden result.
Fail Case
This test fails when the decrypted result does not match the expected golden result.

Variation SAM008.008: SAM crypto DMA CTR-Standard decryption.

Pass Case
This test passes when the decrypted result matches the expected golden result.
Fail Case
This test fails when the decrypted result does not match the expected golden result.

Variation SAM008.009: SAM crypto DMA BYPASS decryption.

Pass Case
This test passes when the decrypted result matches the expected golden result.
Fail Case
This test fails when the decrypted result does not match the expected golden result.

Variation SAM008.010: SAM crypto DMA CTR-AMD decryption.

Pass Case
This test passes when the decrypted result matches the expected golden result.
Fail Case
This test fails when the decrypted result does not match the expected golden result.
DF (Unified Video Decoder (UVD) Suite)
Introduction
The Unified Video Decoder, previously called Universal Video Decoder, or UVD in short, is a video decoding unit
that supports hardware decoding. The formats supported include:
 Full VC-1 and H.264 decoding (UVD 1)
 Frequency transformation and motion compensation in MPEG-2 (UVD 2)
 Full decoding support for MVC, MPEG-2, and MPEG-4/DivX/Xvid (UVD 3)
 Full decoding support for WMV9 (UVD 4)
Each test is composed of approximately 30 frames, each with a pair of bitstream data/decode messages. A
decoding session in the UVD hardware will output to a memory buffer in YUV format, one image for each decoded
frame. The HW CRC delivered by UVD FirmWare (FW) is used to validate the decoding process (and to determine if
the test passed or failed)

Test DF011: H264/VC1 Bitstream Tests

These tests verify UVD decoding of H264/VC1 streams.
Coverage
UVD decoding of H264/VC1 streams.
Pass Case
UVD LMI CRCs collected from FW feedback structure must match the reference values from xml
Fail Case
UVD LMI CRCs collected from FW feedback structure do not match the reference values from the xml.

Variation DF011.001: H264-HD 1920x1088 EightBelow (Blu-Ray)

Variation DF011.002: H264-HD 1920x1088 Yozakura (HD-DVD)

Variation DF011.003: VC1-HD 1920x1088 Rainforest

Variation DF011.004: H264-SD 960x544 Wildlife

Variation DF011.005: VC1-SD 720x352

VCE (Video Compression Encoding)
Introduction
The VCE suite tests the functionality of Video Compression Encoding block on the GPU designed to encode raw
video data (YUV 4:2:0) to various compression standards, including H.264, H.263, and MPEG-4.

Test VCE100: H.264 bit-stream encoding from memory

In all the regular encoder tests, YUV data and encode parameters are feed in, the encoder will output the
bitstreams of types specified for each test. The tests use the golden CRC references for validation. The input YUV
data will be encoded and collected H/W CRC are compared.
Coverage
These tests cover encode the major encoder features in Video Compression Engine including:
 H264 encode in 720p@60FPS
 H264 encode in 1080p@60FPS

Pass Case
Tests pass if CRC references and H/W CRC are identical.
Fail Case
Tests fail if CRC references and H/W CRC are not identical.

Variation VCE100.001: H.264 baseline @ level 3.0 128x96x30FPS

Variation VCE100.002: H.264 baseline @ level 3.0 QCIF

Variation VCE100.003: H.264 baseline @ level 3.0 CIF

Variation VCE100.006: H.264 baseline @ level 3.0 720x480x30FPS (NTSC)

Variation VCE100.007: H.264 baseline @ level 3.0 720x576x25FPS (PAL)

Variation VCE100.008: H.264 baseline @ level 4.1 1280x720x30FPS

Variation VCE100.009: H.264 baseline @ level 4.1 1920x1080x30FPS

Test VCE300: Basic wireless display

Coverage

Pass Case
Tests pass if CRC references and H/W CRC are identical.
Fail Case
Tests fail if CRC references and H/W CRC are not identical.

Variation VCE300.001: 2 TAP subsampling YUV444 input from DCE to YUV420

Variation VCE300.002: 4 TAP subsampling YUV444 input from DCE to YUV420

Test VCE301: Wireless display elementary stream (video only)

Coverage

Pass Case
Tests pass if CRC references and H/W CRC are identical.
Fail Case
Tests fail if CRC references and H/W CRC are not identical.

Variation VCE301.003: Video only @ 1280x720

Variation VCE301.004: Video only @ 1920x1080

AG (PCI Express Suite)
Introduction
The PCIE bus suite checks for link quality by monitoring the NAKs, detects, recoveries occurred during the normal
bus operations. PCIE link width speed are also monitored during the course of the testing. Usually PCIE tests are
run in conjunction with memory and 3D tests in order to simulate normal bus operations.

Test AG020: PCIE link quality test

This test validates the PCIE link quality.

Variation AG020.003: PCIE Nak counter check initialize

Initializes the GPU PCIE performance counters to monitor NAK received or generated events from the GPU
endpoint device. This test is normally run prior to running 3D or memory tests.
Fail Case
This test is designed to always pass.

Variation AG020.004: PCIE Nak counter check test

Verifies the NAKs received and generated by the GPU endpoint device are below the threshold value. The default
threshold value is 0, but the user can overwrite the setting by using the "pcienaks" parameter.
Fail Case
NAKs generated or received by the asic are above the threshold value.

Variation AG020.005: PCIE Link Quality check initialize

Initializes the GPU PCIE performance counters to monitor PCIE link detect or recovery events from the GPU
endpoint device. This test is normally run prior to running 3D or memory tests.
Fail Case
PCIE Link detects or recovers occurred during the normal asic bus operations.

Variation AG020.006: PCIE Link Quality check test

Verifies there are no PCIE Link detect or recovery events recorded in the GPU endpoint device.
Fail Case
PCIE Link detects or recovers occurred during the normal asic bus operations
Variation AG020.008: PCIE Link Width Check
Verifies the asic is running at requested PCIE link width.
Fail Case
The current PCIE link width does not match with the requested PCIE link width.

Variation AG020.010: PCIE Link Speed Check

Verifies the asic is running at requested PCIE link speed.
Fail Case
The current PCIE link speed does not match with the requested PCIE link speed.
AJ (PCIE Phy Suite)
Introduction
PCIE phy suite tests features associated with PCIE physical link layer.

Test AJ015: PCIE PHY Dynamic Link Speed Switching Test (Bridge Initiated)
These tests validate the stability of the PCIE link during PCIE link speed switching.
Coverage
Validates PCIE link speed switching between Gen1, Gen2 and Gen3 speeds using bridge device trigger.
Pass Case
The requested PCIE link speed switching is successful without any errors.
Fail Case
1) The requested PCIE link speed is not supported by endpoint or bridge device.
2) PCIE link NAKs received and generated are above the threshold values.
3) PCIE link Detects are above the threshold value.
4) PCIE link width is not same before and after PCIE link speed switching.

Variation AJ015.001: Link speed change between Gen1 and Gen1

Coverage
Validates PCIE link speed switching to Gen1 speed.

Variation AJ015.002: Link speed change between Gen1 and Gen2

Coverage
Validates PCIE link speed switching between Gen1 and Gen2 speed.

Variation AJ015.003: Link speed change between Gen1 and Gen3

Coverage
Validates PCIE link speed switching between Gen1 and Gen3.

Variation AJ015.004: Link speed change between Gen2 and Gen2

Coverage
Validates PCIE link speed switching to Gen2 speed.
Variation AJ015.005: Link speed change between Gen2 and Gen3
Coverage
Validates PCIE link speed switching between Gen2 and Gen3 speed.

Variation AJ015.006: Link speed change between Gen3 and Gen3

Coverage
Validates PCIE link speed switching to Gen3 speed.

Test AJ018: PCIE PHY Dynamic Link Width Switching Test (Up/Down Config)
These tests validate the stability of the PCIE link during PCIE link width switching.
Coverage
Validates PCIE link width switching between x1, x2, x4, x8, x12, and x16 widths using endpoint trigger.
Pass Case
The requested PCIE link width switching is successful without any errors.
Fail Case
1) The requested PCIE link width is not supported by endpoint or bridge device.
2) PCIE link NAKs received and generated are above the threshold values.
3) PCIE link Detects are above the threshold value.
4) PCIE link speed is not same before and after PCIE link width switching.

Variation AJ018.001: Link width change between x1 and x1

Coverage
Validates PCIE link width switching to x1.

Variation AJ018.002: Link width change between x1 and x2

Coverage
Validates PCIE link width switching between x1 and x2.

Variation AJ018.003: Link width change between x1 and x4

Coverage
Validates PCIE link width switching between x1 and x4.
Variation AJ018.004: Link width change between x1 and x8
Coverage
Validates PCIE link width switching between x1 and x8.

Variation AJ018.006: Link width change between x1 and x16

Coverage
Validates PCIE link width switching between x1 and x16.

Variation AJ018.007: Link width change between x2 and x2

Coverage
Validates PCIE link width switching to x2.

Variation AJ018.008: Link width change between x2 and x4

Coverage
Validates PCIE link width switching between x2 and x4.

Variation AJ018.009: Link width change between x2 and x8

Coverage
Validates PCIE link width switching between x2 and x8.

Variation AJ018.011: Link width change between x2 and x16

Coverage
Validates PCIE link width switching between x2 and x16.

Variation AJ018.012: Link width change between x4 and x4

Coverage
Validates PCIE link width switching to x4.
Variation AJ018.013: Link width change between x4 and x8
Coverage
Validates PCIE link width switching between x4 and x8.

Variation AJ018.015: Link width change between x4 and x16

Coverage
Validates PCIE link width switching between x4 and x16.

Variation AJ018.016: Link width change between x8 and x8

Coverage
Validates PCIE link width switching to x8.

Variation AJ018.018: Link width change between x8 and x16

Coverage
Validates PCIE link width switching between x8 and x16.

Variation AJ018.021: Link width change between x16 and x16

Coverage
Validates PCIE link width switching to x16.
Appendix A - AGT
POWERPLAY COMMANDS:

Name Description
-ppstatus Display current PowerPlay mode
-pprestore Restore to BIOS default PowerPlay Mode
-accel3d Set 3D Acceleration PowerPlay mode
-pplist List all supported PowerPlay modes
-pplist=short List all supported PowerPlay modes with short summary
-pplist=full List all supported PowerPlay modes with full details
-ppmode=[NUM] Set to a PowerPlay mode [NUM] (or bat|perf|uvd) from the
list
-ppsetclk=[NUM1],[NUM2] Set clocks and VDDC to a PowerPlay mode [NUM1]
(bat|perf|uvd), DPM state [NUM2]
-pplog Log output to a file ATIPP.LOG
-ppsave=fn Save PowerPlay settings to a file 'fn' (file name is optional
where default name is 'ppstat.inf'
-ppappend=fn Append PowerPlay settings to a file 'fn' (file name is optional
where default name is 'ppstat.inf')
-ppload=fn Load PowerPlay settings from a file 'fn' (file name is optional
where default name is 'ppstat.inf'
-ppeng=[NUM] Set Engine clock to new value [NUM] (MHz) by overriding
PowerPlay table
-ppmem=[NUM] Set Memory clock to new value [NUM] (Mhz) by overriding
PowerPlay table
-ppvddc=[NUM] Set VDDC to [NUM] (V) by overriding PowerPlay table
-ppvddci=[NUM] Set VDDCI to [NUM] (V) by overriding PowerPlay table
CLOCK COMMANDS:

Name Description
-clkstatus Display BIOS default and current clock values
-clklog Log output to a file called ATICLK.LOG
-clksave=fn Save clock settings to a file 'fn' (file name is optional wher
default name is 'clkstat.inf')
-clkappend=fn Append clock settings to a file 'fn' (file name is optional where
default name is 'clkstat.inf'
-clkload=fn Load clock settings to a file 'fn' (file name is optional where
default name is 'clkstat.inf')
-eng=[NUM] Set engine clock (SCLK in fusion) to new value [NUM] (MHz)
-mem=[NUM] Set memory clock to new value [NUM] (MHz)
Name Description
-clkrestore Restore to BIOS default values
-incclk=[NUM] Increase mem/eng clock to BIOS default + delta [NUM] (MHz)
-decclk=[NUM] Decrease mem/eng clock to BIOS default + delta [NUM] (MHz)
-incmclk=[NUM] Increase mem clock to current clk + delta [NUM] (Mhz)
-incsclk=[NUM] Increase eng clock to current clk + delta [NUM] (MHz)
-incmclkpct=[NUM] Increase mem clock by [NUM] percent of current clk
-incsclkpct=[NUM] increase eng clock by [NUM] percent of current clk (MHz)
-decmclk=[NUM] Decrease mem clock to current clk - delta [NUM] (MHz)
-decsclk=[NUM] Decrease eng clock to current clk - delta [NUM] (MHz)
-dclk=[NUM] Set UVD DCLK to new value [NUM] (MHz)
-vclk=[NUM] Set UVD VCLK to new value [NUM] (MHz)
-maxvco=[NUM] Specify UPLL VCO limit (MHz) for DCLK/VCLK
-uvdclkstatus=[NUM] Change UVD clock gating status: On/Off
-skipmemparam Skip memory parameter changes
-skipmempll Skip memory PLL reprogramming
-gteq Set mem/eng clock to a value >= the value specified for use
with insclkpct/incmclkpct
-lclk=[NUM] Set LCLK to a new value [NUM] (MHz)
-eclk=[NUM] Set ECLK to a new value [NUM] (MHz)
MEMORY COMMANDS:

Name Description
-mccfg Display memory configuration information
-mcchannel=[NUM] Set memory channel configuration to [NUM]
-mccolbit=[NUM] Set column configuration to [NUM]
-mcrowbit=[NUM] Set row configuration to [NUM]
-mcrank=[NUM] Set rank configuration to [NUM]
-mcbank=[NUM] Set bank configuration to [NUM]
-mcreg=[Off],[Val] Write a value [Val] to register at offset [Off]
-mcregb=[Off],[Val] Broadcast [Val] to register groups at offset [Off]
-mcregdump=fn Dump MC registers to a file 'fn' or to the display
-mcregload=fn Load MC registers from a file 'fn'
-mcsetting Display MC settings
-mcclksync Sync MC clock
-mcadllrst Reset ASIC DLL
-mcsize=[Val] Set memory size to [Val](16,32,64,128,256,512,1024MB)
Name Description
-mcdlladj Set DLL ADJ value for read data and strobe
-mcmadj=[Val] Set MADJ value for read strobe
-mcrdqsdly=[Val] Set rdqs delay
-mcrdqdly=[Val] Set rdq delay
-mcwdly=(0-f) Set write delay for all
-mcwdlyclk=(0-f) Set write delay for clock
-mcwdlyadd=(0-f) Set write delay to address
-mcwdlycmd=(0-f) Set write delay for command
-mcwdlydq=(0-f) Set write delay for data
-mcwdlyqs=(0-f) Set write delay for strobe
-mcwdlywck=(0-f) Set WCK delay
-mcwdlywdq=(0-f) Set TX DQ delay
-mcdrv=(p) Set driver impedance for all but clock
-mcdrvcmd=(p) Set driver impedance for command, address and clock
-mcdrvdq=(p) Set driver impedance for data
-mcdrvclk=(p) Set driver impedance for clock
-mcdrvqs=(p) Set driver impedance for strobe
-mcstr=(nnpp) Set buffer strength or offset for all but clock
-mcstrclk=(nnpp) Set buffer strength or offset for clock
-mcstrcmd=(nnpp) Set buffer strength or offset for command and address
-mcstrdq=(nnpp) Set buffer strength or offset for data
-mcstrqs=(nnpp) Set buffer strength or offset for strobe
-mcterm=(p) Set termination for data and strobe
-mctermdq=(p) Set termination for data
-mctermqs=(p) Set termination for strobe
-mcac Display memory AC timing
-mcvrefext Use external VREF
-mcvrefintdq=[Val],[Off] Use internal strobe VREF, [Val]=50|70, [Off]=0x0-0xf
-mcvrefintqs=[Val],[Off] Use internal data VREF, [Val]=50|60|70, [Off]=0x0-0xf
-mcsavefb Save display framebuffer data into file mcl0ad.txt
-mcloadfb Load display framebuffer data from file mcl0ad.txt
-mcautocal=[Val] [Val]=on|off
PCIe COMMANDS:

Name Description
-pciestatus Show current PCIe link status
Name Description
-aspm=[Num] Configure ASPM setting - off | [L1],[L0sRX],[L0sTX] ie. enable
L1 and L0s on both sides: -aspm=L1,L0sTX
Voltage, Fan Speed, and Tempurature COMMANDS:

Name Description
-vctfstatus Display thermal information
-vddc Dispaly current voltage
-vddc=[Num] Set VDDC to [Num] (V)
-vddci=[Num] Set VDDCI to [Num] (V)
-setmaxvddc Set VDDC to maximum allowed based on leakage ID (if
supported)
-temp Display ASIC tempurature
-fanrpm Display current fan speed
-fancontrol=[Num] Set fan speed to [Num] (0=Low speed; 1=High speed; 2=auto;
3=Medium speed)
-firmware_version Get firmware version for voltage control
-vddcsave=fn Save vddc settings to a file 'fn' (file name is optional where
default name is 'vddcstat.inf')
-vddcload=fn Load vddc settings from a file 'fn' (file name is optional where
default name is 'vddcstat.inf')
-vddnb0=[Num] Set SclkVIDLevel 0 to [Num] (V)
-vddnb1=[Num] Set SclkVIDLevel 0 to [Num] (V)
-vddnb2=[Num] Set SclkVIDLevel 0 to [Num] (V)
-vddnb3=[Num] Set SclkVIDLevel 0 to [Num] (V)
-vddnb_cnb=[Num] Set VDDNB request from CNB to [Num] (V)
-vddnb_vid=[Num] Force VID (will trigger VDDNB change)

Appendix B - ATIFLASH
Name Description
-i [Num] Display information of ATI adapters in the system. Display
information of adapter[Num] if specified.
-ai [Num] Display advanced information of ATI adapters in the system.
Display advanced information of adapter[Num] if specified.
-biosfileinfo [File] Display the BIOS info in file [File]
-p [Num] [File] Write BIOS image in file [File] to flash ROM in adapter [Num]
-pa [File] Write BIOS image [File] to all approopriate adapters
-S [Num] [File] [Size] Save BIOS image from adpater [Num] to file [File]. First [Size]
kbytes (except the theater in bytes) of ROM content is saved if
[Size] is specified
Name Description
-cf [File] [Size] [Sum] Calculate 16-bit checksum for file [File]. Checksum for the first
[Size] kbytes of the file is calculated if [Size] is specified
-cb [Num] [Size] [Sum] Calculate 16-bit BIOS image checksum for adapter [Num].
Checksum for the first [Size] kbytes of the ROM content is
calculated if [Size] is specified
-cr [Num] [Size] [Sum] Calculate 16-bit ROM checksum for adapter [Num] and
compare it to the [Sum] provided. This command is the same
as -cb if [Size] is specified
-t [Num] Test ROM access of adapter
-v [Num] [File] Compare ROM content of adapter [Num] to [File]
-mi [Num] [ID] Modify SSID and SVID in BIOS image of adapter [Num] to [ID].
SSID and SVID in BIOS image of adapter [Num] is displayed if
[ID] is not specified
-mb [Num] [File] Modify SSID, SVID, BIOS Pin Number, and Boot Message in
BIOS image of adapter [Num] to values in [File]. Input file
example: ssid = 715b svid = 1002 biospn = "113-xxxxxx-xx"
bootmsg = "ATI graphic board"
-pak [File] Package an executable for BIOS update according to the
commands in [File]. Config file example: outfile = update.exe
banner = "Update v1.0" infile = a123.bin command = -pa -
padevid=715B infile

Appendix C - TSERVER User Parameters

These parameters are available from the TServer command line. These can be used when executing any tserver
command (the command is automatically parsed and the applicable flags will be applied.

Name Type Description

-suitemargin=eng,mem flag This flag allows users to set their own guard band (eng/mem in
percentage). Use of this command over rides the default guard
band added within the suite flow. Usage example: ./tserver -
boardtest=quickmfg -suitemargin=3pct,3pct
-nodefstate flag This flag allows users to run the suite in a predefined state.
This parameter disables the default suite state behaviour.
*Exception is the DPM and UVD block test which require their
respective states. Usage example: ./agt -ppmode=1; ./agt -
ppeng=500 -ppmem=500; ./agt -ppdpmforce=2; ./tserver -
boardtest=quickmfg -nodefstate
-nogb flag This flag allows users to run the suite without the default
guard band added within the default suite state. Usage
example: ./tserver -boardtest=quickmfg -nogb
-noctf flag Addition of this flag will not prompt the question of whether
to run CTF or not. Usage example: ./tserver -
boardtest=quickmfg -noctf
-nw flag no wait
Name Type Description
-tid flag creates testid.log with test results
-log flag creates detailed log file
-templimit flag exits when specified temperature exceeded
-eofe flag exists on first error
-d=gpu.* flag runs on all plugged in GPUs
-pm_rt=1 flag Reduce run time of test
-linkspeed=2 flag Applicable to linkspeed check test - 1 (gen1), 2 (gen2)
-pr flag Production reports
-ascii_report flag displays ascii art of Pass/Fail

Appendix D - How to Mount a USB Key in Linux

Some configuration is required to 'mount' a USB drive and be able to perform read/write operations after a hot-
plug operation in debug mode.
In Linux, the memory stick is considered to be a SCSI device mapped to the /dev directory. The first device to be
detected is mapped to /dev/sda, the second device is mapped to /dev/sdb, etc. Typically with newer systems, the
first device /dev/sda will be assigned to the SATA hard drive.
 Create a folder in the 'mount' directory to where the usb will be mounted. In this example, the directory will
be called 'usbflash' mkdir /mnt/usbflash
 Plug in the USB to the USB port on the system, and observe the /dev directory which the USB key has been
mapped to dmesg | grep -i "SCSI" will show all connected SCSI devices - it will be possible to find the USB key
in this list.
 Mount the USB key to the created directory using the mount command mount
/dev/sd[deviceletter]1/mnt/usbflash
 Begin using the flash drive with the location /mnt/usbflash i.e to copy the file test.bin from the usbflash to the
root directory, type: cp /mnt/usbflash/test.bin /root