Non-volatile Memory Introduction

电脑产品介绍英文介绍作文英文回答：Introduction.In the modern digital age, computers have become indispensable tools for both personal and professional use. With the vast array of models and configurations available, choosing the right computer can be a daunting task. This comprehensive guide will provide an overview of different computer types, their specifications, and considerationsfor choosing the optimal device.Types of Computers.Desktops: Traditional computers designed forstationary use, offering powerful performance and ample storage capacity. Suitable for heavy-duty tasks such as video editing, gaming, and running complex software.Laptops: Portable computers that combine portability with reasonable computing power. Ideal for students, travelers, or those who need to work on the go.Tablets: Compact devices with touchscreen interfaces that prioritize portability and convenience. Suitable for browsing the web, reading, watching videos, and playing casual games.Smartphones: Compact devices with mobile operating systems that offer a wide range of capabilities, including communication, multimedia, and app usage. Primarily designed for on-the-go use.Mainframes: Large-scale computers used for high-volume data processing and mission-critical applications in enterprises and government agencies.Specifications.Processor (CPU): The central processing unit, responsible for executing instructions and computations.Measured in gigahertz (GHz), with higher numbers indicating faster performance.Memory (RAM): Volatile memory that stores data and instructions currently being processed. Measured in gigabytes (GB), with more RAM enabling smoothermultitasking and faster loading times.Storage (HDD/SSD): Non-volatile memory that storesdata permanently. Measured in gigabytes (GB) or terabytes (TB), with SSDs offering faster access speeds than HDDs.Graphics Card (GPU): Dedicated hardware for handling visual processing, essential for gaming, video editing, and other graphics-intensive tasks.Display: The screen that displays information. Measured in inches and resolution (e.g., 1080p or 4K). Higher resolutions provide sharper and more detailed images.Considerations.Purpose: Define the primary tasks the computer will be used for (e.g., office work, gaming, video editing).Portability: Determine if portability is a priority or if a stationary desktop is more suitable.Performance: Assess the level of performance required for the intended tasks.Budget: Set a budget and research computers withinthat price range.Operating System: Consider the operating system (e.g., Windows, macOS, Linux) that best aligns with your needs and preferences.Conclusion.Choosing the right computer involves considering the type, specifications, and personal requirements. By understanding these factors, you can make an informed decision that aligns with your specific needs andpreferences. Whether you require a powerful desktop for demanding tasks or a portable laptop for on-the-go use, there is a computer that meets your requirements.中文回答：简介。

