Abstract:
All the address lines in a data processing system can be tested by using one or more small memory device that do not occupy the full addressing capability of the address lines. In one embodiment, some of the address inputs of the memory device is connected to different address lines at different times. Instructions are pre-loaded into some locations of the memory device such that the address lines has to be asserted to fetch the instructions for execution. By executing the instructions and appropriately connecting the address lines to the address input, all the address lines can be tested. In another embodiment, some of the locations are pre-loaded with a set of predetermined values. A program then writes another set of predetermined values to associated locations. By reading the values in the locations and compared with the sets of predetermined values, it is possible to determine if the address lines are functioning properly.

Description:
FIELD OF THE INVENTION 
   The present invention relates to memory systems, and more particularly to testing of address lines without requiring the presence of memory devices addressable by all the address lines. 
   BACKGROUND OF THE INVENTION 
   Many data processing systems contains a memory controller, which is an electronic component that assists a processor to interface with random access memory (RAM) devices. Typically, a memory controller controls a number of address lines, which defines the maximum amount of addressable memory. In order to make sure that the memory controller works properly, the full addressing capacity need to be tested. In conventional testing, the memory controller is connected to memory devices that span the maximum addressable memory. This allows the testing of the full addressing capacity. 
   In advanced systems, the amount of addressable memory is large. In some situations, it may be very difficult to have memory devices that occupy the full span. One example of such a situation can be found in system-on-a-chip (SoC) devices that contain a processor, memory, and input-output peripherals. The amount of physical memory in the SoC is generally much less than the maximum addressable memory of the processor. Even though it may be possible to attach external memory devices to the SoC, it is desirable to conduct all testing within the SoC. 
   Consequently, there is a need for a new method of testing that does not requires large amount of memory. 
   SUMMARY OF THE INVENTION 
   One embodiment of the present invention is a system for testing a set of address lines. The set of address lines has a first group (e.g., the least significant group) and a second group. The second group is further divided into a number of subgroups. At least one memory device is used. It has a first set of address inputs and a second set of address inputs. The first set of address inputs (e.g., the least significant bits) is connected to the first group of address lines. The second set of address inputs (e.g., the rest of the address inputs of the memory device) is connected to separate subgroups at different times. A program is stored in the memory device and accessible by using the first set of address input. Thus, all the subgroups can access the program. The program contains instructions that branch from one subgroup to a different subgroup. After all the subgroups are accessed, all the address lines are tested. 
   In another embodiment of the present invention the set of address lines having at least a first group and a second group. At least one memory device has a set of address inputs that is connected to the first group and the second group at different times. A program pre-loads a first set of predetermined data into a first set of locations of the memory device and writes a second set of predetermined data into a second set of locations that is associated with the first set of locations. The first and second sets of locations are chosen such that each of the set of address inputs is exercised in accessing the first and the second sets of locations. The program further reads the first and second sets of locations to determine if they are correctly accessed by using the first and the second sets of predetermined data. 
   The above summary of the present invention is not intended to describe each disclosed embodiment of the present invention. The figures and detailed description that follow provide additional example embodiments and aspects of the present invention. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  is a block diagram showing a data processing system in which the present invention can be used. 
       FIG. 2  is a block diagram showing the instruction-side of a data processing system of the present invention. 
       FIGS. 3A-3C  show the relationship between the address lines of the system in  FIG. 2 . 
       FIGS. 4A-4B  show an exemplary code segment of test instructions of the present invention. 
       FIG. 5  is a block diagram showing the data-side of a data processing system of the present invention. 
       FIGS. 6A and 6B  show the relationship between the address lines of the system shown in  FIG. 5 . 
       FIG. 7  shows an exemplary memory map and data values of selected address locations in accordance with the present invention. 
   

   DETAILED DESCRIPTION OF THE INVENTION 
   The present invention relates to a new method for testing address lines. In the following description, numerous specific details are set forth in order to provide a more thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known features have not been described in detail in order to avoid obscuring the present invention. 
     FIG. 1  is a block diagram showing a system  100  in which the present invention can be used. System  100  contains a processor core  102 , an instruction-side memory controller  104 , and a data-side memory controller  106 . Instruction-side memory controller  104  controls an address bus  110  and a data bus  112  that are connected to a plurality of memory devices  114 - 116 . Similarly, data-side memory controller  106  controls an address bus  120  and a data bus  122  that are connected to a plurality of memory devices  124 - 126 . 
   System  100  can be implemented in a field programmable gate array (FPGA). For example, Xilinx, Inc. recently announced a new FPGA, the Virtex-II Pro, that contains a processor core (comprising a PowerPC core), an instruction-side on-chip memory (ISOCM) controller, a data-side on-chip memory (DSOCM) controller, a plurality of block random access memory (BRAM), and a plurality of high speed transceivers. The ISOCM and DSOCM controllers can each interface with 22-bit address buses, which means that the they can address up to a maximum of 16 MBytes of on-chip memory. However, the amount of BRAM in the FPGA is much less than 16 MBytes. Consequently, it is difficult to test the ISOCM and DSOCM controllers using conventional methods. 
   In one version of the Virtex-II Pro, the most significant 8 bits, address [0:7], are used to select the address space, and the remaining 22 bits, address [8:29], are used to access the on-chip memory in those address space. It should be note that other types of integrated circuits may have different architecture. 
   The present invention uses memory devices that span a subset of the addressable capacity, but allows the full capacity to be tested. In the present invention, the instruction-side and data-side are treated differently. In order to illustrate the present invention, the architecture of the Virtex-II Pro is used.  FIG. 2  is a block diagram showing the instruction-side  150  of a data processing system. It contains a processor subsystem  152  that includes a processor core  154  and an ISOCM controller  156 . Processor core  154  and ISOCM controller  156  communicate with each other through a set of signals, such as C_dcrDBus, C_iABus, and I_cRdDBus. The bus C_dcrDBus is a device control register data bus that allows the processor core to write data into registers of peripheral units (such as ISOCM controller  156 ) that reside on-chip. The bus C_iABus is an address bus that the processor core uses to deliver the address to ISOCM controller  156  to fetch the needed instruction from the on-chip memory. The bus I_cRdDBus is the data bus that the ISOCM controller  156  uses to deliver requested instructions to the processor core from the On-chip memory. 
   ISOCM controller  156  generates another set of signals for controlling the operation of its associated memory devices (such as memory devices  160  and  162 ). Examples of the signals are ABus_init, DBus_init, OddWrEn, EvenWrEn, ABus, and InstrDbus. In one embodiment, ISOCM controller  156  has a data width of 64 bits. The bus ABus_init is the address bus that the ISOCM controller uses to initialize the on-chip memory with instructions under user&#39;s (test) program control. DBus_init is the data bus that ISOCM controller  156  uses to write instructions to on-chip memory to initialize the on-chip memory with instructions under user&#39;s (test) Program Control. The signal OddWrEn is a signal that ISOCM controller  156  uses to write instructions to the odd word (bits [32:63]) of the on-chip memory. The signal EvenWrEn is a signal that ISOCM controller  156  uses to write instructions to the even word (bits [0:31]) of the On-chip memory. The bus ABus is an address bus that ISOCM controller  156  uses to fetch instructions from the on-chip memory. The bus InstrDBus is a data bus that carries the pair of instructions fetched from the BRAMs. 
   In instruction-side  150 , each of memory devices  160  and  162  is a two-port device (designated ports A and B). As an example, each memory device can be a 512×32 bit BRAM. They are connected together to form a double word, as required by the exemplary 64-bit ISOCM controller of  FIG. 2 . Note that if the ISOCM controller or the memory device has a different data width, the number of memory devices can be different from two. Each port contains a 9-bit address bus (ADDR), a data in (DI), a data out (DO), an enable (EN), a write enable (WE), and a clock (CLK) signal. The 9-bit address bus is used to address  512  memory locations in the 512×32 bits BRAM. In  FIG. 2 , the letters “A” and “B” are attached to the signals to indicate that the signals belong to the “A” and “B” port, respectively. 
   In  FIG. 2 , the RdEn output of ISOCM controller  156  is connected to the ENA input of BRAM  160  and BRAM  162 . The EvenWrEn output of ISOCM controller  156  is connected to the ENB and WEB inputs of BRAM  160 . The OddWrEn output of ISOCM controller  156  is connected to the ENB and WEB inputs of BRAM  162 . The WEA inputs of BRAMs  160  and  162  are set at a fixed value (in this case, 1′b0). The DIB inputs of BRAM  160  and BRAM  162  are used to accept test program instruction during an initialization process. The DOA outputs of BRAM  160  and BRAM  162  are combined to provide a 64-bit bus for test program execution. Each of the ports of BRAMs  160  and  162  contains a clock (CLK) input. They are connected to the clock signal intended for controlling the operation of memory devices of the data processing system. In one embodiment in which the integrated circuit is a FPGA, the CLK signal is generated by a digital clock manager in the FPGA. 
   The connection between the ABus_init and ABus buses of ISOCOM  156  and the BRAMs depend on the addresses being tested. To test each address line bit of ABus[8:28] of ISOCM controller  156 , the address lines to the BRAMs are connected in three distinct groups, ABus[8:13], ABus[14:19], and ABus[20:28], and three separate test programs are applied. To test address line bits of ABus[20:28] in test program  1 , the address lines are connected to ADDRA[0:8] of BRAMs  160  and  162 . To test address line bits of ABus[14:19] in test program  2 , the address lines ABus[14:19] are connected to ADDRA[0:5] of BRAMs  160  and  162  and address lines ABus[26:28] are connected to ADDRA[6:8] of BRAMs  160  and  162 . To test address line bits of ABus[8:13] in test program  3 , the address lines ABus[8:13] are connected to ADDRA[0:5] of BRAMs  160  and  162  and address lines ABus[26:28] are connected to ADDRA[6:8] of BRAMs  160  and  162 . 
   A table is provided to illustrate the relationship between the connection of ADDRA (shown as ABus* in  FIG. 2 ) and the test programs: 
   Test 1: ABus[20:28]; 
   Test 2: {ABus[14:19],ABus[26:28]}; and 
   Test 3 {ABus[8:13], ABus[26:28]}. 
   Similarly, a table is provided to illustrate the relationship between the connection of ADDRB (shown as ABus_init* in  FIG. 2 ) and the test programs: 
   Test 1: ABus_init[20:28]; 
   Test 2: {ABus_init[14:19],ABus_init[26:28]}; and 
   Test 3 {ABus_init[8:13], ABus_init[26:28]}. 
   If instruction-side  150  is implemented in a FPGA, the connection between the ADDRA and ADDRB ports of the BRAMs and the ABus and ABus_init buses of the ISOCM controller can be configured separately in each of the three tests. Thus, a new configuration is performed before running each test. As a result, there is no need to use extra circuitry in the connection. If the implementation is conducted on a non-programmable device, switching circuit elements (e.g., multiplexers) can be used to implement the different connections. 
   To verify that the address lines are operating properly, each address line bit needs to be toggled. In one embodiment, program instructions are pre-load into different address space regions of BRAMs  160  and  162 . The address lines of the BRAMs and ISOCM controller  156  are connected in the innovative way described above. The address lines are asserted to fetch those instructions for execution. If an address line bit is defective or stucked in a deasserted state, the test program cannot fetch the required instruction for execution, thereby causing test failure. On the other hand, if an address line bit is stucked at an asserted state, then the test program is fetching instruction from a wrong address or undefined memory location, again causing failure in the test. Thus, this embodiment consists of a combination of address bus connection scheme in hardware and associated test program in software. 
   In operation, processor core  154  first initializes BRAMs  160  and  162  by sending test instructions to ISOCM controller  156  via a device control register bus C_dcrDBus[0:31]. ISOCM controller  156  then generates the necessary address and control signals (ABus_init[8:28], OddWrEn and EvenWrEn) and writes those test instructions into BRAMs  160  and  162  through DBus_init[0:31]. After initializing the BRAMs, the test program branches to ISOCM address space and starts executions instructions fetched from the BRAMs. The test instructions stored in each address space region in BRAMs  160  and  162  basically directs the test program to branch from one address space region to another address space region, creating the effect of toggling the next higher significant bit of the address line. In conjunction with the address line connections described above in connection with  FIG. 2 , the three test programs toggle the address line bits one by one as shown in  FIGS. 3A-3C . These three figures show the correspondence between the address lines connection to BRAMs  160  and  162  (ABus[8:28] and ADDRA[0:8]) and the test program instructions exercising the address line bits (Abus[8:28] values). Note that not all address line bits exercised by the test program is shown in the figures. Only those that are used for illustration are shown. 
   If instruction-side  150  is implemented on a FPGA, the test instructions can be pre-loaded into the BRAMs during the configuration of the FPGA at power-up. In this case, there is no need to pre-load through ISOCM controller  156  using the device control register bus. 
   An exemplary code fragment of the test instructions contained in the address space regions in BRAMs is illustrated in  FIG. 4A  (addresses 0x0 to 0x5b) and  FIG. 4B  (addresses 0x5c upward). Because the least significant 3 bits of address lines ABus[26:28] are always connected to the last 3 bits of the BRAM address ports ADDRA[6:8], each address region reserves up to a maximum of 16 instructions for test routines. The three address space regions shown in  FIGS. 4A and 4B  are 0x0-0x3c, 0x40-0x7c, and 0x80-0xbc. 
   In  FIGS. 4A and 4B , the following symbols represent: 
   “addi” (Add Immediate): The format is “addi RT, RA, IM”. The contents of register RA is added to contents of IM field and the sum, sign-extended to 32-bits, is placed into register RT. 
   “addis” (Add Immediate Shifted): The format is “addis RT,RA, IM”. When RA is 0, the contents of IM field is shifted to the left most 16 significant bits and the right is concatenated with 16 0-bits. The result is placed into register RT. 
   “ori” (OR Immediate): The format is “ori RA, RS, IM”. An extended IM field is formed by concatenating 16 0-bits to the left with IM field. Register RS is ORed with the extended IM field, and the result is placed into register RA. 
   “mtctr” (Move to Count (CTR) Register): The format is “mtctr RS”. The contents of register RS are placed into CTR register. 
   “bctr” (Branch): The format is “bctr”. Branch unconditionally to address in CTR register. 
   Turning now to the data side, a block diagram of a data side  180  of a data processing system is shown in  FIG. 5 . It contains a processor subsystem  182  that includes a processor core  184  and a DSOCM controller  186 . Processor core  184  and DSOCM controller  186  communicate with each other through a set of signals, such as C_dABus, C_dWrDBus, and D_cRdDBus. DSOCM controller  186  generates another set of signals for controlling the operation of its associated memory devices (such as memory devices  190 - 193 ). Examples of the signals are ABus, wDBus, WE, EN, and rDbus. In one embodiment, DSOCM controller  186  has a data width of 32 bits. 
   The bus C_dABus is an address bus that the processor core uses to deliver the address to DSOCM controller  186  to get the data located in the data-side on-chip memory address space. The bus C_dWrDBus is a data bus that the processor core uses to deliver data to DSOCM controller  186  to write the data into the data-side on-chip memory address space. The bus D_cRdDBus is the data bus that DSOCM controller  186  uses to transport the read data to the processor core from the BRAMs. The bus ABus is the address bus that DSOCM controller  186  uses to get data from the on-chip memory. The bus wDBus is the data bus that DSOCM controller  186  uses to write data to on-chip memory. The signal WE[0:3] is the write enable signals for byte write. The signal EN is the signal for enabling BRAMs for reading or writing. The bus rDbus is the read data bus that delivers data from BRAMs to DSOCM controller  186 . 
   In an exemplary implementation, the BRAMs are set as single port 2Kx8 bits memory devices. They are connected in parallel so as to be compatible with the interface of DSOCM controller  186  (e.g., 32-bit word in this implementation). Four BRAMs are used because the exemplary DSOCM interface supports byte writes. In the present invention, only these BRAMs (with a total of 8K Bytes) are needed to test the entire address space of DSOCM controller  186  (e.g., 16 MBytes). 
   In  FIG. 5 , the CLK inputs of BRAMs  190 - 193  is connected to the data processing system in a similar way as that described in connection with  FIG. 2 . The EN output of DSOCM controller  186  is connected to the EN inputs of BRAMs  190 - 193 . The four WE outputs of DSOCM controller  186  are connected to the respective WE inputs of BRAMs  190 - 193 . The 32 data lines of wDBus output of DSOCM controller  186  are divided into four sets ([0:7], [8:15], [16:23] and [24:31]) and are connected to the respective DI inputs of BRAMs  190 - 193 . These lines are used to pre-load data into the BRAMs during an initialization process. The DO outputs of BRAMs  190 - 193  are combined to provide a 32-bit bus for testing. 
   In order to test the DSOCM controller, each address line bit needs to be toggled to verify the proper functioning of the address lines. In one embodiment, data is pre-loaded into the BRAMs in the selected address word locations where each address line bit is to be exercised. Preferably, the locations are selected such that the next higher significant bit of address line is toggled. The data value in each location is preferably unique. The pre-loading of data words into the BRAMs is performed by a software program when the integrated circuit is initialized (for example, during configuration when a FPGA is powered-up). The test program writes a known data byte or halfword into those word locations. The data word in those locations now consists of bytes from pre-loaded data word and bytes from data that is written in. Upon read back, the bytes from pre-loaded data word create a “signature” to indicate that the read back data word comes from the correct location. The written bytes indicate that the address bit line being exercised sends the data to the correct address location. As a result, the test program can check the data word and can certify that the address line bits are exercised correctly. 
   In  FIG. 5 , Each BRAM uses 11 address line bits ADDR[0:10] because they are configured as 2K words deep. To test each address line bit of ABus[8:29], these address lines are connected to BRAMs in two distinct ways and two separate test programs are applied. The connection is shown in  FIGS. 6A and 6B . To test address line bits of ABus[19:29] in the first test, these address lines are connected to BRAM address port ADDR[0:10]. To test address line bits of ABus[8:18] in the second test, these address lines are connected to BRAM address port ADDR[0:10]. Note that not all address line bits exercised by the test program is shown in the figures. Only those that are used for illustration are shown. 
   A table is provided to illustrate the relationship between the connection of ADDR (shown as ABus* in  FIG. 5 ) and the test programs: 
   Test 1: ABus[19:29]; and 
   Test 2: ABus[8:18]. 
   If data-side  180  is implemented in a FPGA, the connection between the ADDR port of the BRAMs and the ABus bus of the DSOCM can be configured separately in each of the two tests. As a result, there is no need to use extra circuitry in the connection. If the implementation is conducted on a non-programmable device, switching circuit elements (e.g., multiplexers) can be used to implement the different connections. 
     FIG. 7  shows an exemplary memory map and data values of address locations where data is pre-loaded in the BRAMs when the integrated circuit is initialized and when data is written into and read from. These operations are performed by the test program. 
   In the exemplary examples described in  FIGS. 2 and 5 , the address lines [0:7] are completely inside processor subsystems  152  and  182 , and they are not delivered to the BRAMs by the OCM controller. Consequently, these address lines are not tested in these examples. In a system where all the address lines are available for connection with memory devices, these address lines should also be tested. 
   It can be seen from the above description that a novel routing method has been disclosed. Those having skill in the relevant arts of the invention will now perceive various modifications and additions which may be made as a result of the disclosure herein. Accordingly, all such modifications and additions are deemed to be within the scope of the invention, which is to be limited only by the appended claims and their equivalents.