SECURITY RAM BLOCK WITH MULTIPLE PARTITIONS

Abstract

Circuits, methods, and apparatus for storing application data, keys, authorization codes, or other information in a volatile memory on an FPGA. A field programmable gate array (FPGA) can include multiple memory blocks and partition those blocks among multiple independent reconfigurable regions. Access to the memory blocks can then be restricted so that only authorized regions have access to particular memory partitions. In addition, each partition can store multiple message authentication codes (MACs) for further controlling access to data in each partition.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent application Ser. No. 12/830,447, filed Jul. 6, 2010, which is a divisional of U.S. patent application Ser. No. 11/517,689, filed Sep. 7, 2006, titled “SECURITY RAM BLOCK,” now U.S. Pat. No. 7,752,407, all of which are hereby incorporated by reference herein in their entireties.

BACKGROUND

The present invention relates generally to storing data on an integrated circuit and more particularly to protecting data stored in a battery powered memory on a field programmable gate array (FPGA).

The circuit complexity and the tasks performed by integrated circuits such as field programmable gate arrays have greatly increased the last few years. Highly sophisticated software, or applications, run on programmable logic elements that are configured to perform intricate user-defined functions.

Often these applications need to store data in a memory, for example, an application may store data at different times for later use. Other important data such as chip identification, license information, and encryption keys may need to be stored. Unfortunately, if power is removed from the memory, this data is lost unless the memory is nonvolatile.

But nonvolatile memory typically requires processing that is either not compatible with processing technologies used to manufacture FPGAs or uses extra processing steps that greatly increase device costs. Also, in many situations, the security of the data stored in memory is important, so it is desirable to quickly erase it if a tamper is detected. Unfortunately, it is difficult to quickly erase nonvolatile memory. Further, data stored in a nonvolatile memory can be discovered through reverse engineering.

To protect this data, it is important to also limit access to it, such that the data may not be stolen or copied by a nefarious user or application. For example, a configuration design may be protected by encrypting it with a key. If this key is stored in memory for use during decryption, it is desirable to protect and limit access to this key.

Thus, what is needed are circuits, methods, and apparatus that provide a memory for an FPGA that retains data when power to the FPGA is removed, but is compatible with conventional FPGA manufacturing processes and can quickly be erased in the event of a tamper or other unauthorized event. Also, it is desirable to provide further protection by limiting access to data stored in the memory.

SUMMARY

Accordingly, embodiments of the present invention provide circuits, methods, and apparatus for storing application data, keys, authorization codes, or other information in a memory on an FPGA. An exemplary embodiment of the present invention provides an FPGA that stores this data in an on-chip volatile memory. A battery powers the memory to prevent erasure of the stored information when power to the FPGA is removed. In various embodiments the battery is always the source of power for the memory, in other embodiments one or more other power supplies can be switched in to replace the battery as the source of power to the memory, for example to extend battery life.

In various embodiments of the present invention, the power to the memory may be interrupted in order to erase the contents of the memory. For example, if a tamper or unauthorized configuration bitstream is attempted, power to the memory is cut, thereby erasing the memory. In one exemplary embodiment, a message authentication code (MAC) is used to verify a configuration bitstream. The MAC removes power from the memory if the received bitstream is not verified.

Various embodiments of the present invention also limit access to data stored in memory. Typically, read access is limited, though write access may also be limited, particularly where data is being overwritten. In a specific embodiment of the present invention, access is limited by using authorization codes. An application is only granted access if it provides the correct authorization code, or an access code and authorization codes stored in the memory have a predefined function relationship. Another embodiment of the present invention encrypts data with a key before it is stored. Only an application with the correct key can make use of the data. Embodiments of the present invention may incorporate one or more of these or the other features described herein.

In one embodiment, the present invention provides an apparatus for securely storing data. The apparatus includes a memory core that contains a secure portion allocated to secure data storage, and a control circuit configured to control data written to and read from the secure portion of the memory core, and is adapted to prevent changes to data stored in the secure portion during reconfiguration operations of the memory, such as when an application is configured during a software application installation process which involves data read from and stored to the memory core.

Embodiments of the present invention also provide circuits, methods, and apparatus for sharing one or more memory blocks among multiple independently reconfigurable regions of programmable circuitry, e.g., an FPGA. In various embodiments of the present invention, a configuration controller is configured to partition the one or more memory blocks to allocate different memory partitions to the multiple independently reconfigurable regions. The configuration controller may also be configured to control access to the memory block. For instance, the configuration controller may be configured to prevent all or certain ones of the independently reconfigurable regions from accessing a memory partition which has been allocated to another independently reconfigurable region. This access restriction may apply to read access, write access, or both, and may vary depending on the independently reconfigurable region requesting access.

In one illustrative embodiment, an apparatus includes n memory blocks and m independently reconfigurable regions, where m>n, and the configuration controller is configured to partition the n memory blocks over the m independently reconfigurable regions. The configuration controller may also be configured to control access to each of the n memory blocks to prevent any given one of the m independently reconfigurable regions from accessing memory partitions allocated to another one of the m independently reconfigurable regions.

In some embodiments, each memory partition stores multiple message authentication codes, e.g., generated using a message authentication code (MAC) generator. When a configuration stream is received by the configuration controller, a MAC may be generated and compared to the stored MACs to determine if the generated MAC matches any of the stored MACs. If the configuration controller determines a match, it may grant access to the memory partition storing the matching MAC. Otherwise, the configuration controller may deny access.

In some embodiments, the configuration controller is configured to overwrite all data stored in a memory partition with zero values in response to determining that an unauthorized independently reconfigurable region is attempting to access the memory partition. In other embodiments, the data is erased by cutting power to the memory block containing the targeted memory partition.

The configuration controller may control access to memory blocks and partitions thereof using one or more access control techniques. In one approach, the FPGA is designed so that all memory accesses must go through the configuration controller; i.e., requests to access the memory must be provided to the configuration controller, and the configuration controller communicates with the memory on behalf of the requestor (e.g., an independently reconfigurable region). This can be accomplished, for example, by ensuring (through fixed design or by programming configurable interconnects) that the independently configurable regions are not provided with any direct connections to the memory block(s). The configuration controller, in such a scenario, would only complete requests (e.g., by forwarding the request on to the memory or to the particular memory partition) that it determines to be authorized.

In another approach, the independently configurable regions may be provided with direct connections to the memory blocks, but the data stored in the memory partitions are encrypted. In such a scenario, the configuration controller may limit access to memory partitions by decrypting data only when it determines a memory request to be authorized.