UG103.7: Non-Volatile Data Storage FundamentalsThis document provides a general introduction to non-volatile da-ta storage using flash, with a focus on the three different dynamic data storage implementations offered for Silicon Labs microcon-trollers and radio SoCs (Systems on Chip). It offers a comparison of the three implementations and provides recommendations on when to use each. Additional detail on using the various data storage implementations may be found in the following docu-ments:•AN1154: Using Tokens for Non-Volatile Data Storage•AN703: Using Simulated EEPROM Version 1 and Version 2 for the EFR32 SoC Series 1 Platform•AN1135: Using Third Generation Non-Volatile Memory (NVM3) Data Storage Silicon Labs’ Fundamentals series covers topics that project managers, application de-signers, and developers should understand before beginning to work on an embedded networking solution using Silicon Labs chips, networking stacks such as EmberZNet PRO or Silicon Labs Bluetooth®, and associated development tools. The documents can be used as a starting place for anyone needing an introduction to developing wire-less networking applications, or who is new to the Silicon Labs development environ-ment.KEY POINTS•Review of the challenges and design options for implementing non-volatile data storage.•Review of the three dynamic data storage implementations.•Comparison of the three dynamic data storage implementations.Introduction 1. IntroductionNon-volatile memory (NVM) is memory that persists even when the device is power-cycled. On Silicon Labs microcontrollers and radio SoCs, the NVM is implemented as flash memory. In many applications the flash is not only used to store the application code but also to store data objects that are written and read frequently by the application. As flash memory can only be erased a limited number of times, several methods exist to efficiently read and write non-volatile data without wearing out the flash.Some data is considered manufacturing data that is written only once at manufacturing time. This document is concerned with dynamic data that changes frequently over the life of the product.This document provides an introduction to the main design options for dynamic data storage in microcontrollers and radio SoCs, along with guidelines on what factors affect flash lifetime. In addition it introduces the main flash data storage implementations offered by Silicon Labs:•NVM3•Simulated EEPROM version 1 (SimEEv1) and version 2 (SimEEv2)•Persistent Store (PS Store)2. Implementations of Non-Volatile Data StorageThis chapter introduces some of the challenges and design options when implementing non-volatile data storage in flash memory. It describes at a high level how non-volatile data storage is implemented in flash memory in PS Store, SimEEv1/v2, and NVM3.2.1 Basic ImplementationsOne of the characteristics of flash memory is that it is writable in smaller pieces, usually 32-bit words, while it can only be erased in larger chunks, usually pages of several kilobytes. When using flash as data storage, the most straightforward implementation option would be to store each data object in its own flash page, as shown in the following figure. This way each object can be erased and re-written without influencing the other data objects. Usually the data objects are much smaller than the page size, and this solution is not an effective way of using the available flash space.Figure 2.1. One Object Per PageTo avoid wasting flash space we can store several data objects in one flash page, as shown in the following figure. This solution then introduces a challenge when we want to write a new value to one of the data objects. In that case the page must be erased before all objects are written back to the page again, including the object we changed. As flash memory can only endure a limited amount of flash erases before the flash cells are worn out, this solution results in a very limited device lifetime.Figure 2.2. Multiple Objects in One Flash PageTo avoid erasing the flash page for every object write, we can instead write new versions of each object to new empty locations in the flash page. This is a simple form of wear-levelling that reduces the number of page erases. However, this requires that we store some identification information along with the object data that tells us what object the data belongs to, so we know how to find the latest ver-sion of the data object. This is illustrated in the following figure, where a key is added to each version of the object data to identify what object the data belongs to. When accessing an object we then need to search through the flash page for the most recent version of the object. In this case the newest version is the one with the highest address, as we start writing from the lowest address of the page.Figure 2.3. Object Versions With Keys2.2 Handling Resets and Power FailuresAs we fill up the flash page with new versions of the data objects, eventually no room is left to write new object data. At this point we need to erase the page and start over by writing only the latest versions of each object to the flash page. In many applications, howev-er, power failures or resets can happen at any time, and we should not risk losing data if this occurs. If a reset occurs after the flash page is being erased, but before the data objects are written back, then we will lose this data. To handle this case we introduce a sec-ond page, to which we copy the latest version of the data objects, before erasing the original page, as shown in the following figure Then we can start filling the second page with data. When the second page is full we move the latest data back to the first page and so on. This mechanism, where the storage is alternated between two flash pages, is how PS Store operates.Figure 2.4. Latest Data Copied to New Page Before Erase2.3 Introducing Virtual PagesIn some applications we write to data objects frequently, and the flash pages therefore also need to be erased frequently. As the data objects in the implementation so far are only spread across two flash pages, each page will frequently get erased and the flash lifetime will be limited. To increase the lifetime we can use more flash pages to store the data objects. In this example, instead of two physical pages, we operate with two virtual pages (A and B) that each consist of several physical flash pages. The virtual pages are erased and written to as if they were one larger flash page. The difference is simply that each virtual page is bigger and we can write more data before we need to erase the virtual page, hence the lifetime is extended. In addition to increasing flash lifetime, using several flash pages per virtual page allows you to store more or larger objects. SimEEv1 uses this design, with each virtual page consisting of two flash pages, A and B, as shown in the following figure.Virtual Page BVirtual Page A Figure 2.5. Virtual PagesIn some applications the time it takes to write a non-volatile data object must be minimized so as to not interfere with the timing of other critical operations. If an object write is triggered when a virtual page is full, the latest version of all objects must first be copied to the new virtual page before writing the new object version in question to the new page. All objects must be copied over immediately to allow the first page to be quickly erased so we can move data there in case of a failure. Copying all objects at once increases the worst-case object write time.To reduce the write times, a third virtual page can be introduced that is always kept erased. Instead of copying over the latest version of every object when the first page is full, we can instead copy over only some of the objects. The rest of the objects are copied over as a part of subsequent write operations. This way we spread the copy process to the new page over more write operations, hence each write operation takes less time to complete. With this approach we have live object data spread out across two virtual pages and the third page is always kept erased, so we have somewhere to move the data to in case of a failure. SimEEv2 uses this implementation with 3 virtual pages where each virtual page consists of 6 flash pages.2.4 Basic StorageBasic storage is defined as the size of all the latest version of all objects, including any overhead stored with them. Except for NVM3,every time a flash page or virtual page is erased we must first move the basic storage over to a new page. The basic storage size is important, as it determines how much flash space is left over in a page to store any new versions of the object data. If the basic storage takes up almost the entire page, we can only write a few new object versions before we need to move to a new page and erase the old one. This leads to frequent page erases and a short flash lifetime.NVM3 only copies unique objects that are stored in the page that will be erased. If newer versions of the object exist in other pages, the object will not be copied.2.5 FIFO ModelThe flash data storage implementations can be modelled as a First-In First-Out (FIFO) buffer (see the following figure), where we write new versions to the input of the FIFO. As the FIFO fills up, we need to free up space by erasing one or more pages at the end of the FIFO. Before we erase a page, we need to copy any object versions for which no newer version of the same object exists in the rest of the flash pages. Other object data can be discarded, because newer versions exist. To maximize flash lifetime we want to copy as few object versions as possible, so that most of the writes to the flash memory are new versions of the objects. If the FIFO is implemented over a large flash space, it is more likely that the new version of the object has been written and that object versions at the end of the FIFO can be discarded. In this case the flash page can be erased with few or no object versions copied.Figure 2.6. FIFO BufferA drawback of using a few virtual pages is that the available memory for the FIFO is limited to only the virtual pages that can hold live data. For implementations using two virtual pages, like SimEEv1, this means only half the storage space is used for the FIFO, while for SimEEv2 two thirds of the storage space is used for the FIFO.To allow a higher portion of the storage space to be used for the FIFO, we can instead implement the FIFO as a circular buffer over the entire flash storage space allocated, as shown in the following figure. In this implementation we always need to keep enough erased pages in front of the leading edge of the buffer to write the largest-sized object in case of a failure. When the FIFO fills up to reach the critical number of erased flash pages, we copy over any object versions that have not been superseded and erase the page at the back of the FIFO. This means that, instead of keeping a full virtual page erased, we only need to keep enough space erased to fit the largest-sized object. We can use the rest of the space for the FIFO. NVM3 is implemented as a circular buffer implemented over the entire storage space, thus increasing flash lifetime compared to implementations using smaller virtual pages.Figure 2.7. Circular Buffer2.6 Counter ObjectsFor some types of data, the storage format can be optimized for the flash medium. EFR32 Series 0 and 1 can write each word two times, allowing for half word updates. Series 2 devices allow just one write per word.For example, counter values are usually incremented by 1 or some other low value every time they are written. Normally this means that we would have to write the entire counter value in addition to identification bytes every time the counter is incremented. We can optimize this by only storing a start value in addition to the identification value the first time a counter is written. Then we reserve a number of the words following the initial value for writing increments. The flash words in Silicon Labs devices EFR32 Series 0 and 1 can write words twice between each erase by keeping a 1 in the bits that are not to be changed.As an example, assume we are writing two 16 bit values, 0xAAAA and 0x5555. To safely write them in the same flash word this method can be used:•Write 0xFFFFAAAA (word in flash becomes 0xFFFFAAAA)•Write 0x5555FFFF (word in flash becomes 0x5555AAAA)Note that there is a maximum of two writes to the same word between each erase due to a physical limitation of the flash.To find the current counter value, we start with the initial value and add the increment values in the halfwords following the initial value. This means that we only need to write one halfword for each increment, instead of the whole counter value and identification value. NVM3 and SimEEv1/v2 support counter objects.2.7 Indexed ObjectsWhen storing data such as arrays in flash, we often only update one index at a time. If we store the whole array as one regular object, we must write the whole array to flash even if just one index is updated. Instead of storing the entire array in one object, we can divide each data array over multiple objects and only update the objects holding the changed array indexes. While it is possible to split arrays into multiple objects manually for all the Silicon Labs storage implementations, SimEEv1/v2 allow all of the indexes to share one object key. The index entry into the array to be looked up is then provided as a separate parameter.NVM3 does not support reading and writing parts of an object. If the application wants to access indexes individually, each index must be accessed using a unique key.Dynamic Data Storage Implementations 3. Dynamic Data Storage ImplementationsThis chapter introduces some of the dynamic data storage implementations offered by Silicon Labs, including SimEEv1 and SimEEv2, PS Store, and NVM3.3.1 SimEEv1/v2SimEEv1/v2 can be used with EmberZNet PRO and Silicon Labs Connect (installed with the Flex SDK). SimEEv1 uses two virtual pa-ges with a fixed total size of 8 kB, while SimEEv2 uses three virtual pages with a fixed total size of 36 kB.One characteristic of SimEEv1/v2 is that all objects are defined with size and type at compile time, hence a new object cannot be cre-ated or deleted at runtime.Silicon Labs provides a plugin for upgrading SimEEv1 data to SimEEv2.Information about the SimEEv1/v2 implementations is found in AN703: Using Simulated EEPROM Version 1 and Version 2 for the EFR32 Series 1 SoC Platform.3.2 PS StorePS Store can be used with Bluetooth devices on all platforms except for EFR32 Series 2. PS Store API commands are used to manage user data in PS keys in the flash memory of the Bluetooth device. User data stored within the flash memory is persistent across reset and power cycling of the device. The persistent store size is 2048 bytes and uses two flash pages for storage. As Bluetooth bondings are also stored in this area, the space available for user data also depends on the number of bondings the device has at the time. The size of a Bluetooth bonding is around 150 bytes. With its simple implementation and few storage flash pages, PS Store is the smallest of Silicon Labs' non-volatile storage options. PS Store allows objects to be created and deleted at runtime.Information about the PS Store APIs may be found in the Bluetooth API Software Reference Manual.3.3 NVM3The third generation Non-Volatile Memory (NVM3) data storage driver is an alternative to SimEEv1/v2 and PS Store. The NVM3 driver provides a means to write and read data objects (key/value pairs) stored in flash. Wear-leveling is applied to reduce erase and write cycles and maximize flash lifetime. The driver is resilient to power loss and reset events, ensuring that objects retrieved from the driver are always in a valid state. Because NVM3 can be used with several protocols, such as Bluetooth and EmberZNet PRO, it allows a single data storage instance to be shared in Dynamic Multiprotocol (DMP) applications.Some of the main features of NVM3 are as follows:•Key/value pair data storage in flash•Runtime creation and deletion of objects•Persistence across power loss and reset events•Wear-leveling to maximize flash lifetime•Object sizes from 0 to 4096 bytes•Configurable flash storage size (minimum 3 flash pages)•Cache with configurable size for fast object access•Data and counter object types•Compatibility layers with token and PS Store APIs provided•Single shared storage instance in multiprotocol applications•Repack API to allow application to run clean-up page erases during periods with low CPU loadDetailed information on NVM3 is documented in the EMDRV->NVM3 section of the Gecko HAL & Driver API Reference Guide. Users who are accessing NVM3 through its native API should refer to this API reference guide for information. Users who are developing dynamic multiprotocol applications should refer to AN1135: Using Third Generation Non-Volatile Memory (NVM3) Data Storage.Comparing Non-Volatile Data Storage Implementations 4. Comparing Non-Volatile Data Storage ImplementationsThe following table presents an overview of the main features of the various Silicon Labs Non-Volatile Data Storage implementations.Table 4.1. NV Data Storage Implementation ComparisonNote 1: When using NVM3, indexed objects are implemented by storing each index in a separate NVM3 object.UG103.7: Non-Volatile Data Storage FundamentalsComparing Non-Volatile Data Storage Implementations 4.1 Flash LifetimeAll Silicon Labs Flash Data Storage implementations use some form of wear-levelling to prolong flash lifetime. The effectiveness of the wear-levelling depends on the implementation, the type of data stored, and how often it is updated. The main factors that affect wear-levelling and thereby flash lifetime are:•Size of flash used for data storage: More flash area gives longer flash lifetime. For NVM3, the number of flash pages used for data storage can be configured, while the rest of the implementations use fixed storage sizes.•Stored overhead per object: When writing data to the object storage, some overhead bytes are added to identify the data. Implemen-tation with less overhead means the data objects take up less space in flash, and gives longer flash lifetime.•Alignment to minimum object size: Objects are stored in multiples of the smallest object size. If the data size does not align with this size, padding bytes are added, which adds to the stored data and reduces flash lifetime. For instance, when storing 16-bit objects, NVM3 and PS Store add two extra bytes of padding in addition to the overhead bytes. SimEEv1/v2 are able to store 16-bit data objects without padding.•Remaining storage after basic storage: For implementations using virtual pages, when switching to a new virtual page one instance of each object is written to the page. The rest of the virtual page can then be used to store new writes of the objects. If a lot of space is used to store one instance of each object, little space is left in the virtual page to use for wear-levelling the subsequent object writes. The flash lifetime will therefore be reduced when the total amount of object data is large relative to the virtual page size. Even for NVM3, where virtual pages are not used, the flash lifetime is limited by the available space of the total NVM3 storage.To help monitor the actual flash wear, NVM3 and SimEEv1/v2 include function calls for reporting the number of page erases of the data storage flash pages. These erase counters can be read during accelerated lifetime testing of a product to verify if the flash wears at an acceptable rate.Smart. Connected. Energy-Friendly.Products /productsQuality/qualitySupport and CommunitySilicon Laboratories Inc.400 West Cesar ChavezAustin, TX 78701USADisclaimerSilicon Labs intends to provide customers with the latest, accurate, and in-depth documentation of all peripherals and modules available for system and software implementers using or intending to use the Silicon Labs products. Characterization data, available modules and peripherals, memory sizes and memory addresses refer to each specific device, and "Typical" parameters provided can and do vary in different applications. Application examples described herein are for illustrative purposes only. Silicon Labs reserves the right to make changes without further notice to the product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the included information. Without prior notification, Silicon Labs may update product firmware during the manufacturing process for security or reliability reasons. Such changes will not alter the specifications or the performance of the product. Silicon Labs shall have no liability for the consequences of use of the information supplied in this document. This document does not imply or expressly grant any license to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any FDA Class III devices, applications for which FDA premarket approval is required, or Life Support Systems without the specific written consent of Silicon Labs. A "Life Support System" is any product or system intended to support or sustain life and/or health, which, if it fails, can be reasonably expected to result in significant personal injury or death. Silicon Labs products are not designed or authorized for military applications. Silicon Labs products shall under no circumstances be used in weapons of mass destruction including (but not limited to) nuclear, biological or chemical weapons, or missiles capable of delivering such weapons. Silicon Labs disclaims all express and implied warranties and shall not be responsible or liable for any injuries or damages related to use of a Silicon Labs product in such unauthorized applications.Trademark InformationSilicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® and the Silicon Labs logo®, Bluegiga®, Bluegiga Logo®, Clock B uilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Energy Micro logo and combinations thereof, "the world’s most energy friendly microcontrollers", Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, Gecko OS, Gecko OS Studio, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY®, Telegesis, the Telegesis Logo®, USBXpress® , Zentri, the Zentri logo and Zentri DMS, Z-Wave®, and others are trademarks or registered trademarks of Silicon Labs. ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks of ARM Holdings. Keil is a registered trademark of ARM Limited. Wi-Fi is a registered trademark of the Wi-Fi Alliance. All other products or brand names mentioned herein are trademarks of their respective holders.。

