WO2000065451A1

WO2000065451A1 - System and method for flexible memory banking

Info

Publication number: WO2000065451A1
Application number: PCT/US2000/009548
Authority: WO
Inventors: Scott A. Holcombe; Raymond K. Jessup
Original assignee: Neopoint, Inc.
Priority date: 1999-04-23
Filing date: 2000-04-10
Publication date: 2000-11-02
Also published as: WO2000065451B1; AU4337800A

Abstract

A memory banking scheme for a processor-based system defines a real address space (404) that can include a first unbanked address space region allocated as RAM space (408), a second unbanked address space region allocated as code space (406), and a banked address space region allocated as banked space (410). The actual memory system can include a plurality of memory regions that span an area greater than the real address space (404). The memory system includes a first memory region allocated for use by the processor as RAM (408), a second memory region allocated as a code region (406), and a plurality of banked memory regions that can be alternatively mapped into said banked address space (427, 428, and 429).

Description

DESCRIPTION

System And Method For Flexible Memory Banking

Background Of The Invention

1. Field of the Invention The present invention relates generally to memory systems, and more particularly to a system and method for flexible memory banking.

2. Related Art

Since the advent of microprocessors, computers and processor-based systems have become an increasingly integral part of our contemporary society. In fact, the microprocessor has enabled a plethora of new consumer-related products that play an important role in the day-to-day lives of millions of people throughout the world. For example, the realization of low-cost, relatively fast, mass-producible processors has led to the introduction of affordable consumer items such as, for example, calculators, personal computers, wireless handsets, and electronic organizers, just to name a few. Additionally, the microprocessor has enabled other more conventional consumer products to experience an evolution in features and capabilities, beyond those originally anticipated. In fact, numerous consumer products developed or in existence prior to the proliferation of microprocessors have been enhanced or improved by the addition of one or more processors. Such products include, for example, automobiles, telephones, appliances, televisions, stereo components, and other consumer products. This evolution has not been limited to consumer products, but has also enabled the enhancement of commercial and military products as well.

The vast proliferation of applications for the microprocessor has further fueled the advancement of microprocessor technologies. One area of advancement has been in the width of the address bus associated with microprocessors. Providing the contemporary processor with a wider address bus, allows the processor to address or access larger amounts of memory.

However, situations typically arise in which applications use more memory than the processor can address. One commonly-implemented solution to this situation is to store data or program instructions needed to run the application on a disk drive or other storage device, and to pull these data and instructions into memory (RAM or ROM) for execution. However, disk access times are usually slower than those associated with memory, resulting in a hit in performance. The use of caches and other memory management techniques have minimized the hit in performance suffered by having to store large amounts of data or instructions outside of memory.

Another solution to this problem is memory banking. With memory banking, two or more banks of memory share common address space. These banks are swapped in and out, such that the common address space actually addresses only one of the plurality of available memory banks. However, most contemporary memory banking techniques are somewhat rigid in their application.

Summary Of The Invention

The present invention provides a system and method for providing enhanced memory banking. According to one aspect of the invention, addressable memory space is divided into a plurality of sections, at least one of which is banked, and at least one of which is not banked. The code, data, and other routines for the system are allocated to banked and unbanked portions of the memory space based on system requirements. For example, in one implementation, system critical code is allocated to unbanked memory space, while non-critical code portions are allocated to banked memory space. As a result of this configuration, switching among a plurality of memory banks during system operation can be reduced or even minimized.

According to one aspect of the invention, addressable memory space is divided into at least three portions, non-banked RAM space, non-banked code space, and banked code space. The banked code space is referred to as overlay space, or an overlay region in this document. Non-banked RAM space can be used to implement RAM memory functions conventionally provided with processor systems. It is preferable that the RAM space be unbanked, as this space is generally used by the processor in real time to assist with instruction execution. As stated above, it is preferred that non-banked code space be used to store what is referred to herein as system critical code. System critical code can include code, portions of code or data that are used by the processor and have a measure of time-criticality associated therewith. Examples of system critical code can include the real-time operating system, interrupt service routines, and code that is shared among or executed by or in conjunction with other applications in the system. System critical code can also or alternatively be defined as including code, portions of code or other data that would, if allocated to a banked code space, have to be duplicated in a plurality of banks reducing the need to perform frequent bank switching.

Non-critical code allocated to banked memory space can include, for example, one or more applications, or portions of applications, that can be executed relatively independently of one another. As such, the execution of an application in one bank is less likely to result in the need to do a bank switch to continue or complete execution of that application. However, another aspect of the invention facilitates bank switching to allow code in one bank to efficiently call code in another bank and to return values from the called code.

