Chapter 11. Using MAX II User Flash Memory for Data Storage in Manufacturing Flow

Transcription

1 Chapter 11. Using MAX II User Flash Memory for Data Storage in Manufacturing Flow MII Introduction Small capacity, non-volatile memory is commonly used in storing manufacturing data (e.g., manufacturer s IDs, serial numbers). This data is important in differentiating products, inventory referencing, and storing test results during manufacturing. The MAX II user flash memory (UFM) is ideal for storing manufacturing data instead of using a separate low-density, non-volatile memory device. This solution creates a low-cost, portable medium for storing and controlling access to information. You can read and write manufacturing data using the IEEE Std Joint Test Action Group (JTAG) interface. Using the MAX II UFM block for data storage in manufacturing does not require additional I/O other than the JTAG pins. However, the UFM is not limited to specific standard interface protocols (you can implement any interface protocol in the programmable logic array of a MAX II device) to communicate with the UFM block. Integrating board-level flash memory, EEPROM capabilities, and system logic into one MAX II device improves the board space efficiency and minimizes system cost. This chapter provides guidelines in utilizing the MAX II UFM for manufacturing data storage, including programming and reading stored data from the UFM block. f For more information on the MAX II UFM features, refer to Chapter 10, Using User Flash Memory in MAX II Devices. Manufacturing Data Manufacturing data is a type of non-volatile information used to uniquely identify a device or chipset on the board. The variety of manufacturing data that is commonly stored in small-capacity, nonvolatile memory devices include: Product ID or Product Name Manufacturer s ID Serial or Part Numbers Manufacturing Date or Lot Codes Hardware Revision All other Related Product and Manufacturers Information Manufacturer Test Counts and Results Altera Corporation Core Version a.b.c variable 11 1 March 2004 Preliminary

2 Storing Manufacturing Data in the UFM Manufacturing date or lot codes are used to identify when a board was manufactured. Placing a manufacturer s lot code or a manufacturing date on the board makes future tracking easier. Manufacturing data storage on products is also important in organizing the inventory system. Manufacturing data is typically represented in ASCII text. Refer to Appendix A, ASCII Code Table for the standard characters in ASCII format. Storing Manufacturing Data in the UFM Figure 11 1 shows the flow for writing manufacturing data to the UFM. Every manufacturing data storage flow should start with determining the constant data for UFM and the design function. Choosing the right standard interface protocol to access the UFM block is important to be compatible with the entire board design and to simplify the data read flow. The initial memory content file which consists of the constant data is created in either Hexadecimal (.hex) format or in Memory Initialization File (.mif) format. You can develop the interface between the UFM block and other devices on the board using the MegaWizard Plug-In Manager in the Quartus II software. The initial memory content file is then included using the altufm megafunction of the MegaWizard Plug-In Manager. You can then generate different types of programming files including Programmer Object File (.pof) and Jam Standard Test and Programming Language (STAPL) Files (.jam) using the Quartus II assembler. You can program the UFM block either using the Quartus II Programmer (.pof,.jam) or using the Jam Player (.jam). Dynamic manufacturing data (which is the information that will change such as a lot code, date codes, and manufacturing test result data) is produced in HEX format only during board testing. Recompiling the project and also regenerating a new programming file to include all the static and dynamic data in the Quartus II software is impractical in test environments. Therefore, you can convert the HEX file into a Jam file using the UFM HEX to Jam Utility. You can use this Jam file with the incircuit tester to program or update the UFM. However, during this stage of updating the UFM with the dynamic manufacturing data, it can overwrite the existing constant data. To retain the constant data, you can take advantage on the UFM which is organized into two separate sectors, and program the constant manufacturing data into one sector of the UFM during the compilation flow. Subsequently, in the board testing stage, you can then program the dynamic manufacturing data into the other sector of the UFM Core Version a.b.c variable Altera Corporation MAX II Device Handbook, Volume 1 March 2004

3 Using MAX II User Flash Memory for Data Storage in Manufacturing Flow f Refer to Data Storage Using the JTAG Interface on page 11 5 for more information on programming the UFM block through the JTAG port. Refer to Chapter 10, Using User Flash Memory in MAX II Devices for details on using the altufm megafunction. Altera Corporation Core Version a.b.c variable 11 3 March 2004 MAX II Device Handbook, Volume 1