Any other suitable approach may be used to control access to memory blocks and their partitions and, in some embodiments, a combination of these approaches may be implemented. Additionally, these access control features may be implemented to control only read access requests, write access requests, or both. In yet other embodiments, access control may be achieved without using a configuration controller, e.g., by encrypting the data and/or storing MACs with the data as described above and further below.

A better understanding of the nature and advantages of the present invention may be gained with reference to the following detailed description and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified block diagram of a programmable logic device that is improved by incorporating embodiments of the present invention;

FIG. 2 is a block diagram of an electronic system that is improved by incorporating embodiments of the present invention;

FIG. 3A is a block diagram illustrating the storing of an encrypted configuration bitstream and decryption key according to an embodiment of the present invention, while FIG. 3B illustrates the decryption of an encrypted bitstream and configuration of an FPGA according to an embodiment of the present invention;

FIG. 4A is a flowchart illustrating a method of encrypting a configuration bitstream and storing a key and other parameters in a security RAM according to an embodiment of the present invention, while FIG. 4B is a flowchart illustrating a method of decrypting an encrypted configuration bitstream and configuring an FPGA according to an embodiment of the present invention;

FIG. 5 illustrates a method of powering a security RAM according to an embodiment of the present invention;

FIG. 6 illustrates another method of powering a security RAM according to an embodiment of the present invention;

FIG. 7 illustrates a method of powering a security RAM while utilizing a shutdown switch according to an embodiment of the present invention;

FIG. 8 illustrates a method of powering a security RAM while utilizing a shutdown switch controlled by a message authentication code according to an embodiment of the present invention;

FIG. 9 illustrates a method of generating a configuration bitstream verification signal to control a security RAM shutdown switch according to an embodiment of the present invention;

FIG. 10 is a flowchart illustrating a method of generating a configuration bitstream verification signal to control a security RAM shutdown switch according to an embodiment of the present invention;

FIG. 11 illustrates a circuit that may be used as the function block in FIG. 9;

FIG. 12 illustrates exemplary data transfers between a configuration controller, an access control circuit, and security SRAM during the configuration of an FPGA;

FIGS. 13A and 13B are a flowcharts illustrating the operation of an FPGA where a configuration controller is granted automatic access to a decryption key stored in a security SRAM;

FIG. 14 illustrates exemplary transfers of data in an FPGA where access to data in a memory is limited by requiring an authorization code;

FIG. 15 is a flowchart illustrating a method of limiting read access to data in a security SRAM by requiring an authorization code;

FIGS. 16A and 16B are a flowcharts illustrating a method configuring a device where a decryption key is encrypted using a second key and both keys are stored in a security SRAM;

FIG. 17 illustrates an exemplary dataflow in a device where an application has protected data in a security SRAM through encryption;

FIGS. 18A and 18B are a flowcharts illustrating a method of receiving and decrypting encrypted data stored in a security SRAM;

FIG. 19 is a block diagram of an exemplary FPGA including a configuration controller, an access control circuit, and multiple security SRAMs each having multiple partitions;

FIG. 20 is a flowchart illustrating a method of controlling memory access in an FPGA having multiple memory blocks and independently reconfigurable regions.

DESCRIPTION OF EXEMPLARY EMBODIMENTS

FIG. 1 is a simplified partial block diagram of an exemplary high-density programmable logic device 100 wherein techniques according to the present invention can be utilized. PLD 100 includes a two-dimensional array of programmable logic array blocks (or LABs) 102 that are interconnected by a network of column and row interconnections of varying length and speed. LABs 102 include multiple (e.g., 10) logic elements (or LEs), an LE being a small unit of logic that provides for efficient implementation of user defined logic functions.

PLD 100 also includes a distributed memory structure including RAM blocks of varying sizes provided throughout the array. The RAM blocks include, for example, 512 bit blocks 104, 4K blocks 106, and an M-Block 108 providing 512K bits of RAM. These memory blocks may also include shift registers and FIFO buffers. PLD 100 further includes digital signal processing (DSP) blocks 110 that can implement, for example, multipliers with add or subtract features.

It is to be understood that PLD 100 is described herein for illustrative purposes only and that the present invention can be implemented in many different types of PLDs, FPGAs, and the other types of digital integrated circuits.

While PLDs of the type shown in FIG. 1 provide many of the resources required to implement system level solutions, the present invention can also benefit systems wherein a PLD is one of several components. FIG. 2 shows a block diagram of an exemplary digital system 200, within which the present invention may be embodied. System 200 can be a programmed digital computer system, digital signal processing system, specialized digital switching network, or other processing system. Moreover, such systems may be designed for a wide variety of applications such as telecommunications systems, automotive systems, control systems, consumer electronics, personal computers, Internet communications and networking, and others. Further, system 200 may be provided on a single board, on multiple boards, or within multiple enclosures.

System 200 includes a processing unit 202, a memory unit 204 and an I/O unit 206 interconnected together by one or more buses. According to this exemplary embodiment, a programmable logic device (PLD) 208 is embedded in processing unit 202. PLD 208 may serve many different purposes within the system in FIG. 2. PLD 208 can, for example, be a logical building block of processing unit 202, supporting its internal and external operations. PLD 208 is programmed to implement the logical functions necessary to carry on its particular role in system operation. PLD 208 may be specially coupled to memory 204 through connection 210 and to I/O unit 206 through connection 212.

Processing unit 202 may direct data to an appropriate system component for processing or storage, execute a program stored in memory 204 or receive and transmit data via I/O unit 206, or other similar function. Processing unit 202 can be a central processing unit (CPU), microprocessor, floating point coprocessor, graphics coprocessor, hardware controller, microcontroller, programmable logic device programmed for use as a controller, network controller, and the like. Furthermore, in many embodiments, there is often no need for a CPU.

For example, instead of a CPU, one or more PLD 208 can control the logical operations of the system. In an embodiment, PLD 208 acts as a reconfigurable processor, which can be reprogrammed as needed to handle a particular computing task. Alternately, programmable logic device 208 may itself include an embedded microprocessor. Memory unit 204 may be a random access memory (RAM), read only memory (ROM), fixed or flexible disk media, PC Card flash disk memory, tape, or any other storage means, or any combination of these storage means.

FIG. 3A is a block diagram illustrating a method of storing of an encrypted configuration bitstream and decryption key according to an embodiment of the present invention. This figure includes software modules and hardware interface 320, configuration device 330, FPGA 340, and battery 350. In various embodiments of the present invention, the configuration device 330 may be included as part of the FPGA 340. For example, the configuration device 330 may be a memory on the FPGA 340. This figure, as with the other included figures, is shown for illustrative purposes and does not limit either the possible embodiments of the present invention or the claims.

The software modules and hardware interface 320 include an encryption software module 322, key software module 324, and decryption circuit data module 326. These software modules use one or more hardware interfaces for transferring data to the FPGA 340 and optional configuration device 330. The FPGA 340 includes a security SRAM 342, decryption circuitry 344, and other programmable circuitry 346.