According to one aspect of the invention, when an address is presented by the processor, the invention determines whether the address is in banked space or unbanked space. If the address is in unbanked space, the presented address is the actual address, and this address is used to access the designated memory locations. If, on the other hand, the address is in banked memory space, the invention determines which of a plurality of banks are actually being addressed. Once this is determined, the actual address is converted or translated to address the appropriate banked memory location or locations. In alternative embodiments, the invention determines and drives which one of the memory banks is mapped into the overlay region.. In order to determine which bank is being addressed, in one embodiment a decoder is used to decode one or more bank-select lines. Additionally, the bank select lines can be used in the address translation.

One advantage of the invention is that the allocation of critical and non-critical code to banked and unbanked memory space can reduce the need to switch between banks, thereby reducing the unwanted latencies associated with the bank switching. Further features and advantages of the invention as well as the structure and operation of various embodiments of the invention are described in detail below with reference to the accompanying drawings.

Brief Description Of The Drawings

The present invention is described with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements.

Figure 1 is a diagram illustrating a conventional memory banking scheme.

Figure 2 is a diagram illustrating a conventional memory banking scheme used in a application of an 80186 chip set for CDMA wireless handsets.

Figure 3 is a diagram illustrating an example architecture of a processor-based system using shared software in conjunction with software modules.

Figure 4 is a diagram illustrating an example embodiment of a memory banking scheme according to one embodiment of the invention.

Figure 5 is a block diagram illustrating an example implementation of the memory banking scheme according to one embodiment of the invention. Figure 6 is an operational flow diagram illustrating a process for selecting one of several banks according to one embodiment of the invention.

Figure 7 is a schematic diagram illustrating an example implementation for bank select circuitry according to one embodiment of the invention. Figure 8 is an operational flow diagram illustrating a process for calling a function in an overlay bank according to one embodiment of the invention.

Detailed Description Of The Invention

The present invention is directed toward a system and method for providing an efficient, flexible memory banking scheme. According to one aspect of the invention, the memory space is allocated in such a way that allows system-critical data or code to be maintained in a non-banked address space, while non-critical code portions are banked.

Before describing the invention in detail, it is useful to describe a conventional memory banking technique and an example application of this conventional memory banking technique. Figure 1 is a diagram illustrating a memory mapping for a conventional memory banking technique. Referring now to Figure 1, address space 104 represents the real address space that can be seen by the processor. That is, real address space 104 is within the range of addressable space of the processor.

With most conventional processors, this real address space can be on the order of one megabyte to several megabytes, depending on the width of the address bus of the processor. For purposes of illustrating this example, an actual physical size for the memory space is not critical. Therefore, the size for the memory space is illustrated as being some number N megabytes of addressable space, where N can be a whole number or a fraction.

Real address space 104 is divided into RAM space 108 and ROM space 106. Typically, in most applications, RAM space 108 can be used by the processor for real-time execution-related activities, such as, for example, register space. ROM space 106 typically can be used to store program code executed by the processor, interrupt service routines, the operating system and other code portions. ROM space 106 is typically referred to as code space. The memory that takes up real address space 104 can be divided between ROM space 106 and RAM space 108 as suitable for a given application. In the example illustrated in Figure 1, RAM space 108 is designated as being M megabytes, and ROM space 106 is designated as being N - M megabytes.

Also illustrated in Figure 1 is extended address space 114. Extended address space 114 includes the memory portions that are banked. Because, in most applications, RAM space 108 cannot be banked, a portion 118 of extended address space 114 is not used. Extended address space 114 includes code space 116 that is typically the same size as code space 106. Therefore, by switching the memory bank from real address space 104 to extended address space 114, ROM space 116 is accessed instead of ROM space 106. Thus, within a given range of address capability the range of accessible memory has increased by N - M megabytes. More than one extended address space 114 can be provided, further extending the range of accessible memory.

However, there are some inefficiencies associated with this conventional memory banking approach. In most conventional memory banking applications, ROM space 106 is totally memory banked. However, because some routines are preferably readily accessible to enhance performance, these routines are duplicated within the banked code space. For example, in most applications it is important that interrupt service routines and the real time operating system be present in order to enable the application to run, or at least to run efficiently. Therefore, when the code space is duplicated in banked memory, portions of the code, including interrupt service routines and real-time operating system, for example, are duplicated. This partially defeats the purpose of memory banking.

