Patent Application
20050055671
The present invention relates to integrated circuit manufacturing, and more particularly to distribution of circuit programming items.
Wireless communication systems, such as the Bluetooth standard, allow portable electronic devices to locally interact. However, to be distinguishable among multiple devices capable of receiving a transmission, each device typically has a unique identification number hardwired into its transceiver integrated circuits. Thus as part of the manufacturing process, an inventory of identification numbers must be available to be programmed into the integrated circuits. For Bluetooth, identification numbers are 48 bits long and blocks of 1 M identification numbers can be purchased from organizations such as the IEEE.
Analogously, other systems require unique identification numbers such as integrated circuits with high-definition content protection (HDCP). Manufacturers typically program these identification numbers at the time of circuit testing (wafer probe or package test) and the programming involves electrically blowing fuses within the circuit or programming an EEPROM. Thus identification numbers should be readily available at any of possibly multiple testing sites with multiple testers at each site.
Additionally, an integrated circuit manufacturer's various customers (device vendors) may want their integrated circuits programmed with customer keys such as customer (or user) identifications and security features such as keys for DES and RC4 encryption systems. Customer keys are stored for use in integrated circuit manufacturing, although DES and RC4 keys typically are encrypted for secure storage and need to be decrypted at time of programming.
A single integrated circuit manufacturer with multiple testing sites and, possibly, with affiliated foundry manufacturers for the same products will thus have a problem of management and distribution for integrated circuit programming of unique identification numbers and customer keys required by multiple customers.
The present invention provides a hierarchical distribution system for integrated circuit programming items.
Preferred embodiment methods provide for distribution of items, such as blocks of identification numbers, for programming integrated circuits as part of circuit testing.
A first preferred embodiment method provides distribution of identification numbers (IDs) used in the Bluetooth wireless standard plus additional items, such as customer identifications and encryption keys, for an integrated circuit manufacturer which makes multiple products for various customers and, additionally, has contracted some work out to one or more foundries. Each pertinent site has multiple (e.g., 100) automatic testers for electrically testing each circuit (still in wafer form or already packaged), and these testers are also capable of electrically blowing fuses in circuits under test to program various items, from IDs to activation of redundant circuitry, during the testing. The contract foundries would have similar setups. Each tester runs various software tools (e.g., tester automation and data collection) so its operator can set the tester to automatically test each circuit, record test results, program (blow fuses) IDs for circuits which had tested as good, and so forth.
The operational database for a site (including a foundry's site) acquires Bluetooth IDs from a master database in blocks of size 128K. And the master database has Bluetooth IDs stored in blocks of size 1 M; see
The preferred embodiment methods may waste Bluetooth IDs if the key handler task is shut down. However, by not recycling unused IDs from the tester level, this allows for a robust system which will minimize the chance of duplicate IDs being used for two different circuits.
The system of
Next, an operational database at a testing site pulls one 128K block of IDs from the master database, and the corresponding entry (e.g., 0×0800E7340000) in the master database inventory is updated as “allocated” to the operational database which requested it. This pulling of a 128K block can be triggered by the inventory of available IDs at the operational database dropping to near-empty (low water mark). The operational database divides the block of 128K IDs into blocks of size 128 (0×80). Thus the inventory addition from the 128K block would initially be 0×0800E7340000, 0×0800E7340080, 0×0800E7340100, . . . , 0×0800E735FF80; a total of 1K entries. The site operational database is locally connected to the site testers, and the individual testers will pull a block of 128 IDs from the operational database as needed. This hierarchical ID storage has the following benefits:
Reduces storage requirements.
Reduces load on the databases and network.
Further minimizes the chance that an ID will be used twice.
Allows histories of the used IDs to be kept for a longer time period. The distribution of Customer Keys, such as customer identification, encryption keys, and so forth can likewise be distributed with a master database, site operational databases, and the testers programming the information. The following section has implementation details for a typical system.
a. Web Interface
The web interface could be an application that can be accessed by anyone entering a valid user identification and password. In order to update the values in the Bluetooth table or the Customer Key table, the user identification must be in a list of authorized users.
The web form will enable a business unit engineer to load new Bluetooth IDs and customer/device-specific public and private keys, and to view current key status (e.g., available/allocated). Bluetooth IDs are entered in a range, same as that given by the IEEE: for example IDs in the range 080028800000-080288FFFFF. Bluetooth IDs are stored in blocks of 128K (0×20000). Only the beginning block address is stored in the master database.
The web interface tool will verify that IDs being entered do not duplicate IDs already stored in the master database. It will also verify that the range of IDs being entered is evenly divisible by 0×20000.
Customer IDs, public keys and other key types can be loaded and/or modified using the web interface tool. Public keys are encrypted by the tool before they are stored in the master database.
The low water mark for Bluetooth IDs is set by the user using the web interface. When this mark is reached, the master database notifies the escalation list that IDs are running low and need to be replenished. One week leadtime is typically needed for getting additional IDs from the IEEE, so the low water mark should be set accordingly.
b. Master and Operational Databases
The master database holds Bluetooth IDs in blocks of 128K. The operational database pulls one or more blocks from the master database whenever a low water mark is reached. The operational database breaks up one 128K block into smaller blocks of 128 IDs. The operational database will tell the master database which site pulled the IDs for tracking purposes and keep them in a history table.
Customer keys are automatically pulled from the master database when requested; no push operation from the master database is required. If a new customer key is entered into the master database, it will be allocated to a local operational database when a tester requests it.
A stored procedure on the operational database is used by the key handler (from a tester, see below) to grab the starting address of a block of 128 Bluetooth IDs. This stored procedure updates the table containing available IDs. It will also update a history table to show which testers are being allocated the IDs. A table-level lock is made when a block is requested, guaranteeing that multiple key handlers hitting the same table will not get a duplicate block of IDs.
Tables for the master database include a table for authorized users, a table for available and allocated Bluetooth IDs and a table for current customer keys. The Bluetooth ID tables:
The tables for the operational database include a table for available Bluetooth IDs, a table for allocated Bluetooth IDs and a table for current customer keys. A stored procedure allows the key handler task to easily pull one block of Bluetooth IDs; the procedure will take care of locking the “available” table, getting the next ID, and then it to the “allocated” table.
c. Key Handler
Key handler is a daemon task running a tester. Key handler will not connect to the operational database or grab any Bluetooth IDs until the first request by the test program. Key handler connects and disconnects to the operational database as needed. It does not remain connected while in an idle state. The test program can request one or more Bluetooth IDs, which key handler requests from the operational database and returns to test program. Key handler will pull one block of 128 IDs from the operational database and keep it as cache. This way the test program can request one ID at a time without having the key handler hit the operational database every time. Also, the IDs are not recycled (unused IDs are not returned to the operational database), so uniqueness is guaranteed at the expense of discarding unused IDs in the blocks of 128.
If a customer public key is requested by the test program, the key handler will get it from the operational database, decrypt it, and then pass it back to the test program.
d. Test Program
The test program talks to the key handler task through a pair of named pipes or through a socket using a predefined set of ASCII messages. For example, the pipe names could be /tmp/twkey_in for the input pipe to send messages to the key handler and /tmp/twkey_out for the output pipe to receive messages from the key handler. A predefined set of messages types are available. KEY_REQUEST message: get a key from a particular key type (public key, customer ID, etc.) and a key ID (device name, system item ID, etc.); and BT_REQUEST message: get one or more Bluetooth IDs. All messages to key handler are responded to with an acknowledge ACK or a not acknowledge NAK, along with additional information. Note that in ASCII “ACK” is taken to be 0×06 and “NAK” is 0×15.
A NAK response message will include a reason. For example, the response could be one of:
NAK could not connect to database ebtopdb.
NAK quantity of Bluetooth IDs requested is not available.
NAK could not get PUBLIC_KEY for KEY_ID=XYZ: invalid KEY_ID name.
An example message exchange for a KEY_REQUEST is:
test program:
key handler:
If a Bluetooth ID is needed, the test program can request one ID, which key handler will return to it. The test program can also request a number of IDs, such as a full block of 128, which the key handler will return to it as a range.
If a customer key is needed, the test program will request it by a KEY_TYPE=CUSTOMER_KEY and a KEY_ID, which the key handler will request from the operational database and return to the test program. The customer key is the same for all circuits in a lot, so the test program will only need to request it once at the beginning of the lot.
If a public key is needed (or any other key that is encrypted in the operational database), the key handler will decrypt it before giving it to the test program.
If the key handler cannot get the required number of Bluetooth IDs or a customer key, it will return a NAK to the test program.
The preferred embodiments may be varied while retaining the hierarchical distribution feature. For example, the block sizes in the master database, operational databases, and testers could be varied such as block sizes 64 or 256 in a tester, 64K or 256K in an operational database, and so forth.
The application claims priority from provisional patent application No. 60/500,727, filed Sep. 5, 2003.
| Number | Date | Country | |
|---|---|---|---|
| 60500727 | Sep 2003 | US |