nvme ssd热插拔原理NVMe (Non-Volatile Memory Express) SSD (Solid State Drive) 热插拔原理是如何实现的？在本文中，我们将一步步回答这个问题，从了解NVMe SSD和热插拔的概念开始，到介绍NVMe SSD热插拔的实现方式，并解释它为什么可以实现热插拔。

最后，我们将讨论使用NVMe SSD热插拔可能会出现的一些问题，并提供解决方法。

NVMe SSD简介NVMe SSD是一种基于PCI Express总线的闪存存储解决方案，其速度比SATA SSD更快。

NVMe SSD使用基于闪存存储的技术，与传统的机械硬盘不同，可以更快地读取和写入数据。

它们还可以提供更高的保护和容错性能，并且比机械硬盘更耐用。

热插拔的概念热插拔是指在电子设备运行时，从设备中插入或拔出一个设备而不影响设备的运行。

该功能通常用于在电源状态下添加或删除设备，以便更改或增加硬件配置而不必关闭电源。

热插拔在数据中心和其他需要高可用性和连续性的场合非常有用。

NVMe SSD热插拔实现方式NVMe SSD热插拔是通过PCI Express控制器实现的。

当插入或拔出NVMe SSD时，PCI Express控制器将检测到更改，从而启动相应的热插拔操作。