By way of further explanation, one example implementation of this conventional memory banking technique is now described with reference to Figure 2. Referring now to Figure 2, this example implementation includes real address space 204 and extended address space 214. This example implementation of memory banking is implemented in a CDMA phone system using an 80186 processor that has the ability of addressing one megabyte of address space. Thus, in this example implementation, real address space 204 is one megabyte in size, and is divided into 640 kilobytes of ROM code space 206, 256 kilobytes of RAM space 208, and 128 kilobytes of space reserved for future use. In this example implementation, only ROM code space 206 is banked. Therefore, extended address space 214 includes 640 kilobytes of ROM space 216, and 384 kilobytes of space 218 that is unused. In operation, when the processor is called upon to perform a function that is coded in ROM code space 218 of the extended address space 114, the memory bank is switched such that code space 216 can be accessed. Likewise, if functionality stored in code space 206 subsequently needs to be accessed, the memory banking is again switched such that the processor can access code space 206. As described above, because it is important that certain features such as interrupt service routines and the real time operating system be accessible at all times, these portions of the code are duplicated within both ROM code spaces 206 and 216. If these code portions are not duplicated, valuable time is lost switching between banks to access these critical pieces of code. According to the invention, a modified banking scheme is provided that can be used to avoid the inefficiencies associated with the conventional banking schemes discussed above. According to one embodiment of the invention, an additional space is defined in the address space, in addition to the code space and the RAM space in the memory map. This additional space is referred to in this document as overlay space. In this embodiment, it is this additional overlay space that is banked, thereby allowing the code space to remain unbanked. Thus, system critical code portions can be kept in unbanked memory. Of course, the RAM space can remain unbanked as well.

In order to take full advantage of the fact that the code space does not need to be banked, the code space can include functions required for or shared among some or all banked applications, as well as important functions such as interrupt service routines and the real time operating system. This allows these code portions to be accessed at all times without the need for bank switching, regardless of which bank is currently active.

This embodiment is especially useful in applications where any of several different applications may be called upon to be run by a processor. For example, consider an electronic organizer capable of performing many functions, such as maintaining a list of personal contacts, maintaining a calendar, acting as a calculator, providing the ability to send email, and other similar functions commonly found in contemporary organizers. As another example, consider a multi-function wireless phone capable of performing these organizer-like functions in addition to real-time phone functions. With these or other multi-application examples, the various applications or other non-critical code portions can be provided in banked memory that is mapped into or otherwise accessed via overlay space, and system critical functions can remain in unbanked code space.

In one embodiment, system-critical code portions can be defined as including those portions of code or data that are used for real-time operations, or that may be used as shared code or shared data among a plurality of other code portions, or that are part of the real-time operating system or the interrupt services routines. Another example might include utility functions such as text or graphics formatting code. Likewise, in one embodiment, non-critical code portions can include code portions that are relatively independent of other code portions, or are code portions for one application that are not frequently required by other applications or for real-time processing. In other words, it is preferred that code portions that would otherwise be duplicated in the plurality of banks for performance reasons be kept in the unbanked code portion of the memory space.

An example architecture for a simple personal organizer is now described. This example is used to further describe or illustrate one embodiment of how the code portions of a processor-based system may be distributed among code space and a plurality of banks mapped into overlay space. Figure 3 is a diagram illustrating a high-level architecture for a personal organizer. Referring now to Figure 3, the multi-application organizer includes shared software 304 as well as application specific software, or software modules, 308, 309, 310, 311, 312. In this example application, critical software 304 includes items such as the operating system for the electronic organizer, interrupt service routines, and other portions of the code that may be shared among any of the several applications 308 through 312. For example, critical-code 304 can include code to enable user interfaces such as a keyboard 320, a display 322, sound processing 324, or other features and functions shared among the various applications. In the other example of the multi-function phone, critical code 304 can also include code to enable communications, power control, or other realtime telephone features.

In the example illustrated in Figure 3, the electronic organizer includes an e-mail application 308, a notepad application 309, a calculator application 310, a contact list application 311, and a calendar application 312. According to this example architecture, each application 308 through 312 contains its own set of code that is unique, or at least somewhat unique to that application. Other code used to run the application that may be shared by other applications or by all the applications can be provided as a part of critical code 304. Thus, running a particular application may require the processor to have access to code in both shared code 304 as well as the associated application 308 through 312. Of course, as would be apparent to one of ordinary skill in the art, variations on this architecture are well known and it is common to have scenarios where there are modules of code or applications that may, in themselves, define separate functionality, but may also use shared software, such as shared code 304, to be run.

In the embodiment of the invention described above, where the address space is mapped into RAM space, shared code space and overlay space, a system such as that described with reference to Figure 3 can advantageously be used in conjunction with the invention. In such an example application, shared code 304 resides in code space, and the various applications 308 through 312, or other applications, reside in banked memory locations. The code in banked memory locations, such as, for example, application code, can be switched, or banked in and out of the overlay space of the real address space. For example, as a new application is called upon to run, the code associated with that application is banked into the overlay space.

Figure 4 is a diagram illustrating an example layout of the real address space according to one embodiment of the invention. Also illustrated in Figure 4 is an example implementation of the extended address space according to one embodiment of the invention. Referring now to Figure 4, real address space 404 includes shared code space 406, RAM space 408, and overlay space 410. Extended address space 424 includes shared code space 426 as well as a plurality of banked memory spaces 427, 428, 429. According to this embodiment of the invention, RAM space 408 provides random access storage locations for use by the processor in executing code. The address space 404 can be allocated as necessary by the system designer.

