HC1109102_HCNA-Storage V2_BSSN_第二章 存储与应用环境

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.。

H3C S5110-CMW520-R1102版本说明书Copyright © 2013杭州华三通信技术有限公司版权所有，保留一切权利。

非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。

本文档中的信息可能变动，恕不另行通知。

目录1 版本信息 (1)1.1 版本号 (1)1.2 历史版本信息 (1)1.3 版本配套表 (1)1.4 版本升级注意事项 (2)2 硬件特性变更说明 (2)2.1 S5110-CMW520-R1102版本硬件特性变更说明 (2)2.2 S5110-CMW520-E1101版本硬件特性变更说明 (2)3 软件特性及命令行变更说明 (2)3.1 S5110-CMW520-R1102版本软件特性及命令行变更说明 (2)3.2 S5110-CMW520-E1101版本软件特性及命令行变更说明 (3)4 MIB变更说明 (3)5 操作方式变更说明 (3)5.1 S5110-CMW520-R1102版本操作方式变更 (3)5.2 S5110-CMW520-E1101版本操作方式变更 (3)6 版本使用限制及注意事项 (3)7 存在问题与规避措施 (4)8 解决问题列表 (5)8.1 S5110-CMW520-R1102版本解决问题列表 (5)8.2 S5110-CMW520-E1101版本解决问题列表 (6)9 相关资料 (6)9.1 相关资料清单 (6)9.2 资料获取方式 (6)10 技术支持 (6)附录 A 本版本支持的软、硬件特性列表 (7)A.1 版本硬件特性 (7)A.2 版本软件特性 (8)附录 B 版本升级操作指导 (9)B.1 加载方式简介 (10)B.2 本地加载 (10)B.2.1 BOOT菜单 (10)B.2.2 通过Console口利用XModem完成加载 (11)B.2.3 通过以太网口利用TFTP完成加载 (15)B.3 远程加载 (17)B.3.1 通过FTP实现远程加载 (17)B.3.2 通过TFTP实现远程加载 (18)表目录表1 历史版本信息表 (1)表2 版本配套表 (1)表3 MIB文件变更说明 (3)表4 产品硬件特性 (7)表5 产品软件特性 (8)1 版本信息1.1 版本号版本号：Comware Software, Version 5.20.99, Release 1102注：该版本号可在命令行任何视图下用display version 命令查看，见注①1.2 历史版本信息表1 历史版本信息表 版本号 基础版本号 发布日期 版本类型 备注 S5110_10P-CMW520-R1102 S5110_10P-CMW520-E11012013-11-08 正式版本 S5110_10P_PWR-CMW520-R1102 首次发布S5110_28P-CMW520-R1102 S5110_28P-CMW520-E1101S5110_28P_PWR-CMW520-R1102 首次发布S5110_52P-CMW520-R1102 S5110_52P-CMW520-E1101S5110_10P-CMW520-E1101首次发布 2013-09-02 正式版本首次发布S5110_28P-CMW520-E1101S5110_52P-CMW520-E1101 1.3 版本配套表在升级版本之前，请注意与本版本配套的软、硬件条件必须符合下表的要求。

华为存储MIB接口说明文档版本01发布日期2016-03-30华为技术有限公司版权所有 ? 华为技术有限公司2015。

保留一切权利。

非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。

商标声明和其他华为商标均为华为技术有限公司的商标。

本文档提及的其他所有商标或注册商标，由各自的所有人拥有。

注意您购买的产品、服务或特性等应受华为公司商业合同和条款的约束，本文档中描述的全部或部分产品、服务或特性可能不在您的购买或使用范围之内。

除非合同另有约定，华为公司对本文档内容不做任何明示或默示的声明或保证。

由于产品版本升级或其他原因，本文档内容会不定期进行更新。

除非另有约定，本文档仅作为使用指导，本文档中的所有陈述、信息和建议不构成任何明示或暗示的担保。

华为技术有限公司地址：深圳市龙岗区坂田华为总部办公楼邮编：518129网址：目录1 概述本文档介绍了存储设备实现的各种MIB，包括各个MIB的功能、表间关系、单节点详细描述、MIB Table详细描述、告警节点详细描述。

读者对象本文档主要适用于以下人员：应用开发人员内容简介本文档包含1篇总体介绍和多个具体MIB参考文档，内容如下。

章节内容1 MIB简介主要介绍网络管理、基于SNMP的网络管理体系结构组成、SNMP协议、以及MIB的基本概念和操作。

2 MIB参考以MIB名称命名2 MIB介绍2.1 网络管理概述随着网络的规模越来越庞大，网络中的设备种类繁多，如何对越来越复杂的网络进行有效的管理，从而提供高质量的网络服务已成为网络管理所面临的最大挑战。

网络管理已成为整个网络解决方案中重要的一部分。

网络管理通常包含4个要素：被管理节点：需要进行管理的设备。

代理（Agent）：跟踪被管理设备状态的软件或硬件。

网络管理工作站（Manager）：与在不同的被管理节点中的代理通信，并且显示这些代理状态的设备。

网络管理协议：网络管理工作站和代理用来交换信息的协议。

主机服务器大部分I/O开始于需要访问数据的应用，应用通常不考虑存储后端的操作细节，而是直接调用由操作系统提供的系统调用接口，然后由操作系统支持的文件系统为数据提供数据的逻辑地址和在磁盘上存储的物理地址的映射，再通过设备驱动层，主要是SCSI协议的操作，将数据存储到存储设备（比如主机服务器内部硬盘）上。

因此主机服务器内部数据存储I/O流程中的各个环节对数据存储的可靠性、性能和安全性都起到非常重要作用，从独立的主机服务器来看，其内部I/O流程各个环节即共同构成了存储的内部应用环境。