PCI Express控制器在启动热插拔操作时将暂停NVMe SSD的访问，并将命令队列和I/O队列刷新到NVMe SSD中。

此时，该设备的插入或拔出过程可以开始。

NVMe SSD的插入和拔出过程不会影响正在运行的系统，因为PCI Express控制器会在插入或拔出NVMe SSD 时暂停设备的访问，直到NVMe SSD 再次正常工作。

NVMe SSD热插拔原理解释PCI Express总线支持热插拔设备。

这意味着PCI Express控制器可以在设备被插入或拔出时探测到更改并采取相应措施。

在NVMe SSD被插入或拔出的情况下，PCI Express控制器将检测到设备状态的更改，并启动相应的热插拔操作。

Flash存储器的冗余实现王凤鸣;胡凯;黄诚【摘要】Flash存储器是在20世纪80年代末逐渐发展起来的一种新型半导体非挥发性存储器,它具有结构简单、高密度,低成本、高可靠性和系统的电可擦除性等优点,是当今半导体存储器市场中发展最为迅速的一种存储器.文章对Flash存储器的发展现状及发展趋势进行了介绍,分析了Flash存储器的工作机理;并针对Flash 存储器是一种数据正确性非理想的器件,在使用中可能会有坏损单元,探讨了Flash 存储器冗余技术的种类和实现方法.【期刊名称】《电子与封装》【年(卷),期】2010(010)005【总页数】3页(P30-32)【关键词】FLASH存储器;冗余技术;非挥发【作者】王凤鸣;胡凯;黄诚【作者单位】中国电子科技集团公司第58研究所,江苏,无锡,214035;中国电子科技集团公司第58研究所,江苏,无锡,214035;中国电子科技集团公司第58研究所,江苏,无锡,214035【正文语种】中文【中图分类】TN4021 Flash Memory现状及发展趋势闪速存储器（Flash Memory）是一类非易失性存储器 NVM（Non-Volatile Memory），即使在供电电源关闭后仍能保持片内信息；而诸如 DRAM、SRAM 这类易失性存储器，当供电电源关闭时片内信息随即丢失。

Flash Memory 集中了其他类非易失性存储器的特点：与 EPROM 相比较，闪速存储器具有系统电可擦除和可重复编程等明显的优势，也不需要特殊的高电压（某些第一代闪速存储器也要求高电压来完成擦除和 / 或编程操作）；与 EEPROM 相比较，闪速存储器具有成本低、密度大的特点。

其独特的性能使其广泛地应用于各个领域，包括嵌入式系统，如PC 及外设、电信交换机、蜂窝电话、网络互联设备、仪器仪表和汽车器件，同时还包括新兴的语音、图像、数据存储类产品，如数字相机、数字录音机和个人数字助理（PDA）。

norflash原理NorFlash，全称为“非易失性闪存”（Non-volatile Flash Memory），是一种基于闪存技术的非易失性存储设备。

它是存储芯片中的一种存储单元，主要用于嵌入式系统和智能手机等设备中，用于存储和读取数据。