In one embodiment, shared code space 406 includes common code such as, for example, code shared between one or more applications, the real time operating system, interrupt service routines, and other code that the processor may be called upon to access. One example of common code is shared software 304. Overlay space 410 is mapped as the space into which application spaces 427, 428, 429 will be banked. Banked spaces 427, 428, 429 include the code executed by the processor in carrying the various applications that it may be called upon to provide. Overlay space 410 may be allocated to provide enough space for one or more applications.

In operation, the processor may be executing a first application that is banked in overlay space 410. In executing this application, the processor may be executing code banked in overlay space 410 as well as common code mapped to shared code space 406. When the processor is called upon to execute a second application that is not within the section currently banked to overlay space 410, the actual address space containing that application is banked into overlay space 410. As such, the alternative application space 427, 428, 429 containing the code for that application is banked into overlay space 410. The processor continues to execute the code for the new application, as well as any code that may be required to be executed in shared code space 406.

This memory banking scheme is now described in terms of an example embodiment of a wireless phone communicating using CDMA technology, and having additional features such as a contacts database, organizer, calculator, and so forth. In this example embodiment, the wireless handset is implemented using a chipset based on the 80186 microprocessor. Because the 80186 microprocessor is capable of addressing 1 megabyte of memory space, the real address space for the processor spans the range from 00000 to FFFFF, hexadecimal. An example mapping of the real address space for this embodiment is illustrated in Figure 5. According to the example illustrated in Figure 5, the real address space 504 includes 256 kilobytes of RAM [00000 to 3FFFF], 640 kilobytes of code space [40000 to DFFFF], and 128 kilobytes of bankable application space [E0000 to FFFFF].

Also illustrated in Figure 5 is the extended address space 524 for the example embodiment. Extended address space according to this example embodiment is allocated as having 640 kilobytes of common code space 526 [40000 to DFFFF], and three application banks. The application banks are each 128 kilobytes in the illustrated example. Bank 0 527 ranges from E0000 to FFFFF hex, bank 2 528 from 20000 to 3FFFF hex, and bank 1 529 from 0000 to 1FFFF hex.

In one embodiment, extended address space 524 is the actual memory space, containing the common code in common code space 526, as well as the specific applications in Banks 0, 1 and 2 527, 528, 529. In one implementation, the main system code for the wireless phone is provided in common code space 526, and includes the common code or shared software for the phone and its various applications. For example, in one embodiment, the common code includes basic phone operations (CDMA in the example embodiment), the operating system, a user interface manager, non- volatile data support, interrupt service routines, phone status information, display drivers, and the like. Preferably, the user interface manager is small, and used to start and suspend the various application tasks of the phone, and application bank selection. Non-volatile data support can provide the functionality used to support read and write operations to non-volatile data sections. Examples of the functions that can be associated with the phone status are collect and display phone status, signal strength, battery levels, roaming indicator, SMS indications, time/date, etc.

As stated, banks 0 - 2 contain the applications. Preferably, in one embodiment, each application is self-contained in that they do not need to communicate with other applications in other banks. However, the applications may need to communicate with the common code in common code space 526.

The configuration for banks 0 - 2 in one example implementation are provided in Table 1. After reading this description, it will become apparent to one of ordinary skill in the art how to implement alternative bank configurations.

Bank 1 Bank 2 Bank 3

Application Launcher Calendar Voice Recognition Engine

Call History Contacts Internet Browser

Universal Inbox To Do

User Preference Apps Memo

Voice Recognition

After reading this description, it will become obvious to one of ordinary skill in the art how to implement the memory banking scheme of the present invention with alternative applications or architectures.

Figure 6 is an operational flow diagram illustrating a process for selecting memory banks according to one embodiment of the invention. Specifically, the embodiment illustrated in Figure 6 is that in which there are three possible banks, bank 0, bank 1 and bank 2. In a step 604, a real address is received by the memory banking system. The real address is the address provided by the processor to access a portion of the memory space. In a step 606, the memory banking system determines whether the address provided by the processor lies within a range of the memory space that is not banked. If the address is accessing a portion of memory that is not banked, the real address provided by the processor is used to access that memory location at that address, as illustrated by a step 607.