在传统的计算机存储系统中，存储工作通常是由计算机内置的硬盘来完成，而采用这样的设计方式，硬盘本身的缺陷很容易成为整个系统的性能瓶颈，并且，由于机箱内有限的空间，限制了硬盘数量的扩展，并且同时也对机箱内的散热、供电等提出了严峻的挑战。

再加上不同的计算机各自为战，使用各自内置的硬盘，导致从总体看来存储空间的利用率较低，并且分散保存的数据也不利于数据的共享和备份工作。

在传统的C/S架构中，无论使用的是何种协议，存储设备都直接与服务器相连接。

在这样的结构下，对存储设备上所保存的所有数据的任何读写操作，都必须由服务器来进行，这样的处理方式给服务器带来了沉重的负担。

外部存储系统的出现，彻底将服务器从繁琐的I/O操作中解放出来，使服务器更加专门化，使之仅仅承担应用数据的操作任务，以更充分的释放自身潜能。

网络存储系统按照不同的功能，可划分为三层：第一层：主机层，运行相关应用，发起存储IO操作。

在主机侧需要存储连接的设备主要有FC HBA卡，iSCSI HBA卡，以太网卡，需在主机侧安装的存储连接软件包括：initiator启动器,open-iscsi,多路径软件等。

第二层：网络层，将主机与存储层互联，提供网络通路，可采用FC网络或者以太网络的方式；以太网络可利用原有以太网络连接，利用现有资源组网。

FC网络需要建立专门的网络，速度快，但是FC器件都较昂贵，成本高。

实验二双端口存储器原理实验一、实验目的（1）了解双端口静态随机存储器IDT7132的工作特性及使用方法。

（2）了解半导体存储器怎样存储和读出数据。

（3）了解双端口存储器怎样并行读写，产生冲突的情况如何。

二、实验电路图7 双端口存储器实验电路图图7示出了双端口存储器的实验电路图。

这里使用了一片IDT7132（U36）(2048×8位)，两个端口的地址输入A8—A10引脚接地，因此实际使用存储容量为256字节。

左端口的数据部分连接数据总线DBUS7—DBUS0，右端口的数据部分连接指令总线INS7—INS0。

一片GAL22V10(U37)作为左端口的地址寄存器（AR１），内部具有地址递增的功能。

两片４位的74HC298(U28、U27)作为右端口的地址寄存器（AR2H、AR2L），带有选择输入地址源的功能。

使用两组发光二极管指示灯显示地址和数据：通过开关IR/DBUS 切换显示数据总线DBUS和指令寄存器IR的数据，通过开关AR1/AR2切换显示左右两个端口的存储地址。

写入数据由实验台操作板上的二进制开关SW0—SW7设置，并经过SW_BUS三态门74HC244(U38)发送到数据总线DBUS上。

指令总线INS的指令代码输出到指令寄存器IR(U20)，这是一片74HC374。

存储器IDT7132有6个控制引脚：CEL#、LRW、OEL#、CER#、RRW、OER#。

CEL#、LRW、OEL#控制左端口读、写操作，CER#、RRW、OER#控制右端口读、写操作。

CEL#为左端口选择引脚，低有效。

当CEL# =1时，禁止左端口读、写操作；当CEL# =0 时，允许左端口读、写操作。

当LRW为高时，左端口进行读操作；当LRW为低时，左端口进行写操作。

当OEL#为低时，将左端口读出的数据放到数据总线DBUS上；当OEL#为高时，禁止左端口读出的数据放到数据总线DBUS上。

CER#、RRW、OER#控制右端口读、写操作的方式与CEL#、LRW、OER#控制左端口读、写操作的方式类似，不过右端口读出的数据放到指令总线上而不是数据总线上。

海光BIOS保护卡使用手册北京海光科技开发有限公司E-Mail: lwb@本手册使用的所有产品商标与产品名称均属于北京海光科技开发有限公司。

在软件版本升级后，该发行使用手册中的一些界面可能与软件实际界面有出入，请以实际界面为准。

手册内容如有修改将不另行通知。

保护卡上的任何贴纸请勿自行撕毁，否则将会影响到产品的质保期限的认定，本公司有权拒绝更换。

目录第一章海光BIOS保护卡及操作系统的安装 (4)1－1 安装前的准备 (4)1－2 安装发送端 (5)1－3 网络拷贝 (14)1－4 硬盘复制 (19)第二章自动维护 (20)第三章系统设定 (22)第四章Max－Control/USER使用方法 (27)第五章自动分配IP操作流程 (31)附录一热键提示 (35)附录二硬盘大传小功能 (35)附录三 LINUX系统安装说明 (35)附录四网域登录使用方式 (38)附录五常见问题解答 (41)海光BIOS保护卡安装流程第一章海光BIOS保护卡及操作系统的安装首先非常感谢您使用海光产品。

海光BIOS保护卡能大批量地完成整个计算机机房系统及软件的安装或更新。

先将一台安装好海光BIOS 保护卡系统、操作系统及应用软件的计算机设定为发送端，其余所有的计算机利用海光BIOS保护卡附带的SNCOPY网络联机拷贝盘设定为接收端，通过网络将发送端的硬盘数据同时复制到所有的计算机中，并自动修改所有计算机的IP地址等网络设置，完成整个计算机机房系统的安装和更新。

1－1 安装前的准备安装本系统前，请您确认以下相关事项：1、请进入您计算机CMOS管理界面1.将CMOS中的病毒警告关闭。

2.将CMOS中显卡以外的映射地址设为Disable。

3.将CMOS中的Network/LAN引导选项，设为Enabled或设定为网络优先启动（该项没有,可以不设定）。

4.如CMOS中有Fast Boot的选项，请将此项设定为Disable（该项没有,可以不设定）。