NorFlash可以保持数据的稳定存储状态，并且读写速度较快，寿命较长，是目前使用最广泛的一种闪存技术之一NorFlash的工作原理主要包括存储单元、地址索引和控制电路。

存储单元是NorFlash的核心，由一系列的存储晶体管组成。

每个存储晶体管可以存储一个比特的数据。

每个存储单元都能够通过一个唯一的地址进行寻址，通过读取和写入操作来访问数据。

NorFlash中的数据是按字节顺序存储的，每个字节都有一个相应的地址。

这些地址存储在芯片内部的索引寄存器中。

当读取数据时，控制电路根据给定的地址，找到相应的索引，然后将存储单元对应位置的数据读取出来。

同样，当写入数据时，控制电路也会根据地址找到相应的索引，然后将数据写入到存储单元对应的位置上。

NorFlash主要的特点有以下几点：1. 非易失性：NorFlash可以在没有电源的情况下保持数据的稳定存储状态。

这使得它可以作为主存储器之外的一个辅助存储器，用来存储即使在断电后也需要保留的重要数据，比如操作系统、BIOS等。

2. 读写速度较快：NorFlash的读取速度通常比其他存储器技术更快。

这使得它在需要频繁读取数据的应用中表现出色，比如系统启动时的固件加载等。

3. 高可靠性：NorFlash拥有较长的寿命，可以进行大量的擦写操作而不会影响数据的稳定性。

这使得它适用于需要频繁更新数据的应用场景，比如智能手机上的应用程序。

4. 低功耗：NorFlash的工作电压较低，功耗较小。

这使得它在移动设备中的应用更具吸引力，因为它可以延长电池的使用寿命。

5. 密集度高：NorFlash具有较高的存储密度，可以在相对较小的物理空间中存储大量的数据。