A key 312 is received or otherwise generated by the key software module 324, which provides it as key 322 to the security SRAM 342 on the FPGA 340 and to the encryption software module 322. A configuration bitstream 310 is received by encryption software module 322, which uses the key 324 to generate an encrypted configuration bitstream or encrypted program object file, EPOF 320, which is provided to the configuration device 330. Decryption circuit configuration data 314 may be optionally received by decryption circuit data software module 326, which provides data for storage in the security SRAM 342. This decryption circuit configuration data may include a decryption circuit configuration bitstream, decryption circuit parameters, such as the number of rounds, substitution box entries, and other parameters, or both.

The decryption circuitry 344 may be a fixed decryption circuit, that is, a hard logic or hardwired circuit. The decryption circuitry 344 may alternately be configured from programmable logic or other configurable circuits, or it may include a combination of these techniques. These logic elements can be configured by a decryption circuit configuration bitstream that is part of the decryption circuit configuration data 326. When a decryption circuit 344 is to be configured, decryption circuit configuration data 326 is provided and stored in the security SRAM 342.

In various embodiments, standard or conventional encryption methods and circuits such as triple-DES (3-DES) or AES may be used. Alternately, proprietary encryption circuits may be used. Both conventional and proprietary algorithms may be defined by various encryption algorithm parameters, which may also be part of the decryption circuit configuration data 324 stored on the FPGA 340. For example, when using otherwise standard encryption methods, variations such as the number of rounds may be defined by encryption algorithm parameters. In various embodiments of the present invention where the decryption circuit is fixed or hardwired, these encryption parameters may also be fixed such that encryption algorithm parameters are not needed.

In a typical embodiment of the present invention, the security SRAM 342 is a volatile memory. In various embodiments of the present invention, the key 322, and optionally the decryption circuit configuration data 326, is retained in the volatile memory 342.

In one embodiment, the security SRAM 342 may include other circuits, such as an access control circuit, described further below with respect to FIG. 12, that may be employed to prevent unauthorized access to the security SRAM 342, and may utilize keys or other security measures such as passwords to provide a secure communication interface. Such access control circuits allow data to be loaded into or retrieved from, or not loaded into or retrieved from circuits and applications disposed outside the PLD 208, or resident in the PLD 208. For example, such access control circuits can control data being loaded (i) directly into security SRAM 342 from outside the PLD 208, (ii) from the application running in the PLD 208, generate the data and load it onto the security SRAM 342, or (iii) employ an external process to work with the application in the PLD 208 to load data onto security SRAM 342 (i.e. public key exchange). Such control circuits could operate in a power loss situation or during application loading and/or configuration. In other embodiments, such control circuit may control data retention using (i) a hard switch, such as a fuse, (ii) a soft switch, such as a RAM bit on the PLD 208, and/or (iii) by a memory location inside the security SRAM 342, as described herein.

To ensure that this data is not lost when device power is removed, a backup battery 350 may be used. In this specific example, a battery 350 powers the memory or security SRAM 342 by supplying a voltage VSRB on line 352 with respect to ground on line 354. This battery 350 may be separate from the FPGA 340, or it may be included with the FPGA 340 as part of its packaging. For example, the FPGA 340 may be packaged in a ball grid array package that also includes the battery 350. Alternately, the FPGA 340 and battery may be placed on a common substrate that is then packaged.

The previous activities typically take place at a manufacturing facility, such as an integrated circuit or an original equipment manufacturer's facility. The following activities typically occur once the FPGA 340 is deployed in the field or otherwise used in an application. These activities often take place following a power-up or a power recycle.

FIG. 3B illustrates the decryption of an encrypted bitstream and configuration of an FPGA according to an embodiment of the present invention. This block diagram includes a configuration device 330, FPGA 340, and battery 350. Again, the configuration device 330 may be part of the FPGA 340. The battery 350 powers the security SRAM 342, such that its contents are not lost when the other power supply voltages connected to the FPGA 340 are removed.

Again, the decryption circuitry 344 is typically fixed or hard logic. Optionally, the decryption circuit 344 may be to some degree configurable. For example, the decryption circuitry 344 may include hard logic with additional programmable logic elements, or it may be completely programmable. If the decryption circuitry 344 needs to be configured to some extent, a decryption circuit configuration bitstream is received from the security SRAM 342 as part of the configuration data and parameters 348. If the various parameters of the decryption circuitry 344 are to be programmed, these parameters are received by the decryption circuitry 344 by the security SRAM 342. This information may include the number of rounds of decryption to be used, S-Box entries, permutation settings, and other information. Note that the decryption circuitry 344 needs to be configured before the encrypted configuration bitstream for the rest of the device can be decrypted.

Once the decryption circuitry 344 is configured and any required parameters are received, the key 347 is received from the security SRAM 342. The configuration data for the rest of the circuitry, specifically the EPOF 334, is received by the decryption circuitry 344. The decryption circuitry 344 decrypts the encrypted program object file 334 and generates a decrypted program object file 349, which is then used to configure the other programmable circuitry 346 on the FPGA 340.

FIG. 4A is a flowchart illustrating a method of encrypting a configuration bitstream and storing a key and other parameters in a security RAM according to an embodiment of the present invention. In step 400, a configuration bitstream is generated, for example by using a hardware design program. In step 405, a key is received. Optionally, parameters and configuration information for the decryption circuitry, to the extent they are used, are received in step 410. In step 415, the configuration bitstream is encrypted using the key. This encrypted configuration bitstream can be stored, either on a configuration device or FPGA in step 420.

In step 425, a security RAM is powered with the battery to protect the contents of the security RAM that about to be loaded. In step 430, the key and optional decryption circuit parameters are stored in the security SRAM. At this point, the FPGA, and configuration device if used, can be shipped in step 435 in order be placed into service.

The steps shown in FIG. 4A are typically done at an integrated circuit or original equipment manufacturer's location. The steps in FIG. 4B are typically carried out later, for instance during testing, or once the device is deployed in a user's application.

FIG. 4B is a flowchart illustrating a method of decrypting an encrypted configuration bitstream and configuring an FPGA according to an embodiment of the present invention. Following a power up or other appropriate event, the decryption circuitry parameters and configuration data is received (when used) from the security RAM in step 450. The decryption circuit is configured using the configuration bitstream and parameters received from the security RAM in step 455. In step 460, a key is received from the security RAM by the decryption circuit.

The configuration bitstream, which was previously encrypted, is received from the configuration device or memory locations on the FPGA, in step 465. In step 470, the configuration bitstream is decrypted using the key. In step 475, the FPGA is configured using the newly decrypted configuration bitstream.

