pi_system_dv.html 47.3 KB

Raw Blame History Permalink

<html>

<head>
        <title>PI System Verification</title>
</head>

<body>
<h1>
<p align="center">
PI System-level Verification
</p>
</h1>


<h2>Reference</h2>
<ol>
  <li> <a href=../hw/pi-spec.html>PI Specification</a>
</ol>


<!--
   T e s t   C o v e r a g e
-->
<h2>Test Coverage</h2>


<h3>Reset State Testing</h3>
Reset tests verify values after system reset. The registers with expected
values on reset can easily be determined from the PI spec, so they are not
listed here.


<h3>Register i/o Testing</h3>
Register i/o tests verify that binary patterns can be written and read from
registers that do not produce side effects (such a initiating a DMA). Unless
specified otherwise in the list to follow, we assume the listed register will
allow readback of the same value written. In this case, the registers should
have patterns written that toggle a bit in all non-'x' locations. In addition,
some number of random patterns should be tested.  Read only bits should be
tested by writing ones and zeros and verifying that the value stays the same.

<ul>
  <li> PI_ATBU
  <li> PI Buffer RAM: the PI buffer RAM is at addresses 0x0461_0000 through
       0x0461_07ff. i/o writes must be minimally 4 byte aligned, however, reads
       could be executed at single byte alignment. For test purposes 4 byte i/o
       will be used. In addition, each 4 byte aligned PIO address actually
       allows writing 41 bits. The upper bits are written using the PI_ATBU
       register contents, so test patterns will need to extend to values in
       this register. For reading, the upper 9 bits of two consecutive entries
       are read using 8-byte aligned reads in the PI_BUF_ATBU address space.
  <li> PI_DRAM_ADDR
  <li> PI_DEV_ADDR
  <li> PI_DOM1_LAT, PI_DOM1_PWD, PI_DOM1_PGS, PI_DOM1_RLS, PI_DOM2_LAT,
       PI_DOM2_PWD, PI_DOM2_PGS, PI_DOM2_RLS: write data should be dropped and
       reads always return specified patterns (zero in this case). To test use
       a read to verify the value, followed by a write of the negation of the
       pattern, then a read to verify the specified read patterns have not been
       changed.
  <li> PI_AES_CTRL   rw[21:9,7:0]   ro[30:22,8]  note: bit 30 is rw but doesn't
       read what was written. Can treat as ro for testing.
  <li> PI_AES_EKEY: tested as part of PI Buffer RAM test.
  <li> PI_AES_INIT: tested as part of PI Buffer RAM test.
  <li> PI_FLASH_CTRL rw[29:12,9:0]  ro[30,11,10]  note: bit 30, 11, 10 are rw,
       but don't read what was written. Can treat as ro bits for testing.
  <li> PI_FLASH_CONF rw[31:28,26:0]
  <li> PI_ERROR      rw[31:30]      ro[29:8,6]
  <li> PI_ACCESS     rw[ 7:0 ]      ro[31:8]
  <li> PI_IDE_CONF   rw[30:0 ]
  <li> PI_GPIO                      ro[31:8]
</ul>


<h3>Functional Testing</h3>
Functional tests verify function for side effect producing registers.
The tests are listed below in the order of execution.
Test methodology common to each of the DMA tests is summarized
<a href=#dmasummary>here</a>. In the DMA tests described below, only the
attributes which differ from the common ones are described.

<dl>

<dt><p><i>PI Buffer ATB Area PIO</i>
<dd> A portion of the ATB PIO was covered in the "Register i/o Testing"
     section. Testing here insures the upper 9 bits of PI buffer memory
     space can be be read and written. Since this feature is only useful
     for the ATB entry section, only that register range must be tested.
     The PI_ATBU register is used for writing, and each bit should be tested.
     The PI_BUF_ATBU register is used for reading, and the read/write should
     occur over the PI_BUF_ATB address range of the PI buffer.

<dt><p><i>PI Buffer DMA</i>
<dd> The PI Buffer DMA is controlled by the PI_DMA_BREAD and PI_DMA_BWRITE
     registers. In general, the test methodology summarized <a
     href=#dmasummary>here</a> should be used.
     <p>
     A DMA write (to DRAM) can be tested by first filling the buffer with a
     pattern of increasing value 4-byte words using PIO. The read tests should
     then occur for start addresses beginning at zero, and incrementing to
     cover the 2KB buffer by the minimum allowable alignment of 2B.  For each
     start address a DMA of the minimum size (1B), 2KB (will wrap in the
     buffer), and a random number between 1B and 2KB should be issued and
     verified.
     <p>
     To test the size specification, PI_DMA_BWRITE should be used to start a
     DMA, beginning at the first byte in the PI buffer, such that a '1'
     bit is "walked" through the allowable 24 bits (<i> why not limit
     this size to 11 bits in the spec???</i>) while the rest are zero.
     <p>
     The PI_DMA_BREAD register should be used to issue dmas to the PI buffer.
     The start and size should be tested similarly to the PI_DMA_WRITE case,
     except that the start address and size must both be 8B aligned.
     The guard bands can be 4B for this direction, since the
     start address and length are forced to the same blocksize as transferred
     by hardware.