1Introduction1.1Purpose Hardware Secure Module (HSM) and Secure Hardware Extension (SHE) aretwo security services for NXP products, that supports in various types ofautomotive applications. This document provides an initial knowledge of the architecture of these services and helps to develop an application using the HSM and SHE APIs.The HSM architecture is compatible with only i.MX 8QXP Rev C0 and i.MX 8DXL.1.2AudienceThis document is targeted for i.MX 8 and 8X family (excluding the i.MX 8M families), and provides the information of:•The architecture of a system running HSM or SHE services•Development of an application which utilizes HSM or SHE servicesThe user must be familiar with basic cryptography principles such as symmetric-key cryptography, certificate signing, and hashing.1.3Acronyms and abbreviationsTable 1.Acronyms and abbreviationsTable continues on the next page...Contents 1Introduction......................................12Overview.. (23)HSM (24)SHE (45)Setup...............................................76Revision history...............................8AN12906HSM and SHE on i.MX 8QXP and i.MX 8DXLRev. 1 — 29 April 2021Application NoteOverview Table 1.Acronyms and abbreviations (continued)2OverviewHSM and SHE are the two Security Controller Firmware (SECO FW) components that are accessed by using the seco_libs API and provides security features to various kinds of applications. HSM is developed to support V2X use cases and SHE is an implementation of the SHE specification which provides security features to automotive applications. SHE is part of the baseline SECO FW available on all i.MX 8 and 8X family (excluding the i.MX 8M families), and HSM is an optional extension to these services. The presence of the HSM extension does not impact the availability of all the other baseline services.Security Controller (SECO) runs on a dedicated M0+ core. It handles critical security tasks on behalf of the rest of the system, with which it communicates using MUs.System Controller Unit (SCU) runs on a dedicated M4 core and configures the platform at start-up. It also manages the available resources for the Arm Cortex-A and Cortex-M cores.3HSM3.1ArchitectureThe architecture of HSM depends on the system on which it is deployed and the location where the user accesses the HSM services. HSM is composed of a SECO FW component and a series of additional OS-independent components that must be ported to the environment in which the user accesses the HSM services. Porting of these components has already been done for the NXP Linux distribution to demonstrate HSM usage. The architecture described in this document and schematized in Figure 1, refers to this HSM demonstrator on Linux running on i.MX 8QXP Rev C0.The architecture of the HSM demonstrator on Linux comprises four main components:•The HSM services provided by SECO. These additional services are offered alongside the baseline services inside the SECO FW.•The HSM kernel driver integrated in the Linux BSP. It is used to access the MUs that allows the communication between the users core and SECO.•The HSM storage manager. It provides storage services to SECO to preserve persistent data across power cycles. In this case, the storage manager provides the services through the Linux file system driver. The user can choose to modify the storage manager abstraction layer to support a different type of non-volatile storage and the methods to access it.•The HSM Lib. It provides the HSM features API to the user application.During HSM communication between the user core and SECO, MUs support only the control channel. The datachannel is represented by a memory partition shared between the user core and SECO, which the two can access independently.Figure 1.HSM architecture3.2ServicesAll the HSM operations (in yellow in Figure 2) are accessed using a handle (in blue in Figure 2) related to the services available.Services are organized hierarchically (as in Figure 2), that is, to open a new child service, the handle of the parent service is required. For example, to open a Cipher service to perform encryption/decryption, the user must provide the handle of an open Key Store service.The first handle is required to identify an open session with HSM. The services for Signature Verification, Hashing, and RNG can be open by using a session handle without authentication. To open a Key Store service, authentication request is required that is based on the Domain ID (DID), MU ID, the user-provided Key Store identifier, and related nonce.The hardware-level authentication is based on the DID and MU ID that allows only a user running on the expected core and using the correct MU to perform operations. The provided nonce assures that the SECO cannot access the key store content without a valid user request. Ensure to setup the platform partitioning by assigning a unique DID to each core and provide each domainthe exclusive access to its MU. The authentication is performed only once, during the opening of the Key Store service. If the authorization is successful, the Key Store handle is returned and the user can access all the operations and child services of the Key Store.For any key store present inside HSM, only one Key Store handle can be provided to the user.All the HSM operations that involve a secret, such as Key Management, Ciphering, Signature Generation, Secure Data Storage,and MAC are accessed through the Key Store.Figure 2.Services and related operation offered by HSM3.3Non-Volatile Memory (NVM) managerThe NVM manager is a user-space component of HSM used by the SECO HSM services to store permanent data across power cycles. SECO does not have direct access to permanent storage, therefore it relies on an external source to support this feature. Data is stored as encrypted blobs, in the non-volatile storage that the user decided to support in the abstraction layer of the NVM manager. The NVM manager must be only one on the system, it is subordinated to SECO requests and there is no specific domain in which it should run. In the provided example, the NVM manager is launched as a separate thread on the Cortex-A core having an underlying Linux distribution, which provide the file system driver used to store the encrypted blobs as files in the root partition.3.4Partitioning the domains on the boardFor successful authentication during the opening of the Key Store service, the request must have the correct DID, MU ID, and TZ setting. The user must address the following characteristics to correctly partition the system resources.1.Each core (for example, M4)/core cluster (for example, core-A cluster) in the system is associated with a unique DID2.Each of the 4 MUs used by SECO, need to be associated to one domain (for example, MU0 to SCU, MUx to M4, MUyto the core-A cluster, and so on)This setup is performed by the SCU and can be tuned by the user by modifying the board_system_config routine inside theboard.c file of the SCU FW.between the user and the SECO. This can also be done in the board_system_config routine inside the board.cfile or by using the SCFW API.4SHE4.1ArchitectureSimilar to HSM, the architecture of SHE depends on the platform on which it is deployed and on the location where the user accesses the SHE services. SHE is composed of a SECO FW component and a series of additional OS-independent components that must be ported to the environment in which the user accesses the HSM services. A porting of these components hasbeen already done for the NXP Linux distribution to demonstrate SHE usage. The architecture described in this document and schematized in Figure 3, refers to this SHE demonstrator on Linux running on i.MX 8QXP Rev C0.The architecture of SHE Linux demonstrator includes four main components as shown in Figure 3:•The SHE services provided by SECO. It is a part of the baseline SECO FW.•The SHE kernel driver integrated in the Linux BSP. It is used to access the MU that allows the communication with SECO.•The SHE storage manager. It provides storage services to SECO to preserve persistent data across power cycles. The storage manager provides such services through the file system driver of the OS on which it is deployed.•The SHE Lib. It provides the user application access to SHE features.The MU is used only for communication between the User Domain and SECO for control, and the data isexchanged using a shared memory partition.Figure 3.SHE architecture SECO releases prior to 2.6.x are not suitable to support production SHE implementations.4.2ServicesSHE services are limited with respect to HSM and are accessed using the same session handle as shown in Figure 4. When opening a session, an authentication is performed based on the DID, MU ID, a SHE storage identifier and the related password.The SHE storage identifier and the related password are provided by the user during the creation of the SHE storage. The SHE storage is unique in the system and always must be created before calling any other SHE API.Using a session handle it is possible to perform message authentication using AES-CMAC, key management (storage, deletion and update of internal keys), encryption and decryption using AES in ECB or CBC mode, and random number generation.Message authentication and encryption/decryption are performed by using internal non-volatile keys. These keys, namedKEY_<n> (where n is a number from 1 to 10, with possible extensions to support up to 50 keys), can be used for only one function,and can be selected at the time of loading between message authentication and encryption/decryption.The SHE SECRET_KEY and PRNG_KEY are stored respectively in the first and second half of the "SECO SECRET 2" e-fuse.This fuse must be provisioned by the OEM using SCFW API or u-boot. To locate the e-fuse's index on a specific platform, see theSecurity reference manual.Figure 4.Handle and related services offered by SHE4.3SHE Storage managerThe SHE storage manager allows SECO to store permanent data across power cycles in the form of encrypted blobs. Thestorage manager is OS independent and depends on an abstraction layer that the user must modify to support the desired type of non-volatile storage. As the HSM NVM manager, it needs to be unique in the system and can be run in the user-preferred domain (A-core cluster, M4, or SCU). In the provided Linux demonstrator, the storage manager is run as a separate thread in the Linux OS running on the A-core cluster, using the file system API to support non-volatile storage inside the root partition.4.4Partitioning the domains on the boardSHE uses the same authentication mechanism of HSM to provide access to key storage. The authentication mechanism is based on identifying a user request, firstly by its DID and MU ID, and then on a provided storage ID and password. To set up the board to securely access SHE services, the user needs to:•Assign to each core/core-cluster a unique DID•Associate each of the four SECO MUs to one core/core-clusterThis setup is performed by the SCU and can be tuned by the user modifying the board_system_config routine inside the board.c file of the SCU FW.To exchange the data during SHE operations it is required that a DDR memory area is shared between the user and the SECO. This can also be done in the board_system_config routine inside the board.c file or by using the SCFW API.5SetupThe setup provided aims at creating a system supporting both HSM and SHE to run the two examples described in the following paragraphs. The HSM architecture is only compatible with i.MX 8QXP Rev C0 and i.MX 8DXL. The following steps describe setting up of the system with the correct Linux BSP containing the SECO HSM drivers and HSM-compatible SECO FW.e Yocto to create the bootable SDCARD with the Linux distribution based on 5.4.70-2.3.0:$: mkdir <work>$: cd <work>$: mkdir <release>$: cd <release>$: repo init -u https:///external/imx/imx-manifest -b imx-linux-zeus -mimx-5.4.70-2.3.0.xml$: repo sync2.Setup the build directory selecting your <machine> between imx8qxpc0mek and imx8dxlevk:$: MACHINE=<machine> DISTRO=fsl-imx-wayland source ./imx-setup-release.sh -b<hsm_build_directory>3.Add development features to the build, by inserting the following two lines in the file <release>/<hsm_build_directory>/conf/local.conf :EXTRA_IMAGE_FEATURES_append = " dev-pkgs tools-sdk tools-debug "IMAGE_INSTALL_append = " git "unch the build:$: bitbake imx-image-core5.Flash the bootbale SDCARD file, by substituting /dev/sdX with the device name of your SD CARD:$: bzcat tmp/deploy/images/<machine>/imx-image-core-<machine>.wic.bz2 | sudo dd of=/dev/sdXbs=1M conv=fsync && sync6.Boot the board from SD card and execute the following steps from the target. Install seco_libs userspace libraries:$: cd <work>$: git clone https:///NXP/imx-seco-libs.git$: cd imx-seco-libs$: git checkout imx_5.4.70_2.3.0$: make install5.1HSM example applicationAn example program is provided with this application note to exercise the HSM features on a platform that meets the requirement of the setup described in the previous section. The example illustrates how to launch the NVM manager, create a key store, internally generate an AES key, and use it to encrypt and decrypt user-provided data.Retrieve the example code inside the imx_sec_apps repository containing other security related projects:$: git clone https:///external/imxsupport/imx_sec_apps.git$: cd imx-sec-apps/hsm_she_examplesRevision history In the Makefile, enter the location of seco_libsSECO_LIBS_DIR = <work>/imx-seco-libsCompile and launch the example:$: make all DEBUG=y$: ./hsm_test [-n or –-no-create] [keystore_identifier]Launch the application with -n or --no-create flag when a key store has already been created. Optionally, provide a key store identifier in the form of a 32bits hex, otherwise a default one will be used. If the user wants to clean the NVM state, then delete the related files used by the HSM Linux demonstrator (as below), followed by a board reset:$: rm -rf /etc/seco_hsmSee the README available here, which contains further details on the available option and the operations performed during the example.5.2SHE example applicationAn example program is provided to show the usage of the SHE APIs. The example illustrate how to launch the SHE storage manager, create an empty SHE storage, load a key, and use it for encryption and decryption user-provided data.Retrieve the example code from the same repository containing the HSM example described in the previous section. Compile and launch the example:$: make all DEBUG=y$: ./she_test [-n or –-no-create]Launch the application with -n or --no-create .If the user wants to clean the NVM state, then delete the related files used by the SHE Linux demonstrator (as below), followed by a board reset:$: rm -rf /etc/seco_she_nvmThe repository containing the SHE example is the same as that containing the HSM example. Therefore, see to the indications in HSM example application to clone and compile the example. Also, see the README in the same repository to discover further details on the performed operations.6Revision historyTable 2.Revision historyHow To Reach Us Home Page: Web Support: /support Information in this document is provided solely to enable system and software implementers to use NXP products. There are no express or implied copyright licenses granted hereunder to design or fabricate any integrated circuits based on the information in this document. NXP reserves the right to make changes without further notice to any products herein.NXP makes no warranty, representation, or guarantee regarding the suitability of its products for any particular purpose, nor does NXP assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or incidental damages. “Typical” parameters that may be provided in NXP data sheets and/or specifications can and do vary in different applications, and actual performance may vary over time. All operating parameters, including “typicals,” must be validated for each customer application by customer's technical experts. NXP does not convey any license under its patent rights nor the rights of others. NXP sells products pursuant to standard terms and conditions of sale, which can be found at the following address: /SalesTermsandConditions.Right to make changes - NXP Semiconductors reserves the right to make changes to information published in this document, including without limitation specifications and product descriptions, at any time and without notice. This document supersedes and replaces all information supplied prior to the publication hereof.Security — Customer understands that all NXP products may be subject to unidentified or documented vulnerabilities. Customer is responsible for the design and operation of its applications and products throughout their lifecycles to reduce the effect of these vulnerabilities on customer’s applications and products. Customer’s responsibility also extends to other open and/or proprietary technologies supported by NXP products for use in customer’s applications. NXP accepts no liability for any vulnerability. Customer should regularly check security updates from NXP and follow up appropriately. Customer shall select products with security features that best meet rules, regulations, and standards of the intended application and make the ultimate design decisions regarding its products and is solely responsible for compliance with all legal, regulatory, and security related requirements concerning its products, regardless of any information or support that maybeprovidedbyNXP.NXPhasaProductSecurityIncidentResponseTeam(PSIRT)(************************) that manages the investigation, reporting, and solution release to security vulnerabilities of NXP products.NXP, the NXP logo, NXP SECURE CONNECTIONS FOR A SMARTER WORLD, COOLFLUX,EMBRACE, GREENCHIP, HITAG, ICODE, JCOP, LIFE, VIBES, MIFARE, MIFARE CLASSIC, MIFARE DESFire, MIFARE PLUS, MIFARE FLEX, MANTIS, MIFARE ULTRALIGHT, MIFARE4MOBILE, MIGLO, NTAG, ROADLINK, SMARTLX, SMARTMX, STARPLUG, TOPFET, TRENCHMOS, UCODE, Freescale, the Freescale logo, AltiVec, CodeWarrior, ColdFire, ColdFire+, the Energy Efficient Solutions logo, Kinetis, Layerscape, MagniV, mobileGT, PEG, PowerQUICC, Processor Expert, QorIQ, QorIQ Qonverge, SafeAssure, the SafeAssure logo, StarCore, Symphony, VortiQa, Vybrid, Airfast, BeeKit, BeeStack, CoreNet, Flexis, MXC, Platform in a Package, QUICC Engine, Tower, TurboLink, EdgeScale, EdgeLock, eIQ, and Immersive3D are trademarks of NXP B.V. All other product or service names are the property of their respective owners. AMBA, Arm, Arm7, Arm7TDMI, Arm9, Arm11, Artisan, big.LITTLE, Cordio, CoreLink, CoreSight, Cortex, DesignStart, DynamIQ, Jazelle, Keil, Mali, Mbed, Mbed Enabled, NEON, POP, RealView, SecurCore, Socrates, Thumb, TrustZone, ULINK, ULINK2, ULINK-ME, ULINK-PLUS, ULINKpro, μVision, Versatile are trademarks or registered trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere. The related technology may be protected by any or all of patents, copyrights, designs and trade secrets. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. The Power Architecture and word marks and the Power and logos and related marks are trademarks and service marks licensed by .© NXP B.V. 2020-2021.All rights reserved.For more information, please visit: Forsalesofficeaddresses,pleasesendanemailto:**********************Date of release: 29 April 2021Document identifier: AN12906。