FIG. 5 illustrates a method of powering a security RAM according to an embodiment of the present invention. In this particular example, the FPGA 510 is broken into input/output circuitry forming a ring 520, and a core 530, which includes a security SRAM 532, decryption circuitry 534, and other programmable circuitry 536.

In this particular example, the input output circuitry 520, core 530, and security SRAM 532 are powered individually. Specifically, VCCio 540 and GNDio 542 power the I/O ring 520, the FPGA core 530 is powered by VCCint 550 and GNDint 552, while the security SRAM 530 is powered by VCCsrb 560 and GNDsrb 562. It will to be appreciated by one skilled in the art that the more or fewer power supplies connected to different circuitry portions may be used.

FIG. 6 illustrates another method of powering a security RAM according to an embodiment of the present invention. In this figure, as compared to FIG. 5, a power supply switch has been added. Specifically, this figure includes an FPGA 610, which includes an input/output ring, I/O ring 620, and an FPGA core including a security SRAM 632, decryption circuitry 634, other programmable circuitry 636, and the power supply switch 670. In this example, the power supply switch 670 is included on the FPGA 610. In other embodiments of the present invention, the power supply switch 670 may be separate and not included on the FPGA 610.

As before, the I/O ring 620, FPGA core 630, and security SRAM 632 receive separate power supplies. Specifically, the VCCio 640 and GNDio 642 power the I/O ring 620, while the FPGA VCCint 650, and GNDint 662 power core 630.

The security SRAM is powered by the output of the power supply switch 670, which provides VCCsrb 670, and GNDsrb 662. The power supply switch 670, in this example, receives VCCio 640, VCCint 650, and VCCbat 670. VCCbat 660 may be provided by a battery, such as the battery 350 in FIG. 3. The power supply switch 670 selects one of the voltages at its input and provides VCCsrb 672 to the security SRAM 632.

In various embodiments of the present invention, the power supply switch 670 may receive these or other power supplies. In various embodiments, the power supply switch 670 may use different algorithms for selecting which of these power supplies is provided as VCCsrb 672 to the security SRAM 632. Also, the power supplies switch 670 may perform additional functions such as power supply regulation or filtering. That is, the power supply switch 670 may use one or more of the applied input voltages to generate VCCsrb 672, rather than simply connecting a selected applied voltage to the security SRAM 632.

In a specific embodiment, when VCCbat 660 is the only active power supply received by the power supply switch 670, that voltage is used to generate VCCsrb 672. However, if one of the other power supplies received by the power supply switch 670 is active, that is, above a certain voltage threshold, VCCbat 660 is not used such that actual battery life is extended. If more than one other power supply is active, for example both VCCio 640 and VCCint 650 areactive, the quieter of the two supplies, typically VCCint 650, is used to generate VCCsrb 672, though in other embodiments, the noisier supply is used. In another embodiment, if VCCbat 660 is active, that power supply is used by the power supply switch 670 to generate VCCsrb 672.

Again, the security SRAM 632 is typically a volatile memory. Thus, if its power supplies are removed, the contents of the memory are lost. This is useful in applications where the contents of the security SRAM 632 need to be erased quickly due to a tampering or other unauthorized event. When the security SRAM 632 is formed using a volatile memory, such erasure can occur by interrupting the power supply connection to the security SRAM 632.

FIG. 7 illustrates a method of powering a security RAM while utilizing a shutdown switch according to an embodiment of the present invention. This figure includes an FPGA 710 divided into an input/output ring 720 and FPGA core 730. The FPGA core 730 includes a security SRAM 732, decryption circuitry 734, and other programmable circuitry 736. VCCio 740 and GNDio 742 power the I/O ring 720, while VCCint 750 and GNDint 752 power the FPGA core 730

VCCsrb 760 and GNDsrb 762 power the security SRAM. The VCCsrb 760 power supply can be disconnected from the security SRAM 732 by shutdown switch 770. The shutdown switch 770 may be formed on the FPGA 710. Alternately, the shutdown switch 770 may be off-chip. The shutdown switch 770 may be controlled by circuitry that detects a tamper or other unauthorized event.

One such unauthorized event is the loading of an unauthorized configuration bitstream. Accordingly, the configuration bitstream that is used may be verified. If the configuration bitstream is invalid, the power supply to the security SRAM 72 is interrupted and its contents are lost.

The power supply switch 670 in FIG. 6 and the shutdown switch 770 in FIG. 7 may be incorporated into a single unit, shown in FIG. 8 as the power supplies switch 870. The power supply switch 870 selects among different input voltages to provide VCCsrb 872, and also interrupts that power supply when instructed by message authentication code 832.

FIG. 8 illustrates a method of powering a security RAM while utilizing a shutdown switch controlled by a method authentication code according to an embodiment of the present invention. This figure includes an FPGA 810, which includes an I/O ring 820 and FPGA core 830. The FPGA core 830 includes a security SRAM 832, decryption circuitry 834, message authentication code 836, other programmable circuitry 838, and a power supply switch 870.

In this example, VCCio 840 and GNDio 842 power the I/O ring 820, the FPGA core 830 is powered by VCCint 850 and GNDint 852, while VCCsrb 872 and GNDsrb 872 power the security SRAM 832. The power supply switch 870 generates VCCsrb 872. The power supply switch 870, in this example, receives VCCio 840, VCCint 850, and VCCbat 860 as inputs. In embodiments of the present invention, the power supply switch 870 may receive these or other voltages. The power supply switch 870 may select among the received voltages as described above with regards to power supply switch 670.

After the decryption circuitry 834 decrypts the configuration bitstream, the configuration bitstream may be processed by a message authentication code 836, which verifies the configuration bitstream. If the configuration bitstream is invalid, the power supply switch 870 is instructed to remove power from the security SRAM 832. In this way, when an unauthorized configuration bitstream is used, the contents of the security SRAM 832 are lost. On-chip circuitry can track the loss of the contents of the security SRAM and disable the FPGA 810 appropriately.

FIG. 9 illustrates a method of generating a configuration bitstream verification signal to control a power supply shutdown switch according to an embodiment of the present invention. Message authentication code 836 in FIG. 8 may use this method. This configuration bitstream includes a header portion and configuration data. The configuration data is encrypted, while the header portion is not encrypted. Under some circumstances, portions of the header may be well known, or able to be determined. If the header were encoded, this information could lead to discovery of the encryption key. Accordingly, the header is not encrypted. The header portion includes an expected value 906 and a remainder 904. In this example, the portion of the header that is not the expected value 906 is not used.