In the embodiment illustrated in Figure 5, for example, step 606 can determine whether the address provided by a processor is addressing the common code address space from 40000 through DFFFF. If so, the real address is used to access code in common code portion 526 of the system memory. In an alternative embodiment, the system can also determine whether the address is within the RAM address space, ranging from 00000 to 3FFFF in the embodiment illustrated in Figure 5. If so, in that embodiment, the RAM space 508 is also not banked, and therefore when an address in this range is received, the system addresses RAM address space 508. In one embodiment, addressing is not used, per se, to drive banking. Instead, special functions can be called when banked code needs to be accessed or invoked. These functions perform the overlay mapping if needed. In this manner, real addresses can always be used, and simply translated at times based on input to the banking hardware. Because addressing isn't used to drive banking, normal areas (e.g., 40000 through DFFFF described in the example above) can be accessed in the usual fashion. In the illustrated embodiment, if the address is not in the range of common code space 506 or RAM space 508, then it is within overlay space 510. Therefore, the system determines which of a plurality of memory banks are actually to be addressed when an address indicating overlay space region 510 is received. In the example embodiment illustrated in Figure 5, there are three banks, bank 0 527, bank 1 529 and bank 2 528. Therefore, the system determines which of those three banks the processor is actually addressing. If the processor is actually addressing bank 0 527, the memory banking system simply uses the real address to access bank 0, which, in the illustrated embodiment, lies within the same address range as application space 510. Specifically, in the illustrated embodiment, bank 0 527 lies within the address ranges EOOOO to FFFFF. This is illustrated by steps 610 and 616 in Figure 6.

If, on the other hand, banks 1 or 2 are indicated, then the real address is translated or manipulated to address the appropriate one of banks 1 or 2. In one embodiment, this translation or manipulation is performed by simply performing an address offset calculation, such as, for example, an addition or a subtraction from the real address value. In the embodiment illustrated in Figure 5, because bank regions 1 and 2, 529, 528, are at the lower end of the memory space, this computation is performed by subtracting an address offset from the actual address. This is illustrated by steps 612, 614, 618 and 620 in Figure 6. Specifically, in the embodiment illustrated in Figure 5, if bank 1 529 is selected, the memory banking system subtracts the address value EOOOO from the real address to achieve the address mapped to bank 1 529. In one embodiment, this subtraction can be done by exclusive-OR-ing the real address with the offset value EOOOO.

Further, in the embodiment illustrated in Figure 5, if bank 2 is selected, then the memory banking system subtracts the address value C0000 from the real address to achieve the correct address within the space of bank 2 528. Again, in one embodiment, this subtraction is performed by exclusive-OR-ing the real address with the value C0000.

Although some of the embodiments described above set forth specific address ranges, region sizes, and number of banks, it would be apparent to one of ordinary skill in the art after reading this description that these factors are scalable and that alternative address ranges, memory or address space region sizes, and numbers of banked regions and numbers of banks can be implemented within the spirit and scope of the invention.

As also would be apparent to one of ordinary skill in the art after reading this description, there are numerous techniques for implementing the address offset or manipulation as highlighted, for example, by steps 618 and 620. For example, this technique can be performed using hardware, software, or a combination thereof. One example hardware embodiment is illustrated in Figure 7, wherein the real address is exclusive-OR' ed with a selected offset value to effectively subtract that offset value from the real address. Referring now to Figure 7, the offset circuit according to this example embodiment includes AND gates Ul, U3, U4 and exclusive-OR gates U2, U5, U6 and U7. The operation of this example implementation illustrated in Figure 6 is now described. Specifically, its operation is described with reference to an example embodiment such as that illustrated in Figure 5, where the total addressable memory space is one megabyte (i.e., 1024 kilobytes) although the circuit illustrated in Figure 7 is described with reference to this example embodiment of Figure 5, having three bank regions and one megabyte of total addressable memory space, it will become apparent to one of ordinary skill in the art after reading this description how this circuit can be applied to applications having different numbers of memory banks, different total addressable space sizes and different size memory regions or allocations.

Referring now to Figure 7, AND gate Ul has three inputs, which, in the described embodiment, receive the three most-significant bits (MSBs) of the real address. For example, in the embodiment where the real address space is one megabyte, inputs N, N-l, and N-2 represent the three most significant bits of the 20-bit address bus used to address the one megabyte of memory space. When the three most significant bits N, N-l and N-2 are all high (1), then Ul outputs a high level at its output.

The output of Ul is tied to input pins A and B of AND gates U3 and U4. Therefore, when the output of Ul is high, inputs A, B of U3 and U4 are high, allowing U3 and U4 to pass the signals at their respective inputs C to exclusive-OR gates U5, U6 and U7. Thus, when the most significant bits of the address bus are high, AND gates Ul, U3 and U4 can be said to be active in that they enable the exclusive-OR operation performed by exclusive-OR gates U5, U6 and U7. Thus, when the real address is in the range of 111XX...X (i.e., 11100...0 to 11111...1), the exclusive-OR address offset function is enabled.

In terms of the example illustrated in Figure 5, when the three most significant bits of the 20-bit address bus are high, the address bus is addressing memory in the range EOOOO through FFFFF, the overlay region 510. As stated, when this section of the address space is being address, bank regions 0, 1 and 2, 527, 528 and 529 are being accessed.