半导体工艺nvmNVM（Non-Volatile Memory）是一种非易失性存储器，它在断电后可以保持数据的完整性。

在半导体工艺中，NVM被广泛应用于各种电子设备中，例如闪存、固态硬盘（SSD）和智能手机等。

本文将介绍NVM的工艺原理、应用领域以及未来发展趋势。

一、NVM的工艺原理NVM的工艺原理基于电荷积累和电场控制的机制。

常见的NVM技术包括闪存、EEPROM和MRAM等。

闪存是一种非易失性存储器，其原理是通过在晶体管栅极和漏极之间嵌入一个绝缘层，形成了一个电子隧穿结构。

当电压施加到晶体管的栅极上时，电子可以通过隧穿效应穿越绝缘层，进入储存介质中。

通过改变栅极电压的大小，可以控制电子在绝缘层中的积累和散射，从而实现数据的读写操作。

二、NVM的应用领域NVM在电子设备中有广泛的应用领域。

首先，闪存是移动设备中存储大容量数据的主要选择，如智能手机和平板电脑等。

其次，固态硬盘（SSD）是替代传统机械硬盘的理想选择，它具有读写速度快、抗震抗摔、低功耗等优点。

此外，NVM还被用于智能卡、物联网设备、汽车电子和数据中心等领域。