The encrypted configuration data is received by a function block 910, which performs a function on it. The output 920 is provided to a comparison circuit 930. The comparison circuit compares the expected value 906 to the output on line 922 and makes a determination of validity 940. If the configuration bitstream is invalid, a power supply can be removed from a security RAM, thus erasing its contents.

FIG. 10 is a flowchart illustrating a method of generating a configuration bitstream verification signal to control a security RAM shutdown switch according to an embodiment of the present invention. In step 1010, a header including an expected value is received. In step 1020, encrypted configuration data is received. The header and encrypted configuration data form an encrypted configuration bitstream.

In step 1030, a function is performed on the encrypted configuration data by a function block in order to generate an output. This output is compared to an expected value in step 1040. In step 1050, it is determined whether the expected value received as part of the header matches the output provided by the function block. If there is a match, the bitstream is valid 1060. If there is not a match, the bitstream is invalid 1070.

FIG. 11 illustrates a circuit that may be used as the function block in FIG. 9. The received configuration data is broken up into plaintext portions 1102, 1104, and 1106. The concatenation of these portions results in reassembling the configuration data. The first portion of the configuration data 1102 is encrypted using a key 1112, thus generating an output on line 1114. The output on line 1114 is exclusive-ORed with the second portion of the configuration data 114 by exclusive-OR circuit 1122. The result on line 1124 passes through a number of similar blocks until a final stage is reached. At this point, the cumulative result on line 1126 is exclusive-ORed with configuration data 1106 by exclusive-OR circuit 1122. The output is encrypted by encryption block 1130 and the result is provided to a final encryption stage 1140. Encryption block 1140 provides an output that may be compared to an expected value that is provided as part of a configuration bitstream header. While the encryption functions 1110, 1120, 1130, and 1140 are shown as separate circuits, in practical integrated circuits, these are one circuit.

In various embodiments of the present invention, data may be stored in a security SRAM as encrypted or unencrypted data, or as a combination thereof. The data may be encrypted using AES, DES, or 3-DES. Alternately, other standard or proprietary encryption algorithms may be used.

Again, the data stored in this security SRAM may include keys used for decryption of encrypted configuration bitstreams or other data encrypted data. Other information, such as chip identification data, and other cryptographic data may be stored.

Also, applications running on an FPGA may use a security SRAM to store data in order to protect it from being lost when power is removed or during an application configuration/reconfiguration process. For example, an application may store data in the security SRAM and protect it with an authentication code that is also stored in the security SRAM and protected from erasure when power is removed. Later, when that application needs to recover its data, for example after a power recycle (that is, where power is removed and then restored, or more particularly, where power drops below a threshold before rising above it), the application can access the data using the authentication code. Data stored in this way is typically stored as unencrypted data, since it is only accessible by an application that knows the authorization code, though this data may be stored as encrypted data as well.

Instead of relying on an authorization code, an application may encrypt data before storing it in the security SRAM. This protects the data since an application that accesses this encrypted data without having the correct decryption key cannot properly decrypt the data.

In the above and other embodiments of the present invention, read and write access to the security SRAM may be controlled by an access control circuit. The access control circuit is typically a hard logic circuit, that is, it is pre-wired, though it various embodiments it may be formed by a number of programmable logic elements. Alternately, some of the access control circuit may be hard logic, while portions may be formed using programmable logic elements. For example, in some embodiments a simple version of the access control circuits may be hard logic, while optional additional circuitry, such as an encoder/decoder circuit, may be formed using programmable logic elements.

Typically, read access is limited, while write accesses are not, though write access may also be limited in various embodiments of the present invention. Read access is typically limited to a lesser degree since the power to the security SRAM can be removed, thereby erasing its contents.

The access control circuit can be used to limit access to data in the security SRAM by applications running in the programmable logic elements or by outside users or applications. Typically however, the access control circuit is either bypassed or automatically allows access by an on-chip configuration controller, though access by this circuit may also be limited. Examples of configuration controllers accessing data in a security SRAM, specifically a decryption key used to decrypt an encrypted bitstream, are shown in the following three figures.

FIG. 12 illustrates exemplary data transfers between a configuration controller, an access control circuit, and security SRAM during the configuration of an FPGA. In this example, the key to be used to decrypt the encrypted bitstream, key 1242, is stored as unencrypted data. This figure includes an FPGA 1210 that further includes an I/O ring 1220 and an FPGA core 1230. The FPGA core 1230 includes a security SRAM 1240, programmable logic elements 1250, configuration controller 1260, and access control circuit 1270.

In this example, the configuration controller 1260 requests the key 1242 from the access control circuit. Since the configuration controller 1260 is a known hard logic circuit, the access control circuit 1270 does not require specific authorization from the configuration controller 1260, though in other embodiments of the present invention, such authorization may be required. Accordingly, the access control circuit 1270 reads the key 1242 from the security of SRAM 1240. The access control circuit 1270 then provides the key to the configuration controller 1260. The configuration controller 1260 receives the encrypted configuration bitstream and decrypts the encrypted configuration bitstream. The FPGA is then configured using the decrypted configuration bitstream.

Again, in various embodiments of the present invention, the access control circuit 1270 may limit access to the security SRAM 1240 by the configuration controller 1260. Typically this is not done since the configuration controller 1260 is a hard logic circuit that is pre-wired on the FPGA and not subject to surreptitious reconfiguration. Accordingly, the configuration controller 1260 may either be granted automatic access by the access control circuit 1270, or it may be connected directly to the security SRAM 1240. Flowcharts illustrating these last two methods are shown in the following two figures.

FIG. 13A is a flowchart illustrating the operation of an FPGA where a configuration controller is granted automatic access by an access control circuit to a decryption key stored in a security SRAM.

Specifically, in step 1310, a configuration controller requests a key from an access control circuit. The access control circuit reads the key from a security SRAM in step 1320. The access control circuit provides the key to the configuration controller in step 1330. In step 1340, the configuration controller receives an encrypted bitstream. The configuration controller then decrypts the encrypted bitstream using the key and configures the FPGA.

FIG. 13B is a flowchart illustrating the operation of an FPGA where are a configuration controller is directly connected or can bypass the access control circuit. In step 1360, the configuration controller receives a key from the security SRAM. The configuration controller receives an encrypted bitstream in step 1370, and decrypts the bitstream and configures the FPGA in step 1380.

Again, applications running and/or upon configuration/reconfiguration or installation, in the programmable logic circuitry can protect data from erasure by storing it in the battery backed-up security SRAM. The stored data is protected and isolated from external conditions affecting the programmable logic circuitry. For example, if power is removed from the FPGA, the application can recover the data once power is restored. An application may protect this data by encrypting it before storing it in the security SRAM. Alternately, it may store an authorization code in memory along with the data. When the application attempts to recover the data, it provides the location of the data and the authorization code to the access control circuit. If the correct authorization code is given, the access control circuit provides the data to the application. Examples of how this can be implemented are shown in the following two figures.