In order to determine the amount of offset, if any, to introduce to the real address, two bank select bits are provided. These are illustrated as BSEL0 and BSEL1. These bits are provided at the input of exclusive-OR gate U2 and are ultimately used in conjunction with AND gates U3 and U4 (when these gates are 'enabled' by high inputs A, B) to provide the values to be exclusive-OR' ed to the real address space. Specifically, in the illustrated embodiment, when BSELO and BSEL1 are both low, the output of U2 is a zero, which provides a zero at input C of AND gate U3. Additionally, because BSEL1 is provided as an input C to AND gate U4, this input C of AND gate U4 is also zero. Therefore, the output of AND gates U3 and U4 are both zero. When the outputs of AND gates U3 and U4 are zero, inputs D, E and F of exclusive-OR gates U5, U6 and U7, respectively, are all zero. Therefore, the most significant bits of the address N, N-l, and N-2, which are provided to the other input of exclusive-OR gates U5, U6, and U7, respectively, are effectively passed unchanged through exclusive-OR gates U5, U6, and U7. Therefore, with both bank select bits being a zero, and the three most significant bits of the address being high, the real address remains unchanged and bank 0 space 527 is accessed by addresses in the range of 111XX...X.

Another possibility with the embodiment illustrated in Figure 6 is BSELO being a low level and BSEL1 being a high level. In this embodiment, the output of exclusive-OR gate U2 is high. This high level is provided to input C of AND gate U3. When all of the most significant bits of the address bus are high, and input C is high, U3 outputs a high level to inputs D and E of exclusive-OR gates U5 and U6. Similarly, input C of AND gate U4 is high, as it is provided directly BSEL1. With input C being high and the most significant bits of the address begin high, the output of U4 is a high and this high level is provided to input F of exclusive-OR gate U7. Thus, as can be seen from this description, with the bank select inputs being a 1 0, inputs D, E and F of exclusive-OR gates U5, U6 and U7 are all high. Thus, the three most significant bits of the address (111) are exclusive-OR' ed with 111, resulting in a low output from each of U5, U6, and U7 (000). Thus, bank 1 529 is selected, because the new, most significant bits of the address bus are all zeros. Thus, the address 111XX...X is now changed to 000XX...X. Alternatively, if BSELO is high and BSEL1 is low, input C to U4 is now zero.

Thus, input F to exclusive-OR gate U7 is also zero. Because the output of exclusive-OR U2 is a 1 , input C to U3 is high, which, when the most significant bits of the address bus are high, provides a high output from AND gate U3, which results in a high level at inputs D and E of exclusive-OR gates U5 and U6. Thus, the most significant bits of the address N, N-l, N-2 are exclusive-OR' ed in gates U5, U6, U7 with the value 110. This results in an output of the address value for the most significant bits as 001. Thus, the address 111XXXXXXX, is replaced with the address OOIXXXXXXX. As such, bank 2 528 is selected.

Thus, simply put, the occurrence of all l's in the three most significant bits of the address enable the exclusive-OR function to take place. The values for the two bank select bits determine whether the most significant bits of the address are exclusive-OR' ed with one of the following: 111, 110, or 000.

Note that the embodiment illustrated in Figure 7, the combination of banked select bits being both high, is not a valid combination and is therefore not recognized. Preferably, the system is programmed such that this combination does not occur.

As illustrated by the example embodiment depicted in Figure 7, additional bits (i.e., bank select bits) can be provided to enable the bank selection. In one embodiment, these bits are provided by a routine that is running in the common code of the application. By providing this routine in the common code region of the application, it can be made available to and executed by the processor when necessary, regardless of the bank selected. One embodiment of this routine is described below and is referred to in this document as a program code overlay mechanism, or simply, overlay code.

As stated above, the banking architecture permits memory regions outside of the processor's address space to be logically mapped into an overlay bank (e.g., bank region 510) residing within the memory address space. As disclosed above, in one embodiment of the invention, the overlay bank region 510 resides at the top 128 kilobytes of the ROM (896 K-1024 K). While the hardware architecture described above is described in terms of an embodiment having a 1 megabyte address range, the software design can be extended to multiple megabyte code storage with little modification. As stated above, any code can reside in a bank or overlay, but in the preferred embodiment, application-level code is designated as residing in the bank due to slight additional overhead requirements to invoke functions residing in a bank. Additionally, it is preferred that code within a bank is mostly self-contained, meaning that it primarily calls for functions that reside within the same bank. As such, this minimizes the need to do bank switching. However, one aspect of the invention enables code in one bank to call functions residing within another bank, effectively mapping both banks into memory at the same time.