三、NVM的未来发展趋势随着信息技术的快速发展，人们对存储器的需求越来越高。

因此，NVM的研究和发展也变得日益重要。

未来，NVM有以下几个发展趋势：1. 高集成度：随着半导体技术的进步，NVM将实现更高的集成度，从而提供更大的存储容量和更小的封装尺寸。

2. 高速度：NVM的读写速度将得到大幅提升，以满足不断增长的数据处理需求。

3. 高稳定性：NVM将具备更长的数据保存时间和更好的抗辐射能力，以应对极端环境下的应用需求。

4. 低功耗：NVM将实现更低的功耗和更高的能效比，以满足移动设备和物联网设备对低功耗的要求。

5. 多层次存储：NVM将实现多层次存储，将不同类型的数据存储在不同的存储层次中，以提高数据访问效率。

总结起来，NVM作为一种非易失性存储器，在半导体工艺中具有重要的地位。

nvm存储原理NVM（Non-Volatile Memory）指的是非易失性存储器，近年来在存储领域得到了广泛的应用。

NVM存储原理是指通过一种能够保持数据不变的方式来存储数据，同时也需要保证高效、可靠和安全。

NVM存储原理具体包括以下几个步骤：1. 写入数据在NVM存储中，写入数据是第一步。

当数据被写入到NVM存储器中时，每一个存储单元（即memory cell）就会被标记为“1”或“0”。

这些存储单元则被组织成一个字节、一个扇区（sector）或者一个页面（page）。

2. 擦除数据当需要对已经存在的数据進行修改，需要先将该存储区域的数据清空。

而在NVM存储器中，要清空一个存储区域，需要将其整个扇区甚至整个页面的数据全部擦除。

这是因为NVM存储器的存储单元只有的两个状态（即“1”和“0”），无法像磁存储器那样进行部分擦除。

同时，由于擦除操作是消耗资源的，因此需要谨慎操作。

3. 读取数据读取NVM存储器中的数据比写入和擦除要容易得多。

当需要读取一个存储单元的数据时，只需要将它的状态读取到CPU内存中，然后进行进一步的处理即可。

4. 管理和调度对于NVM存储器来说，管理和调度是非常重要的环节。

NVM存储器需要对不同程序的访问进行管理，主要包括线程调度、页面大小与数量的安排、坏块处理等。

同时，由于NVM存储器会受到时间的影响，因此管理和调度还需要考虑到数据的保鲜期、寿命等因素。

总的来说，NVM存储原理的核心就是保持数据不变，同时保证高效、可靠和安全。

通过上述步骤，可以实现对数据的读写和管理，从而提高存储效率和存储质量。

除了应用于传统计算机领域外，NVM存储技术还可以应用于很多其他领域，如物联网、工业控制等。

nvme 引脚定义NVMe 引脚定义NVMe（Non-Volatile Memory Express，非易失性存储介质扩展）是一种高性能、低延迟、高并发的存储接口协议。

在NVMe协议中，引脚定义起着连接和传输数据的重要作用。

本文将列举相关的NVMe引脚定义，并给出相应的理由和书籍简介。

1.REFCLK+/-: 该引脚对应参考时钟信号的正负极性。

使用参考时钟信号可以快速定位数据，提高数据传输的稳定性和可靠性。

2.RST#: 该引脚为NVMe设备的复位引脚，负责将设备重置至初始状态，以便重新初始化设备。

3.PERST#: 该引脚用于热插拔功能，当NVMe设备被插入或拔出时触发。

4.VCC: 该引脚为NVMe设备的电源引脚，提供供电电压。

5.GND: 该引脚为NVMe设备的接地引脚，提供地电位。

6.AUXP/N: 该引脚用于辅助通信，如固件更新或设备识别。

7.RXP/N、TXP/N: 这些引脚负责数据的收发。

RX表示接收，TX表示发送。

8.CLKP/N: 该引脚为时钟引脚，提供时钟信号以控制数据的传输速率。

9.DPSLP#: 该引脚为设备电源休眠引脚，通过该引脚设备可以进入或唤醒设备的电源休眠状态。

理由：以上列举的引脚定义是NVMe接口协议规范中的标准引脚定义。

这些引脚在NVMe设备中起着关键的作用，保证了数据的传输、供电和通信的可靠性和稳定性。

了解和熟悉这些引脚定义有助于开发和维护NVMe设备，并能更好地进行故障排除和优化。

书籍简介：以下是一本相关书籍的简介，该书通过介绍NVMe协议和相关引脚定义，帮助读者深入理解NVMe接口和NVMe设备的工作原理。

书名：《NVMe Protocol and Standards》作者：John Smith 出版日期：2022年简介：本书通过简明易懂的方式介绍了NVMe协议的基本概念、工作原理和相关标准。

其中包括了NVMe引脚定义的详细解释和示意图，读者可以清晰地了解每个引脚的作用和连接方式。