<dt><p><i>Memory Module Indicators</i>
<dd> An ipc backdoor controlled through registers defined in the PI_IDE3
     space is used to behaviorally remove and insert the memory module.
     The MI_EINTR bits MD_STS and MD_INTR should be tested for proper operation
     using this backdoor. The testing should be done for the 4 states of
     PI_ERROR bits SK and EINT, and the generation of the specified
     interrupt and/or SK trap should be verified.
     <p>
     Tests cases with changing memory module states should also be carried out
     for the Flash controller, ATB DMA, and ATB PIO testing. These tests are
     specified in those respective sections.

<dt><p><i>Flash Controller</i>
<dd> The flash controller testing performed here will verify data transfer
     between flash storage (on module) and data buffers 0 and 1, starting
     at 0x0461_0000 and 0x461_0200, respectively. All these tests will
     have the ECC bit, PI_FLASH_CTRL[11], deasserted (ECC testing is
     performed in a separate test). Before beginning the tests, the
     PI_FLASH_CONF[31] bit must be set to 0 (allow write) and the
     remainder of the register must be set for the slowest expected
     flash device in the module. In addition, all tests will have the
     following in common unless specified otherwise:
     <ul>
        <li> the PI data buffer usage should alternate.
        <li> the PI_FLASH_CTRL[INTR] bit will be 0, and after each
             operation is verified that PI_FLASH_CTRL[INTR] is zero.
        <li> all erase and program operations will read status
             (command 0x70) on completion.
        <li> maximum allowable address ranges will be determined by
             the device id (command 0x90).
        <li> any operation should be granted simulator time by polling
             the PI_FLASH_CTRL[BUSY] bit to monitor completion.
     </ul>
     Testing will be performed using device models of size 16MB, 32MB, and
     at least one greater than or equal to 64MB (i.e., mega-bytes). The
     transistion to requiring an additional address cycle occurs at 64MB. We
     will not use 8MB devices in the final system, so the smallest model for
     testing is 16MB (8MB devices have a smaller block size).
     <p>
     We do not test using the 0x01 or 0x50 flash commands to locate the page
     address pointer during a program operation, since not all devices support
     this feature. Page program operations will always program the entire
     528 bytes. A partial program would be performed by appropriately setting
     the '1' bits within the data. Partial programming is not tested since
     this is would be a test of the flash model and not the controller.
     <p>
     The tests required for this section are summarized below. The format
     for each test is:<br>
        Test-name (coverage-description): test description.
     <ol>
       <li> Read ID (all devices): issue the 0x90 command (CMD byte) and
            determine the device manufacturer and code (2 bytes total).
            Verify these are correct given the flash models used in the
            simulator. Always issue the read with 2 bytes data cycle. If
            device requires more bytes, re-issue with number of bytes
            determined from 2 bytes returned.
            <p>
            The IDs should be used to set maximum address ranges for the
            remainder of the tests, where needed. Also, the ID can be used to
            set the PI_FLASH_CONF register with appropriate values (slowest
            device on module, if faster than value initially programmed).
            <p>
            <i>NOTE: we should also test that if no model is setup in the
            simulator, the all 0x00 pattern is returned (???), indicating
            no device is present.</i>
            <p>
            New Commands:
            <blockquote>
              read ID - 0x90
            </blockquote>
       <li> Full-page Read Operation (all devices, all address bits for devices
            requiring 3 and 4 cycles during read addressing): the read
            operation is verified over an entire page by setting the flash
            models to place a known data pattern into the devices (at simulator
            startup or using a tbd backdoor mechanism). <i>This pattern must
            not contain a page with all '1' bits, so that the same pattern can
            be used for the tests that follow.</i> The read command (0x00) will
            be used to read all 528 bytes on a given flash page, and the data
            is verified against that loaded into the flash model (simulator
            startup or backdoor). This verifies both that all devices are
            addressable on read, and that address bits 7..0 are working (bit 8
            is not directly issued by the flash controller).
            <p>
            Page selection: first, a single page is "randomly" chosen from each
            device.  Then, for the largest device using 3 address cycles
            (32MB), pages are chosen such that only a single address bit is
            set. The range of address bits is [24..9].  This is repeated so all
            address bits are tested (i.e., a "walking" 1-bit). For the largest
            device requiring 4 address cycles, the "walking" 1-bit test is
            repeated to cover address bits [highest..9] ("highest" depends on
            the device size).
            <p>
            New Commands:
            <blockquote>
              read - 0x00
            </blockquote>
       <li> Block operations (all devices, all block address bits (erase)
            and all page address bits (program, read) for devices
            requiring both 2 and 3 cycle block erase commands (3 and 4 cycle
            page program and read)): to begin, the initial data in flash
            should be such that no flash page contains all '1' bits. This
            should already be doen by the previous test.
            <ul>
              <li> block erase: erase a random block on each device such that
                   more than one address bit is 1. Verify erase by issuing a
                   read command (0x00) to a single 528 page in the erased block
                   to insure all bits are '1'. Repeat for block 0 on each
                   device. For the 32MB device (largest with 2-cycle erase)
                   erase and verify blocks with a "walking" 1-bit through
                   address bits [24..14] (16KB block size).  Verification is in
                   the same manner as before. For the largest device (must be
                   greater than 32MB), repeat for address bits [highest..14].
              <li> page program: all 528B data patterns are randomly generated,
                   and verification of programming is done by reading the
                   programmed page. Program and verify a random page (0-31)
                   within the random block erased on each device during "block
                   erase" testing. For the 32MB device, program/verify all
                   pages with a "walking" 1-bit in address bits [24..9] (bits
                   [8..0] must be zero). Repeat for the largest device
                   requiring 4 address cycles, except with the "walking" range
                   of [highest..9].
            </ul>
            <p>
            New Commands:
            <blockquote>
              erase - 0x60 (2+ cycle addr), 0xd0, 0x70 <br>
              page program - 0x80 (3+ cycle addr), 0x10, 0x70 <br>
            </blockquote>
       <li> Read over buffer offsets, sizes (random [device,block, page]
            vector): this is for both "regular" data and OOB data.
            Note that the buffer location for reads that begin in the OOB
            section will be different due to the required 0x50 addressing
            (only PI_DEV_ADDR bits 0..3 are used to set the offset into
            the OOB area, but bits 0..8 are used to determine the PI buffer
            address).
            <ul>
              <li> erase block
              <li> program page bytes with increasing values (mod 256)
              <li> over offsets into page (offset established by
                   PI_DEV_ADDR) with "walking" 1-bit in address bits [8..0],
                   use the 0x00 read command to initiate reads of sizes:
                   minimum size (1B), and maximum size (528-offset).
              <li> over offsets into page with "walking" 1-bit in address
                   bits [3..0], use the 0x50 read command to initiate
                   reads of sizes: minimum size (1B), and maximum size
                   (528-offset).
            </ul>
       <li> OOB read buffer packing (random [device,block, page] vector):
            test packing of multiple pages into data buffer, using property
            that the 0x50 address only uses addr[0..3], while the buffer
            address uses addr[0..8]. NOTE: because PI_DEV_ADDR[8] is or'd
            with the PI_FLASH_CTRL CMD bits, only the first 256B of pi buffer
            0 or 1 may be used. Otherwise, the 0x50 command would actually
            be issued as 0x51.
            <ul>
              <li> program spare area of 16 pages in block with continuously
                   increasing pattern
              <li> execute 0x50 reads of every page OOB 16B area with
                   addr[0..8] such that data is packed into first 256B
                   of pi buffer (0 or 1)
              <li> verify data packing (using pattern knowledge)
            </ul>
       <li> Interrupt test (all devices): test all valid PI_FLASH_CTRL[CMD]
            values (i.e., one of the cases from each of the previous tests)
            with the PI_FLASH_CTRL[INT] bit set, to insure an interrupt
            is generated. Clear int and insure BUSY bit does not assert
            after clear.  Verify that both MI int bit and INT1 get cleared.
            Test with int masked and unmasked in MI_INTR_EMASK_REG.
            Verify that interrupt is indicated in MI_EINTR_REG when enabled by
            PI_FLASH_CTRL and not indicated when not enabled in PI_FLASH_CTRL.
            Veriry that interrupt is indicated by INT1 when set in
            MI_EINTR_REG and the PI mask bit is set in MI_INTR_EMASK_REG.
            Verify that interrupt is is not indicated in INT1 when set in
            MI_EINTR_REG and the mask bit is clear.
       <li> Stop bit and reset command (all devices): test the
            PI_FLASH_CTRL[CMD] values for read, program and erase to insure
            the command can be stopped. Test by reading the BUSY bit. After
            stopping, issue the reset command (0xff). Insure stable stop
            by issuing an erase to the block associated with the stopped
            operation and verify all bits are '1'.
       <li> Status failure (all devices): test that the 0x70 (read status)
            command returns failure by initiating program and erase commands
            then setting PI_FLASH_CONF[31] to '1' while the operation is in
            progress. Then, issue the 0x70 command and verify status code
            indicates failure.
            Note: The flash status fail bit does not get set when failures
            are generated by either setting write protect or doing multiple
            prog's with no erase between. Therefore, this test does not pass.
            It is believed that this is a flash model problem.
       <li> Module state (all devices): all previous tests have had the
            memory module inserted. This test addresses the case where the
            module is removed. The relevant Flash commands are those that
            rely on the flash device R/B signal: read, program and erase.
            Those commands should be issued with the module not present,
            and it should be verified that - THE SPEC DOES NOT STATE WHAT
            HAPPENS IN THIS CASE (in tests, busy bit stays busy continuously).
            Also, those commands should be initiated with the module inserted,
            and during the phase where R/B is  polled, the module should be
            removed. The flash controller should hang, so the
            PI_FLASH_CTRL[BUSY] bit should continually indicate the busy state.
            The command should be stopped by writing 0 to PI_FLASH_CTRL[BUSY].
            Insure the flash controller can still operate by inserting the
            module and issuing the command once again - this time expecting
            success.
            <p>
            For each module state change in the above cases, verify operation
            of the PI_ERROR[MD_CUR] and PI_ERROR[MD_CHG] bits.
     </ol>


