Source: http://www.google.com/patents/US7459931?dq=7,546,338
Timestamp: 2015-03-05 19:28:05
Document Index: 373159363

Matched Legal Cases: ['art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300']

Patent US7459931 - Programmable logic devices with transparent field reconfiguration - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsSystems and methods are disclosed herein to provide reconfiguration techniques for PLDs. For example, in accordance with an embodiment of the present invention, a programmable logic device includes logic blocks, input/output blocks, a volatile memory block, and configuration memory cells to store configuration...http://www.google.com/patents/US7459931?utm_source=gb-gplus-sharePatent US7459931 - Programmable logic devices with transparent field reconfigurationAdvanced Patent SearchPublication numberUS7459931 B1Publication typeGrantApplication numberUS 11/398,437Publication dateDec 2, 2008Filing dateApr 5, 2006Priority dateApr 5, 2006Fee statusPaidPublication number11398437, 398437, US 7459931 B1, US 7459931B1, US-B1-7459931, US7459931 B1, US7459931B1InventorsHoward Tang, Henry Law, David L. Rutledge, Om P. Agrawal, Fabiano FontanaOriginal AssigneeLattice Semiconductor CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (29), Non-Patent Citations (14), Referenced by (8), Classifications (9), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetProgrammable logic devices with transparent field reconfiguration
US 7459931 B1Abstract
Systems and methods are disclosed herein to provide reconfiguration techniques for PLDs. For example, in accordance with an embodiment of the present invention, a programmable logic device includes logic blocks, input/output blocks, a volatile memory block, and configuration memory cells to store configuration data for configuration of the logic blocks, the input/output blocks, and the volatile memory block of the programmable logic device. The programmable logic device further includes circuit techniques for preventing loss of data stored in the volatile memory block due to a reconfiguration. Furthermore, for example, the programmable logic device may further prevent the loss of data stored in user registers or loss of input/output personality due to the reconfiguration.
a plurality of registers, wherein the logic blocks and the registers are within a user programmable logic area;
a plurality of input/output blocks, wherein the plurality of input/output blocks include boundary scan cells adapted to precondition the registers with desired signal values, prior to release of control of the input/output blocks to user-defined logic provided by a reconfiguration of the programmable logic device, such that the registers provide the desired data values after the reconfiguration;
a volatile memory block adapted to store data within the programmable logic device; and
a circuit adapted to preserve the data for the volatile memory during the reconfiguration of the programmable logic device, wherein the circuit comprises:
a non-volatile memory block adapted to store data transferred from the volatile memory block prior to the reconfiguration and return the data to the volatile memory block prior to entering user mode after the reconfiguration, wherein the non-volatile memory block is further adapted to store second configuration data and transfer the second configuration data to the configuration memory cells for the reconfiguration of the programmable logic device; and
a control circuit adapted to control transfer of the data between the non-volatile memory block and the volatile memory block and further adapted to control transfer of the second configuration data to the configuration memory cells.
2. The programmable logic device of claim 1, wherein the volatile memory block comprises a user register, and wherein the circuit comprises a latch circuit adapted to capture a data value stored in the user register and provide the data value for the user register during the reconfiguration.
3. The programmable logic device of claim 1, wherein the volatile memory block comprises a user register, and wherein the circuit comprises a multiplexer adapted to selectively capture a data value stored in the user register or a second data value and provide to a preload data terminal of the user register.
4. The programmable logic device of claim 1, wherein the volatile memory block comprises one of the configuration memory cells, and wherein the circuit comprises a latch circuit adapted to capture a data value stored in the configuration memory cell and provide the data value for the configuration memory cell during the reconfiguration.
5. The programmable logic device of claim 1, wherein the volatile memory block comprises one of the configuration memory cells configured to control a personality aspect of one of the input/output blocks, and wherein the circuit comprises a latch circuit adapted to capture a data value stored in the configuration memory cell and provide the data value for the configuration memory cell during the reconfiguration.
6. The programmable logic device of claim 1, further comprising at least a first data port adapted to receive commands for controlling the reconfiguration of the programmable logic device.
7. The programmable logic device of claim 1, wherein the boundary scan cells are further adapted to capture current output values of the corresponding input/output blocks or receive values provided to the programmable logic device and provide the captured or received values as output signals from the programmable logic device during the reconfiguration of the programmable logic device.
an input/output block, wherein the input/output block comprises a boundary scan cell adapted to precondition at least one of the registers with a desired signal value, prior to release of control of the input/output block to user-defined logic provided by a reconfiguration, such that the register provides the desired data value after the reconfiguration;
a volatile memory block adapted to store data within the programmable logic device;
configuration memory cells adapted to store first configuration data for configuration of the logic blocks, the input/output blocks, and the volatile memory block of the programmable logic device;
a non-volatile memory block having a first section adapted to receive data from the volatile memory block prior to the reconfiguration for transfer back to the volatile memory block prior to entering a user mode of operation after the reconfiguration, wherein the non-volatile memory block further includes a second section adapted to store second configuration data to transfer to the configuration memory cells during the reconfiguration; and
a control circuit adapted to control the transfer of the data between the non-volatile memory block and the volatile memory block to save the data during the reconfiguration and to control the transfer of the second configuration data from the non-volatile memory block to the configuration memory cells to reconfigure the programmable logic device.
9. The programmable logic device of claim 8, further comprising:
a user register; and
a latch circuit adapted to capture a data value stored in the user register and provide the data value for the user register during the reconfiguration.
10. The programmable logic device of claim 8, further comprising:
a multiplexer circuit adapted to selectively capture a data value stored in the user register or a second data value and provide to a preload data terminal of the user register to provide the data value or the second data value from the user register after the reconfiguration.
11. The programmable logic device of claim 8, further comprising a latch circuit adapted to capture a data value stored in one of the configuration memory cells and provide the data value for the configuration memory cell during the reconfiguration to retain a personality aspect of the input/output block during the reconfiguration.
12. The programmable logic device of claim 8, wherein the boundary scan cell is further adapted to capture a current output value of the input/output block or receive a value provided to the programmable logic device and provide the captured or received value as an output signal from the programmable logic device during the reconfiguration of the programmable logic device.
13. A method of reconfiguring a programmable logic device, the method comprising:
performing a background programming operation of the programmable logic device prior to a reconfiguring;
transferring data from a volatile memory block to a non-volatile memory block prior to the reconfiguring;
transferring the data from the non-volatile memory block to the volatile memory block during the reconfiguring such that the data is available within the volatile memory block after the reconfiguring;
capturing input/output states prior to the reconfiguring to provide during the reconfiguring;
copying configuration data from the non-volatile memory block to configuration memory for the reconfiguring;
reconfiguring the programmable logic device;
preserving at least one data value of a volatile memory during the reconfiguring; and
providing a desired data value to the programmable logic device to precondition a register within a user logic area of the programmable logic device, prior to release of control to user-defined logic provided by the reconfiguring, such that the register provides the desired data value after the reconfiguring.
14. The method of claim 13, wherein the volatile memory comprises a user register, and wherein the preserving comprises latching and providing the data value during the reconfiguring.
15. The method of claim 13, wherein the volatile memory comprises a user register, and wherein the preserving comprises providing the data value to a preload data terminal of the user register to provide the data value from the user register after the reconfiguring.
16. The method of claim 13, wherein the volatile memory comprises a configuration memory cell for an input/output block, and wherein the preserving retains a personality aspect of the input/output block during the reconfiguring.
capturing current output signal values of the programmable logic device; and
providing from the programmable logic device, during the reconfiguring, at least one of the captured output signal values and desired output signal values.
18. The method of claim 13, wherein the volatile memory comprises a volatile memory block, and wherein the preserving comprises:
transferring the at least one data value from the volatile memory block to non-volatile memory prior to the reconfiguring; and
transferring the at least one data value during the reconfiguring from the non-volatile memory to the volatile memory block.
19. The method of claim 13, further comprising performing a background programming operation of the programmable logic device prior to the reconfiguring.
20. The method of claim 13, further comprising altering at least one of the captured input/output states prior to providing during the reconfiguring.
21. The method of claim 13, further comprising preserving at least one user register value and at least one input/output personality through the reconfiguring. Description
A drawback of a conventional PLD is that, while being programmed (which may take seconds to load an external configuration bitstream), the PLD enters a sleep state, with its input and output pins typically disabled (e.g., non-responsive to input signals while providing indeterminate output signals). If the PLD is in a critical path or is used to control critical functions, these drawbacks may be unacceptable. Furthermore, data stored in user registers or in memory blocks (e.g., volatile embedded RAM blocks) is generally lost during the programming process. As a result, there is a need for improved programming and configuration techniques for PLDs.
In accordance with one embodiment of the present invention, a programmable logic device includes a plurality of logic blocks; a plurality of input/output blocks; configuration memory cells adapted to store first configuration data for configuration of the logic blocks and the input/output blocks of the programmable logic device; volatile memory adapted to store data within the programmable logic device; and a circuit adapted to preserve the data for the volatile memory during a reconfiguration of the programmable logic device.
In accordance with another embodiment of the present invention, a programmable logic device includes a plurality of logic blocks; an input/output block; a volatile memory block adapted to store data within the programmable logic device; configuration memory cells adapted to store first configuration data for configuration of the logic blocks, the input/output blocks, and the volatile memory block of the programmable logic device; and means for preventing loss of data stored in the volatile memory block due to a reconfiguration.
In accordance with another embodiment of the present invention, a method of reconfiguring a programmable logic device includes reconfiguring the programmable logic device; and preserving at least one data value of a volatile memory during the reconfiguring.
FIG. 9 shows a block diagram illustrating an exemplary circuit implementation for a latch within the programmable logic device of FIG. 1 in accordance with an embodiment of the present invention.
FIG. 10 shows a block diagram illustrating an exemplary circuit implementation for preserving a user register value and providing a known state exit for the programmable logic device of FIG. 1 in accordance with an embodiment of the present invention.
FIG. 11 shows a block diagram illustrating exemplary implementation details for the programmable logic device of FIG. 1 in accordance with an embodiment of the present invention.
FIGS. 12-14 show block diagrams illustrating exemplary implementation details for a store-to-flash operation for the programmable logic device of FIG. 1 in accordance with an embodiment of the present invention.
FIG. 15 shows a block diagram illustrating exemplary implementation details for the programmable logic device of FIG. 1 in accordance with an embodiment of the present invention.
FIG. 1 shows a block diagram illustrating an exemplary programmable logic device (PLD) 100 in accordance with an embodiment of the present invention. PLD 100 includes input/output (I/O) blocks 102 and programmable logic blocks 104 (e.g., also referred to in the art as configurable logic blocks or logic array blocks). I/O blocks 102 provide I/O functionality (e.g., supports one or more I/O and/or memory interface standards) for PLD 100. Logic blocks 104 provide logic functionality for PLD 100, such as LUT-based logic typically associated with FPGAs or array-based logic typically associated with CPLDs.
PLD 100 may also include non-volatile memory 106 (e.g., EEPROM or flash memory), volatile memory 108 (e.g., block SRAM), clock-related circuitry 110 (e.g., PLL circuits), one or more data ports 112, configuration memory 114, and/or an interconnect 116. It should be understood that the number and placement of the various elements, such as I/O blocks 102, logic blocks 104, non-volatile memory 106, volatile memory 108, clock-related circuitry 110, data port 112, configuration memory 114, and interconnect 116, is not limiting and may depend upon the desired application. Furthermore, it should be understood that the elements are illustrated in block form for clarity and that certain elements, such as configuration memory 114 and interconnect 116, would typically be distributed throughout PLD 100 to perform their conventional functions (e.g., storing configuration data that configures PLD 100 and providing routing resources, respectively).
Data port 112 may be used for programming PLD 100, for example as explained further herein. For example, data port 112(1) may represent a programming port such as a central processing unit (CPU) port, also referred to as a peripheral data port or a sysCONFIG programming port. Data port 112(2) may represent, for example, a programming port such as a joint test action group (JTAG) port by employing standards such as Institute of Electrical and Electronics Engineers (IEEE) 1149.1 or 1532 standards. Data ports 112(1) and 112(2) are not both required, but one or the other may be included as a port to receive configuration data and commands.
Non-volatile memory 106 may also be used to provide background programming and/or storage for PLD 100 in accordance with some embodiments of the present invention. For example for storage functionality, non-volatile memory 106 may be used to store data (e.g., the data values) from volatile memory 108 and/or other types of memory (e.g., user registers within PLD 100) during the reconfiguration process. Thus as an example, the values of the data stored by volatile memory 108 within PLD 100, just prior to reconfiguration, may be preserved in non-volatile memory 106 during the reconfiguration process and then written back into volatile memory 108 prior to returning to user mode, as explained further herein.
For example for background programming, PLD 100 may remain in user mode, based on the configuration data stored in configuration memory 114 within PLD 100, while non-volatile memory 106 is programmed with new configuration data (e.g., a new user defined pattern). Once the new configuration data is stored in non-volatile memory 106, this data can be transferred from non-volatile memory 106 to configuration memory 114 to reconfigure PLD 100, a process sometimes referred to as refresh. As explained further herein, the refresh process can be initiated by a signal or instruction provided to data port 112 (e.g., pulsing data port 112(1) or providing a JTAG refresh instruction via data port 112(2)).
It should be understood that flash memory represents an exemplary type of memory for non-volatile memory 106, but other types of non-volatile memory (e.g., EECMOS) that can be reprogrammed once or repeatedly may be substituted for non-volatile memory 106. Furthermore, either non-volatile memory 106 or configuration memory 114 may be programmed (i.e., receive and store information in its memory) to store configuration data for PLD 200, but the device functionality of PLD 200 is determined by the information stored in configuration memory 114. Thus, PLD 200 is configured (including reconfiguration or partial reconfiguration) when information is programmed into configuration memory 114.
In general, during programming of configuration memory 114 and reconfiguration of the PLD (e.g., PLD 100), it would be advantageous to continue to support system operation functions. However, conventional approaches typically used an external bitstream to provide the configuration data directly to the configuration memory of the PLD, while the PLD's output signals are tri-stated or held to logical high or low values. Additionally for conventional approaches, any information stored in volatile memory 108 and other information (e.g., data stored in user registers of a user programmable logic area) are not saved and are lost during the reconfiguration process. Furthermore during the reconfiguration process, an I/O block's personality is not maintained (e.g., an I/O block's buffers are not preserved as LVDS, but may revert to some default state such as LVCMOS), where the personality refers to the programmable characteristics of the I/O block, such as for example the drive strength, signal levels, or other aspects for the type of I/O standard implemented for the configured I/O block).
In contrast, in accordance with one or more embodiments of the present invention, techniques are disclosed herein to use background programming to provide the configuration data to the PLD and, during configuration, provide desired PLD output signals that remain glitch-free during the transition from configuration to user mode of the PLD (e.g., full control of the logical values of the output signals provided by PLD 100 during the refresh process can still be provided). Furthermore, in accordance with some embodiments of the present invention and as discussed further herein, the personality of I/O blocks 102 and/or the data stored in volatile memory 108 and/or other information (e.g., data stored in user registers) may be preserved during a reconfiguration and then restored after completion of the programming of configuration memory 114 (e.g., prior to entering user mode of operation after the reconfiguration).
For example, FIG. 3 shows a flowchart 300 illustrating exemplary reconfiguration operations for PLD 100 of FIG. 1 in accordance with an embodiment of the present invention. It should be understood that the various flowchart operations are note all required and some may be performed in a different order. Also as discussed further herein, the operations illustrated in flowchart 300 may be controlled by software (e.g., user software) or hardware, as illustrated in an exemplary fashion in FIG. 3 with the corresponding operational flow for the exemplary commands and the exemplary software control indicators (e.g., user software start) and/or JTAG commands.
For example, Lattice Semiconductor Corporation's ispVM software is a Windows-based tool set that facilitates the programming of their PLDs. The ispVM Embedded tool generates C code that, when compiled for and executed on a wide range of embedded processors, enables the programming of the PLDs. Consequently, the ispVM software or other conventional PLD programming software can issue the programming commands directly, such as during prototyping, or generate, for example, an industry-standard Serial Vector Format (SVF) file for reconfiguration in the field. Thus, for example, the SVF file may be used to control the various operations in flowchart 300, such as for example the background programming, store-to-flash, leave alone operation, refresh process, restore operation, and/or the known-state exit operation (e.g., create a delay period for users to apply the vectors to precondition the registers), which are described further herein.
In reference to FIG. 3, background programming is first initiated (302), while the PLD remains in user mode operation based on the current configuration data stored in configuration memory 114. For example, background programming of non-volatile memory 106 (flash memory) with the new configuration data is performed as the PLD operates based on current configuration data stored in configuration memory 114.
The background programming may be verified and then an optional store-to-flash operation (304) may be performed, which may be triggered for example by a store-to-flash control signal. For example for operation 304, data from volatile memory 108, user registers, and/or other types of memory or information within PLD 100 may be stored by non-volatile memory 106. The information stored by non-volatile memory 106 can then be returned back or restored to its original source within PLD 100, such as for example to volatile memory 108, during or after the new configuration data is written to configuration memory 114 (operation 312). Consequently, desired information within PLD 100 may be preserved while a reconfiguration is performed.
As explained further herein in accordance with some embodiments of the present invention, non-volatile memory 106 may be viewed as having a configuration flash section (e.g., to store configuration data) and a user flash section (e.g., to store and preserve data within PLD 100 (i.e., for operation 304) during the reconfiguration process). The background programming (302) may only write to the configuration flash section. Alternatively, if the background programming (302) writes over the user flash section, the store-to-flash operation (304) transfers the desired information to be preserved (e.g., data from volatile memory 108) to the user flash section and writes over the data in the user flash section provided during the background programming.
The I/O states (e.g., current I/O values, such as logical high or low, high impedance values, or sampled state) may be captured at operation 306. Optionally as part of operation 306, the I/O states may be altered as desired by a user, as explained further herein (e.g., via input paths through the boundary scan cells by manipulating pins via an external device or through JTAG).
Using the boundary scan cells at operation 308, the I/O states are held at the captured or desired values and the PLD is reconfigured or refreshed (312) by copying the configuration data from non-volatile memory 106 to configuration memory 114. The reconfiguration may be initiated, for example, by pulsing or toggling data port 112(1) or providing a JTAG instruction (Refresh) to data port 112(2).
As an alternative or in addition to using the boundary scan cells for operations 306 and 308, latches may be used as described further herein to latch and preserve the current state of one or more of the user registers at operation 310. Consequently, prior to the refresh (operation 312), the data values of the user registers may be latched while the refresh operation programs configuration memory 114. After the refresh operation (312), the user registers may be preconditioned (operation 314) by altering the register's values as desired by a user as explained further herein (e.g., via input paths through the boundary scan cells by manipulating pins via an external device or through JTAG).
Operation 310 may also optionally retain the personalities of one or more of I/O blocks 102. For example, latches may be provided to latch and retain the current personalities of one or more of I/O blocks 102, while the refresh is performed (312).
The refresh process may be verified prior to initiating the release of the I/O to the newly configured user-defined logic (operation 314). Internal registers within the I/O or other portions of the PLD may be preconditioned (314) with data to prevent glitches from occurring during the transition to user-defined logic control of the I/O (e.g., the data for preconditioning provided via input paths through the boundary scan cells). After providing the JTAG instruction (e.g., BYPASS or EXIT_EXTEST), the PLD is now configured and operating based upon the new configuration data, with the I/O output signals under control of the newly configured user logic of the PLD. Furthermore, if the internal registers were preconditioned, the logic outputs exit in the desired state determined by the inputs to the user control logic.
The techniques illustrated may also be referred to herein by the operations of �leave alone I/O� and �known-state exit.� The leave alone I/O operation refers to the ability to program in background mode and, while the PLD is refreshed, hold the state of the I/O output pins in a known logic state (e.g., generally operations 302 and 306 through 312 of flowchart 300). The known state may be based on the I/O values captured or based on a known system vector that is provided to set the I/O values based on user-predefined settings. Thus, the leave alone I/O allows critical signals (e.g., reset and power enable signals provided by the PLD in a system) to not glitch and to not go active (e.g., float or provide undesired values) while the PLD is reconfigured.
The known state exit operation refers to the updating of some or all of the internal register states with predefined values (e.g., the optional portion of operation 314 of flowchart 300). The values may be provided by latches (e.g., as discussed in reference to FIG. 9) and/or via I/O pins and input paths through the boundary scan (BSCAN) cells (e.g., as discussed in reference to FIGS. 4 and 5). This operation is useful when the PLD logic that provides the value for the I/O pin may be in a state that would cause the I/O pin to pass through a glitch or inappropriate signal level (e.g., glitch or active level). Thus, the PLD exits to user-defined operation after reconfiguration in a known logic state.
The leave alone operation (operations 306 and 308) may be implemented, for example, by using the BSCAN cells within the PLD to capture current I/O pin output states and/or optionally overlay with a custom I/O vector to set desired I/O pin output values. For example, FIGS. 4 and 5 show exemplary block diagram implementations for BSCAN circuits 400 and 500, respectively, for I/O blocks 102 of PLD 100 of FIG. 1 in accordance with an embodiment of the present invention.
BSCAN circuit 400 (BSCAN cell) illustrates that one or more BSCAN registers may be used to store the sampled I/O value to provide as an output signal via an I/O pin (e.g., using the JTAG instruction SAMPLE provided via data port 112(2) to place output states in BSCAN cell preload registers) and/or overlay a custom vector of user-defined values to provide as the output signal via the I/O pin (e.g., using the JTAG instruction PRELOAD). If custom vector values are provided, these can be preloaded into the PLD just prior to the refresh process (e.g., during operation 306 or 308 of flowchart 300). The I/O control can then be transferred to BSCAN circuit 400 (e.g., by using the JTAG instruction EXTEST), with the dotted path and bold arrow illustrating I/O values provided to the I/O pin based on custom vector values or captured I/O values.
For example, FIG. 6 shows PLD 100 operating in a user mode of operation prior to the refresh operation. The logical states stored in BSCAN circuit 602 may be unknown (or don't care state as indicated by the question mark) and a user register 606 within logic area 604 may store a logical high value (i.e., a logical high data value �1�), which user register 606 provides to an I/O pin 608, as shown by the dotted path. It should also be noted that some fuses (e.g., configuration memory 114) may be programmed and others may not be programmed within logic area 604, as shown by the shaded and clear squares (where shaded indicates a programmed connection).
Furthermore, user register 606 in logic area 604 may not be accessible and may store an unknown data value, as shown in FIG. 7. For example, a clock signal provided to user register 606 via a clock pin (CLK) may not be externally held low to maintain the logical high value in user register 606 during the refresh operation. As another example, if the fuse connecting the reset (R) terminal of user register 606 to a global reset signal is programmed, the logical high value (i.e., a �1� data value) stored in user register 606 may be reset to a logical low value (i.e., a �0� data value) when the global reset signal is asserted during the refresh operation.
FIG. 8 shows PLD 100 after the refresh process and with a known-state exit. User register 606 within logic area 604 has been preconditioned (i.e., preloaded) with a desired logical high value, as shown by the dotted input path, so that the logical high value on I/O pin 608 is maintained glitch-free when user mode of operation resumes. This is possible because the appropriate fuses within logic area 604 have been programmed by the refresh process to provide the proper connections to access user register 606 within logic area 604. Consequently, before transitioning to the user mode of operation and releasing control of I/O pin 608 to the user-defined logic, the appropriate data value may be provided via BSCAN circuit 602 to user register 606 within logic area 604. User register 606, in turn, provides the appropriate value to I/O pin 608 when the user mode of operation resumes.
FIG. 9 shows a circuit 900, which illustrates an exemplary circuit implementation for a latch (also referred to herein and optionally used as a bus keeper circuit) for PLD 100 in accordance with an embodiment of the present invention. One or more of circuits 900 may be implemented within PLD 100 to store and preserve user register output values and/or retain the personality of I/O blocks 102, as described for operation 310 (FIG. 3).
Circuit 900 includes a transistor 902, a memory cell 904, and a multiplexer 906. A signal 910 may be stored by memory cell 904 by asserting (e.g., a logical high value) a capture control signal 908 to switch on transistor 902. A control signal 912 controls multiplexer 906 to select signal 910 or the stored value provided by memory cell 904 (e.g., a latch) to provide on an output signal path 914.
Signal 910 may represent a signal from one of configuration memory cells 114, a user register output signal (e.g., a Q output signal of user register 606), or some other signal whose value it is desired to acquire and preserve during the reconfiguration process (e.g., a signal (e.g., data value) from one configuration memory 114 that controls some personality aspect for I/O block 102). During the refresh (operation 312), for example, control signal 912 can be asserted to provide the latched data value on output signal path 914 to maintain a consistent output value during the refresh, and then be deasserted when desired so that signal 910 is selected by multiplexer 912 and provided on output signal path 914 after the reconfiguration has been completed.
It should also be understood that circuit 900 may be modified as desired, depending upon the desired application, as would be understood by one skilled in the art. For example, circuit 900 may include weak pull-up and pull-down resistors on output signal path 914 at the output of multiplexer 906 to maintain logical high or logical low states on output signal path 914 during programming mode. However, the weak pull-up and pull-down resistors permit the latched logic state provided by memory cell 904 to be overridden by external signals driven onto output signal path 914 if desired.
For example, external signals may be driven onto output signal path 914 to precondition registers in a logic area of PLD 100 to support the known state exit operation previously described herein. In this regard, it will be appreciated that, in various embodiments, output signal path 914 of circuit 900 (e.g., a bus keeper circuit) may be connected with input path 502 of FIG. 5 previously described herein. Thus, one or more circuits 900 may be implemented as bus keeper circuits to maintain the desired values on I/O pins during the refresh (operation 312), for example, to preserve user register values and maintain continuity from the old user configuration to the new user configuration, but would allow external input signals to be driven onto output signal path 914 to precondition registers (operation 314).
FIG. 10 shows a circuit 1000, which illustrates an exemplary circuit implementation for preserving a user register value and/or providing a known state exit for PLD 100 of FIG. 1 in accordance with an embodiment of the present invention. Circuit 1000 includes a user register 1002 (e.g., representing user register 606) and a multiplexer 1004, which are within PLD 100.
For this exemplary implementation, user register 1002 may represent a D-type flip flop with preload functionality. As an example, when PLD 100 enters the programming mode (to reconfigure PLD 100), a PRELOAD signal 1008 may be held high to preload data provided at a preload data (PD) terminal 1010 of user register 1002. For example, by controlling multiplexer 1004, either the current Q output signal 1012 or another data signal 1014 may be latched into user register 1002 at PD terminal 1010 as provided by multiplexer 1004. The control of multiplexer 1004 and the value of data signal 1014 may be provided, for example, by configuration memory cells 1006 (separately referenced as 1006(1) and 1006(2)), which are part of configuration memory 114.
In general, if the current value of Q output signal 1012 is stored into preload data (PD) terminal 1010, user register 1002 will provide (after reentering user mode after reconfiguration) the same value as just prior to the reconfiguration. Thus, the value provided by user register 1002 will be preserved during the reconfiguration (e.g., the register value from the previous user pattern is carried into the new pattern or may be viewed as using the user register to store the current data for the next application).
If the value stored into preload data (PD) terminal 1010 is provided by data signal 1014 (e.g., the SRAM fuse), user register 1002 will provide this user defined new value (after reentering user mode after reconfiguration). Consequently, user register 1002 will enter the user mode after the reconfiguration with a user specified state in user register 1002. Thus, in accordance with some embodiments of the present invention, this technique may be applied as desired to any number of user registers within PLD 100 to provide a known state (e.g., known state exit) from the user register when entering the user mode after a reconfiguration. Additionally in accordance with an embodiment of the present invention, this technique may be applied to provide a known state entrance such that user register 1002 is providing a known value just prior to entering reconfiguration.
FIG. 11 shows a block diagram illustrating a PLD 1100, which provides exemplary store-to-flash implementation details (e.g., operation 304 of FIG. 3) for PLD 100 of FIG. 1 in accordance with an embodiment of the present invention. PLD 1100 includes a non-volatile memory 1102, which may represent, for example, non-volatile memory 106 (FIG. 1). Non-volatile memory 1102 includes a configuration flash section 1102(1) and a user flash section 1102(2) (also referred to herein as a shadow flash section).
Configuration flash section 1102(1) is used to store configuration data for transfer to configuration memory 114 (not shown) within a PLD portion 1104 of PLD 1100 to configure PLD 1100. PLD portion 1104 includes generally core circuitry 1108 (e.g., I/O blocks 102, programmable logic blocks 104, and interconnect 116) and volatile memory blocks 1106 (e.g., representing volatile memory 108 and labeled EBR). User flash section 1102(2) is used to store data transferred from volatile memory blocks 1106 to preserve during reconfiguration and which is later transferred back to volatile memory blocks 1106 during or after the refresh (e.g., operation 312) but prior to transition to user mode of operation.
For example, FIGS. 12-14 show circuits 1200, 1300, and 1400, respectively, which illustrate exemplary implementation details for a store-to-flash operation (e.g., operation 304) for PLD 1100 of FIG. 11 (or PLD 100 of FIG. 1) in accordance with an embodiment of the present invention. FIGS. 12-14 may be viewed as illustrating generally a user programming flow of operations for user flash.
Circuit 1200 includes control logic 1202, user flash section 1102(2), and volatile memory blocks 1106. Control logic 1202, for example, may be formed as part of or separate from control logic 202 (FIG. 2). It should be noted that other circuitry, such as configuration flash section 1102(1) or programmable logic blocks 104, are not shown for clarity.
Volatile memory blocks 1106, for example, have been configured by a user pattern to function as flash memory (Flash), RAM, and ROM, as labeled in FIG. 12. User flash section 1102(2) is also illustrated in an exemplary fashion to include sections 1204(1) through 1204(4), which correspond to memory available for storage of data for the flash memory, RAM, RAM, and ROM as labeled for volatile memory blocks 1106. For example, volatile memory block 1106 that is labeled Flash is a volatile memory block (e.g., embedded block RAM or EBR) that a user desired to configure to function as flash memory. Furthermore for example, section 1204(1) is the section of user flash section 1102(2) (e.g., shadow flash) that will hold and preserve data for volatile memory block 1106 labeled flash memory during the reconfiguration for the store-to-flash operation (e.g., section 1204(1) shadows volatile memory block 1106 labeled Flash).
Circuit 1200 illustrates, with the bold arrow from user flash section 1102(2) through volatile memory blocks 1106, the ability to transfer data from user flash section 1102(2) to volatile memory blocks 1106 to initialize volatile memory blocks 1106 with desired data. For example, control logic 1202 may provide an enable signal 1206 (labeled EBR enable) to volatile memory blocks 1106 to enable volatile memory blocks 1106 to store the data provided by user flash section 1102(2). Control logic 1202 may be controlled, for example, via SPI or JTAG ports (e.g., via data port 112) during the store-to-flash operation or to initiate the store-to-flash operation.
PLD 1100 containing circuit 1200 may be viewed as operating in a user mode of operation as configured by a user pattern (i.e., a user defined pattern �A�). If a user desires to reconfigure PLD 1100, non-volatile memory 1102 may be erased (e.g., write all logical high values �1�) and then a new user pattern (i.e., a user defined pattern �B�) may be written to non-volatile memory 1102 (including user flash section 1102(2)), while PLD 1100 operates in user mode with user defined pattern �A� (e.g., background programming operation 302 is performed). For example, user flash section 1102(2) may now store a default pattern (e.g., store all logical low values �0�), except for section 1204(4) corresponding to volatile memory block 1106 (labeled ROM) that a user desires to function as ROM and thus section 1204(4) stores the desired ROM data (e.g., the same ROM data as in user defined pattern �A�).
Prior to performing the refresh operation (e.g., operation 312), a user may desire to preserve the data stored in volatile memory blocks 1106. Therefore, as illustrated in FIG. 13, a store-to-flash operation (e.g., operation 304) may be performed to transfer the data stored in volatile memory blocks 1106 to user flash section 1102(2) to preserve the data during the refresh. Upon completion of the store-to-flash operation for this example, section 1204(1) through 1204(4) will store the data from volatile memory blocks 1106 labeled Flash, RAM, RAM, and ROM, respectively.
For example as shown in circuit 1300, when a store-to-flash control signal 1308 is deasserted, a store control signal 1314 is provided by a logic gate 1302 (e.g., which may also be controlled by a store signal 1306 provided by an SRAM fuse programmed to a �1� value) to control logic 1202. Alternatively, the store-to-flash operation may be controlled by SPI or JTAG ports. A store status signal 1304 may be provided by control logic 1202 to indicate when the store-to-flash operation has been completed.
During the store-to-flash operation (FIG. 13), control logic 1202 may provide a store control signal 1312 to volatile memory blocks 1106 and a flash enable control signal 1310 to user flash section 1102(2) to control the transfer and storage of data from volatile memory blocks 1106 to user flash section 1102(2). Upon completion of the store-to-flash operation, the refresh operation may be performed to reconfigure PLD 1100. For example for the refresh operation, the configuration data stored in configuration flash section 1102(1) may be transferred to configuration memory 114, and the data stored and preserved in user flash section 1102(2) may be transferred to volatile memory blocks 1106 (e.g., as illustrated in FIG. 14). The refresh operation may be initiated, for example, by powering down and then powering up PLD 1100, toggling a program pin of PLD 1100, or sending a refresh command to PLD 1100 (e.g., via a slave SPI interface or JTAG port).
FIG. 15 shows a block diagram illustrating a PLD 1500, which provides exemplary implementation details (e.g., operation 304 of FIG. 3) for the programmable logic device of FIG. 1 in accordance with an embodiment of the present invention. In general, FIG. 15 illustrates an exemplary data flow between non-volatile memory 106 (e.g., flash memory) and volatile memory 108 (e.g., EBR) and configuration memory 114 (e.g., configuration SRAM fuses). As noted herein, although configuration memory 114 is shown in block form, it should be understood that configuration memory 114 typically would be distributed within PLD 1500 in a conventional fashion to store configuration data and configure PLD 1500 for its intended purpose based on the configuration data.
Non-volatile memory 106 may be viewed in accordance with some embodiments of the present invention as including configuration flash sections 1102(1) and user flash sections 1102(2). Configuration flash sections 1102(1), which are shown as shaded portions of non-volatile memory 106 and also referred to as configuration flash, are used to store configuration data for transfer to configuration memory 114 to configure PLD 1500. This is illustrated in FIG. 15 by the single-headed arrows drawn from configuration flash sections 1102(1) to portions of PLD 1500 where configuration memory 114 would typically be distributed. For example, configuration flash sections 1102(1) on the left and right sides of PLD 1500 may be used to transfer data to configuration memory 114 on the left half and right half, respectively, of PLD 1500 as shown.
User flash sections 1102(2), which are shown as unshaded portions of non-volatile memory 106 and also referred to as user flash or EBR shadow flash, are used to store the data for volatile memory 108 and preserve the data for volatile memory 108 through a reconfiguration of PLD 1500. This is illustrated in FIG. 15 by the double-headed arrows drawn between user flash sections 1102(2) and volatile memory 108 (e.g., bi-directional operation of user flash). For example, user flash sections 1102(2) on the left and right sides of PLD 1500 may be used to transfer data to volatile memory 108 on the left half and right half, respectively, of PLD 1500 as shown. Furthermore for example, user flash sections 1102(2) on the left and right sides of PLD 1500 may be used to receive data from volatile memory 108 on the left half and right half, respectively, of PLD 1500 as shown.
Thus, the content of volatile memory 108 may be programmed back into user flash sections 1102(2), the process of which may also be referred to as a Store action (e.g., as discussed in reference to FIG. 13), to preserve data stored by volatile memory 108 prior to a reconfiguration. Consequently, user flash sections 1102(2) may be viewed, for this example, as user flash memory and as a subset of non-volatile memory 106 to provide self-programming capability.
In general, many system designs, within which the PLD operates, require 99.999% up-time. For example, by using background programming, the PLD continues to operate while the external bitstream is loaded into non-volatile memory. The non-volatile memory can also optionally be used to preserve information, such as from the embedded block RAM, during the reconfiguration process and then restored into the corresponding memory (e.g., embedded block RAM) prior to returning to user mode of operation. Furthermore, by driving glitch-free known values as output signals via the I/O circuits, the PLD can provide valuable functionality to the system in which it operates, such as to continue to provide power enable, reset, or other critical signals (e.g., which may be used to bring up the system) while the PLD is reconfigured (e.g., in an on-the-fly reconfiguration procedure). Thus, techniques are disclosed herein to control the state of the logic within the PLD prior to exiting the configuration process, which allows the device logic to drive the correct levels on its outputs immediately and provide a known state exit and seamless transfer to user logic, when control of I/O is passed back to the PLD logic at the end of the configuration cycle.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5548228Sep 28, 1994Aug 20, 1996Altera CorporationReconfigurable programmable logic device having static and non-volatile memoryUS5640107Oct 24, 1995Jun 17, 1997Northrop Grumman CorporationMethod for in-circuit programming of a field-programmable gate array configuration memoryUS5689516Jun 26, 1996Nov 18, 1997Xilinx, Inc.Reset circuit for a programmable logic deviceUS5696455 *Aug 19, 1996Dec 9, 1997Altera CorporationIn a single integrated circuit packageUS5844422Nov 13, 1996Dec 1, 1998Xilinx, Inc.State saving and restoration in reprogrammable FPGAsUS6049222Dec 30, 1997Apr 11, 2000Xilinx, IncConfiguring an FPGA using embedded memoryUS6150837Feb 28, 1997Nov 21, 2000Actel CorporationEnhanced field programmable gate arrayUS6208162 *Feb 19, 1998Mar 27, 2001Altera CorporationTechnique for preconditioning I/Os during reconfigurationUS6304099May 21, 1998Oct 16, 2001Lattice Semiconductor CorporationMethod and structure for dynamic in-system programmingUS6356107Nov 13, 2000Mar 12, 2002Lattice Semiconductor CorporationMethod and structure dynamic in-system programmingUS6467009Oct 14, 1998Oct 15, 2002Triscend CorporationConfigurable processor system unitUS6507211Jul 29, 1999Jan 14, 2003Xilinx, Inc.Programmable logic device capable of preserving user data during partial or complete reconfigurationUS6538468 *Jul 31, 2000Mar 25, 2003Cypress Semiconductor CorporationMethod and apparatus for multiple boot-up functionalities for a programmable logic device (PLD)US6704850Aug 23, 2000Mar 9, 2004Triscend CorporationMethod and apparatus for determining the width of a memory subsystemUS6714041Aug 30, 2002Mar 30, 2004Xilinx, Inc.Programming on-the-fly (OTF)US6721840Aug 18, 2000Apr 13, 2004Triscend CorporationMethod and system for interfacing an integrated circuit to synchronous dynamic memory and static memoryUS6732263Sep 22, 2000May 4, 2004Altera CorporationConfiguring both a programmable logic device and its embedded logic with a single serialized configuration bit streamUS6774668Jan 8, 2003Aug 10, 2004Xilinx Inc.Apparatus and method for preinitializing logic functionUS6828823 *May 16, 2003Dec 7, 2004Lattice Semiconductor CorporationNon-volatile and reconfigurable programmable logic devicesUS6851047Oct 15, 1999Feb 1, 2005Xilinx, Inc.Configuration in a configurable system on a chipUS6873177 *Aug 12, 2003Mar 29, 2005Xilinx, Inc.Systems and methods for programming a secured CPLD on-the-flyUS7099227 *Jan 16, 2004Aug 29, 2006Xilinx, Inc.PLD hardwire programming with multiple functional modesUS7180776 *Feb 1, 2005Feb 20, 2007Xilinx, Inc.Systems and methods for programming a secured CPLD on-the-flyUS20020163840 *Jun 25, 2002Nov 7, 2002Mitsuru HirakiSemiconductor integrated circuit device, memory module, storage device and the method for repairing semiconductor integrated circuit deviceUS20040025086 *Aug 2, 2002Feb 5, 2004Gorday Robert MarkError checking in a reconfigurable logic signal processor (RLSP)US20050083743 *Sep 7, 2004Apr 21, 2005Integrated Magnetoelectronics Corporation A California CorporationNonvolatile sequential machinesUS20050189962Feb 20, 2004Sep 1, 2005Agrawal Om P.Upgradeable and reconfigurable programmable logic deviceUS20050248364 *Apr 30, 2004Nov 10, 2005Xilinx, Inc.Reconfiguration port for dynamic reconfigurationUS20060067102 *Sep 26, 2005Mar 30, 2006Matsushita Electric Industrial Co., Ltd.Non-volatile logic circuit and system LSI having the same* Cited by examinerNon-Patent CitationsReference1Actel Corporation, "ProASIC<SUP>Plus </SUP>Flash Family FPGAs", v.3.4 Dec. 2003, pp. i-iv and I-I-I-64 & 2-1-2.67 & 2-1-2-7 (list of changes).2Actel Corporation, ProASICE Flash Family FPGAs, ARM7(TM) Soft IP Support in ProASIC3E ARM7-Ready Devices, Oct. 2005, 166 pages.3Altera R, Max II Device Handbook, http://www.altera.com, M115V1-1.7, 330 pages.4Altera(R) , Max II Device Handbook, http://www.altera.com, M115V1-1.7, 330 pages, no date.5Lattice Semiconductor Corporation, ispXP(TM) Configuration Usage Guidelines, Technical Notes TN1026, Aug. 2002, pp. 1-18.6Lattice Semiconductor Corporation, ispXPGA(TM) Family, Dec. 2002, pp. 1-90.7Lattice Semiconductor Corporation, ispXPGA(TM) Family, Preliminary Data Sheet, Sep. 2003, pp. 1-112.8Lattice Semiconductor Corporation, LatticeXP Family Data sheet, Version 01.0, Feb. 2005, 77 pages.9U.S. Appl. No. 10/809,658, Howard Tang.10U.S. Appl. No. 11/243,255, Howard Tang.11U.S. Appl. No. 11/293,941, Howard Tang.12U.S. Appl. No. 11/350,436, Howard Tang.13U.S. Appl. No. 11/397,985, filed Apr. 5, 2006, Fontana et al.14Xilinx, On the Fly Reconfiguration with CoolRunner-II CPLDs, Application Note: CoolRunner-II CPLDs, May 15, 2003, pp. 1-10.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7535253 *Nov 15, 2007May 19, 2009Lattice Semiconductor CorporationRegister data retention systems and methods during reprogramming of programmable logic devicesUS7538574 *Dec 5, 2005May 26, 2009Lattice Semiconductor CorporationTransparent field reconfiguration for programmable logic devicesUS7576561 *Nov 13, 2007Aug 18, 2009Xilinx, Inc.Device and method of configuring a device having programmable logicUS7652500Mar 7, 2008Jan 26, 2010Lattice Semiconductor CorporationReconfiguration of programmable logic devicesUS7834154Feb 8, 2008Nov 16, 2010Genentech, Inc.Angiogenesis inhibitionUS7957208 *Feb 19, 2009Jun 7, 2011Lattice Semiconductor CorporationFlexible memory architectures for programmable logic devicesUS20120286821 *May 9, 2011Nov 15, 2012Altera CorporationSystems and methods for configuring an sopc without a need to use an external memoryEP2523349A2 *May 8, 2012Nov 14, 2012Altera CorporationSystems and methods for configuring an SOPC without a need to use an external memory* Cited by examinerClassifications U.S. Classification326/38, 326/40International ClassificationH03K19/177Cooperative ClassificationH03K19/17772, H03K19/17744, H03K19/1776European ClassificationH03K19/177H3, H03K19/177H6, H03K19/177F4Legal EventsDateCodeEventDescriptionMay 2, 2012FPAYFee paymentYear of fee payment: 4May 25, 2006ASAssignmentOwner name: LATTICE SEMICONDUCTOR CORPORATION, OREGONFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:TANG, HOWARD;LAW, HENRY;RUTLEDGE, DAVID L.;AND OTHERS;REEL/FRAME:017678/0693;SIGNING DATES FROM 20060404 TO 20060525RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services