Graphical user interface for dynamically reconfiguring a programmable device

Description

RELATED APPLICATIONS

This application is a continuation of U.S. patent application No. 09/989,817, filed Nov. 19, 2001, now U.S. Pat. No. 6,971,004, issued Nov. 29, 2005.

This application is related to co-pending commonly-owned U.S. patent application Ser. No. 10/033,027, filed Oct. 22, 2001, entitled “MICROCONTROLLER PROGRAMMABLE SYSTEM ON A CHIP,” U.S. patent application Ser. No. 09/989,574, filed Nov. 19, 2001, entitled “METHOD AND SYSTEM FOR USING A GRAPHICS USER INTERFACE FOR PROGRAMMING AN ELECTRONIC DEVICE,” U.S. patent application Ser. No. 09/989,570, filed Nov. 19, 2001, entitled “METHOD FOR FACILITATING MICROCONTROLLER PROGRAMMING,” U.S. patent application Ser. No. 09/989,571, filed Nov. 19, 2001, entitled “METHOD FOR DESIGNING A CIRCUIT FOR PROGRAMMABLE MICROCONTROLLERS,” and U.S. patent application Ser. No. 09/989,817, filed Nov. 19, 2001, entitled “SYSTEM AND METHOD OF DYNAMICALLY RECONFIGURING A PROGRAMMABLE SYSTEM ON A CHIP,” all of which are incorporated herein by reference.

FIELD OF THE INVENTION

Embodiments of the present invention generally relate to the field of software interfaces and methods for programming and/or developing integrated circuits. More specifically, embodiments of the present invention pertain to a graphical user interface (GUI) and method for programming a dynamically reconfigurable integrated circuit.

BACKGROUND

Electronic systems and circuits have made a significant contribution towards the advancement of modern society and are utilized in a number of applications to achieve advantageous results. Numerous electronic technologies such as digital computers, calculators, audio devices, video equipment, and telephone systems have facilitated increased productivity and reduced costs in analyzing and communicating data, ideas and trends in most areas of business, science, education and entertainment. Electronic systems designed to provide these benefits often include integrated circuits on a single substrate that provide a variety advantages over discrete component circuits. However, traditional design and manufacturing approaches for integrated circuits are often very complex and consume significant resources.

Electronic systems often rely upon a variety of components included in integrated circuits to provide numerous functions. Microcontrollers are one example of integrated circuit components with characteristics that are potentially useful in a variety of applications. For example, microcontrollers are typically reliable and relatively economical to produce. Microcontrollers have evolved since they were first introduced and have substantially replaced mechanical and electromechanical components in numerous applications and devices. However, while traditional microcontrollers have some characteristics that are advantageous, they also tend to be limited in the number of applications in which any given microcontroller integrated circuit can be utilized.

Traditionally each microcontroller is custom designed precisely for a narrow range of applications with a fixed combination of required peripheral functionalities. Developing custom microcontroller designs with particular fixed peripherals is time and resource intensive, typically requiring separate and dedicated manufacturing operations for each different microcontroller (which is particularly expensive for small volume applications). Even if a microcontroller may suffice for more than one application, the range of those applications may be somewhat limited. For example, completely different and totally separate integrated circuits are generally used for disparate applications such as monitoring ambient temperature over time and transmitting the time/temperature data to a remote location, or detecting light and controlling the operation of a motor, or playing an audio recording and receiving/checking digital security information.

Application specific integrated circuits (ASICs) may appear to address some of the above issues, but they can present significant hurdles. ASICs tend to require sophisticated design expertise, high development costs, and large volume requirements. To the extent some flexibility may be provided by the inclusion of gate arrays or other logic devices, the traditional approaches remain expensive and require a sophisticated level of design expertise. In addition, traditional integrated circuit configurations and configuration are typically set during initial manufacture and are not readily adaptable to changing conditions in the field.

Traditional integrated circuits typically have a predetermined set configuration and configuration that do not conveniently facilitate dynamic changes. Typically, one set of components is included and set to perform one function and a second set of components perform another function. Many applications require a variety of different functions, resulting in significantly increased resource commitments where the configuration is “hard-wired” into the design. Providing circuit components dedicated to single functions may results in less than the most efficient utilization of those dedicated components. For example, numerous functions in a variety of applications are performed infrequently or intermittently, and the valuable resources committed to these activities sit idle for much of the time. In addition, in some applications, functions are performed sequentially, with a second group of components dedicated to later activities sitting idle waiting on input from a first group of components dedicated to earlier activities, and when the first group of components has finished, they sit idle while the second group performs their dedicated function.

Similarly, the purpose of particular external ports or pins is typically fixed, and traditional systems typically dedicate external ports or pins to very precise, well-defined purposes. Accomplishing additional or different interactions with external components sometimes requires additional dedicated external ports or pins which consume valuable resources that are typically limited. Some dedicated external ports or pins may be utilized infrequently (e.g., only on start-up) and/or required to wait while activities proceed via other external ports or pins.

What is desired is an interface, system and method that enables dynamic reconfiguration of a programmable device in a convenient and efficient manner.

SUMMARY