FIG. 14 illustrates exemplary transfers of data in an FPGA where access to data in a memory is limited by requiring an authorization code. This figure includes an FPGA 1410, including an I/O ring 1420 and an FPGA core 1430. The FPGA core 1430 includes a security SRAM 1440, programmable logic elements 1450, configuration controller 1460, and access control circuit 1470.

In this example, an FPGA running in the programmable logic 1450 has previously stored data and a corresponding authorization code 1442 in the security SRAM 1440. To recover this data, any number of methods may be employed to validate access, for example, passwords, etc. In one embodiment, the application provides the address of the data and authorization code to the access control circuit. The access control circuit verifies the authorization code provided by the application. For example, the access control circuit may do a bit-by-bit match, or employ a function associated with the authorization code provided by the application with the authorization code 1442 stored in the security SRAM 1440. If the codes match or function relationship established, the access control circuit allows access to the data by the application. If there is a mismatch, access is denied which may be indicated using a variety of techniques without necessarily returning incorrect data.

FIG. 15 is a flowchart illustrating a method of limiting read access to data in a security SRAM by requiring an authorization code. In this example, the application has previously stored data and an authorization code in the security SRAM. Again, this write access is typically not limited, though in various embodiments of the present invention this access may be limited as well. For example, the access control circuit may require the authorization code to overwrite data that has been previously protected with the code.

Specifically, in step 1510, an application provides an address for data and an authorization code to an access circuit. In step 1520, the access circuit compares the authorization code with an authorization code stored in the security SRAM. Typically, the authorization code stored in a security SRAM was stored by the application, though other circuits, such as the access control circuit, may generate an authorization code, which is then stored in a security SRAM and given to the application for future use. In step 1530, if the codes match, the access control circuit grants access to the data, otherwise access is denied.

In the above examples, data is typically stored as unencrypted data. However, as discussed above, data may also be stored as encrypted data. For example, a decryption key used to decrypt an encrypted bitstream may itself be encrypted using a second key. This second key may be stored as unencrypted data, or it may be encrypted using yet another key. In the following example, a decryption key is encrypted using a second key, which is stored as unencrypted data.

FIG. 16A is a flowchart illustrating a method of storing decryption keys where a decryption key is encrypted using a second key and both keys are stored in a security SRAM. In this example, an access control circuit is responsible for decrypting the decryption key. This has the advantage as not requiring the configuration controller to know how the decryption key is stored in memory, that is, the configuration controller does not need to know whether the decryption key is stored as encrypted or unencrypted data.

Specifically, in step 1610, a configuration controller requests a decryption key stored in a security SRAM. An access control circuit reads an encrypted decryption key and a second, unencrypted key from the security SRAM in step 1615. In step 1620, the access control circuit decrypts the encrypted decryption key using the second key and provides the decryption key to the configuration controller. In step 1625, the configuration controller receives an encrypted bitstream, and in step 1630, the configuration controller decrypts the encrypted configuration bitstream and configures the FPGA using the decrypted configuration bitstream.

FIG. 16B is another flowchart illustrating a method of storing decryption keys where a decryption key is encrypted using a second key, and both keys are stored in a security SRAM. In this example, the configuration controller is responsible for decrypting the decryption key.

Specifically, in step 1650, the configuration controller requests the decryption key. In step 1655, the access control circuit reads the encrypted decryption key and unencrypted second key from memory and provides them to the configuration controller. The configuration controller decrypts the encrypted decryption key using the second key in step 1660. In step 1665, the configuration controller receives an encrypted configuration bitstream. The encrypted configuration bitstream is decrypted using the decryption key, and in step 1670, the FPGA is configured.

Again, applications may also store encrypted data in the security SRAM. While an authorization code may be required to access this encrypted data, such authorization is typically not required since only an application having the correct decryption key can utilize the data. (Again however, various embodiments of the present invention may require some sort of authorization to overwrite previously written data.) Examples illustrating applications storing encrypted data in a security SRAM are shown in the following three figures.

FIG. 17 illustrates an exemplary dataflow in a device where an application has protected data in a security SRAM through encryption. This figure includes an FPGA 1710 that further includes an I/O ring 1720 and an FPGA core 1730. The FPGA core 1730 includes a security SRAM 1740, programmable logic elements 1750, configuration controller 1760, and access control circuit 1770. In this example, an application running in the programmable logic 1750 has previously stored encrypted data 1742 in the security SRAM 1740, for example before a power recycle, and now the application needs to recover the stored data. The data may have been encrypted by the application itself or by they access control circuit 1770.

The application provides an address for the encrypted data 1742 to the access control circuit 1770. The access control circuit reads the encrypted data 1742 and provides it to the application. The application then decrypts the data using its key. Only an application having the correct key can make use of the encrypted data, otherwise the data is useless.

While in this embodiment the decryption is done by the application itself, in other embodiments the decryption may be done by the access control circuit. For example, this may be useful where the access control circuit encrypts data using a key, and then provides the key to the application for further use. Examples are shown in the following flowcharts.

FIG. 18A is a flowchart illustrating a method of receiving encrypted data stored in a security SRAM. In this example, an access control circuit decrypts data for an application. The encrypted data may have been originally encrypted by either the application or the access control circuit, depending on the exact implementation.

Specifically, in step 1810, an application provides an address of encrypted data and the key to the access control circuit. In step 1820, the access control circuit reads the encrypted data from the security SRAM. In step 1830, the access control circuit decrypts the encrypted data and provides the decrypted data to the application. Again, this data is useful only if the correct key was given to the access control circuit by the application.

FIG. 18B is another flowchart illustrating a method of receiving encrypted in data stored in a security SRAM. In this example, the application itself is responsible for decrypting data.

Specifically, in step 1850, the application gives an address for the encrypted data to the access control circuit. In step 1860, the access control circuit reads the encrypted data from a security SRAM. In step 1870, the access control circuit provides the encrypted data to the application. The application decrypts the data using its key in step 1880. Again, this data is only useful if the application uses the correct decryption key.

In one embodiment, for flexible use the security SRAM may be partitioned with no access control, partitioned to include an access control area plus a data storage area where the data storage area may be further partitioned into protected areas. To further protect the data stored in security SRAM, is by write protecting the access control section. There are a plurality of write protection schemes that may be employed such as one-time write where once a memory location has been written to it cannot be overwritten.

