Testing address lines of a memory controller

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-TI 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, EyenWrEn, 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'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'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 8 K 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 2 K 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.

Claims

1. A system for testing a set of address lines, said set of address lines having a first group and a second group, said second group being further divided into predetermined subgroups, said system comprising: at least one memory device having a first set of address inputs and a second set of address inputs, wherein said first set of address inputs is connected to said first group of address lines and said second set of address inputs is connected to separate subgroups at different times; anda program stored in said memory device and accessible by using said first set of address inputs, said program containing instructions that branch to access the separate subgroups.

2. The system of claim 1 wherein said memory device is a dual port memory device.

3. The system of claim 1 wherein the program is pre-loaded into the memory device using a first port and the program is executed using a second port.

4. The system of claim 1 wherein the program contains a plurality of code segments stored in different locations of said memory device.

5. The system of claim 1 wherein the program is pre-loaded during power-up.

6. The system of claim 1 wherein a first set of predetermined data is pre-loaded into the memory device using the first address inputs and wherein a second set of data is written into the memory device using the second address inputs, wherein addresses of the second set of data are associated with the first set of addresses by the program when the program is used to read the second set of data.

7. A data processing system comprising: a processor core;a memory controller for controlling a set of address lines having a first group and a second group, said second group being further divided into predetermined subgroups, said system comprising:at least one memory device having a first set of address inputs and a second set of address inputs, wherein said first set of address inputs is connected to said first group of address lines and said second set of address inputs is connected to separate subgroups at different times; anda program stored in said memory device and accessible by using said first set of address inputs, said program containing instructions that branch to access the separate subgroups.

8. The system of claim 7 wherein said memory device is a dual port memory device.

9. The system of claim 7 wherein the program is pre-loaded into the memory device using a first port and the program is executed using a second port.

10. The system of claim 7 wherein the program contains a plurality of code segments stored in different locations of said memory device.

11. The system of claim 7 wherein the memory controller is an instruction side memory controller.

12. The system of claim of claim 11, further comprising a data side memory controller that accesses the at least one memory device.

13. The system of claim 7 wherein said memory controller, said at least one memory device and said processor core are implemented on an integrated circuit.

14. The system of claim 13 wherein the integrated circuit is a field programmable gate array.

15. The system of claim 14 wherein the program is pre-loaded during configuration of said field programmable gate array.

16. A data processing system comprising: a processor core;a data side memory controller connected to the processor core that controls a set of address lines having a first group and a second group;an instruction side memory controller connected to the processor core that operates separately from the data side memory controller, and that provides address signals to at least the second group of address lines;at least one memory device having a first set of address inputs and a second set of address inputs, wherein said first set of address inputs is connected to said first group of address lines and said second set of address inputs is connected to access the second of address lines; anda program stored in said at least one memory device and accessible by using said first set of address inputs using the data side memory controller, said program containing instructions that branch to access the second set of address lines.