Method for importing DDR simulation parameters into eFuse
By importing DDR simulation parameters in eFuse, the bootloader compatibility problem of security products after DDR model changes is solved, and the flexible configuration and maintenance of DDR parameters are realized, which facilitates the switching of DDR models in the later production process.
Patent Information
- Application Number
- CN202311746277.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-12-19
- Publication Date
- 2025-06-20
AI Technical Summary
When existing security products perform DDR initialization operation when the system is started, the configuration parameter distinction increases, resulting in difficulty in software compatibility and update. After the DDR model changes, the previous bootloader is incompatible, resulting in product mass production and supply chain impacts.
By importing DDR simulation parameters in eFuse, the parameters required to initialize DDR are preferred from eFuse. If there is no data in eFuse, the default parameters will be started; if there is data, the index mark is decoded and parsed through Hamming code, and the fixed mode or index mode is selected for DDR parameter configuration.
It realizes arbitrarily switching or importing new DDR models during post-production, avoiding the difficulties of software updates and maintenance, and ensuring that the DDR parameters are always consistent with the chip.
Smart Images
Figure CN120179299A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of chip processing, and particularly relates to a method for importing DDR simulation parameters into eFuse. Background Art
[0002] In the prior art, with the continuous iteration and update of security products and the increasing variety of product types, the demand for different types of DDR increases. As a result, when the security product initializes the DDR during system startup, there are more configuration parameters to distinguish, which brings difficulties to software compatibility and update. To solve this problem, the technology of importing DDR simulation parameters into eFuse is introduced.
[0003] The DDR parameters of traditional security products are usually stored in external memories such as nor flash / emmc through software compilation. After the system starts up, the DDR simulation parameters on the external storage device are read out, and then the DDR is initialized to start the system. When the parameters change and need to be updated, the software package must be changed and the external memory must be re-burned and upgraded.
[0004] However, since the DDR initialization operation is integrated in the system bootloader, once the security product is mass-produced, the bootloader will be fixed and cannot be upgraded. Later, due to changes in the DDR model or the need to introduce a new DDR model, the previous bootloader may not be compatible, which will affect the mass production of the user's product and the software package upgrade of the supplier. According to the current market situation, the change and update of DDR are very frequent. If a certain type of DDR is out of stock and needs to be replaced with a new DDR model and the DDR parameters need to be updated later, it cannot be achieved with the existing technology, which will bring great risks.
[0005] In addition, the commonly used terms in the prior art include:
[0006] eFuse: One-time programmable memory, usually belonging to the internal memory of the chip.
[0007] DDR: A memory name, which means Double Data Rate Synchronous Dynamic Random Access Memory, and it is one type of memory.
[0008] NorFlash (also known as NOR-type flash memory) is a non-volatile memory, commonly used in embedded systems and storage devices.
[0009] Emmc: (Embedded Multi Media Card) is a standard specification for embedded memory established by the MMC Association, mainly for products such as mobile phones or tablets.
[0010] Bootloader: Boot loader.
[0011] Hamming Code: It is a linear debugging code in the field of telecommunications, named after its inventor Richard Wesley Hamming.
[0012] BCH code: It is an abbreviation taken from Bose, Ray-Chaudhuri, and Hocquenghem, and is a coding method that has been studied relatively much in coding theory, especially error-correcting codes.
[0013] CRC (Cyclic Redundancy Check): That is, cyclic redundancy check, which is a fast algorithm for generating a short fixed-bit check code based on data such as network data packets or computer files, mainly used to detect or check possible errors after data transmission or storage. CRC utilizes the principle of division and remainders to achieve the function of error detection, and has advantages such as clear principle and simple implementation.
[0014] RS code: Also known as the Reed-Solomon code, that is, Reed-solomon codes, which is a low-rate forward error correction channel coding and is effective for polynomials generated from corrected oversampled data. The encoding process first obtains redundancy for these polynomials at multiple points, and then transmits or stores them. This oversampling of the polynomials beyond the necessary value makes the polynomials overdetermined (overconstrained). When the receiver correctly receives enough points, it can recover the original polynomial, even if many points on the received polynomial are distorted by noise interference.
[0015] ODT (On-Die Termination): On-die termination, used to control the signals on the DDR. The ODT_PU and ODT_PD mentioned in the text are the pull-up and pull-down signals of ODT respectively.
[0016] CMD: The command signal of the DDR. The PU / PD in the text respectively represent the pull-up and pull-down signals. CK: The clock signal of the DDR. The PU / PD in the text respectively represent the pull-up and pull-down signals. DS (Driver Strength): It represents the driving ability of the DDR in the text.
[0017] SLT: Also known as functional testing, which is a method for testing the chip under test in an analog terminal usage scenario.
[0018] Byte: A byte, which is a measurement unit used by computer information technology to measure storage capacity. Summary of the Invention
[0019] To solve the above problems, the purpose of this application is to solve the problem that the chip products that customers have mass-produced cannot be changed or new DDR models cannot be imported. After using this technology, new DDR models can be arbitrarily switched or imported during the later production process.
[0020] Specifically, the present invention provides a method for importing DDR simulation parameters into an eFuse. The method includes that parameters required for initializing the DDR are preferentially obtained from the eFuse. If all the read data is 0, it means that there are no programmed parameters in the eFuse, and the default parameters will be used to start. If data is read from the eFuse, the data in the eFuse will be parsed. All data bits will be parsed through Hamming code decoding, and then the index marker of the data bits will be judged. If the index marker is 0, it means to use the fixed mode for DDR parameter configuration. If the index marker is 1, it means to use the index mode, and the index value needs to be further parsed. Corresponding DDR parameters will be configured according to different index values, and then the original parameters will be overwritten for configuration and startup.
[0021] The method further includes the following steps:
[0022] S1. Enter the sdram_init() of the DDR, and first obtain the content stored in the eFuse at the DDR position;
[0023] S2. Judge whether there is data at this position,
[0024] If there is no data and all are 0, then the default data in the array will be used for configuration and startup; if the content read from the eFuse is not 0, it means that the DDR parameters have been programmed. At this time, the 32-bit data in the eFuse needs to be parsed through Hamming code decoding;
[0025] S3. Judge whether the first bit of the data bit is 0 or 1,
[0026] If it is 0, it means to use the fixed mode. At this time, the corresponding parameters will be parsed according to Table 1 below and then replace the original data in the array;
[0027] If the first bit of the data bit is 1, it means to use the index mode. At this time, the index data will be parsed respectively, and then the parameter values corresponding to the index will be obtained according to the DDR parameters corresponding to the index bits. Finally, after parsing, the original data in the array will be replaced, and then the data in the array will be used for initialization to complete the startup.
[0028] In step S2, when the read content is not 0, the 32-bit data in the eFuse is parsed through Hamming code decoding, and the parity bits are removed. At this time, it will be checked whether the data is in error. A 1-bit error will default to correct the error to provide the correct data. For a 2-bit error, the software will default to the default configuration because the error cannot be corrected. If incorrect data is used, it may affect the system startup or stability. If there are more than 2-bit errors, there is usually no way to handle it.
[0029] In step S3, in order to distinguish between the fixed mode and the index mode, an additional flag bit is added as a selection. This flag is the first data of the positioning data. If it is 0, it means using the fixed mode. If it is 1, it means using the index mode.
[0030] For the use of the fixed mode, regarding the structure of the fixed mode in eFuse: 1-bit index flag; 25-bit DDR parameter information; 6-bit check code information; a total of 32 bits are written. For the use of the index mode, regarding the structure of the index mode in eFuse: 1-bit index flag; 25-bit DDR parameter information. The DDR parameter information includes 3 groups of modifiable data. Two of them are 3-bit index and 5-bit data, and the other group is 4-bit index and 5-bit data; 6-bit check code information; a total of 32 bits are written.
[0031] In step S3:
[0032] For the fixed mode, the parameters required for programming are defined fixed as shown in Table 1.
[0033] Table 1:
[0034]
[0035] Here, PU / PD are the same values because there is no distinction between PU / PD in the table. Here, PU / PD represent pull-up and pull-down signals respectively.
[0036] For the index mode, all parameters can be selected in the index mode. Each time, at most 3 groups of index parameters can be selected, which is used for the case where the overall DDR parameters do not change much. The DDR parameters corresponding to the index bits are shown in Table 2:
[0037] Table 2:
[0038] 000(0x0): ODT_PU 001(0x1): ODT_PD 010(0x2): CMD_RC_PU 011(0x3): CMD_RC_PD 100(0x4): CK_RC_PU 101(0x5): CK_RC_PD 110(0x6): DATA_RC_PU 111(0x7): DATA_RC_PD 1000(0x8): KGD
[0039] By these two modes, the parameters to be programmed are reduced.
[0040] The method is used for chips with built-in DDR. Usually, there are multiple DDR models for the same chip model. There is eFuse or a similar storage device in the chip.
[0041] The method is applied to embedded software development and is applicable to the situation where the software has been fixed and the DDR parameters cannot be updated or new DDR models cannot be added; programming the eFuse is carried out in the SLT test stage. Some versions will be programmed in the SLT test stage to distinguish the chip models. At this time, the DDR parameters can be programmed into the eFuse together.
[0042] The definition of the analog parameter content of the DDR configured in the software is fixed as shown in Table 1. What needs to be adjusted for the DDR parameters is the content in the parameters. An array will be pre-allocated in the software to fill in all the DDR parameters. During the initial debugging phase, a set of default parameters will be debugged to fill the array, and the default startup will also obtain parameters from the array.
[0043] The method can also select to use a combination of Hamming code and CRC error correction and detection codes.
[0044] Therefore, the advantages of this application are as follows: This application can make the chip with built-in DDR more convenient for software update and maintenance in the later stage. Since the existing technical solutions must define specific DDR parameters in the initial stage of the product, if the DDR model changes or a new DDR model needs to be imported in the later stage, the previous software will not be adaptable. After using the technical solution of this application, when switching or updating the DDR model, only the corresponding DDR parameters need to be written into the eFuse. When the system starts up, it will initialize the DDR according to the parameters in the eFuse, without relying on the fixed DDR parameters in the software, which can ensure that the DDR parameters and the chip always remain consistent. BRIEF DESCRIPTION OF THE DRAWINGS
[0045] The drawings described herein are used to provide a further understanding of the present invention, form a part of this application, and do not limit the present invention.
[0046] Figure 1 It is a schematic structural diagram of the fixed mode in the eFuse.
[0047] Figure 2 It is a schematic structural diagram of the index mode in the eFuse.
[0048] Figure 3 It is a schematic flow diagram of this method.
[0049] Figure 4 It is a schematic diagram of the DDR analog parameters to be imported.
[0050] Figure 5 It is a schematic diagram of the number of Hamming code check bits required. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0051] In order to more clearly understand the technical content and advantages of the present invention, the present invention will be further described in detail below with reference to the drawings.
[0052] This application is used in embedded software development and is currently used in the long-term power supply project of intelligent video of Hefei Juzheng Technology Co., Ltd. (referred to as Juzheng) T series. The chips involved include three chips: T23 / T40 / T41. The long-term power supply project of T series intelligent video mainly focuses on monitoring and security. By means of intelligent monitoring and control, fault warning and maintenance management, remote monitoring and management, etc., the reliability and stability of the video monitoring system are improved, and higher-quality monitoring services are provided for users.
[0053] In the prior art, when intelligent video products are supplied, they often encounter the problem that products that have been stably shipped before cannot be compatible due to the change of DDR model. If the DDR model is not changed, production may not be able to continue due to insufficient supply of the old DDR model. If the DDR model is to be changed, the software package needs to be adapted and updated. For users who have already purchased products normally, there is no way to promote software updates. To address this problem, multiple DDR models are selected in the early stage of chip production, which can provide more choices for DDR supply. However, it is found in actual production that the problem still cannot be completely avoided. For example, during the production of the T41 model product, it is found that there is a better DDR model that wants to be incorporated. Since the user's product has been finalized, if the new DDR model is to be incorporated and the software package is updated, when the user does not agree, the update cannot be carried out, and the incorporation of the new DDR has been delayed for a long time.
[0054] To solve the problem of changing the DDR model without updating the software package, it is considered that the DDR parameters must be separated from the software package. Only the acquisition and configuration of DDR parameters are done in the software, and the generation and saving of DDR parameters are not done. In addition, considering that the same chip type includes multiple DDR models, the corresponding chip and the corresponding DDR parameters need to be well matched. Therefore, importing the DDR parameters into the chip internal memory eFuse is a perfect solution.
[0055] Idea of the specific implementation process:
[0056] 1. Select a suitable error correction code to cope with the possible bit flips of eFuse:
[0057] DDR parameters are very important for the startup and stability of the system. If there are errors in parameter configuration, the product may not be usable. To ensure the correctness of the parameters, an error correction algorithm needs to be added. When selecting an error correction code, aspects such as error detection and correction capabilities, the number of parity bits, and the efficiency of error detection and correction need to be considered, so as to select the most suitable error correction code.
[0058] For current T-series intelligent video products, the probability of bit flips in eFuse is extremely low, and the demand for error detection and correction capabilities is not very high. Defining 1-bit error correction and 2-bit error detection can meet the requirements. Since the storage space of eFuse is limited, the demand for the number of check bits is as small as possible. Because the encoding and decoding of error correction codes are operations during system startup and have high efficiency requirements, otherwise it will increase the startup time. Combining the above requirements, Hamming code can be used to achieve this.
[0059] For other common error detection / correction code usage scenarios, a simple description is also provided here to facilitate the selection of various projects:
[0060] (1) Without considering error correction and only considering error detection, CRC check can be used. The advantage is that it can detect errors in any bit and support large data volume detection. The disadvantage is that the check bits occupy more space and cannot correct errors.
[0061] (2) Considering 1-bit error correction and 2-bit error detection, and unable to detect or correct errors of more than 2 bits, Hamming code can be used. The advantages are that the check bits occupy less space, it can correct 1 bit, and the encoding and decoding efficiency is high. The disadvantage is that it cannot handle data errors of more than 2 bits.
[0062] (3) Considering multi-bit error correction and detection, and unable to detect or correct errors beyond the error correction ability, BCH code / RS code can be used. The advantage is that it can correct multi-bit data and is suitable for memories prone to bit flips. The disadvantages are that it cannot correct and detect errors when the error data exceeds the error correction ability, and the check bits occupy more space.
[0063] (4) Considering a small number of bit error corrections and any bit error detection, multiple error correction and detection code combinations such as Hamming code + CRC or BCH code + CRC can be used. The advantage is that it can detect data anomalies well. The disadvantage is that the check bits occupy too much space, and it is suitable for memories with larger storage space.
[0064] II. Determine the storage space of eFuse and solve how to save space:
[0065] As an on-chip memory, eFuse can store limited data. It is usually used to record the unique ID and version information of the chip, and the space available for users is limited. It is necessary to save space as much as possible. Currently, the available space for users in the T-series chips is 4Byte, which means that the number of parameters needs to be controlled within 4Byte.
[0066] The DDR simulation parameters to be imported are as Figure 4 shown. Just the total DDR parameters require 45bit = 5Byte + 5bit. The number of Hamming code check bits required is as Figure 5As shown in the figure, when the data bit is 45 bits, 7 parity bits are required, and the total including the Hamming code parity bit is 52 bits = 6 bytes + 4 bits, which has exceeded the remaining 4 bytes. To solve this problem, two import schemes are defined. One is the fixed mode, where the required parameters are burned, and the definition of the burned parameters is fixed as shown in Table 1:
[0067] Table 1:
[0068] The other is the index mode. In the index mode, all parameters can be selected, but at most 3 groups of index parameters can be selected each time, which is used for the case where the overall DDR parameters change little. The DDR parameters corresponding to the index bits are shown in Table 2:
[0069] Table 2:
[0070] 000(0x0): ODT_PU 001(0x1): ODT_PD 010(0x2): CMD_RC_PU 011(0x3): CMD_RC_PD 100(0x4): CK_RC_PU 101(0x5): CK_RC_PD 110(0x6): DATA_RC_PU 111(0x7): DATA_RC_PD 1000(0x8): KGD
[0071] By these two modes, the parameters to be burned are reduced, saving the storage space of eFuse.
[0072] To distinguish between the fixed mode and the index mode, an additional flag bit needs to be added as a selection. This flag is located at the first data of the data. If it is 0, it means using the fixed mode; if it is 1, it means using the index mode. In the fixed mode, the total data is 25 bits, the parity bit is 6 bits, and the index bit is 1 bit, totaling 32 bits = 4 bytes, meeting the requirements. The details of the fixed mode are as Figure 1 shown. In the index mode, 3 groups of data can be modified. Two of them are 3-bit index and 5-bit data (16 bits), and the other group is 4-bit index and 5-bit data (9 bits); the parity bit is 6 bits, and the index bit is 1 bit, totaling 32 bits, meeting the requirements. The details of the index mode are as Figure 2 shown.
[0073] Regarding the structure of the fixed mode and the index mode in eFuse:
[0074] Fixed mode, (1 + 25) + 6: 1-bit index mark; 25-bit DDR parameter information; 6-bit check code information, totaling 32 bits written. As Figure 2 shown: p represents the parity bit; s represents the index switch; d represents the data bit.
[0075] Index mode, (1 + 8 * 2 + 9) + 6: 1-bit index mark; 25-bit (3 groups of data can be modified, two of which are 3-bit index and 5-bit data, and the other group is 4-bit index and 5-bit data) DDR parameter information; 6-bit check code information, totaling 32 bits written. AsFigure 3 As shown: p represents the parity bit; s represents the index switch; i represents the index value; d represents the data bit.
[0076] III. Method Flow Design and DDR Parameter Import:
[0077] It has been determined in the early stage to use Hamming code for encoding and decoding algorithms, and the layout of the corresponding data bits on the eFuse has also been determined. Next, attention needs to be paid to the overall method flow design.
[0078] (1) Under what circumstances do we need to import DDR parameters into the eFuse, and how to import them specifically:
[0079] During the early debugging and production of the chip, since it does not involve the production of the user's product, the designed software package can be freely adjusted. At this time, the DDR parameters can be arbitrarily configured and modified without being written into the eFuse. Only after the user's product has been produced and shipped, when the software package is fixed and the DDR parameters cannot be updated, if there is a change in the DDR model during the chip production process, or if a new DDR model is to be added, and the DDR parameters are incompatible with the previous ones, the changed parameters need to be imported into the eFuse.
[0080] The action of burning the eFuse is normally carried out in the SLT test stage. Some versions will be burned in the SLT test stage to distinguish the chip models. At this time, the DDR parameters can be burned into the eFuse together.
[0081] (2) After using this method, how to adjust and implement the Bootloader:
[0082] The definition of the content of the analog parameters of the DDR configured in the Bootloader software is basically fixed as shown in Table 1. What needs to be adjusted for the DDR parameters is the content in the parameters. An array will be allocated in advance in the Bootloader software to fill in all the DDR parameters. A set of default parameters will be debugged and filled into the array during the initial debugging stage, and the default startup will also obtain the parameters from the array.
[0083] Finally, regarding the method flow as Figure 3 shown:
[0084] S1, enter the DDR initialization function sdram_init(), and first obtain the content stored in the eFuse for the DDR location;
[0085] S2. Determine whether there is data at this position. If there is no data and all are 0, then the default data in the array will be used for configuration and startup. If the content read from the eFuse is not 0, it means that the DDR parameters have been burned. At this time, the 32-bit data in the eFuse needs to be parsed through Hamming code decoding, and the parity bits are removed. Note that the data will be checked for errors at this time. A 1-bit error will be corrected by default to provide the correct data, and for a 2-bit error, the software will default to the default configuration because the error cannot be corrected. Using incorrect data may affect system startup or stability. If there are more than 2-bit errors, there is usually no way to handle it;
[0086] S3. Determine whether the first bit of the data bit is 0 or 1,
[0087] If it is 0, it means using the fixed mode. At this time, the corresponding parameters will be parsed according to Table 1 and then replace the original data in the array. Note that the PU / PD here are the same values because PU / PD are not distinguished in Table 1;
[0088] If the first bit of the data bit is 1, it means using the index mode. At this time, the index data will be parsed respectively, and then the parameter values corresponding to the index will be obtained according to Table 2. Finally, after the parsing is completed, the original array data will be replaced. Note that at most 3 groups can be replaced here, and finally the data in the array will be used for initialization to complete the startup.
[0089] That is, for the software process after using this method, the parameters required for software initialization of DDR will be preferentially obtained from the eFuse. If the data read is all 0, it means that there are no burned parameters in the eFuse, and the default parameters in the code will be used for startup. If data is read from the eFuse, the data in the eFuse will be parsed, and all the data bits will be parsed through Hamming code decoding, and then the index mark of the data bit will be judged. If the index mark is 0, it means using the fixed mode for DDR parameter configuration. If the index mark is 1, it means using the index mode, and the index value needs to be further parsed. According to different index values, the corresponding DDR parameters will be configured, and then the original parameters will be overwritten for configuration and startup. See details in Figure 4 as shown
[0090] So far, the import of DDR simulation parameters into eFuse has been completed. However, due to the limitation of data size in eFuse, the function is not perfect. For example, when using Hamming code for error correction, errors of more than 2 bits cannot be detected, which poses some risks. If the combination of Hamming code + CRC can be used, data errors can be detected, reducing the occurrence of risks, but it will require more check bits. In addition, although the design of fixed mode and index reduces the amount of data written, it also reduces the flexibility of DDR parameter configuration. If the parameter differences are large, complete coverage cannot be achieved. However, for current intelligent video products, the current technical solutions can fully cope with them.
[0091] In summary, the key points of this application are as follows:
[0092] (1) This invention is mainly used to solve the situation where multiple DDR models are used in the actual product chip and to solve the problem of adapting multiple DDR models.
[0093] (2) This invention requires the integration of eFuse or similar memories in the product chip to store DDR parameters.
[0094] (3) This invention supports error correction and error detection of data in storage devices, improving the fault tolerance of data.
[0095] The above are only the preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, various changes and modifications can be made to the embodiments of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.
Claims
1. A method for importing DDR simulation parameters in an eFuse, characterized in that, The method includes that the parameters required for initializing the DDR will preferentially be obtained from the eFuse. If all the read data is 0, it means that there are no programmed parameters in the eFuse, and the default parameters will be used to start. If data is read from the eFuse, the data in the eFuse will be parsed, and all the data bits will be parsed through Hamming code decoding. Then, the index marker of the data bits will be judged. If the index marker is 0, it means to use the fixed mode for DDR parameter configuration. If the index marker is 1, it means to use the index mode, and the index value needs to be further parsed. According to different index values, the corresponding DDR parameters will be configured, and then the original parameters will be overwritten for configuration and start-up.
2. The method for importing DDR simulation parameters in an eFuse according to claim 1, characterized in that, The method further includes the following steps: S1. Enter the DDR initialization function sdram_init(), and first obtain the content stored in the eFuse for the DDR position; S2. Judge whether there is data in the content of this position. If there is no data and all are 0, then the default data in the array will be used for configuration and start-up; if the content read from the eFuse is not 0, it means that the DDR parameters have been programmed. At this time, the 32-bit data in the eFuse needs to be parsed through Hamming code decoding; S3. Judge whether the first bit of the data bits is 0 or 1. If it is 0, it means to use the fixed mode. At this time, the corresponding parameters will be parsed according to Table 1 and then replace the original data in the array; Table 1: If the first bit of the data bits is 1, it means to use the index mode. At this time, the index data will be parsed respectively, and then according to the DDR parameters corresponding to the index bits, the parameter values corresponding to the respective indexes will be obtained. Finally, after the parsing is completed, the original data in the array will be replaced, and then the data in the array will be used for initialization and start-up.
3. The method for importing DDR simulation parameters in an eFuse according to claim 2, characterized in that, In step S2, when the read content is not 0, the 32-bit data in the eFuse is parsed through Hamming code decoding, and the parity bits are removed. At this time, it will be checked whether the data is in error. A 1-bit error will default to correct the error to provide the correct data, and for a 2-bit error, the software will default to the default configuration because the error cannot be corrected. If the wrong data is used, it may affect the system start-up or stability. If there are more than 2-bit errors, usually there is no way to handle it.
4. The method for importing DDR simulation parameters in an eFuse according to claim 2, characterized in that, In step S3, in order to distinguish the fixed mode and the index mode, an additional flag bit is added as a selection. This flag bit locates the first data of the data. If it is 0, it means to use the fixed mode. If it is 1, it means to use the index mode; Regarding the fixed mode, the structure of the fixed mode in the eFuse: 1-bit index marker; 25-bit DDR parameter information; 6-bit parity code information; a total of 32 bits are written; Regarding the index mode, the structure of the index mode in the eFuse: 1-bit index marker; 25-bit DDR parameter information, where the DDR parameter information includes 3 groups of modifiable data. Two of them are 3-bit index and 5-bit data, and the other one is 4-bit index and 5-bit data; 6-bit check code information; a total of 32 bits are written.
5. The method for importing DDR simulation parameters in an eFuse according to claim 4, characterized in that, In the step S3: In the fixed mode, the parameters required for programming are programmed. The definition of the programming parameters is fixed as shown in Table 1. Here, PU / PD are the same values because PU / PD are not distinguished in the table. Among them, PU / PD represent pull-up and pull-down signals respectively; In the index mode, all parameters can be selected in the index mode. At most 3 groups of index parameters can be selected each time, which is used for the situation where the overall change of DDR parameters is not large. The DDR parameters corresponding to the index bits are shown in Table 2: Table 2: These two modes are used to reduce the parameters that need to be programmed.
6. The method for importing DDR simulation parameters in an eFuse according to claim 1, characterized in that, The method is used for chips with built-in DDR. Usually, there are multiple DDR models for the same chip model. There is an eFuse or a similar storage device in the chip.
7. The method for importing DDR simulation parameters in an eFuse according to claim 1, characterized in that, The method is applied to embedded software development and is applicable to the situation where the software has been fixed and the DDR parameters cannot be updated or new DDR models cannot be added; programming the eFuse is carried out in the SLT test stage. Some versions will be programmed in the SLT test stage to distinguish the chip models. At this time, the DDR parameters can be programmed into the eFuse together.
8. The method for importing DDR simulation parameters in an eFuse according to claim 7, characterized in that, The definition of the analog parameter content of DDR configured in the software is fixed as shown in Table 1. What needs to be adjusted for the DDR parameters is the content in the parameters. An array will be allocated in advance in the software to fill in all the DDR parameters. A set of default parameters will be debugged and filled into the array in the initial debugging stage, and the default startup will also obtain parameters from the array.
9. The method for importing DDR simulation parameters in an eFuse according to claim 1, characterized in that, The method can also select to use the combination of Hamming code + CRC error correction and detection code.