CROSS REFERENCE TO RELATED APPLICATIONSThis is a continuation of U.S. patent application Ser. No. 11/767,636, filed Jun. 25, 2007, to which priority is claimed and which is incorporated herein by reference in its entirety.
FIELD OF THE INVENTIONThe present invention relates generally to implantable medical devices, and more particularly, to improved architectures for the circuitry in an implantable medical device.
BACKGROUNDImplantable stimulation devices are devices that generate and deliver electrical stimuli to body nerves and tissues for the therapy of various biological disorders, such as pacemakers to treat cardiac arrhythmia, defibrillators to treat cardiac fibrillation, cochlear stimulators to treat deafness, retinal stimulators to treat blindness, muscle stimulators to produce coordinated limb movement, spinal cord stimulators to treat chronic pain, cortical and deep brain stimulators to treat motor and psychological disorders, and other neural stimulators to treat urinary incontinence, sleep apnea, shoulder sublaxation, etc. The present invention may find applicability in all such applications, although the description that follows will generally focus on the use of the invention within a Spinal Cord Stimulation (SCS) system, such as that disclosed in U.S. Pat. No. 6,516,227 (“the '227 patent”), which is incorporated herein by reference in its entirety.
Spinal cord stimulation is a well-accepted clinical method for reducing pain in certain populations of patients. As shown inFIGS. 1A and 1B, a SCS system typically includes an Implantable Pulse Generator (IPG)100, which includes abiocompatible case30 formed of titanium for example. Thecase30 usually holds the circuitry and power source or battery necessary for the IPG to function. The IPG100 is coupled toelectrodes106 via one or more electrode leads (twosuch leads102 and104 are shown), such that theelectrodes106 form anelectrode array110. Theelectrodes106 are carried on aflexible body108, which also houses theindividual signal wires112,114, coupled to each electrode. Thesignal wires112 and114 are connected to the IPG100 by way of aninterface115, which may be any suitable device that allows theleads102 and104 (or a lead extension, not shown) to be removably connected to the IPG100.Interface115 may comprise, for example, an electro-mechanical connector arrangement includinglead connectors38aand38bconfigured to mate withcorresponding connectors119aand119bon theleads102 and104. In the illustrated embodiment, there are eight electrodes onlead102, labeled E1-E8, and eight electrodes onlead104, labeled E9-E16, although the number of leads and electrodes is application specific and therefore can vary. Theelectrode array110 is typically implanted along the dura of the spinal cord, and the IPG100 generates electrical pulses that are delivered through theelectrodes106 to the nerve fibers within the spinal column. The IPG100 itself is then typically implanted somewhat distantly in the buttocks of the patient.
As shown inFIG. 2, an IPG100 typically includes anelectronic substrate assembly14 including a printed circuit board (PCB)16, along with variouselectronic components20, such as microprocessors, integrated circuits, and capacitors, mounted to thePCB16. Ultimately, the electronic circuitry performs a therapeutic function, such as neurostimulation. Afeedthrough assembly24 routes the various electrode signals from theelectronic substrate assembly14 to thelead connectors38a,38b, which are in turn coupled to theleads102 and104 (seeFIGS. 1A and 1B). The IPG100 further comprises aheader connector36, which among other things houses thelead connectors38a,38b. The IPG100 can further include a telemetry antenna or coil96 (FIG. 1A) mounted within theheader connector36 for transmission and receipt of data to and from an external device such as a hand-held or clinician programmer (not shown). As noted earlier, the IPG100 usually also includes apower source26, usually arechargeable battery26. Thepower source26 can be recharged transcutaneously by an external charger12. Specifically, when active during a charging session, the external charger12 energizes itscharging coil17, which in turn induces a current in thecharging coil18 in the IPG100. This induced current is rectified and ultimately used to charge thepower source26 through the patient'sflesh25.
Further details concerning the structure and function of typical IPGs and IPG systems are disclosed in U.S. patent application Ser. No. 11/305,898, filed Dec. 14, 2005, which is incorporated herein by reference.
Atraditional architecture50 for the circuitry inside of an IPG100 is shown inFIG. 3. As one skilled in the art will appreciate,FIG. 3 depicts the IPG100's circuitry at a relatively high level sufficient to understand the points this disclosure makes. Thearchitecture50 contains basic circuit blocks for executing various electrical functions in the IPG100. For example,telemetry circuit62 is coupled tocoil96, and operates to send and receive data to and from an external controller (not shown). Charging andbattery protection circuitry64 is similarly coupled to chargingcoil18, and intervenes between thepower source26 and the rest of the circuitry. Both of thesecircuits62 and64 are coupled to amicrocontroller60, which as can be noticed is central to the design of thearchitecture50. Programs and data needed by themicrocontroller60 upon power up are stored in amemory66, preferably a serial nonvolatile memory, which is coupled to themicrocontroller60 by aserial interface67.
Circuitry involved in providing a predictable therapy of stimulation is provided by a digital integrated circuit (IC)70 and ananalog IC80. In one application, thedigital IC70 contains stimulation control logic, such as the various timers that are used by the IPG's timing channels to provide a stimulation pulse train with a particular timing. Theanalog IC80 receives data from thedigital IC70 via a serial link, where such data is converted to analog signals by a digital-to-analog converter (DAC)82, which in turn ultimately provides the stimulus to the electrodes (E1 . . . EN). Additionally, an analog-to-digital (A/D)converter74 is used to inform themicrocontroller60 of various analog voltages being produced or monitored on theanalog IC80, such as various reference voltages, the stimulation compliance voltage, etc., and within thecharging64 andtelemetry62 blocks. Although shown as integrated with themicrocontroller60, the A/D converter74 could also be a discrete component outside of themicrocontroller60.
In one embodiment, themicrocontroller60, thedigital IC70, and theanalog IC80 comprise discrete ICs each comprising one of thecomponents20 on the IPG's printed circuit board16 (seeFIG. 1). Other functional blocks in thearchitecture50 might compriseother components20, which might not be integrated but rather formed at least in part of discrete components.
Having briefly described the functional blocks inarchitecture50, it should be noted that it is not important to the present disclosure to understand the detailed workings of those blocks. (The reader can consult the above-incorporated '898 application should a greater knowledge of each of the functional blocks be desired). Instead, what is important to understand is the manner in which the functional blocks are interconnected. As one skilled in the art will understand, central to the operation ofarchitecture50 is themicrocontroller60, which ultimately receives and issues all commands from and to the other blocks. Furthermore, it can be noticed that the various interconnections between the blocks vary in type and complexity, with some connections being serial in nature, and others comprising single data lines or comprising data digital busses. Moreover, some of the blocks lack direct connections with other blocks, and hence must communicate through intermediary blocks. For example, themicrocontroller60 must, at least in part, communicate with theanalog IC80 through thedigital IC70.
Such inter-connectivity adds to the expense of the IPG100 and its complexity. Moreover, it also makes it difficult to adapt a particular architecture to desired changes and/or newer IPG revisions. For example, the changing of one of the functional blocks may require significant corresponding changes in other functional blocks, making upgrades or revisions expensive.
Additionally, space within an IPG100 is limited, because IPGs are preferably as small as possible to make the implant as unobtrusive as possible for the patient. In this regard, thearchitecture50 ofFIG. 3 is further problematic because of its requirement of separate IC used for themicrocontroller60, thedigital IC70, and the analog IC80 (and possibly other components). Having numerous components generally negatively impacts the reliability of the circuit, and increases power consumption, generally a big concern for a power-limited IPG.
This disclosure presents a solution to this problem in the art of implantable medical devices via an improved IPG architecture.
BRIEF DESCRIPTION OF THE DRAWINGSFIGS. 1A and 1B show an implantable pulse generator (IPG), and the manner in which an electrode array is coupled to the IPG in accordance with the prior art.
FIG. 2 shows the IPG in relation to an external charger in accordance with the prior art.
FIG. 3 shows the architecture of the circuitry within the IPG in accordance with the prior art.
FIG. 4 shows an improved architecture for an IPG incorporating a centralized bus operating with the various functional blocks in accordance with a communication protocol.
FIG. 5 shows the various signal on the centralized bus ofFIG. 4 and indicates the communication protocol used on the bus.
FIG. 6 shows the basic structure of the bus interface circuitry used by each functional block communicating with the centralized bus ofFIG. 4.
FIG. 7 shows how the improved architecture ofFIG. 4 easily provides for additional memory or controller resources outside of an IPG IC built in accordance with the architecture ofFIG. 4.
FIG. 8 shows various registers useful in sharing control between an external controller and a controller internal to an IPG IC built in accordance with the architecture ofFIG. 4.
FIG. 9 shows the circuitry useful for sharing control between the external and internal controller ofFIG. 8.
FIG. 10 shows a flow chart discussing the operation of the circuitry ofFIG. 9.
DETAILED DESCRIPTIONAn improved architecture for an implantable medical device such as an implantable pulse generator (IPG) is disclosed. In one embodiment, the various functional blocks for the IPG are incorporated into a single integrated circuit (IC). Each of the functional blocks communicate with each other, and with other off-chip devices if necessary, via a centralized bus governed by a communication protocol. To communicate with the bus and to adhere to the protocol, each circuit block includes bus interface circuitry adherent with that protocol. Because each block complies with the protocol, any given block can easily be modified or upgraded without affecting the design of the other blocks, facilitating debugging and upgrading of the IPG circuitry. Moreover, because the centralized bus can be taken off the integrated circuit, extra circuitry can easily be added off chip to modify or add functionality to the IPG without the need for a major redesign of the main IPG IC.
FIG. 4 shows one example of theimproved IPG architecture150. As a comparison toFIG. 3 shows, most of the functional blocks inFIG. 4 correspond to circuit blocks ofFIG. 3, and thus perform similar functions in thenew architecture150. However, in a major difference, all of the functional blocks in theimproved architecture150 are coupled to acentralized bus190. In the embodiment illustrated in this disclosure, thecentralized bus190 is a parallel bus containing a plurality of multiplexed address and data lines operating in parallel. However, this is not strictly necessary, and insteadbus190 can comprise a serial bus as well.
In a preferred embodiment, each of the illustrated functional blocks are integrated within a single integrated circuit (IC)200. Because theIPG IC200 as illustrated contains both analog and digital signals, theIC200 would comprise a mixed mode chip. However, it is not strictly necessary that thearchitecture150 be realized on asingle IC200 as shown. Moreover, it should be understood that certain other circuitry components within the IPG100 (such as the data and chargingcoils96 and18, thepower source26, andexternal memory66, etc.) would logically reside outside of theIC200. That being said, it is still preferred that as many as possible of the functional blocks within the IPG be consolidated on theIC200, as this increases yield, increases reliability, decreases space of the electronic circuitry within the IPG, decreases power consumption of the circuitry within theIPG100, etc.
Each of the various functional blocks in theimproved IPG architecture150 communicate with thecentralized bus190 viabus interface circuitry215, which will be discussed in further detail later. Preferably, all other non-bus-based communications between the functional blocks are kept to a minimum, but some such communications are beneficial. For example, as shown, various interrupts (INT1, INT2, . . . ) communicate directly with an interruptcontroller173, which allows their issuance to be immediately recognized without the potential delays involved in protocol-based communication through thecentralized bus190. For example, INT2 can inform the interruptcontroller173 if thepower source26 is charged to a dangerous level, so that operation of theIC200 might be temporarily curtailed if necessary. In another off-bus communication, an analog bus192 is used to send various analog signals to a A/D block74 where such voltages can be digitized and made available to other functional blocks via thecentralized bus190 as needed.
While it is not terribly important to the disclosedimproved IPG architecture150 to understand the operation of each of the functional blocks, note fromFIG. 4 that thedigital IC70 and theanalog IC80 of the prior art (FIG. 3) have effectively been consolidated into a mixed-modestimulation circuitry block175, which both sets the timing, magnitude, and polarity of the stimulation pulses appearing at each of the electrodes, Ex.
In another important difference with thearchitecture50 of the prior art (FIG. 3), notice that the centralized microcontroller60 (FIG. 3) has been replaced by aninternal controller160. Given the paralleled nature of thecentralized bus190, control within theIC200 is less focused on one source, and instead control is essentially divided between thecontroller160 and the various functional blocks, with thecontroller160 acting as the “master.” Specifically, each functional block contains set up and status registers (not shown). Thecontroller160, upon initialization, writes to the set up registers to configure and enable each functional block. The status registers are then set by each functional block and read by thecontroller160 to query for status and other results. Aside from such control imposed by themaster controller160, many of the functional blocks outside of thecontroller160 can employ simple state machines to manage their operation, which state machines are enabled and modified via the set up registers. Because it acts as the master, thebus interface circuitry215 of theinternal controller160 is somewhat unique and, for example, containsdriver circuitry216 for the control signals used by the communications protocol (e.g., ALE, W/E, and R/E) which would be lacking in thebus interface circuitry215 of other functional blocks within theIC200.
As can be seen inFIG. 4, theIC200 contains several external terminals202 (e.g., pins, solder bumps, etc.), such as those necessary to connect thepower source26, to connect thecoils18,96, to connect theexternal memory66, and to connect the stimulation electrodes. In a preferred embodiment, otherexternal terminals202 are dedicated to the various signals that comprise thecentralized bus190 to allow this bus to communicate with other devices outside of theIC200, as will be explained in more detail later.
The various signals comprising thebus190 can be seen inFIG. 5, which also discloses one possible protocol for communications on the bus. As shown, thecentralized bus190 comprises a clock signal (CLK) for synchronization, time-multiplexed address and data signals (A/Dx); an address latch enable signal (ALE); an active-low write enable signal (*W/E), and an active-low read enable signal (*R/E). The centralized bus90 may comprise sixteen address/data signals, but of course this number can change depending on system requirements.
As one skilled in the art will appreciate, communications in an IPG system such as one including theIC200 ofFIG. 4 can operate relatively slowly compared to other computerized systems. This eases the requirements of the protocol used on thecentralized bus190, and allows for a relatively simple and comparatively-slow protocol to be used. For example, the frequency for the clock signal, CLK, can be in the range of 32 kHZ to 1 MHz. Such a frequency is generally slow for a computerized protocol, but is suitably fast compared to operation of the IPG, which typically provide stimulation pulses on the order of tens of microseconds to milliseconds.
As shown, the protocol uses a fairly simple address-before-data scheme in which an address is followed by pertinent data for that address, etc. To help discern between address and data, the address latch enable signal (ALE) is active only upon the issuance of an address, which allows the address to be latched upon the rising edge of the clock. Whether the data corresponding to a particular address is to be written or read depends on the assertion of the write and read enable signals (*W/E; *R/E). Of course, this protocol is merely exemplary and other protocols and formats could be use for communication on thecentralized bus190.
The nature of the protocol ofFIG. 5 means that all functional blocks coupled to thecentralized bus190 must be designated an address, or more likely, a range of addresses. For example, the address for a data register holding the value for the compliance voltage (in A/D block74) might be ADDR[3401] while the address for a bandgap reference voltage might be ADDR[3402]; the address for the magnitude of stimulation to be provided by electrode E6 (in stimulation circuitry block175) may be ADDR[7655], while the duration of that pulse may be stored at ADDR[7656], etc.
To assist the various functional blocks in recognizing pertinent addresses, and to ensure each block's ability to function in accordance with thecentralized bus190's protocol, each block containsbus interface circuitry215, which is shown inFIG. 6. One skilled in the art will well understand the operation ofbus interface circuitry215, and so it is explained at a general level. As noted earlier, one or more addresses may be associated with each functional block, such as ADDR[1]-[5] in the simple example ofFIG. 6. When such addresses are received at the various blocks, each block decodes those addresses to determine a match, i.e., to determine if the address corresponds to one of the addresses pointing to that block. If so, and depending of whether data is to be written to of read from the address in question, bus drivers (in the case of a read) or bus receivers (in the case of a write) are enabled, and the data is then written to or read from the block's data register. To adhere to this protocol, the actual functional circuitry in the block (not shown inFIG. 6) must interface with the data register appropriately as one skilled in the art understands.
With thebus interface circuitry215 allowing each functional block to communicate using the protocol established for thebus190, it now becomes a relatively simple endeavor to make changes to the various functional blocks to fix circuit errors, and/or to upgrade theIC200 for use in next-generation IPGs. This is because each of the blocks' circuitry can be changed without worries that such changes will necessitate other changes in related blocks, or otherwise perturb the operation of other blocks. Functional blocks can be independently designed and verified in parallel, saving time and hassle during the design process.
Another advantage of theimproved architecture150 is the ability to easily modify or add functionality to theIPG100 outside of theIC200. For example, future improvements may require the IPG to store more data than is otherwise available in the on-chip memory177 or the off-chip memory66 (seeFIG. 4). In such a case, and if the centralized-bus architecture150 is used within theIC200, thebus190 may be extended outside of theIC200 as shown inFIG. 7, and more memory300 (preferably, nonvolatile memory) added. This is of great benefit, because it allows the IPG circuitry to be upgraded without to need to redesign theIC200 and/or some of its functional blocks.
In another example showing how the disclosedarchitecture150 benefits system integration, the capacity of the system can be effectively doubled by the addition of anotherIC200′ similarly constructed to thefirst IC200. This would allow theIPG100 in which theIC200 and200′ were placed to provide 32 stimulation electrodes, i.e.,16 each from both of the ICs. In other words, the capacity of the IPG can be increased by simply “daisy chaining” a plurality of stimulation ICs together. In such an embodiment, it may be beneficial that theinternal controller160 in one of theICs200 or200′ be inactivated so only onecontroller160 acts as the master controller for the system. Alternatively, the IPG system can utilize bothcontrollers160 in both of theICs200 and200′, although this requires arbitration between the two controllers to prevent potential conflicts, a subject discussed below with reference toFIGS. 8-10.
Other devices may also be added external to theIC200 via thebus190. For example, one particularly interesting application enabled by the use ofarchitecture150 is the ability to place at least some degree of systemic control outside of theIC200. For example, inFIG. 7, anexternal microcontroller240 is used to supplant or augment theinternal controller160 resident within theIC200. (Theexternal microcontroller240 could comprise theinternal controller160 of anadditional IC200′, a point discussed above). Again, the ability to control the IPG via an external controller means that the programming for the IPG can be changed without changes to theIC200 or the various functional blocks.
However, to add additional control via anexternal microcontroller240, additional communications may be required between theinternal controller160 and theexternal microcontroller240 to ensure no conflict between the two control mechanisms.FIG. 8-10 describe how theinternal controller160 andexternal microcontroller240 can share control of theIC200 without conflict.
In recognition of the possibility of external control, theinternal controller160 is provided with additional functionality as illustrated inFIGS. 8 and 9. By way of a quick preview, this additional functionality is designed to recognize whether a particular command issued on thebus190 is to be handled by theinternal controller160 or theexternal microcontroller240. Whichdevice160 or240 ultimately processes the command at issue is set by a controller select bit (CSB). If CSB=0, theinternal controller160 executes the command in question; if CSB=1, theexternal controller240 executes the command. As can be seen inFIGS. 7 and 9, CSB can comprise a discrete communication signal generally outside of the scope of thecentralized bus190, which due to its discrete nature can be a preferable implementation as a faster and safer method of arbitration between the twocontrollers160 and240.
In other implementations, the controller select bit can comprise data sent via thebus190 using thebus190's protocol. In such an implementation, the CSB data could be viewed as a control “token” which is passed between theinternal controller160 and theexternal microcontroller240 via thebus190. Such a purely bus-based method for arbitration between the controllers is easily implemented. However, because it is easier to illustrate the passage of control between the twocontrollers160 and240 using a discrete non-bus based signal approach, that approach is illustrated below and in the figures.
As shown, theinternal controller160 is designed with two registers, acommand register220 and acommand owner register230, shown in detail inFIG. 8. Thecommand register220 is a standard feature of many controllers, and simply comprises a binary representation of the various commands the IPG can execute. In the example shown, because thecommand register220 is eight bits long, theIPG100 is capable of processing 256 (2̂8) different commands. Thecommand owner register230 is comprised of as many bits as there are relevant commands (in this example, 256), with each bit in the register denoting whether a particular command is to be handled by theinternal controller160 or theexternal microcontroller240. As shown, if particular bit in thecommand owner register230 is a ‘0 ’, the corresponding command is to be executed by theinternal controller160; and if a ‘1,’ theexternal microcontroller240 will execute the command. In a simple example, if the 256-bitcommand owner register230 reads ‘1010000 . . . 0001,” commands256,254, and1 (CMD256, CMD254, and CMD1) would be executed by theexternal microcontroller240, with all other commands executed by theinternal controller160.
The use ofcommand register220 andcommand owner register230 to issue a controller select bit (CSB)245 is illustrated inFIG. 9. Once a command has been received by thecommand register220, it is decoded (e.g., demultiplexed) to understand its command number (CMD256 to CMD1). Then, the command number is used to retrieve the appropriate command owner bit from thecommand owner register230. This bit is set as the controller select bit (CSB)245 to indicate which controller (160,240) is to handle the command as mentioned earlier.
This process is explained in detail with respect toFIG. 10. Upon boot up, thecommand owner register230 is loaded with default values from memory (internal memory177, serialexternal memory66, etc.). Normally, the default values of the various command owner bits in thecommand owner register230 would be all ‘0’s, denoting that at least initially all commands are to be executed by theinternal controller160. Thereafter, at some point during operation, thecommand register220 is loaded with a command at its address (ADDR[CMD]). The command is decoded (demultiplexed) as explained above, and the corresponding command owner bit is issued as the controller select bit (CSB)245. TheCSB245 is also stored in the controller enableregister250 at its address (ADDR[CER]), which may comprise a single bit, as shown inFIG. 9. TheCSB245 is also sent to theexternal controller240.
With theCSB245 issued, it is now known which of thecontrollers160 or240 is to execute the command in question, and thus various actions are taken accordingly. If CSB=‘0 ’, denoting theinternal controller160, little needs to be accomplished but for thatcontroller160 to execute the command. As a default, to ensure that theexternal microcontroller240 will not conflict with execution of the command by theinternal controller160,arbitration logic246 programmed into theexternal controller240 disables the external controller'sbus drivers242 upon sensing that CSB=0. In contrast, the internalcontroller bus drivers212 are enabled by the stored controller enable register bit250 (an active low signal). After theinternal controller160 has executed its command, the system waits for the next command, and the method repeats, etc.
However, if CSB=‘1’, denoting theexternal microcontroller240, extra steps are taken to allow control to be temporarily shifted to theexternal microcontroller240. Specifically, thearbitration logic246 in the external controller recognizes upon sensing that CSB=‘1’ that it is in control, and enables itsbus drivers242. By contrast, the internalcontroller bus drivers212 are disabled. Additionally, upon recognizing that CSB=‘1’, thearbitration logic246 retrieves the command (i.e., its command) as stored in thecommand register220 by requesting a read via thebus190 from that register's address (ADDR[CMD]). Once received, theexternal controller240 executes the command.
With the command executed by theexternal microcontroller240, the remaining steps illustrated inFIG. 10 are directed to returning control back to theinternal controller160 prior to the receipt of a next command. After execution of the command, thearbitration logic246 now writes a ‘0’ in the controller enableregister250, which can be accessed via thebus190 at its address ADDR[CER]. This in turn once again enables thebus drivers212 for theinternal controller160. Concurrent with overwriting the controller enableregister250, thearbitration logic246 disables thebus drivers242 for theexternal controller240. This restores the system to its initial state in which theinternal controller160 assumes control by default, at which point the system awaits its next command, and the method repeats, etc.
The flow ofFIG. 10 is just one way to allow the internal andexternal controllers160 and240 to operate together without conflict in accordance with the improvedcentralized bus architecture150. However, one skilled in the art will recognize that other flows and circuitry are possible for achieving this same goal, and therefore what is depicted should be understood as merely an example.
Although particular embodiments of the present invention have been shown and described, it should be understood that the above discussion is not intended to limit the present invention to these embodiments. It will be obvious to those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the present invention. Thus, the present invention is intended to cover alternatives, modifications, and equivalents that may fall within the spirit and scope of the present invention as defined by the claims.