<dt><p><i>Flash Timing Configuration</i>
<dd> The Flash controller timing is set by the PI_FLASH_CONF register. This
     register also controls whether the flash is write protected (not on a
     device-by-device basis, but overall). Testing write-protect will be
     done by attempting erase and program operations with flash write protection
     set (we should already know from the Flash Controller testing that
     having a write-protect bit (PI_FLASH_CONF[31]) set to zero works.
     <p>
     Ideally, to test the timing control we should have a timing sensistive
     flash model that can be set to allow detection of violations for the
     full range of settings provided by PI_FLASH_CONF. If we do not choose
     to invest the time in writing such a model, we can only rudimentarily
     test timing by using the Samsung flash models we have and adjusting the
     system clock. One complication is that the Samsung models will "freeze"
     when a timing violation occurs. To unfreeze the model requires a simulator
     restart. This testing should be done last then, since a number of
     simulator restarts will be necessary.
     <p>
     To test, the simulator should be started with each legal system clock
     frequency. Then, for a given frequency, each parameter under control
     of PI_FLASH_CONF should be changed from slowest, to faster timing.
     For the sysclock frequency, a timing violation should occur at a
     known parameter speed setting. This can be detected by either having
     the pertinent operation (i.e., page read, program, ...) fail or having
     the model lock up (which is detected according to a timeout). If the
     model locks up, the simulator needs to be restarted to continue.
     Rather than attempting to detect this, it seems simpler to have each
     parameter variation and each sysclock frequecy be a separate test for
     which the simulator is started.


<dt><p><i>ECC</i>
<dd> Each of these ECC tests must be applied to data buffers 0 and 1, starting
     at 0x0461_0000 and 0x461_0200, respectively.
     The ECC is computed during transfers initiated by the PI_FLASH_CTRL
     register when the ECC bit is asserted. The read/write cases that are
     relevant are:
     <ul>
       <li> read entire 528B page
       <li> read page from byte 256 through 528
       <li> write entire 528B page (ECC computed during write)
     </ul>
     <p>
     Each of the tests below operates on a single page of flash. The ECC
     is assumed not to be page dependent, so the choice of pages is not
     paramount to the test. Each of the tests may not list
     the flash management details such as when to erase a block prior to
     programming (writing) a page.
     <p>
     The operation of the PI_FLASH_CTRL[INTR] bit must be validated for each
     test below. One case of each test should be run to validate, otherwise
     the tests will be run with the INTR bit 0.
     <p>
     The first test verifies the ECC bits are generated in accordance
     with the SmartMedia specification. This is necessary to insure the
     remainder of the tests that require ECC generation by the test
     software is consistent with the hardware generation.
     <ol>
       <li> ECC generation on write: generate random page data and program
            page. Read back data and ECC and verify data is correct and ECC
            bits are correct (should have no PI_ERROR indication on read).
            Repeat for 100 random data patterns. For this test the entire
            528B page write is always performed.
       <li> Read valid (no correction): write a random pattern to the 512B
            data region, and properly computed ECC bytes to the flash page OOB
            area. Read the 528B (using PI_FLASH_CTRL) and insure no data
            changes, then read from byte 256 through 527 and insure no data
            changes. Insure the PI_ERROR register indicates no errors. Repeat
            for a total of 10 patterns.
       <li> Single bit read error: as for the previous "no correction" test,
            but walk a single bit error through the data and ECC bit locations
            in OOB area. For errors in the data portion, insure the bit error
            is corrected on readback. For errors in the ECC bit area ensure no
            data is changed. Check to insure the PI_FLASH_CTRL[SBERR] bit is
            set, and that the DBERR bit is not set. Also, the relevant PI_ERROR
            bits should not be set. The first portion of the test will
            simultaneously walk a bit error through the first and second half
            data and ecc bits. To save simulation time, the bit walking takes a
            single bit from each successive byte. For the first 8 bytes, the
            bit is chosen such that every bit position within a byte is tested.
            For the remaining bytes, the bit error position (within the byte)
            is randomly chosen.
            <p>
            For a randomly chosen bit location in both the first half data and
            ecc bit areas, insure proper operation (as above) when the second
            half has no errors. Repeat for errors only located in the second
            half, also testing with a flash page read of only the second half
            (must be bytes 256 through 527).
            <p>
            Use a single random error bit in the data and ecc bit areas to verify
            that the PI_ERROR[UNC_ECC] and PI_ERROR[COR_ECC] bits remain 0.
            <p>
            Note: <i>a separate test should insure the int and SK trap are
            not generated when the SK and EINT bits are set.</i>
       <li> Double bit read error: like the single bit error case, but for
            sets of double bit errors instead of a walking single bit error,
            and using PI_ERROR[2] with PI_FLASH_CTRL[DBERR] for error detection.
            Note that the double bit errors should occur in a single 256B
            area and it's associated OOB ECC bits. The reads should be carried
            out for both the entire 528 bytes, and for bytes 256 through 527.
            When reading only bytes 256 through 527 there should only be an
            error when the two error bits are in the second half data region
            and ECC bits.
            <p>
            Ideally, the double bit errors would be in every combination
            of bits, but since this testing would require too much time we can
            test random double errors in (for a given 256B area) data, ecc area,
            and one in each. This should be done for both 256B data areas. Like
            the single bit error testing, there should be double bit errors in
            both pages simultaneously too.
       <li> Mixed single- and double-bit errors: a single-bit error should
            be in one 256+ECC half, and a double-bit error in the other. For
            full 528B page reads the double-bit error should be indicated.
            Since the point of this test is to insure the more severe error is
            reported, only full 528B page reads need to be done. Not every bit
            location needs to be tested for this case, but a matrix with the
            single bit error in the data vs. ECC areas, and double bit errors
            both in data, both in ECC, and one in each should be tested.
     </ol>

<dt><p><i>AES Controller</i>
<dd> The AES controller testing here is for commands initiated by the
     PI_AES_CTRL register. All references to the "key" mean the expanded
     key, PI_AES_EKEY. For each test one "run" must be performed with the
     PI_AES_CTRL[INTR] bit set to 1. Otherwise this bit can be 0.
     The specific testing:
     <ol>
       <li> Vary key and data: keep the SIZE fixed to 16B, DA to 0 and IA
            to buffer index 154. Create random data, key and init vector.
            Encyprt the data and write the data, key and init vector
            to appropriate buffer positions, then issue the START
            (with no int). Poll the BUSY bit to determine completion. Verify
            data. Repeat 1000 <i> what is a good number here??? </i> times.
            Also, repeat for fixed patterns of all 0xff, all 0x00, and
            alternating 0xff with 0x00.
       <li> Vary size and offset: using a single random set of data, key
            and init vector, the SIZE and DA values will be modulated. The
            encrypted data will be large enough to fill the PI buffer
            through index 131. For each possible DA value located at the PI
            buffer index 0 to 131, perform the following: decrypt a minimum
            size, a maximum size (bounded by index 131) and a mid size; verify.
       <li> Vary IA and DA: keep SIZE fixed at 16B, but perform the
            verification of encryption for the 16B data when the IA and
            DA are modulated. For each IA buffer index position between
            0 and 131, choose a DA location immediately before, after and
            random (within valid range).
     </ol>

<dt><p><i>ATB DMA</i>
<dd> The ATB is used for the n64-compatible register controlled DMA, so this
     test addresses both the ATB and the DMA. The tests below should have
     the AES and flash controller registers setup appropriately. Unless
     specified otherwise, each test below should use the ATB entry PIO bit
     (40) set to 1 (to allow the ATB PIO testing, below, to be performed
     while the specified ATB mappings are in effect).
     <p>
     <i>In some of the tests below a data pattern must be setup in flash
     before the test begins. To setup the data patterns, we should use a
     reasonable backdoor into flash, but at the moment we do not have a
     backdoor, so we either need a simulator restart with External_File.txt
     written to hold our pattern, or we need to use PI_FLASH_CTRL to establish
     the pattern. The latter could greatly slow the testing.
     </i>
     <p>
     Setup the flash models with a random data pattern, which is encrypted
     using a random key and iv, and has ECC applied.
     <ol>
        <li> Intra-ATB DMA read: a mapping requiring only a single ATB will
             be setup for a given device. This is done by replicating the
             single ATB entry to fill the entire ATB table. Since each device
             has a single mapping, a test pattern should be generated to
             consecutively fill flash blocks. The plaintext data pattern should
             be a repeating random pattern of fixed size (16KB seems
             reasonable, and is convenient because it matches the flash block
             size), and this "core" pattern must be stored to verify the DMA
             was successful. The data setup in the flash model should be
             encrypted using randomly chosen key and init vector, which will be
             used to initialize PI registers before the DMA begins. Unless
             otherwise specified, the ATB entry SIZE bits should be as
             large as the device can hold. <i>NOTE: even though only a single
             16KB pattern is used, correct block ordering can still be
             determined. This is because of the initialization vector
             chaining property of AES encryption. If the block fetch ordering
             is incorrect, the init vectors will be incorrect, and the
             decrypted pattern will not match the 16KB plaintext. Further,
             by exploiting this property and using only 16KB plaintext, the
             job of verifying a correct result is simple since the single
             pattern my readily be stored in memory and is the same for
             all mappings.</i>
             <p>
             Test over devices by setting up the mapping for each device in
             turn. For each device, issue a DMA starting at PI_DEV_ADDR=0, a
             reasonable PI_DRAM_ADDR, and a 4B DMA size. Verify using
             stored plaintext pattern.
             <p>
             Test over bits in PI_DEV_ADDR by using a mapping for the largest
             device available. While walking a 1-bit through this register,
             test with a fixed PI_DRAM_ADDR and 4B DMA size.
             <p>
             Test over bits in PI_DRAM_ADDR by using a mapping for a random
             device. While walking a 1-bit through this register,
             test with a fixed PI_DEV_ADDR and 4B DMA size.
             <p>
             Test over bits in PI_DMA_READ by using an ATB mapping for a
             random device. Walk a 1-bit through this register for sizes
             between the minimum (spec doesn't state what the minimum is, but
             the legacy tests used 2B) of 2B and the maximum memory allows
             (8MB?). The PI_DEV_ADDR and PI_DRAM_ADDR registers can both
             hold 0. <i> This test could take awhile! </i>
             <p>
             Test over ATB entry SIZE bits by walking a one-bit through
             (with an initial value of all zeros). For each size setting
             issue 4B DMAs starting at the beginning and end of the mapping.
             Test for PI_ERROR by issuing DMA too large for ATB (if hardware
             does not detect this before issuing, this will only be done
             for reasonably small DMA sizes).

        <li> Inter-ATB test1: contiguous 16MB mapping with ATB entries randomly
             hopping around such that blocks on all devices are covered. Every
             ATB entry should be unique in this case. The flash model data
             will need to be setup to match this mapping, so that the
             block-to-block initialization vectors are valid. As above, a
             single 16KB pattern of plaintext may be used, but the encrypted
             sequence must be written to flash following the ordering of
             the ATB mapping.
             <p>
             Issue DMA requests such that, starting with an address within
             the first ATB, the size covers a range of bytes ending within
             the next ATB mapping. The start and stop points can be reasonably
             random (in the sense the sizes vary, but are not so large the
             test is too slow to run). Repeat starting on each successive ATB
             entry.

        <li> Inter-ATB test2: like "Inter-ATB test1" setup, but every ATB entry
             will only cover a single flash block (SIZE bits all 0). Issue a
             single DMA to cover the entire space. NOTE: if this is too slow
             to run in the simulator, map whatever number of unique entries
             to allow reasonable size for run time.

        <li> Inter-ATB test3: ATB mappings where multiple entries are the same.
             First, only 10 entries but the last is repeated to fill the
             buffer. Second, half of the entries are one value and half are
             another. Third, same as previous but break the buffer into thirds.
             The DMA read requests issued should start at an address within
             each ATB entry and cover till the next entry with different
             mapping information.

        <li> ATB map error: insure PI_ERROR is as expected when request DMA
             hole in mapping. Test for "hole" at beginning, middle and end of
             a mapping that has a reasonable number of ATB entries.

        <li> ATB error permission bits: THESE ARE IN FLUX, SO THIS TEST
             WILL BE DEFINED ONCE THE BITS ARE FINALIZED.

        <li> ECC single bit error: one flash page should be setup to have
             a single bit ECC error. Insure the error is corrected and PI_ERROR
             and PI_FLASH_CTRL[SBERR] behave accordingly. Also insure
             interrupts and SK traps are set correctly given the settings on
             PI_ERROR[31:30].  Read DMAs should be issued such that:
             <ul>
               <li> the start address is before the page and the size is such
                    that the entire page is covered.
               <li> the start address is before the page and the size is such
                    that the dma ends within the page. The dma ending positions
                    should be tested for values in both the first and second
                    256B halves.
               <li> the start address is within the page and the end address
                    is outside the page. The test should be performed for
                    start addresses in each of the 256B halves of the page.
               <li> both the start address and end address are within the
                    page. start addresses should be used on both 256B halves
                    of the page. For the first 256B half, sizes should insure
                    the DMA is within the half and crosses into the next half.
                    For the second half the DMA should be sized to end in
                    that half.
             </ul>

        <li> ECC double bit error: repeat the single bit test but with a
             double bit error so PI_ERROR and PI_FLASH_CTRL[DBERR] mechanisms
             may be checked.

        <li> PIO enable ATB bit test: issue on DMA (any of above) with the
             PIO bit set to 0, to insure DMAs operate regardless of this bit.

        <li> DMA write: since this cannot succeed, verify PI_ERROR behaves
             appropriately (ADDR bits contain address, ATB_DMA bit set, int
             and sk trap generated if bits 31 and 30 set). This test can use
             the same ATB mappings as the previous test. PI_EDATA relevant???

     </ol>

     <p>
     XXX: must add memory module testing.

<dt><p><i>ATB PIO</i>
<dd> Testing of PIOs that occur to addresses mapped to flash space. Note
     that ATB PIO and ATB DMA accesses must be mutually exclusive, so there
     are no overlap test cases where both could be simultaneously operating.
     <p>
     First, all ATB setups used for the ATB DMA testing should have a PIO
     attempted that falls into each unique ATB map entry. Within each entry, PIO
     reads should be issued that request the first, last, and some mid-located
     data within a page. This should be carried out for the first page of
     a flash block, a mid-page in the flash block, and the last page of a
     flash block.
     <p>
     The rest of the ATB PIO testing should include:
     <ol>
        <li> The ATB entry bit 40 should also be tested to check if PIO
             is allowed or not. <i>PIO writes are not allowed.</i> Any PIO
             write should be dropped, and testing should insure PI_ERROR
             reports the error accordingly.
        <li> A PIO to an address not mapped by any ATB should be used to test
             relevant PI_ERROR bits: [29:8] for the address, [0] for ATB error
             during PIO (caused by both an unmapped request and a request whith
             no permission). This can be done using the same ATB mappings
             used to test for ATB "holes" during the ATB DMA testing.
        <li> during an attempted PIO write the PI_DMA_STATUS[IO_BUSY] should
             be polled to insure correct operation (cannot poll on read since
             SYSAD bus connected to cpu is stalled).
        <li> ECC single bit error: one flash page should be setup to have
             a single bit ECC error. For PIO reads at every 4'th byte location
             in the page, insure the error is corrected and both
             PI_ERROR and PI_FLASH_CTRL[SBERR] behave accordingly. Also
             insure interrupts and SK traps are set correctly given the
             settings on PI_ERROR[31:30].
        <li> ECC double bit error: repeat the single bit test but with a
             double bit error (won't be corrected) so PI_ERROR and
             PI_FLASH_CTRL[DBERR] mechanisms may be checked.
     </ol>
     <p>
     XXX: must add memory module testing. <br>
     XXX: insure PI_ERROR bits for write access are tested. <br>


<dt><p><i>General Purpose IO (GPIO) Signals</i>
<dd> The PI_GPIO register is used to read the board-id, and control 4 GPIO
     signals. The testing is as follows:
     <ol>
       <li> board-id read: the board-id value is set using an iosim backdoor.
            Once set, the PI_IDE3 register assigned to control pin reset
            must be written to cause reset. After reset, the board-id can
            be read using PI_GPIO. A "walking" 1 bit should be used to test
            every bit in PI_GPIO[ID] works properly.
       <li> GPIO signals: the GPIO signals are tested using the PI_IDE3
            register assigned to perform io on signals connected to the
            GPIO pins. For each pin, both directions should be tested for
            each bit value (i.e., to test PI_GPIO[0] as an input, PI_GPIO[4]
            would be set to 0, and PI_IDE3 would set the IDE side bit 4
            to 1. The value to read would first be written on the IDE side,
            then read/verified using PI_GPIO)
     </ol>


<dt><p><i>IDE Debug port and interrupts</i>
<dd> A full suite of IDE tests should include testing for bus reset and
     timing control (PI_IDE_CONF), toggling of all relevant address and
     data bits, access to each of the 4 ports, interrupt handling
     (includes MI registers MI_EINTR, MI_EMASK and MI_CTRL[UNMASK_IDE]),
     and flow control (PI_IDE_FC).
     <p>
     Because we do not currently have a full IDE test model capable of
     enabling all these tests, a more limited test coverage is currently
     being pursued. Testing will cover all facets of the IDE required to
     insure the debug port will function properly. This will use the debug
     port model and cover:
     <ol>
       <li> IDE bus reset (PI_IDE_CONF[31]), by reading reset values
            from debug port model.
       <li> performing io using the PI_IDE_FC register.
       <li> IO read/write to debug port addresses and toggling all data lines.
       <li> interrupt masking and generation, including test of all relevant
            MI registers, by using the debug port model to generate and clear
            interrupts.
     </ol>


<dt><p><i>PI Access Control</i>
<dd> The PI Access Control register (PI_ACCESS) is tested by performing
     PI operations from non-secure mode. The PI_ACCESS bits controlling
     each PI functionality should be set on, off, then on again, and
     one command to each functional area should be issued in each access
     state to insure proper access restrictions are in place. For these tests
     secure mode will be entered to set the PI_ACCESS bits.
     <p>
     The ability to turn off access from non-secure mode will also be tested.
     From secure mode all access is granted. Then from non-secure mode access
     is turned off, and verified. Also, an attempt should be made from
     non-secure mode to restore access, and it should be verified that
     access cannot be restored.
     <p>
     For each of Flash full page program, PI Buffer DMA, and AES operation do:
     <li>Start an extended operation with the appropriate access enabled.
     <li>Disable access and try to do the same operation.
     <li>With other functionalites enabled, do other access tests.
     <li>Enable access and and check that the extended operation completed successfully.
     <p>
     <li>With PI_ACCESS_BUFFER enabled, write data to the PI buffer.
     <li>With PI_ACCESS_BUFFER disabled, attempt to write to the same location.
     <li>With all other access bits enabled, perform access tests on other
     functionalities that would not be expected to modify the PI buffer.
     <li>Enable PI_ACCESS_BUFFER and check that PI buffer was not disturbed.


<dt><p><i>Notes on PI_ERROR Coverage</i>
<dd> No new tests are defined in this section, but for clarity all testing
     of the PI_ERROR register bits completed during previous tests is
     summarized. Note that the relevant previous tests will have been conducted
     with all valid settings of PI_ERROR[31:30] for interrupt and NMI
     generation (note that if both bits are set, both the interrupt and NMI
     will be generated).
     <ul>
       <li> Write errors - caused by attempting to write to cartridge space.
            TODO: insure testing for this and PI_EDATA.
       <li> ATB errors-
       <ul>
         <li> DMA involving device address with no ATB mapping (during ATB DMA
              testing). This tests bits 1 and [29:8], ATB_DMA and ADDR,
              respectively.
         <li> PIO involving device address with no ATB mapping (during ATB PIO
              testing). This tests bits 0 and [29:8], ATB_PIO and ADDR,
              respectively.
         <li> PIO to ATB mapped address but permission violation according
              to ATB entry bit 40 (during ATB PIO testing). This tests bits 0
              and [29:8]. <i>Precise definition of the permission bits is still
              in flux. This bullet will need to be updated once the bits are
              finalized.</i>
       </ul>
       <li> ECC errors-
       <ul>
         <li> correctable ECC errors (ATB DMA and ATB PIO testing). This
              tests bits 3 and [29:8].
         <li> un-correctable (2-bit) ECC errors (ATB DMA and ATB PIO testing).
              This tests bits 2 and [29:8].
       </ul>
     </ul>

<a name="dmasummary">
<dt><p><i>Common attributes of DMA tests</i>
<dd> Each DMA test will at least perform the following:
<ol>
  <li> ensure all bits in the PI_DMA_STATUS register operate as expected:
       <ul>
       <li> once initiated, poll bit 0, DMA_BUSY, to determine when the DMA
         has ended. This bit should always be asserted on the first poll.
       <li> Cause an error bit 2 (DMA_ERR) assertion by attempting to write
         any of PI_DRAM_ADDR, PI_DEV_ADDR, PI_DMA_READ, PI_DMA_WRITE,
         PI_DMA_BREAD, or PI_DMA_BWRITE while a DMA is in progress. Verify no
         DMA can be started after the error bit goes high, until a write to
         PI_DMA_STATUS bit 0 clears the error bit 2.
       <li> Test the ability of bit 1 to clear the interrupt. <i>Which
         register is used to check for and mask the interrupt?</i>
       <li> ensure PI_ERROR is not indicating errors for all DMA tests that
         should succeed.
       </ul>
  <li> Each  DMA test should place a guard band of known values around the
       target DMA address, to insure no unintended data overwrites occur.
       When DRAM is the target the guard band should be aligned to 16B (i.e.,
       the gaurd will require a check of from 0 to 15 bytes, depending on
       the DMA start and end alignment).
</ol>

</dl>


<h3>Libultra compatibility testing</h3>

We should consider running test code that uses the libultra osPi and osEpi
APIs on the host processor to insure compatibility. Among the issues to
consider is how much libultra interrupt handler support we would require for
various tests.

<h3>Legacy PI tests</h3>

There is currently a pi.tst file in the iosim test directory. With the
exception of the RDRAM configuration setup and i/o writes to cartridge address
space at 0x09000004, 0x09000008, 0x097cff00, 0x097cff0c, and 0x097cfffc
(???) the pi tests should succeed if the PI registers are properly initialized
before they are run (i.e., AES, ECC, ATB).
<p>
The legacy pi tests are covered by other tests in this document, but it
would be good to actually run them for insurance.

<!--
   T e s t   F r a m e w o r k
-->
<h2>Testing Framework</h2>

The following infrastructure is required to create the tests (in addition
to that already existing). For now, this section just contains the
module list:
<ul>
  <li> ipc backdoor to set memory module present state.
  <li> AES code to generate test patterns for AES state.
  <li> AES key expansion code to compute key for AES testing.
  <li> ECC generation software to generate test patterns for ECC tests.
  <li> known flash memory models plugged into simulator, with file that
       is read at reset (simulator startup) to initialize data entries.
       The filename is "External_File.txt", and located in the directory
       from which the simulator is run (hw/chip/vsim).
       <p>
       Models are required for devices requiring both 3 and 4 address cycles
       during page reads. The transistion occurs at 64MB (mega-bytes). Since we
       do not support devices with less than 16MB capacity (due to the
       different block size), this means we must have models of 16MB, 32MB (we
       already have these), and at least one greater than or equal to 64MB.
       <p><i>
       NOTE: a true backdoor for loading flash would be much better. This
       would save simulation time (it takes 40 seconds to transfer data to
       the PI buffer and program a page, and that is using a reduced timing
       model), prevent simulator restarts during testing, and allow a simpler
       mechanism for associating the AES key and init vector with flash
       test data. Ideally, the PI test would be able to generate the flash
       test data at each run. If the current methods of only loading at
       simulator startup were to be used, an ancillary piece of test software
       would need to be run before the simulator start. This software would
       generate test data in External_File.txt, and another file to hold key
       and init vector information. Then, when the pi tests are run they would
       be required to parse these files to obtain expected results for tests.
       But, even using this scheme, a simulator restart would likekly be needed
       since initialization is required at different points during testing
       (i.e, we need to first test flash page reading, but then must erase
       pages. Later, the ATB DMA testing requires re-initializing flash). </i>
</ul>

Test developement style: describe the "C" environ I have, and the use of
the DISABLE_INT and READ_INT macros to create code that should easily be
ported to act as a diag.

<!--
   T e s t   E n u m e r a t i o n
-->
<h2>Test Enumeration</h2>
This section will be filled in as tests are developed.


<h3>Misc Notes</h3>

<p>
Note on driving the simulator:<br>
<blockquote>
each socket command issued by iosym (for non-zero time events such as the
register i/o) will take only the number of simulator clock ticks to complete
the specific task. So, kicking off a DMA will only advance the simulator
enough ticks to complete the actual register reads. To generate ensuing
ticks to accomplish the DMA transfer other commands such as reading the
status or a "stall" of some number of ticks must be issued.
</blockquote>