FIG. 19 is a block diagram of an exemplary FPGA 1910 in accordance with some embodiments. FPGA 1910 includes I/O Ring 1920 and FPGA Core 1930. FPGA Core 1930 includes programmable circuitry 1950 with multiple independently reconfigurable regions 1952 and 1954, a configuration controller 1960, an access control circuit 1970, and multiple security SRAMs 1940, 1944 and 1946. The description below describes certain functionality of configuration controller 1960, but it should be understood that some or all of this functionality may be implemented in access control 1970. Indeed, in some embodiments, configuration controller 1960 and access control 1970 may be the same module. In other embodiments, each of SRAMs 1940, 1944 and 1946 has its own dedicated access controller.

In various embodiments, the configuration controller 1960 is configured to partition the one or more memory blocks 1940, 1944, 1946 to allocate different memory partitions to the multiple independently reconfigurable regions (e.g., regions 1952 and 1954). FIG. 19 shows partitions 1941 and 1942 as examples. It should be understood, however, that any number of partitions may be allocated, and that the memory locations allocated to each partition may vary in terms of physical location in the memory. In some embodiments, the configuration controller is also configured to control access to the memory block, e.g., through access controller 1970. For instance, the configuration controller may be configured to prevent all or certain ones of the independently reconfigurable regions from accessing a memory partition which has been allocated to another independently reconfigurable region. This access restriction may apply to read access, write access, or both, and may vary depending on the independently reconfigurable region requesting access.

In one illustrative embodiment, FPGA 1910 includes n memory blocks (e.g., memories 1940, 1944, and 1946) and m independently reconfigurable regions (e.g., including regions 1952 and 1954), where m>n. The configuration controller 1960 may be configured to partition the n memory blocks over the m independently reconfigurable regions, e.g., so that each of the m independently reconfigurable regions is allocated a memory partition on one or more of the n memory blocks. The partitions may be of any suitable size. The configuration controller 1960 may also be configured to control access to each of the n memory blocks (e.g., alone or in combination with access controller 1970) to prevent any given one of the m independently reconfigurable regions from accessing memory partitions allocated to another one of the m independently reconfigurable regions.

In some embodiments, the partitioning is fixed; in others, the partitioning can be set on first configuration of the FPGA. There may also be default partitioning, which could optionally be overwritten by the first configuration. Partition information including a start and stop address, and/or memory size, for each configurable region may be stored, e.g., as part of the start up data, first configuration data, or default data. In one approach, each configurable region may be allocated a contiguous memory space that sequentially follows the memory space allocated to the immediately preceding configurable region, thereby obviating the need for storing start and stop addresses (memory size may be a fixed or default value and/or memory size may be stored after allocation).

In various embodiments, the configuration controller 1960 is configured to determine whether a independently reconfigurable region should be granted access to a memory partition allocated to a different region. This determination may be made, for example, based on a bit set on first configuration. In response to the determination, the configuration controller 1960 may then control access to the memory block to allow the first independently reconfigurable region to access the memory partition, or to deny the request. The configuration controller 1960 may also determine, based on the stored bit, whether the independently reconfigurable region should be granted read access and write access to the memory partition. In response to a read-only determination, the configuration controller 1960 may control access to the memory block to allow the independently reconfigurable region to read data stored in the memory partition and to prevent the region writing data to the memory partition. In response to a write-only determination, the configuration controller 1960 may control access to the memory block to allow the independently reconfigurable region to write data to the memory partition and to prevent the region reading data from the memory partition. Finally, in response to a read and write determination, the configuration controller 1960 may control access to the memory block to allow the independently reconfigurable region to both read data from and write data to the memory partition. Of course, it should be understood that different configurable regions may have different privileges to access memory partitions, and that those privileges may vary on a partition to partition basis.

The configuration controller 1960 may control access to memory blocks and their partitions using one or more access control techniques. In one approach, FPGA 1910 is designed so that all memory accesses must go through configuration controller 1960. That is, FPGA 1910 may be designed in a manner that requires requests to access the memory be provided to the configuration controller, and the configuration controller communicates with the memory on behalf of the requestor (e.g., an independently reconfigurable region). This can be accomplished, for example, by ensuring (through fixed design or by programming configurable interconnects) that the independently configurable regions are not provided with any direct connections to the memory block(s). The configuration controller, in such a scenario, would only complete requests (e.g., by forwarding the request on to the memory or to the particular memory partition) that it determines to be authorized. The configuration controller may be automatically authorized to read and/or write data from any partition of the memory block(s).

In another approach, the independently configurable regions may be provided with direct connections to the memory blocks (e.g., through communication path 1972 and, optionally, access control 1970), but the data stored in the memory partitions are encrypted. In such a scenario, the configuration controller may limit access to memory partitions by decrypting data only when it determines a memory request to be authorized.

Any other suitable approach may be used to control access to memory blocks and their partitions and, in some embodiments, a combination of these approaches may be implemented. Additionally, these access control features may be implemented to control only read access requests, write access requests, or both. In yet other embodiments, access control may be achieved without using a configuration controller, e.g., by encrypting the data and/or storing MACs with the data as described above and further below.

In some embodiments, each memory partition stores multiple message authentication codes, e.g., generated using a message authentication code (MAC) generator (e.g., as shown in FIG. 11). When a configuration stream is received by the configuration controller 1960, a MAC may be generated and compared to the stored MACs to determine if the generated MAC matches any of the stored MACs. If configuration controller 1960 determines a match, it may grant access to the memory partition storing the matching MAC. Otherwise, configuration controller 1960 may deny access.

In some embodiments, configuration controller 1960 is configured to overwrite all data stored in a memory partition with zero values in response to determining that an unauthorized independently reconfigurable region is attempting to access the memory partition. In other embodiments, the data is erased by cutting power to the memory block containing the targeted memory partition, as described above.

In some embodiments, once the first configuration allocates the memory partitions and MAC codes, they cannot be changed through any authorized function. If the controller detects that the memory partitions or MAC codes have changed, then it will erase all data on the device. This will prevent an attacker from trying to gain control of the device using the configuration block. Alternately, a first configuration may include setting of some fuse bits or other non-volatile memory which can define partition access or MAC codes.

In various embodiments, a message authentication code (MAC) generator is configured to input a received configuration stream and output a generated message authentication code. The MAC generator may be implemented as hard logic, soft logic, or a combination of hard logic and soft logic. In one approach, the MAC generator may include a Galois field (GF) multiplier implemented in soft logic (e.g., the FPGA fabric). For example, modified soft logic DSP blocks can be used to implement these GF multipliers. The DSP blocks can support, for instance, a finite field reduction of a GF expansion, as discussed in U.S. patent application Ser. No. 14/524,526, filed Oct. 27, 2014, hereby incorporated by reference herein in its entirety.

The MAC generator may retrieve one of a plurality of keys from one or more of the memory blocks for use in generating message authentication codes. Alternatively, a key may be embedded in a soft logic portion of the MAC generator during a first configuration of the programmable circuitry.