In one embodiment described above, bank select lines BSEL1, BSEL2 can be used to address the appropriate bank in memory. In one embodiment, overlay code is invoked and results in specific outputs on a pair of GPIO (general purpose I/O) lines on the processor as the bank select lines. Depending on the values output on the GPIO lines, the desired bank is mapped into the overlay mapping area designated in the address space.

As will become apparent to one of ordinary skill in the art after reading this description, additional overlay banks could be supported with additional space to store code overlays and additional hardware support. To accomplish this, additional GPIO lines could be used, or some other type of chip select mechanism, to support more code capacity. One problem associated with allowing code resident in one bank to invoke code in another bank, is that while the return address for the calling function is valid, the proper code overlay won't be mapped into the memory space when the called function is returned. Because the calling function's code would not be re-mapped into the overlay bank, invalid code would be executed. This would most likely result in a hardware reset. One aspect of the invention avoids this problem by providing small stub functions in the main code that access all overlay functions. The stub functions map the appropriate bank into the overlay region if necessary, call the appropriate function, and restore the previously overlayed mapping, and pass back any return value from the called overlay function.

Figure 8 is an operational flow diagram illustrating a process for calling code in an overlay bank and allowing code in one overlay bank to call code in another overlay bank, according to one embodiment of the invention. Referring now to Figure 8, in a step 804 executing code calls a function that is coded in one of a plurality of overlay banks. This could be a standard case where code in a common code region (e.g., common code 526) calls a function in one of a plurality of overlay banks. Alternatively, this could be the case where code in one overlay bank is calling a function which resides in another overlay bank, requiring switching between the overlay banks. Therefore, in a step 808, the overlay manager checks to determine which bank is currently mapped in the overlay space. If the overlay function being called resides in a bank that is different from the bank currently mapped into the overlay region, the overlay manager maps the new bank into the overlay region. This is illustrated by steps 810 and 812. In embodiments where the banks are selected using GPIO outputs, the overlay manager simply causes the GPIO outputs to be changed, reflecting that the new bank is now mapped into the overlay region, at least for the duration of the called function. If, on the other hand, the function being called resides in the same bank as that currently mapped into the overlay region, as illustrated by decision step 810, no re-mapping of the overlay space needs to be done.

In a step 816, the software calls the function from the overlay region, executes the function and saves the return value. If the overlay manager determined that bank switching needed to occur, and the new bank was mapped into the overlay region, this function was then called from that new bank mapped into the overlay region. Additionally, if a bank switch did occur to execute the called function, it is more than likely that the previously mapped bank needs to be restored.

Thus, if a bank switch did occur, the overlay manager maps the previously mapped bank back to the overlay space as illustrated by steps 820 and 822. Once the previously mapped bank is restored, if needed, the saved value return from the overlay function is provided to the calling function in the previously mapped bank. This is illustrated by step 824. Of course, if a bank switch did not occur, there was no need to restore the previously mapped bank and the process can continue directly to step 824 where the saved value is returned to the calling function. In a preferred embodiment, these overlay functions are contained in a single module referred to as the overlay manager. Preferably, the overlay manager resides in a common code region of the memory space such that it is readily available for use by applications or other software running in any of the mapped banks. In addition to providing bank-to-bank calls, the overlay manager provides the function of tracking the currently mapped bank into the overlay region. This eliminates the need for the rest of the system code to know in which bank a particular overlay function resides and whether or not it's currently mapped.

It may be desired in one embodiment to change the name of overlay functions such that the existing code can specify whether it is calling an overlay version of a function rather than the actual function. In one embodiment, the overlay version of the function is provided with the same name as the actual function with the additional designation OV_ added to the beginning of the name. For example, a call to a function named print will be replaced by a call to OV_print, designating the overlay version. Note that the code that actually resides in an overlay requires no modification. Preferably, in one embodiment, code is placed in overlay banks at a module level.

As such, it is not necessary for code in a module to use the overlay manager in order to call functions within the same module. This direct call capability can actually be extended to code within the same bank, but care should be taken to ensure that the collection of modules function as a unit, as it typically the case with a code library. While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

1. A processor-based system for implementing an architecture having common code and a plurality of application code modules, the system comprising: a processor; an address bus connected to said processor and defining a real address space, wherein said real address space includes a first unbanked address space region allocated as RAM space, a second unbanked address space region allocated as code space, and a banked address space region allocated as banked space, and a memory system, addressable by said address bus and having a plurality of memory regions that span an area greater than said real address space defined by said address bus, wherein said memory system includes a first memory region allocated for use by the processor as RAM, a second memory region allocated as a code region, in which common code is stored, wherein said common code includes interrupt service routines, a real-time operating system, and code shared among the plurality of application code modules, and a plurality of banked memory regions that are alternatively mapped into said banked address space, wherein said banked memory regions each store one or more of said application code modules, wherein said processor switches among the plurality of banked memory regions depending on the application module currently being executed.