The present invention relates to a GUI, system and method for programming a dynamically reconfigurable electronic device (e.g., a programmable mixed signal integrated circuit, such as a programmable microcontroller, data communications device or clock device). In one embodiment of the present invention, the GUI enables easy and efficient switching between different configurations while preserving and/or monitoring the validity of the different configuration states. In one exemplary embodiment, the present invention is implemented in software for dynamically programming different configurations and functions of a microcontroller having integrated, configurable analog and digital/mathematical blocks of circuitry. A plurality of different configuration images may be utilized to define the different configurations and functions and facilitate allocation of programmable components included in the electronic device accordingly.

In one embodiment, the GUI is used to program a microcontroller that further includes configurable analog and digital/mathematical blocks of circuitry, all on a single substrate. (The term “configurable digital/mathematical block of circuitry” as used herein refers to a configurable digital block of circuitry that has been at least partially optimized to perform a variety of mathematical functions, such as counting, incrementing, adding, subtracting, multiplying, dividing, etc.)

In a preferred embodiment, the microcontroller (which may be as described in U.S. patent application Ser. No. 10/033,027, may further include a microprocessor, a plurality of internal peripherals, an interconnecting component, an external coupling port, and a memory for storing instructions. The microprocessor processes information. The plurality of internal peripherals (which may be configured from the configurable analog and digital/mathematical blocks of circuitry) are programmably configurable to perform a variety of functions associated with the microcontroller. The interconnecting component may be programmably configurable for selectively interconnecting the internal peripherals and other internal microcontroller components. The external coupling port may be programmably configurable to implement different connectability states by which the electronic system is connectable to an external device. The memory may store instructions and data (e.g., a configuration image) directed at setting the configurations and functions allocated to the plurality of internal peripherals, the interconnecting component and the external coupling port.

DRAWINGS

FIG. 1 is a box diagram showing a high-level architectural overview of an exemplary programmable device design/development software program and its primary components.

FIG. 2 is a screen view of a first configuration for an exemplary programmable device, as seen in a user module/datasheet view of the configuration editing subsystem component of FIG. 1.

FIG. 3 is a flow chart describing a basic dynamic reconfiguration process.

FIG. 4 is a screen view of the first configuration of FIG. 2, as seen in a pinout view of the configuration editing subsystem component of FIG. 1.

FIG. 5 is a screen view of the source code editing subsystem component of FIG. 1 for the exemplary programmable device of FIG. 2.

FIG. 6 shows a toolbar (GUI) configured for adding, deleting or switching between configurations in an exemplary dynamic reconfiguration process.

FIG. 7 shows an icon-based GUI for selecting between the different subsystems in the program of FIG. 1 and between different exemplary views of the configuration editing subsystem component of FIG. 1.

DETAILED DESCRIPTION OF THE INVENTION

Reference will now be made in detail to the preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be readily apparent to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the present invention.

Some portions of the detailed descriptions which follow are presented in terms of procedures, logic blocks, processing, and other symbolic representations of operations on data bits within a computer, processor, controller and/or memory. These descriptions and representations are the means generally used by those skilled in data processing arts to effectively convey the substance of their work to others skilled in the art. A procedure, logic block, process, etc., is herein, and is generally, conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps include physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, optical, or quantum signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present application, discussions utilizing terms such as “processing”, “computing”, “calculating”, “determining”, “displaying” or the like, refer to the action and processes of a computer system, or similar processing device (e.g., an electrical, optical, or quantum, computing device), that manipulates and transforms data represented as physical (e.g., electronic) quantities. The terms refer to actions and processes of the processing devices that manipulate or transform physical quantities within a computer system's component (e.g., registers, memories, other such information storage, transmission or display devices, etc.) into other data similarly represented as physical quantities within other components.

The present invention concerns an interface, method and system for dynamically (re)programming a programmable electronic device, comprising one or more configuration workspaces for configuring the programmable electronic device such that it has different functionalities at different times, and a separate “reconfiguration operations” workspace for adding, deleting, opening, closing, importing, exporting, saving and/or selecting a configuration and/or its corresponding workspace. The graphical depiction of a particular device configuration in a workspace on the screen or monitor of a general purpose computer or PC configured to run a software tool that includes the present interface is sometimes referred to as an “overlay.”

For a given reprogrammable device having different time-multiplexed configurations and/or functionality, the software tool that designs, programs or configures each such configuration and/or functionality will have a number of viewing screens, windows or workspaces corresponding to the number of device configurations and/or functionalities. The view screen(s), window(s) or workspace(s) corresponding to a given/unique device configuration and/or functionality may sometimes be known as an “overlay.” Thus, the software design, program, data file set or configuration(s) for a given reprogrammable device having different time-multiplexed configurations and/or functionality (a so-called “project”) may contain multiple overlays.

Each overlay may be considered to be a hardware design within the programmable electronic device that exists at a given point in time to perform a given function. One overlay may be replaced or augmented (or partially replaced and partially augmented) by another overlay within the same project, to enable the device to perform two different functions (or have two different performance capabilities) at two different times. The two overlays map onto the same hardware resources in the device, and therefore, should be (and preferably are) time-multiplexed (i.e., operable in the device at mutually exclusive times, or configured such that at most one overlay is operable in the device at any given time). As a result, different functions and/or performance capabilities can be time-multiplexed within a single (re)programmable device by virtue of different overlays (e.g., different configuration data sets) that may be stored in memory that is in communication with the device. In the present system, such memory (which may be volatile, such as dynamic and/or static random access memory, non-volatile, such as EPROM, EEPROM, or flash memory, or both) is preferably on the same die as the electronic device (i.e., is monolithic).

In one embodiment, the programmable electronic device can be reconfigured dynamically; e.g., the different configurations and/or functionalities may be swapped or switched (partially or fully) “on the fly.” At one instant in time, the device can configured using a first set of partially or fully programmed (and optionally pre-programmed) modules to transmit electrical signals (an exemplary “first overlay”), then within the time a processor takes to unload and load a set of registers or register banks, the same device can be reprogrammed with a second set of partially or fully programmed (and optionally pre-programmed) modules to receive electrical data signals (an exemplary “second overlay”).

The present invention relates to an interface, system and method that enables such dynamic reconfiguration of a programmable electronic device, notably through software tools, operations, instructions and/or code that allows one to design, configure, create or modify multiple overlays or configurations, the active states of which are operably time-multiplexed in the device. For example, within a module or component placement and/or configuration workspace displayed by such software operating in a suitable computing environment, one may switch back and forth between different overlays to easily compare functional and/or performance (parameter value) similarities and differences between the different overlays. Thus, in a preferred embodiment in the present interface and system provides the first configuration with instructions, programming and/or information sufficient to enable reconfiguration of the device from said first configuration to said second, different configuration.

In a preferred embodiment, a tool having such a “reconfiguration operation” GUI for operating on overlays within a project created with the tool can also compute the hardware resources that are shared and/or that are different and/or not compatible between the different overlays. Such capability is useful because it enables the programmer to reprogram only those features, parameters and/or hardware resources that differ between the different overlays. Resources, features and/or parameters that are common to the different overlays need not be reprogrammed.

The present invention is related to several U.S. patent applications which are incorporate herein by reference. U.S. patent application Ser. No. 10/033,027, filed Oct. 22, 2001, entitled “MICROCONTROLLER PROGRAMMABLE SYSTEM ON A CHIP,” describes a programmable microcontroller having configurable analog and digital blocks of circuitry that solves a number of the above-described obstacles. U.S. patent application Ser. No. 09/989,570, filed Nov. 19, 2001, entitled “METHOD FOR FACILITATING MICROCONTROLLER PROGRAMMING,” describes a method, interface, software and system for designing and/or programming a circuit (such as a microcontroller) having configurable, programmable functions that can be embodied in configurable analog and/or digital blocks. U.S. patent application Ser. No. 09/989,571, filed Nov. 19, 2001, entitled “METHOD FOR DESIGNING A CIRCUIT FOR PROGRAMMABLE MICROCONTROLLERS,” describes a methodology, interface, software and system by which a user programs and/or configures a programmable microcontroller having configurable and/or programmable functions that can be embodied in configurable analog and/or digital blocks of circuitry.

U.S. patent application Ser. No. 09/989,574, filed Nov. 19, 2001, entitled “METHOD AND SYSTEM FOR USING A GRAPHICS USER INTERFACE FOR PROGRAMMING AN ELECTRONIC DEVICE,” describes a method, system and GUI for programming and/or configuring such a programmable microcontroller. U.S. patent application Ser. No. 09/989,817, filed Nov. 19, 2001, entitled “SYSTEM AND METHOD OF DYNAMICALLY RECONFIGURING A PROGRAMMABLE SYSTEM ON A CHIP,” describes an improved programmable electronic device wherein instructions stored in memory facilitate dynamic reconfiguration of the device. Based upon the existence of a predetermined condition, the electronic device is automatically reconfigured by activating different configuration images.

FIG. 1 is a block-level overview of an exemplary software program or tool 2 for designing, configuring and/or programming a programmable electronic device, such as a mixed signal integrated circuit having configurable analog and/or digital circuit/function blocks (see, e.g., U.S. patent application Ser. No. 10/033,027.

In a preferred embodiment, the tool 2 is exemplified by PSoC Designer™ software (for designing and/or configuring programmable analog and/or digital functional blocks and/or modules of circuitry in a programmable integrated circuit; see version 3.10, available from Cypress MicroSystems, Inc., Bothell, Wash., or from the world wide web at http://www.cypressmicro.com/).

Tool 2 may contain one or more component subsystems: a device configuration editing subsystem 4 (known as “Device Editor” in PSoC Designer™ software), a source code editing subsystem 6 (known as “Application Editor” in PSoC Designer™ software), and a debugging subsystem 8 (known as “Debugger” in PSoC Designer™ software). A preferred embodiment of the present system comprises at least device configuration editing subsystem 4. Source code editing subsystem 6 enables further customization of device configurations and operation(s), and debugging subsystem 8 enables testing of device configuration(s) and/or programming. Thus, although preferred, subsystems 6 and 8 are optional in the present invention. For detailed descriptions of particularly preferred, working embodiments of device configuration editing subsystem 4, source code editing subsystem 6, and debugging subsystem 8, see the PSoC Designer IDE User Guide, version 1.13 (available from Cypress MicroSystems, Inc., Bothell, Wash., or from the world wide web at http://www.cypressmicro.com/).

FIG. 2 shows an exemplary functional block or module “selection” view 10 within configuration editing subsystem 4 of tool 2 in FIG. 1. (For a general description of an exemplary configuration editing subsystem 4, see, e.g., U.S. patent application Ser. Nos. 09/989,570 and 09/989,571, each of which was filed Nov. 19, 2001.) In FIG. 2, the present interface is embodied in toolbar 12, which is sometimes referred to herein as a “reconfiguration operation” toolbar, and tabs 14a and 14b, which are sometimes referred to herein as “overlay” or “configuration” tabs. Alternatively (or additionally), the present interface can be implemented as a dropdown list in box 20 (which, as shown, may be contained within workspace 12) and/or as one or more commands (each of which may optionally contain one or more subcommands) under a heading in menu 16, such as “Config” 18.

The configuration workspace(s) in the present graphical user interface may contain commands, operations and/or instructions for adding a new or existing configuration, deleting an existing or open configuration, saving an open configuration, importing a saved configuration, exporting a completed configuration, and/or selecting between at least first and second configurations. Preferably, the commands and/or operations carried out through the interface comprise adding a configuration, deleting a configuration, and selecting a different configuration, more preferably further including importing a configuration and exporting a configuration.

Referring now to FIG. 6, toolbar 12 comprises a plurality of icons 402 and 404 and down-arrow box 406. Icons 402 and 404 carry out reconfiguration operations, such as adding a new configuration (e.g., icon 402) or deleting an open configuration (e.g., icon 404). These icons are not required to practice the present invention; menu- and down-arrow-based alternatives are described elsewhere herein. Additional or alternative icons can be added or substituted for additional or other commands, functions or operations. Down-arrow box 406, when activated by clicking on down-arrow 408, explodes into a list (not shown) containing the names of all overlays in the project. Optionally, this “down-arrow list” may further include a selection/entry for a new configuration (e.g., “[New Config]”). It is noted that the overlay shown in down-arrow box 406, named “Second_PWM,” differs from the overlay shown in down-arrow box 20 in FIG. 2 (from a working embodiment; see elsewhere herein for details).

FIG. 3 is a flow chart of dynamic reconfiguration method 100, one embodiment of the present invention. In step 102, a first configuration (or “overlay”) is loaded or created in a first (configuration and/or placement) workspace. The workspace(s) for configuring, designing, developing or modifying an overlay may have a plurality of different subworkspaces (in FIG. 2, see, e.g., [preconfigured] user module selection workspace 22, user module configuration workspace 24), each of which may have a plurality of different selectable views (in FIG. 2, see, e.g., tabs 26a-26g).

At any point (but preferably after the first configuration/overlay has been loaded and/or is otherwise completed and/or functionally operable), in step 104, one may activate (e.g., open, add or select) a new configuration in a second (e.g., “reconfiguration operation”) workspace. Preferably, the software tool is configured (using conventional techniques) such that the first configuration or overlay defines a set of valid (e.g., allowed, permissible and/or legal) states for the second, new configuration or overlay. Conversely, the software tool is also preferably configured (using conventional techniques) such that the first configuration or overlay enables a highlighting or alerting function in the second, new overlay when an invalid configuration or state (e.g., not allowed, impermissible and/or illegal) is entered, designed, programmed or configured therein.

In step 106, one configures (e.g., creates, designs, develops, loads and/or modifies) the second (or next incremental) configuration or overlay for the device in a third (or next incremental) configuration or placement workspace. The workspace for the second (or next incremental) configuration or overlay may occupy the same or different display area as the workspace for the first (or any previous) configuration or overlay. Preferably, the default workspace areas for each overlay are coextensive (i.e., the same). However, and preferably, a user may adjust the workspace boundaries for a given overlay in a project as desired. Thus, the workspaces for different overlays may not necessarily coincide, and they can be adjusted or modified such that two or more overlays are partially or completely visible (but, preferably, only one configuration workspace at a time is active, to avoid potential automatic source code generation errors).

Decision point 108 is where the user decides whether to create a new, incremental overlay. If, for example, after two overlays have been created, the user determines that all desired time-multiplexed device functionalities in the project have been loaded, imported, created and/or added, the user is done. On the other hand, for example, if the user determines that, after two overlays have been created, more time-multiplexed device functionalities are desired in the project, the user may return to step 104 and activate a new, incremental overlay in the second (reconfiguration operation) workspace. The cycle of steps 104, 106 and 108 may be repeated as often as the user likes, until all of the desired time-multiplexed device functionalities, configurations and/or performance capabilities have been designed into the project.

In one embodiment of the present invention, the configuration images are provided by a design tool (e.g., a computer implemented software design tool). Additional details on an exemplary implementation of a present invention design tool are set forth in co-pending commonly-owned U.S. patent application Ser. No. 09/989,570 filed Nov. 19, 2001, entitled “METHOD FOR FACILITATING MICROCONTROLLER PROGRAMMING”, which is incorporated herein by reference, and U.S. patent application Ser. No. 09/989,819 filed Nov. 19, 2001, entitled “A SYSTEM AND METHOD FOR CREATING A BOOT FILE UTILIZING A BOOT TEMPLATE”, also incorporated herein by reference.

In one further embodiment, the design process embodied in design program 2 (FIG. 1) and the reconfiguration development process 100 (FIG. 3) may be carried out by a computer system under the control of computer-readable and computer-executable instructions directed at implementing such a process. One embodiment of an exemplary computer system utilized to implement design tool process 400 is set forth in incorporated U.S. patent application Ser. No. 09/989,570, filed Nov. 19, 2001, entitled “METHOD FOR FACILITATING MICROCONTROLLER PROGRAMMING”. The computer-readable and computer-executable instructions reside, for example, in data storage features of the computer system such as a computer usable volatile memory, computer-usable non-volatile memory and/or data storage device. The computer-readable and computer-executable instructions direct the computer system operation (e.g., a processor) in accordance with the process of design tool 2 and/or dynamic reconfiguration flow 100.

Although specific steps are disclosed in process 100 of FIG. 3, such steps are exemplary. That is, the present invention is well suited to use with various other steps or variations of the steps recited in process 100. Additionally, for purposes of clarity and brevity, the discussion is directed at times to specific examples. The present invention, design tool 2 and/or process 100, however, are not limited to designing a sole particular target device (e.g., a mixed signal device and/or microcontroller). Instead, the present invention is well suited to use with other types of computer-aided hardware and software design systems in which it may be desirable to accomplish a multitude of tasks as part of an overall process directed at designing an electronic device.

One aspect of the invention described herein includes the generation of automatic interrupts and/or “API's,” by the software tool that contains, configures and/or controls the present interface. The interrupts and/or “API's,” load, unload and/or reload the device registers, effectively reprogramming and/or reconfiguring the device to conform with a different overlay. Each overlay contains a set of instructions, tables and/or data (which may be compiled from one or more sets of corresponding instructions, tables and/or data in one or more user modules incorporated into the overlay) that generate the API's in accordance with the programming and/or configuration in the overlay. For example, if a first overlay defines an event monitor (e.g., a temperature or light sensor), then that first overlay is configured to generate an API when the event being monitored occurs. At that point, the API unloads the first overlay and loads a second overlay (which may be a data transmitter, UART or modem that reports the occurrence of the event). Alternatively, an API can be generated from a preset timer (for which a variety of user modules exist), for applications in which collection and/or reporting of data at specific time intervals is desired.

EXAMPLE

PSoC Designer software (version 3.10, dated Apr. 16, 2002; for designing and/or configuring programmable analog and/or digital functional blocks and/or modules of circuitry in a programmable integrated circuit) was downloaded from the Cypress MicroSystems, Inc., web site (at http://www.cypressmicro.com/) onto a Gateway Solo laptop computer having at least the minimum requirements for installing and operating the software. The software was installed according to the provider's instructions. After rebooting to allow new computer settings to take effect, the PSoC Designer software was launched and the “Dynamic PWM example” project (time-multiplexed pulse width modulator) was loaded.

The PSoC Designer IDE User Guide, version 1.13, was also downloaded onto the Gateway Solo laptop computer. Section 6 of the User Guide was consulted for reference to dynamic reconfiguration.

Dynamic reconfiguration allows for microcontroller applications to dynamically load and unload configurations. With this feature, a single MCU can have multiple functions. Upon installing and launching an appropriate version of software that contains dynamic reconfiguration capabilities, an example project that has multiple configurations was selected.

In the Start dialog box, a subsystem icon (preferably Device Editor) was selected by clicking on the icon, and C:\Program Files\Cypress Micro-Systems\Designer\Examples\Example_Dynamic_PWM\Example_Dynamic_PWM.SOC was opened. Using the example project, features of dynamic reconfiguration were sampled.

Adding a Configuration

To add a loadable configuration to the project, the following steps were executed (the designer, device editor, and target project files/workspaces were open). From the menu, Config>>Loadable Configuration>>New were clicked/selected. Alternatively, the “New Configuration” (left-most) icon 402 in the dynamic reconfiguration toolbar 12 was clicked (see FIG. 6). The name of the new configuration is Config1 (and each additional configuration will take on consecutive numbering, i.e., Config2, Config3, Config4, etc.).

Upon the addition of a new configuration, a new tab 406 appeared directly below the dynamic reconfiguration toolbar 404, and a drop-arrow selection 408 appeared in the dynamic reconfiguration toolbar 404, both bearing the name Config1. The different project configurations were selected (or “moved between”) by clicking on the corresponding tabs. Whichever tab is selected dictates the project configuration, regardless of the view. All views showed the settings or configuration for the project configuration of the current tab.

There is at least one tab with the project name when a project is created. This tab represents the base configuration and has special characteristics. In this embodiment of the software, the base configuration cannot be deleted but can be exported. Any new configuration, by default, has global settings and pin settings identical to the base configuration.

The configuration name (to be configuration or project specific) was changed by double-clicking (or right-clicking) the tab 406 and typing the new name. The new name appeared on the tab 406 and in the drop-arrow selection 408 in the dynamic reconfiguration toolbar 404. The configuration corresponding to that named in the tab 406 (and drop-arrow selection 408) now was the currently “loaded” working configuration.

The configuration process (i.e., selecting and placing user modules, setting up parameters, and specifying pinout) was conducted according to the procedures defined elsewhere in the PSoC Designer IDE User Guide, version 1.13, the relevant portions of which are incorporated by reference herein, and described generally in copending U.S. patent application Ser. Nos. 09/989,570 and 09/989,571, each of which was filed Nov. 19, 2001.

To avoid confusion in code generation, user module instance names should be unique across all configurations (i.e., a user module name in one configuration should not be re-used in a different configuration). Otherwise, the functions of all other icons and menu items in the software are identical to projects that do not employ additional configurations. In this embodiment of the software, additional configuration tabs appear in alphabetical order from left to right (beginning after the base configuration tab).

Importing a Configuration

In order to import an existing configuration (e.g., a .cfg file), the desired configuration to be imported must have been previously exported (i.e., the .cfg file generated). See the “Exporting a Configuration” section below for details. To import a loadable configuration to a project using dynamic reconfiguration, the following steps are executed (the designer, device editor, and target project files/workspaces were open):

• • 1. From the menu, Config>>Loadable Configuration>>Import were each selected.
  • 2. In the Import Loadable Configuration dialog box, the .cfg file to be imported was located (i.e., to be added to the open project). One may also specify whether to auto-load configuration information, which is done (in this embodiment, checked) by default.
  • 3. “OK” was clicked.

Once the configuration was imported (added), it was loaded and ready for further developing, manipulating and/or configuring.

Exporting a Configuration

To export a loadable configuration from a project (to later be imported to a different project), the following steps were executed (the designer, device editor, and target project files/workspaces were open):

• • 1. From the menu, Config>>Loadable Configuration>>Export were each selected/clicked.
  • 2. In the Export Loadable Configuration dialog box, the configuration, by name, to be exported was selected/clicked (to be later imported to a project). One may select all configurations by holding the [Shift] key and dragging the mouse down, or alternatively, certain specific configurations may be selected by holding the [Ctrl] key and clicking only those desired configurations.
  • 3. “OK” was clicked.
  • 4. In the Save Loadable Configuration dialog box, the configuration name was typed and the file path designated. In this embodiment, notes could be added for later reference.
  • 5. “OK” was clicked.

These steps created an exported configuration (e.g., a .cfg file) that can now be imported (added) to another project (see, e.g., “Importing a Configuration” above for details).

Deleting a Configuration

To delete a loadable configuration from your project, the following steps were executed (the designer, device editor, and target project files/workspaces were open):

• • 1. From the menu, Config>>Loadable Configuration>>Delete were clicked. Alternatively, the “Delete Configuration” icon 404 (see FIG. 6) could be clicked, or tab 14a or 14b (see FIG. 2) of the configuration to be deleted could be right-clicked and “Delete” selected.
  • 2. Once deleting the configuration was selected, the software asked to confirm the selection. “Yes” was clicked. (Alternatively, to cancel the “delete” operation, one may click “No.”)

Once a configuration is deleted, the associated source files are removed from the project (if application files had been generated).

Global Parameters and Dynamic Reconfiguration

When employing dynamic reconfiguration, global parameters are set in the same manner as in a project having a single configuration. However, in this example of dynamic reconfiguration, changes to base configuration global parameters were propagated by default to all additional configurations. Therefore, global parameter changes made to an additional configuration are done locally to only that particular configuration. The code generation operation (Application Generation icon 28 in FIG. 2) considered global parameter changes made to some, but not all, configurations to determine compatibility issues and the possibility of invalid states between the different configurations. These so-called “local” global parameter changes should be made cautiously to prevent unexpected configuration incompatibility issues.

Pin Settings and Dynamic Reconfiguration

When employing dynamic reconfiguration, port pin settings are similar to global parameters in that all settings in the base configuration are propagated to additional configurations. When manually set, port pin settings become local to the configuration.

Port Pin Interrupts

To enable port pin settings that are local to a particular configuration, port pin interrupts are created. To set port pin interrupts, execute the following steps:

• • 1. The Pin-out View mode 200 of the device editor workspace was accessed by clicking on icon 202 in toolbar 204 (see FIG. 4).
  • 2. The drop-arrow item 408 or tab 14a/14b was selected that corresponds to the configuration view for which port pin interrupts were to be set.
  • 3. The pin interrupt was set in either of two places: (a) in the Pin Parameter Grid 206 (see FIG. 4), under the Interrupt column 208; or (b) through the pop-up menu (not shown) that appears when a pin (e.g., 212) in the pin-out diagram 210 is clicked.
  • In the Pin Parameter Grid 206, the drop-down list was accessed by clicking the drop-arrow (not shown) in the Interrupt column 208 and highlighting a selection. In the pop-up menu (not shown) on diagram 210, the interrupt setting appears in a list along with the select and drive options. Clicking the Port Pin Interrupt option enables the same drop-arrow selection as in the Pin Parameter Grid 206. A choice is selected by double-clicking.

The default pin interrupt setting is “Disable.” In this embodiment, if all pin interrupts are set to “Disable,” there is no additional code generated for the pin interrupts. If at least one pin is set to a value other than “Disable,” code generation performs some additional operations. In boot.asm, the vector table is modified so that the GPIO interrupt vector has an entry with the name ProjectName_GPIO_ISR. Additional files (e.g., PSoCGPIOINT.asm and PSoCGPIOINT.inc) are generated as necessary and/or desired.

PSoCGPIOINT.asm contains an export and a placeholder label so the appropriate pin interrupt handling code can be entered. This file is generated once and treated in a similar way to the user module interrupt source files in that they are generated once, and then are not overwritten in subsequent code generation cycles.

PSoCGPIOINT.inc contains equates that are useful in writing the pin interrupt handling code. For each pin (with enabled interrupt or custom name), a set of equates are generated that define symbols for (i) the data address and bit, and (ii) the interrupt mask address and bit associated with the pin. In this embodiment, the naming convention for the equates is:

• • CustomPinName_Data_ADDR
  • CustomPinName_MASK
  • CustomPinName_IntEn_ADDR
  • CustomPinName_Bypass_ADDR
  • CustomPinName_DriveMode_0_ADDR
  • CustomPinName_DriveMode_1_ADDR
  • CustomPinName_IntCtrl_0_ADDR
  • CustomPinName_IntCtrl_1_ADDR

The CustomPinName is replaced by the name entered for the pin during code generation. Custom pin naming allows one to change the name of the pin. The name field is included in the pin parameter area of the pin-out diagram.

The Name column in the Pin Parameter Grid 602 shows the names assigned to each of the pins. The default name shows the port and bit number. The name field may be double-clicked and the custom name typed in. In this embodiment, the name cannot include embedded spaces. The pin name is primarily used in code generation when the pin interrupt is enabled. The pin name may be appended to the equates that are used to represent the address and bit position associated with the pin for interrupt enabling and disabling, as well as testing the state of the port data.

Code Generation and Dynamic Reconfiguration

When more than one configuration is present in a project, there is a considerable difference in code generation and the files generated, although the user module files may be generated identically to previous versions. Differences are described below.

PSoCConfig.asm

The static PSoCConfig.asm file contains exports and code for:

• • LoadConfigInit: Initial configuration-loading function
  • LoadConfig_projectname: Load configuration function

and code only for:

• • LoadConfig: General load registers from a table

For projects with more than one configuration, a variable is added to the bottom of the file that tracks the configurations that are loaded. The LoadConfig function does not change at all. The LoadConfig_projectname function includes a line that sets the appropriate bit in the active configuration status variable. The name of this variable is fixed for all projects. Additional variables that shadow the “write only” registers are added when useful and/or needed.

Additional functions named LoadConfig_configurationname are generated with exports that load the respective configuration. These functions are the equivalent of the LoadConfig_projectname function, including the setting of the bit in the active configuration status variable. The only difference is that LoadConfig_configurationname loads values from LoadConfigTBL_configurationname_Bankn, and there is some additional code that manages the values of any global registers that are changed in the configuration relative to the base configuration.

For each LoadConfig_xxx function, an UnloadConfig_xxx function is generated and exported to unload each configuration, including the base configuration. The UnloadConfig_xxx_Bankn operations are similar to the LoadConfig_xxx functions except that they load an UnloadConfigTBL_xxx_Bankn register (or register set or bank) and clear a bit in the active configuration status variable. In these functions, the global registers are restored to a state that depends on the currently active configuration.

With regard to the base configuration, UnloadConfig_xxx and ReloadConfig_xxx functions are also generated. These functions load and unload only user modules contained in the base configuration. When the base configuration is unloaded, the ReloadConfig_xxx function must be used to restore the base configuration user modules. The ReloadConfig_xxx function ensures the integrity of the “write only” shadow registers. Respective load tables are generated for these functions in PSoCConfigTBL.asm.

An additional unload function is generated as UnloadConfig_Total, which loads tables UnloadConfigTBL_Total_Bank0 and UnloadConfigTBL_Total_Bank1. These tables include the unload registers and values for all blocks. The active configuration status variable is also set to 0. The global registers are not set by this function.

The name of the base configuration matches the name of the project. The project name changes to match the base configuration name if the name of the base configuration is changed from the project name.

A “C” callable version of each function is defined and exported so that these functions can be called from a “C” program.

PSoCConfigTBL.asm

PSoCConfigTBL.asm contains the personalization data tables used by the functions defined in PSoCConfig.asm. For static configurations, there are only two tables defined: LoadConfigTBL_projectname_Bank0 and LoadConfigTBL_projectname_Bank1, which support the LoadConfig_projectname function. These tables personalize the entire global register set and all registers associated with blocks that are used by user modules placed in the project.

For projects with additional configurations, a pair of tables are generated for each LoadConfig_xxx function generated in PSoCConfig.asm. The naming convention follows the same pattern as LoadConfig_xxx and uses two tables: LoadConfigTBL_xxx_Bank0 and LoadConfigTBL_xxx_Bank1. UnloadConfigTBL_xxx_Bank0 and UnloadConfigTBL_xxx_Bank1 are used by UnloadConfig_xxx. The labels for these tables are exported at the top of the file.

The tables for the additional configurations' loading function differ from the base configuration load table in that the additional configuration tables only include those registers associated with blocks that are used by user modules placed in the project and only those global registers with settings that differ from the base configuration. If the additional configuration has no changes to the global parameters or pin settings, only the placed user module registers are included in the tables.

The tables for additional configurations' unloading functions include registers that deactivate any blocks that were used by placed user modules, and all global registers which were modified when the configuration was loaded. The registers and the values for the blocks are determined by a list in the device description for bitfields to set when unloading a user module, and are set according to the type of block. The exceptions are the UnloadConfigTBL_Total_Bankn tables, which include the registers for unloading all blocks.

boot.asm

The boot.asm file is generated similarly to a project that has no additional configurations unless there are one or more configurations that have user modules placed in such a way that common interrupt vectors are used between configurations. In this case, the vector entry in the interrupt vector table will show the line “ljmp Dispatch_INTERRUPT_n” instead of a user module defined Interrupt Service Routine.

New Files

There are three new files that are generated when additional configurations are present in a project (while the exemplary file names given below may be changed, the corresponding functions will be the same regardless of the actual file names used):

• • PSoCDynamic.inc
  • PSoCDynamic.asm
  • PSoCDynamicINT.asm

The PSoCDynamic.inc file contains a set of equates that represent the bit position in the active configuration status variable, and the offset to index the byte in which the status bit resides if the number of configurations exceeds eight. A third equate for each configuration indicates an integer index representing the ordinal value of the configuration.

The PSoCDynamic.asm file contains exports and functions that test whether a configuration is loaded or not. The naming convention for these functions is IsOverlayNameLoaded.

The PSoCDynamicINT.asm file is generated only when the user module placement between configurations results in both configurations using a common interrupt vector. The reference to Dispatch_INTERRUPT_n function is resolved in this file. For each conflicting interrupt vector, one of these ISR dispatch sets is generated. The ISR dispatch has a code section that tests the configuration that is active and loads the appropriate table offset into a jump table immediately following the code. The length of the jump table and the number of tests depends on the number of user modules that need the common vector rather than the total number of configurations. The number of conflicts can equal the number of configurations if each configuration utilizes the common interrupt vector. Generally, there will be fewer interrupt conflicts on a per vector basis.

The Application (Source Code) Editor Workspace and Dynamic Reconfiguration

The application (e.g., source code) editor (see, e.g., FIG. 5) operates essentially as set forth in the PSoC Designer IDE User Guide, version 1.13, and as described generally in copending U.S. patent application Ser. Nos. 09/989,570 and 09/989,571, each of which was filed Nov. 19, 2001. The additional files generated are placed in the Library Source and Library Headers folders of the source tree. Library source files that are associated with an additional configuration are shown under a folder with the name of the configuration. This partitions the files so that the source tree view is not excessively long.

The Debugger Workspace and Dynamic Reconfiguration

A debugging subsystem in the downloaded software now displays currently loaded configuration names and input/output (I/O) register labels during debugging halts. The I/O register grid labels are compiled from the labels for all currently loaded configurations.

The names of loaded configurations are displayed in a new debugging view (see, e.g., menu item 30 in FIG. 2). The new view is a new tab titled “Config” below the memory map (which already contains RAM, I/O Banks 0,1, and Flash tabs).

The I/O register labels modify the existing I/O register bank grids. In addition to setting I/O register labels on entry to the debugger workspace, labels are updated on M8C (microcontroller) halts if the set of loaded user modules has changed since the last halt.

The debugger workspace obtains the active configuration names from the runtime configuration data stored in M8C RAM. This data is maintained by the “LoadConfig” and “UnloadConfig” routines generated by the Device Editor software.

Active Configuration Display

The set of currently active configurations is displayed in the “Config” tab of the memory map during debugging software halts. The display lists all project configurations with the status for each currently loaded configuration marked “Active.” The display may not be valid immediately after a reset. In this embodiment, the initialization code must run before the “Config” tab display is valid.

Active Configuration I/O Register Labels

The debugging software I/O register bank labels (Bank 0, Bank 1) are updated to match the user modules defined in the currently active configurations.

Active Configuration Limitations

The new displays are based on a bitmap of loaded configurations maintained by the “LoadConfig” and “UnloadConfig” routines, which are generated by the Device Editor software. This bitmap can get out-of-sync with the actual device con-figuration in several ways:

• • The bitmap's RAM area can be accidentally overwritten.
  • Overlapping (conflicting) configurations, loaded at the same time, may scramble the register labels.
  • If an overlapping configuration is loaded and then unloaded, register labels from the original configuration may be used, even though some blocks will have been cleared by the last “UnloadConfig” routine.

Active Configuration Display Test

The new display features can be tested with a single project that loads and unloads configurations containing overlapping user modules. The test project should have a base configuration that defines one or more user modules and several overlay configurations, some conflicting and some not conflicting. The test project should load and unload configurations in various combinations. After each load and unload operation, the status of the active configuration display and the register label display should be checked.

Checking the displays after loading and unloading conflicting configurations is recommended.

CONCLUSION/SUMMARY

Thus, the present invention provides a convenient, simple and efficient interface for dynamically configuring an electronic device (e.g., a mixed signal integrated circuit such as a microcontroller).

The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the Claims appended hereto and their equivalents.