In some embodiments, a single reconfigurable region may be allocated partitions on multiple memory blocks. For example, one partition may store encryption keys and MACs and another may store backed up data. Multiple memory blocks may be used to securely back up data. As another example, a memory block may not be sufficient to store all data required by a reconfigurable region, and so it may be allocated one or more partitions on one or more other memory blocks.

FIG. 20 is a flowchart illustrating a method of controlling memory access in an FPGA having multiple memory blocks and independently reconfigurable regions in accordance with some embodiments. In step 2002, n memory blocks are partitioned over m independently reconfigurable regions, e.g., at first configuration. At step 2004, a plurality of MACs may be stored in one or more of the memory partitions, e.g., at first configuration or when data is later stored in a memory block by an authorized region. At step 2006, a MAC is generated for a received configuration stream, e.g., by another region. At step 2008, the generated MAC is compared with each of the stored MACs and, at step 2010, the process determines whether the generated MAC matched any of the stored MACs. If so, memory access is granted at step 2012. If there are no matches, memory access is denied at step 2014.

The above description of exemplary embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form described, and many modifications and variations are possible in light of the teaching above. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications to thereby enable others skilled in the art to best utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated.

Claims

1. An apparatus for storing data, the apparatus comprising:

programmable circuitry including first and second independently reconfigurable regions;

a memory block configured to store data; and

a configuration controller configured to: partition the memory block to allocate a first memory partition to the first independently reconfigurable region and a second memory partition to the second independently reconfigurable region; receive requests from the first and second independently reconfigurable regions to access the memory block; and control access to the memory block to prevent the first independently reconfigurable region from accessing the second memory partition and to prevent the second independently reconfigurable region from accessing the first memory partition.

2. The apparatus of claim 1, wherein the configuration controller is further configured to:

determine whether to the first independently reconfigurable region should be granted access to the second memory partition based on a stored bit; and

control access to the memory block to allow the first independently reconfigurable region to access the second memory partition in response to determining that the first independently reconfigurable region should be granted access to the second memory partition;

wherein the configuration controller is configured to control access to the memory block to prevent the first independently reconfigurable region from accessing the second memory partition in response to determining that the first independently reconfigurable region should not be granted access to the second memory partition.

3. The apparatus of claim 2, wherein the configuration controller is further configured to:

determine, based on the stored bit, whether the first independently reconfigurable region should be granted read access and write access to the second memory partition;

in response to a read-only determination, control access to the memory block to allow the first independently reconfigurable region to read data stored in the second memory partition and to prevent the first independently reconfigurable region writing data to the second memory partition;

in response to a write-only determination, control access to the memory block to allow the first independently reconfigurable region to write data to the second memory partition and to prevent the first independently reconfigurable region reading data from the second memory partition; and

in response to a read and write determination, control access to the memory block to allow the first independently reconfigurable region to both read data from and write data to the second memory partition.

4. The apparatus of claim 1 further comprising n memory blocks and m independently reconfigurable regions, where m>n, wherein the configuration controller is further configured to:

partition the n memory blocks over m independently reconfigurable regions; and

control access to the n memory blocks to prevent any given one of the m independently reconfigurable regions from accessing memory partitions allocated to another one of the m independently reconfigurable regions.

5. The apparatus of claim 4, wherein the memory block is partitioned at the first configuration.

6. The apparatus of claim 4, wherein each memory partition stores multiple message authentication codes.

7. The apparatus of claim 6, wherein the configuration controller is further configured to:

generate a message authentication code for a received configuration stream;

compare the generated message authentication code with each of the stored message authentication codes; and

determine that the received configuration stream is an authorized configuration stream when any of the stored message authentication codes match the generated message authentication code.

8. The apparatus of claim 7, wherein the apparatus further comprises:

a message authentication code (MAC) generator configured to input the received configuration stream and output the generated message authentication code, wherein the MAC generator is implemented as a combination of hard logic and soft logic.

9. The apparatus of claim 8, wherein the MAC generator retrieves one of a plurality of keys from the memory block for use in generating message authentication codes.

10. The apparatus of claim 8, wherein a key is embedded in a soft logic portion of the MAC generator during a first configuration of the programmable circuitry, and wherein the key is used for generating message authentication codes.

11. The apparatus of claim 1, wherein the configuration controller is further configured to overwrite all data stored in the second memory partition with zero values in response to determining that the first independently reconfigurable region is attempting to access the second memory partition.

12. The apparatus of claim 1 further comprising an encryption circuit, wherein the encryption circuit is configured to decrypt data stored in a given memory partition in response to the configuration controller determining an authorized access request.

13. The apparatus of claim 1, wherein the configuration controller is automatically authorized to read data from any partition of the memory block.

14. An apparatus for storing data, the apparatus comprising:

programmable circuitry including m independently reconfigurable regions;

n memory blocks for storing data, where m>n;

a message authentication code (MAC) generator configured to generate a message authentication code for a received configuration stream; and

a configuration controller configured to: partition the n memory blocks over m independently reconfigurable regions; store a plurality of message authentication codes in at least one of the memory partitions; compare the generated message authentication code with each of the stored plurality of message authentication codes; and determine that the received configuration stream is an authorized configuration stream when any of the stored plurality of message authentication codes match the generated message authentication code

15. The apparatus of claim 14, wherein the MAC generator is further configured to retrieve at least one of a plurality of keys from the n memory blocks for use in generating message authentication codes.

16. The apparatus of claim 14, wherein the configuration controller is further configured to:

control access to the n memory blocks to prevent at least one of the m independently reconfigurable regions from accessing a memory partition allocated to another one of the m independently reconfigurable regions.

17. A method of controlling memory access in a field programmable gate array (FPGA) having n memory blocks and m independently reconfigurable regions, the method comprising:

partitioning the n memory blocks over the m independently reconfigurable regions;

storing a plurality of message authentication codes in at least one of the memory partitions;

generating a message authentication code for a received configuration stream;

comparing the generated message authentication code with each of the stored plurality of message authentication codes; and

determining that the received configuration stream is an authorized configuration stream when any of the stored plurality of message authentication codes match the generated message authentication code.

18. The method of claim 17 further comprising:

retrieving at least one of a plurality of keys from the n memory blocks for use in generating the message authentication code.

19. The method of claim 17 further comprising:

controlling access to the n memory blocks to prevent at least one of the m independently reconfigurable regions from accessing a memory partition allocated to another one of the m independently reconfigurable regions.

20. The method of claim 19 further comprising:

controlling access to the n memory blocks to prevent any of the m independently reconfigurable regions from accessing a memory partition allocated to another one of the m independently reconfigurable regions.