4 Storing Manufacturing Data in the UFM Figure Data Storage Flow Chart Start Determine Constant Data for UFM Create Initial Memory Initialization File (.hex/.mif) Interface Development with MegaWizard Plug-In Manager Quartus II Environment Compilation of the Complete Design for MAX II Devices Quartus II Assembler.pof/.jam Programming Files Program Device Test Board and Determine Dynamic Manufacturing Data HEX UFM HEX to Jam Utility Jam Update UFM Sector 0 Update UFM Sector Core Version a.b.c variable Altera Corporation MAX II Device Handbook, Volume 1 March 2004

5 Using MAX II User Flash Memory for Data Storage in Manufacturing Flow Reading Manufacturing Data from UFM Accessing manufacturing data from the MAX II UFM block starts with determining the data needed to be read. You can read the manufacturing data from the UFM block in two ways: You can read the entire contents of sector 0 and/or sector 1 of the UFM block through the JTAG port using the Jam Player; or you can access the UFM contents through the MAX II device I/O pins that are assigned as the interface signals, where the interface between the UFM block and the other devices was developed earlier in the Quartus II software. Tracking the UFM address where the specific data is located is important for accessing the correct data. After obtaining this data, you can then display it on any user interface (such as a monitor or LCD, or save it to a file through the manufacturing software). See Figure Figure Reading Storage Flow Chart Start Determine Data to Read Yes Accessing Through the JTAG Port No Jam Player Data Location (Address) Read UFM Sector 0 Access Data Through Interface Port Read UFM Sector 1 Display Data Altera Corporation Core Version a.b.c variable 11 5 March 2004 MAX II Device Handbook, Volume 1

6 Data Storage Using the JTAG Interface Data Storage Using the JTAG Interface You can program and read manufacturing data using the IEEE Std JTAG interface. You can program the UFM block and the MAX II logic array together using the JTAG interface in in-system programming (ISP) mode. Also, you can program to and read from the UFM block independently through the JTAG interface when the MAX II device is in user mode with the real-time ISP feature. You can program and read through the JTAG interface by using the Jam file output from the Quartus II and the standardized Jam Player software. This design example describes one way to create manufacturing data for storage in the UFM block. All manufacturing data is converted into ASCII data format to maximize the memory efficiency. The code below shows the example manufacturing data. <DESIGN name= "LED Driver FUNCTION"> <COMPANY> ALTERA CORPORATION <BoardData> <DeviceName> EPM1270T144C3 <PartNo> 2003-MAX2-113 <ManucDate> 11/3/ PM <Revision> a0.95 Table 11 1 shows the ASCII text of a manufacturing data example. This text is then written into either HEX or MIF format. The address radix is in HEX format. Table ASCII Text of Manufacturing Data Example (Sector 0) (Part 1 of 2) Address C E E D D C E F 004F E 000D 003C F D E E C F F F E E C E F 006D D 003C E E 000D 003C E D E D Core Version a.b.c variable Altera Corporation MAX II Device Handbook, Volume 1 March 2004

7 Using MAX II User Flash Memory for Data Storage in Manufacturing Flow Table ASCII Text of Manufacturing Data Example (Sector 0) (Part 2 of 2) Address D 003C E 006F E D 004D D D C 004D E E F A0 002F E 0A D 003C B F 006E 003E B E D 003C C B D 003E C D0 000D D E E F F Figure 11 3 shows the HEX file containing the manufacturing data in the Quartus II software (MIF format is also available). Altera Corporation Core Version a.b.c variable 11 7 March 2004 MAX II Device Handbook, Volume 1

8 Data Storage Using the JTAG Interface Figure HEX File Format 11 8 Core Version a.b.c variable Altera Corporation MAX II Device Handbook, Volume 1 March 2004

9 Using MAX II User Flash Memory for Data Storage in Manufacturing Flow Generating a Programming File A POF for the entire device is generated when you compile the design file in the Quartus II software. The Quartus II Programmer gives you an option to target the portion of device you wish to program. You can convert the POF to Jam STAPL or JBC File format targeting certain areas of the device using the Convert Programming Files feature in the Quartus II software. A Jam STAPL or JBC File can also be generated during compilation using the Settings option in the Quartus II software. Conclusion The MAX II UFM block is the best choice for storing manufacturing data, helping to improve board space efficiency and minimizing system cost by integrating board-level flash memory, EEPROM capabilities, and system logic into one MAX II device. You can customize the UFM communication system to comply with different manufacturers standard interface protocols to access manufacturing product data. Altera Corporation Core Version a.b.c variable 11 9 March 2004 MAX II Device Handbook, Volume 1

10 Conclusion Core Version a.b.c variable Altera Corporation MAX II Device Handbook, Volume 1 March 2004