2. The system of claim 1, further comprising a bank-select circuit to map one of said plurality of banked memory regions to said banked address space region.

3. The system of claim 2 wherein said bank-select circuit subtracts an address offset value from the actual address presented on the address bus to address the selected one of said plurality of banked memory regions.

4. The system of claim 3, wherein said subtraction is performed by exclusive- OR' ing the real address with said address offset value.

5. The system of claim 3, wherein said bank-select circuit comprises: a first AND gate having first, second and third inputs and one output, wherein said first, second and third inputs are coupled to the three most significant bits of the real address bus; a first exclusive-OR gate having a first input coupled to a first bank select bit, a second input coupled to a second bank select bit, and an output; a second AND gate having a first input coupled to said output of said first exclusive-OR gate, a second input coupled to said output of said first AND gate, and an output; a third AND gate having a first input coupled to said second input of said first exclusive-OR gate, a second input coupled to said output of said first AND gate, and an output; a second exclusive-OR gate having a first input coupled to said first input of said first AND gate, a second input coupled to said output of said second AND gate, and an output; a third exclusive-OR gate having a first input coupled to said second input of said first AND gate, a second input coupled to said output of said second AND gate, and an output; a fourth exclusive-OR gate having a first input coupled to said third input of said first AND gate, a second input coupled to said output of said third AND gate, and an output.

6. A memory system for expanding the address range of a processor, comprising: a real address space, wherein said real address space includes an unbanked address space region allocated as code space, and a banked address space region allocated as banked space, and a system memory, addressable by the processor and having a plurality of memory regions that span an area greater than said real address, wherein said memory system includes a first memory region allocated as a code region, in which common code is stored, and a plurality of banked memory regions that can be alternatively mapped into said banked address space.

7. The memory system of claim 6, wherein said common code includes interrupt service routines, and a real-time operating system.

8. The memory system of claim 6, wherein said real address space further comprises a second unbanked address space region allocated as RAM space; and said system memory further comprises a second memory region allocated for use by the processor as RAM.

9. The system of claim 6, further comprising a bank-select circuit to map one of said plurality of banked memory regions to said banked address space region.

10. The system of claim 9, wherein said bank-select circuit comprises: means for determining whether said real address is in said banked address space region; means for subtracting an offset value from said real address if said real address is in said banked address space region.

11. The system of claim 9, wherein said bank select circuit comprises: a first AND gate having first, second and third inputs and one output, wherein said first, second and third inputs are coupled to the three most significant bits of the real address bus; a first exclusive-OR gate having a first input coupled to a first bank select bit, a second input coupled to a second bank select bit, and an output; a second AND gate having a first input coupled to said output of said first exclusive-OR gate, a second input coupled to said output of said first AND gate, and an output; a third AND gate having a first input coupled to said second input of said first exclusive-OR gate, a second input coupled to said output of said first AND gate, and an output; a second exclusive-OR gate having a first input coupled to said first input of said first AND gate, a second input coupled to said output of said second AND gate, and an output; a third exclusive-OR gate having a first input coupled to said second input of said first AND gate, a second input coupled to said output of said second AND gate, and an output;

a fourth exclusive-OR gate having a first input coupled to said third input of said first AND gate, a second input coupled to said output of said third AND gate, and an output.

12. The system of claim 11, wherein said outputs of said second, third and fourth exclusive-OR gates are an offset value subtracted from said real address.

13. A method for expanding the address range of a processor, comprising: allocating a real address space as having an unbanked address space region as code space, and a banked address space region as banked space, and allocating a system memory as having a plurality of memory regions that span an area greater than said real address, wherein said memory system is allocated with a first memory region allocated as a code region, in which common code is stored, and a plurality of banked memory regions that are alternatively mapped into said banked address space.

14. The method of claim 13, wherein said real address space is further allocated as comprising a second unbanked address space region allocated as RAM space and said system memory is further allocated as comprising a second memory region allocated for use by the processor as RAM.

15. The method of claim 13 , further comprising the steps of: determining whether a processor is addressing one of a plurality of banked memory regions; and mapping a real address from the processor to access the appropriate one of said banked memory regions.

16. The method of claim 15, wherein said step of mapping a real address from the processor to access the appropriate one of said banked memory regions is performed during the execution of code stored in another one of said banked memory regions.

17. The method of claim 13, further comprising a step of calling a function residing in a first banked memory region from code currently executing from a second banked memory region that is mapped into said banked address space.

18. The method of claim 17, wherein said step of calling comprises the steps of: mapping said first banked memory region into said banked address space; calling a function from said first banked memory region mapped into said banked address space; saving the value returned from said called function; restoring said second banked memory region into said banked address space; and returning said saved return value to the executing code.

19. The system of claim 15, wherein said step of mapping comprises the step of subtracting an offset value from said real address if said real address is in said banked address space region.