一种软硬件协同片上系统诊断方法与流程

1.本发明属于芯片调试领域，特别涉及一种软硬件协同片上系统诊断方法。


背景技术：

2.在芯片调试阶段，片内数据和指令的跟踪对于片上系统的诊断是至关重要的。在片上处理器调试过程，需要解决处理器运行状态的实时跟踪观测问题。越来越多的处理器厂商开始提供硬件片上trace即跟踪功能。片上trace系统通过专用硬件设计，以非入侵方式实时记录程序执行路径和数据读写等信息，随后将有效信息压缩成trace数据流，然后通过专用数据通道传输至调试主机，最后通过外部接收工具接收解压缩trace数据流，恢复程序运行信息以进行系统调试和性能分析。常用的两种片上调试方法包括软件日志调试方法和coresight trace数据分析方法。
3.其中，软件日志调试是指在系统软件运行过程中，额外加入开发的日志调试程序，该日志调试程序随系统软件一起运行，对系统运行状态进行记录，对寄存器状态和软件执行或跳转标记进行日志生成，通过预留调试接口(通常为uart通用异步收发传输器)对外输出，由外部工具进行接收存储为文本形式，最后由调试人员进行系统分析和调试。所述uart是一种异步收发传输器。它将要传输的资料在串行通信与并行通信之间进行转换。作为将并行输入信号转成串行输出信号的芯片，uart通常被集成于其他通讯接口的连结上。uart工作原理分为发送数据过程和接收数据过程，具体接口连接方式如图1所示。发送数据端tx用于连接对端设备的接收数据端rx。gnd为接地端，保证收发设备共地，具有统一的参考平面，在发送数据过程中，空闲状态下线路处于高电平；当收到发送数据指令后，拉低线路一个数据位的时间，然后数据按低位到高位依次发送，数据发送完毕后，然后发送奇偶校验位和停止位(停止位为高电平)，一帧数据发送结束。而在接收数据过程中，空闲状态下线路处于高电位；当检测到线路的下降沿即线路电位由高电位变为低电位时说明线路存在数据传输，按照约定的波特率从低位到高位接收数据，数据接收完毕后，然后接收并比较奇偶校验位是否正确，如果正确，则通知后续设备准备接收数据或存入缓存。由于uart传输速率较低，在面对cpu多核复杂场景下生成的日志信息，可能影响对外输出，进而导致日志信息即使已经正常生成也不能快速无损地输出至片外，造成日志记录丢失，最终影响系统调试分析。软件日志程序的开发编写也受到uart传输速率的限制，在调试过程中还需要反复修改日志输出代码或等级以控制信息量大小和适应输出带宽，势必造成软件程序维护成本过高和使用便捷性较低。
4.此外，尽管软件日志调试方法可以直观的记录反映片内寄存器状态和软件预设标记，帮助测试人员进行系统问题大致定位，但是对于较复杂的系统问题难以进行更深层次分析。为支持软件日志输出功能，在芯片封装加工时还需要保留专用的对外调试接口，增加了封装成本。例如在分析cpu多核协同工作场景时，系统软件本身就较复杂，再加上额外的调试程序会造成整个软件复杂度极大增加。此外，硬件内部数据流控制和状态机跳转逻辑全部由硬件电路设计实现，一旦芯片制造出来后这些电路就难以更改，而软件通常难以获
取硬件内部状态机和关键数据流等实时信息，因此硬件自身设计的复杂性和不可观测性会极大地增加芯片工作异常的风险。如果芯片工作过程中出现异常，仅靠典型软件日志数据进行硬件诊断，很有可能出现系统问题无法定位和分析的情况。
5.所述coresight trace数据分析方法建立在开放体系结构coresight的基础上。soc设计人员能够将其他ip内核的调试和跟踪功能添加到coresight基础结构中。coresight包括arm处理器的各种跟踪宏单元、系统和软件测量以及一整套ip块，以便对各种复杂的多核soc进行调试和跟踪。coresight网络中通常包括trace通路。trace通路用于将cpu core即处理器核的内部信息输出到外部。通过coresight网络的trace通路，可以实现对cpu core的数据追踪功能。典型的cpu(4cores)coresight网络的trace通路如图2所示。etm(embedded trace macrocell)负责追踪处理器的信息，将信息封装并通过atb总线(amba trace bus)发送到trace总线上。通过配置trace总线上的coresight funnel和replicator组件，将atb数据发送给coresight etb(embedded trace buffer)和tpiu组件(trace port interface)，最终输出至片外。cpu每个core在运行期间由各自etm对其监控并以atb格式输出对应追踪信息。coresight funnel组件通过配置将接收到的4路atb数据输出为1路atb数据后，送至coresight replicator组件。coresight replicator组件将接收到的1路atb数据复制为2路，分别送至coresight tpiu和coresight etb组件。coresight tpiu组件将接收到的atb数据通过内部处理后以串行方式，从芯片管脚发送到片外。其中trace_out_clk为输出时钟，供外部工具采样使用；trace_ctrl和trace_data为待采样数据，由外部工具使用trace_out_clk对其进行双沿采样，从而实现数据接收。而coresight etb组件将接收到的atb数据缓存至其内部ram中，由外部调试工具进行数据读取。coresight网络的trace通路通过对其内部cpu的运行进行数据追踪，输出至片外进行系统分析，能够解决较为复杂的系统问题。
6.尽管利用典型coresight trace数据进行系统问题分析能够对片内进行硬件数据流和指令流追踪，但coresight trace数据由etm生成，抓取的是片内硬件数据流和指令流。为节约片上数据带宽，通常采用高压缩率算法，导致数据不具备直接可读性，需要通过片外专用的解析工具进行数据还原才能查看使用。而抓取的trace数据只包含硬件追踪信息，与系统运行期间最直观的调试信息即各模块寄存器状态值或软件标记等信息缺乏关联性。并且trace数据格式固定，只能通过配置切换为有限种类的数据格式，而不支持加入用户自定义数据格式。软件调试信息是针对实际系统应用场景进行开发维护的，通常这些信息能够较直观的反映系统运行状态，而无需专用工具进行数据还原解析。由于不支持加入灵活的软件调试信息，因此不能较好的支持系统软硬件协同诊断分析。


技术实现要素：

7.本发明的目的在于提供一种软硬件协同片上系统诊断方法，以解决传统的软件日志调试方法和传统coresight trace数据分析方法存在的问题。所述软硬件协同片上系统诊断方法包括：
8.接收片上系统的硬件trace数据，当所述片上系统的cpu在运行中检测到命令执行异常时，将软件日志数据进行缓存；
9.监测所述软件日志数据的缓存数据量，当所述缓存数据量达到预定义阈值时，读
出所缓存的软件日志数据；
10.根据读出的所述软件日志数据生成软件trace数据，并将所述硬件trace数据和所述软件trace数据输出到片外进行解析。
11.优选地，所述片上系统包括日志信息缓存单元，用于缓存所述软件日志数据，当所述片上系统cpu为多核处理器时，所述日志信息缓存单元具有多个缓存模块，每个缓存模块与所述片上系统的一个处理器核相对应，用于缓存相应处理器核独立生成的软件日志数据。
12.优选地，所述片上系统包括trace数据生成单元，所述根据读出的所述软件日志数据生成软件trace数据，进一步包括：
13.由所述trace数据生成单元读出所述日志信息缓存单元所缓存的软件日志数据，其中将软件日志数据封装转换为atb格式的软件trace数据。
14.优选地，所述软件日志数据包括trace id信息，用于标识处理器核，当对所述trace数据进行解析时，通过atb格式的trace数据中的trace id信息来确定该数据所属的处理器核。
15.优选地，所述监测所述软件日志数据的缓存数据量，进一步包括：
16.由所述trace数据生成单元采用轮询方式循环读取所述多个缓存模块中缓存的软件日志数据，当读出所缓存的软件日志数据时，每次读取固定长度的软件日志数据。
17.优选地，所述预定义阈值和所述固定长度均为可配置参数。
18.优选地，所述软件日志数据包括cpu的关键寄存器状态和软件执行标记。
19.优选地，所述硬件trace数据和所述软件日志数据均包括时间戳信息，用于表示当前系统时间。
20.优选地，所述将硬件trace数据和软件trace数据输出到片外进行解析，进一步包括：根据所述时间戳信息，将硬件trace数据和软件日志数据进行合并整理。
21.优选地，所述将硬件trace数据和软件trace数据输出到片外进行解析，进一步包括：
22.将所述硬件trace数据和所述软件trace数据通过coresight trace网络转换为tpiu标准输出时序并输出到片外，利用外部接收工具存储并解析atb格式的软件trace数据，以识别所述软件日志数据。
23.相比于现有技术，本发明具有以下优点：
24.本发明的方法得到的trace数据同时包含软件日志数据和硬件trace数据，将软硬件信息有效关联起来更有利于进行软硬件协同分析定位，便于测试人员获取错误场景下的硬件trace数据和系统运行期间最直观的调试信息。通过复用既有的coresight tpiu端口，节约了芯片pad资源，同时降低了封装成本。在单位时间内能够提供更多的调试信息，降低了软件维护及调试时间成本。所生成的日志信息能够较直观的反映系统运行状态和具备较强的可读性和灵活性，更符合测试人员的使用习惯，能够大幅提高产品调试效率，克服了传统软件日志调试方法和传统coresight trace数据分析方法存在的缺陷。
25.本发明的其它特征和优点将在随后的说明书中阐述，并且部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可以通过在说明书、权利要求书以及附图中所指出的结构来实现和获取。
附图说明
26.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单介绍，显而易见地，下面描述中的附图是本发明的某些实施例，对于本领域普通技术人员来说，在不付出创造性劳动的前提下，还可以根据这些附图获取其他的附图。
27.图1示出了根据现有技术的典型uart连接结构示意图。
28.图2示出了根据现有技术的典型coresight网络的trace通路示意图。
29.图3示出了根据本发明的软硬件协同片上系统诊断方法实现架构示意图。
30.图4示出了根据本发明的log_trace_gen单元状态迁移控制示意图。
31.图5示出了根据本发明的软硬件协同片上系统诊断方法的执行流程示意图。
32.图6示出了根据本发明的软硬件协同片上系统诊断过程的控制流图。
33.图7示出了根据现有技术的sata dma写操作的帧通信状态示意图。
34.图8示出了根据现有技术的dma写操作正确条件下的trace数据示意图。
35.图9-图11示出了根据现有技术的dma写操作的不同错误条件下的trace数据示意图。
36.图12示出了根据本发明的软硬件协同片上系统诊断方法生成的在dma写操作正确条件下的软件trace数据示意图。
37.图13-图15示出了根据本发明的软硬件协同片上系统诊断方法生成的在dma写操作的不同错误条件下的软件trace数据示意图。
38.图16-图18示出了根据本发明的将软件日志数据和硬件trace数据合并整理后的软硬件trace数据示意图。
具体实施方式
39.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地说明，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获取的所有其他实施例，都属于本发明保护的范围。
40.针对传统的软件日志调试方法和传统coresight trace数据分析方法存在的局限性和缺陷，本发明提出了一种软硬件协同片上系统诊断方法，将软件日志数据缓存封装处理后加入到coresight trace网络，然后将包含软件日志和硬件信息的trace数据输出至片外，解析过滤筛选关键数据，将软硬件信息进行关联、匹配和整合，利用软件日志数据的灵活性及直观可读性和硬件内部关键追踪信息，最后通过软硬件协同系统诊断的方法快速有效地实现系统问题定位分析，以此解决软件日志调试方法无法应对较复杂系统较深层次问题分析、需保留对外调试端口(uart)和数据传输速率偏低的问题，以及传统coresight trace数据分析方法与软件运行的关联性弱并且不支持用户自定义数据格式以及灵活性较差的问题，从而增强系统问题诊断分析能力，提高系统问题分析效率和节约芯片调试成本。
41.本发明首先在典型coresight网络基础架构上，设置log_buf和log_trace_gen单元，将软件日志数据加入到coresight trace网络，并支持多核处理器并行生成独立的软件日志信息，通过解析输出到片外的软硬件trace数据完成系统问题诊断分析。图3为本发明
软硬件协同片上系统诊断方法实现架构的示意图，可见本发明设计由发明单元和标准ip单元组成，其中发明单元包括log_buf和log_trace_gen单元，标准ip单元为coresight组件单元。
42.所述log_buf单元为日志信息缓存单元。该单元内部包含多个缓存模块core_buf，分别用于缓存处理器核的软件日志数据。如图3所示，log_buf单元通过apb总线(advanced peripheral bus)与cpu进行通信。core 0_buf～core 3_buf分别用于缓存cpu core 0～cpu core 3通过apb总线写入的软件日志数据。每个core_buf数据宽度为32位，深度为64。在具体的应用中，缓存模块的设计参数可以根据实际应用进行调整。
43.所述log_trace_gen单元为trace数据生成单元。该单元控制读取log_buf单元中缓存的软件日志数据，然后将数据封装转换为标准的atb格式，最后传输至coresight trace网络。
44.所述log_buf单元和log_trace_gen单元工作机制如下。当core 0_buf～core 3_buf写入的日志数据量超过预定义的阈值时，log_trace_gen单元采用轮询方式循环读取core 0_buf～core 3_buf缓存的软件日志数据，每次读取固定长度的软件日志数据。其中所述阈值和固定长度都是可配置参数。其中各buf可通过配置进行独立使能控制，即可屏蔽不期望的数据源。log_trace_gen单元读取日志数据的状态机迁移控制图如图4所示。采用轮询的方式监测log_buf单元内不同缓存模块的日志数据大小是否达到预定义阈值，当监测到某个缓存模块到达阈值后，将其缓存数据读取到log_trace_gen单元中。
45.图5示出了根据本发明的软硬件协同片上系统诊断方法的总体流程图。以图3的片上系统网络架构为基础，将本发明的片上系统具体诊断流程描述如下：
46.步骤101：接收片上系统的硬件trace数据，当所述片上系统的cpu在运行中检测到命令执行异常时，将软件日志数据进行缓存。
47.结合图6从事件的角度所描述的软硬件协同片上系统诊断方法的执行流程图，在事件t1中，cpu core 0执行程序，通过配置etm生成对应trace数据，利用coresight trace网络将数据传输至coresight funnel单元。在事件t2中，coresight funnel单元通过配置将接收到的trace数据传递至coresight replicator单元。事件t3中coresight funnel单元将trace数据复制2份，分别传输至coresight tpiu单元和etb单元，etb用于内部缓存，可通过外部调试工具读出数据，在事件t4中，coresight tpiu单元将trace数据转换为tpiu标准输出时序并输出到片外，供外部接收工具存储解析。事件t1-t4属于传统coresight trace数据传输和分析过程。然而在事件t5中，当cpu core 0运行中检测到命令执行异常后，进入本发明设计的日志生成程序分支，该日志生成程序向所述log_buf单元写入软件日志数据。如前所述，core 0_buf用于缓存cpu core 0写入的软件日志数据。因此日志程序向core 0_buf中写入软件日志数据，软件日志数据包括cpu的关键寄存器状态和软件执行标记。
48.步骤102：监测所述软件日志数据的缓存数据量，当所述缓存数据量达到预定义阈值时，读出所缓存的软件日志数据。
49.参见图6，在事件t6中，log_trace_gen单元采用轮询的方式监测log_buf单元内core 0_buf～core 3_buf缓存的日志数据大小是否达到预定义阈值，图6以core 0_buf为例，当监测到core 0_buf到达阈值后将其缓存数据读取到log_trace_gen单元中。
50.步骤103：根据读出的所述软件日志数据生成软件trace数据，并将所述硬件trace数据和所述软件trace数据输出到片外进行解析。
51.参见图6，在事件t7中，所述log_trace_gen单元将读取到的日志数据按照标准的atb总线格式进行转换，得到软件trace数据，并传输至coresight funnel单元，然后执行事件t8-t10。事件t8-t10分别与传统coresight trace数据分析过程中的事件t2-t4类似，然而应当注意的是，此时传输的trace数据是在事件t7中被转换为atb格式的软件日志数据。因此，事件t8-t10具体包括，coresight funnel单元通过配置将接收到的软件trace数据传递至coresight replicator单元。coresight funnel单元将软件trace数据复制2份，分别传输至coresight tpiu单元和etb单元。coresight tpiu单元将软件trace数据转换为tpiu标准输出时序并输出到片外，供外部接收工具存储解析。在实际情况下，根据不同数据源的就绪状态，以及coresight funnel组件的配置仲裁策略，可以将硬件追踪信息和软件日志数据先后两次输出到片外，也可以以完整的数据包为单位而一起交织输出至片外。
52.因此，上述方法执行完成后，最终得到的trace数据不仅包含硬件追踪信息，还包含软件日志数据，为软硬件协同诊断功能提供了支持，更有利于进行系统运行问题的定位分析。
53.为了便于举例说明，图6的实施例仅描述了cpu core 0，即处理器单核运行的场景。本领域技术人员可以理解，在实际应用中，还可以支持cpu core 0～cpu core 3的多核运行场景。多核场景与单核场景类似。多个处理器核并行执行，并生成独立的trace数据，解析时通过atb格式数据中的trace id信息区分目标处理器核，然后进行独立分析。
54.其中，上述软件日志数据需要由log_trace_gen单元转换为标准的atb数据格式才能使用coresight trace网络进行输出。表1示出了日志trace数据帧格式的具体示例。该数据输出至片外后，由外部解析工具接收并识别其内容，还原得到整个日志内容供调试人员查看。
55.表1日志信息atb数据格式
56.序号内容(32位)1head2timestamp[63:32]3timestamp[31:0]4trace_data_0
……
n 3trace_data_n-1n 4{15’d0,pressure_back,package_num[7:0],timestamp_en,trace_id[6:0]}n 5crc32n 6tail
[0057]
在表1的示例中，数据位域的具体定义为：
[0058]
head：数据包头标记；
[0059]
timestamp：时间戳；
[0060]
trace_data：日志内容有效信息；
[0061]
trace_id：id信息，用于区分数据源来自哪个处理器核；
[0062]
timestamp_en：是否使用时间戳功能标记；
[0063]
package_num：数据包编号，用来检测是否丢包；
[0064]
pressure_back：数据包内部分数据发生丢失标志；
[0065]
crc32：数据包校验位；
[0066]
tail：数据包尾标记。
[0067]
本领域技术人员可以理解，上述实施例中描述的方法步骤和装置的组件以及参数仅为举例。本领域技术人员可以根据需要，对上述软硬件协同片上系统诊断方法流程的多个步骤进行合并、增删或顺序调整，或者对coresight trace网络架构进行容易想到的调整。而不应将本发明的构思限制于上述示例的具体结构、参数和流程。
[0068]
接下来，以测试主机对sata盘进行dma写操作出现异常为例，来说明使用本发明所述的软硬件协同诊断方法相对于传统软件日志调试方法或传统coresight trace数据分析方法的技术效果。假设在循环测试dma写操作过程中出现多次异常，由于这些异常都是随机出现，因此给调试定位带来很大难度。在对dma写操作关键步骤进行硬件trace数据抓取，该trace数据内容记录了如图7所示的sata dma写操作过程中主机和设备之间的帧通信状态。抓取的trace数据经过解析还原后获得信息如图8～图11所示，其中图8为正确的trace数据，图9～图11为发生异常的trace数据。
[0069]
由图7可知，在进行循环测试dma写操作过程中发生3次不同类型的错误，分别如图9～图11所示。但是仅靠这些信息不足以进行系统诊断和故障分析解决，原因是这些数据只能表明曾经发生过某种错误，但是对在程序运行在哪次循环或执行何种操作发生了这些错误却并不明确。这就为测试人员带来极大困扰，甚至有可能造成该问题最终无法澄清和解决。
[0070]
采用本发明提供的软硬件协同片上系统诊断方法，将系统运行中的软件日志封装处理后加入到trace网络中，最后输出至片外解析还原后得到图12～图15所示的数据。其中图12为正确的日志trace数据，图13～图15为发生错误异常的日志信息。
[0071]
根据图13～图15，可以确定在测试过程中发生了三次执行命令错误，经解析后的软件日志数据提供了当前循环次数、配置信息、memory地址、数据和命令等内容。由于对硬件内部发生过何种错误并不清晰，仅通过以上提供的软件日志数据，也很难进行定位分析这些异常问题。然而，上述软件日志数据和硬件trace数据中还携带有timestamp信息，该信息为原始数据生成时所对应的系统时间。虽然软硬件数据分别由不同数据源生成，但是可以通过timestamp信息是否一致来判定两者的时间关联性。将以上软件日志数据和抓取到的硬件trace数据进行结合分析，将timestamp信息一致的数据进行合并整理后得到的结果如图16～图18所示。对上述整理后的软件日志数据和硬件trace数据进行分析，可以直接得到如下数据：
[0072]
1)由图16的第1行至第3行可知，测试过程在第9次循环时发生了错误，传输data长度为256字节，操作基地址为0xe79a5d50，该次错误原因为传输过程中发生了fifo overflow(倒数第3行)。
[0073]
2)由图17的第1行至第3行可知，测试过程在第102次循环时发生了错误，传输data长度为256字节，操作基地址为0xe79a5ed0，该次错误原因为传输过程中发生了crc错误(倒数第3行)。
[0074]
3)由图18的第1行至第3行可知，测试过程在第225次循环时发生了错误，传输data长度为256字节，操作基地址为0x26b81280，该次错误原因为传输过程中发生了链路丢失(connection lost，倒数第3行)。
[0075]
通过上述采用软硬件协同诊断分析过程得出的结论，测试人员可以更方便、更准确地识别错误场景，为错误场景再现提供了良好的支撑，对系统异常问题诊断分析提供了更有效的帮助信息。
[0076]
本发明所涉及的系统环境不限于arm cpu系列，还可以是诸如risc_v和8051单片机等系统环境。本领域技术人员可以理解，当在上述系统环境下使用本发明时，可以根据需要在coresight trace网络架构基础上增加相应的开发逻辑以支持对应的系统环境，本文不再详细说明。
[0077]
可以看出，本发明提出的软硬件协同片上系统诊断方法，除了能够提供支持片上软硬件协同诊断分析功能之外，还解决了传统软件日志调试方法和传统coresight trace数据分析方法存在的局限性和不足。具体解决问题如下：
[0078]
(1)针对典型软件日志调试对较深层硬件问题诊断分析能力较差的问题，本发明的方法得到的最终trace数据不仅包含软件日志数据，还包含硬件trace数据。软件日志数据涵盖寄存器状态和执行状态，而硬件trace数据针对测量片内数据流和指令流有明显帮助。通过两者的timestamp信息将软硬件信息有效关联起来，更有利于进行软硬件协同分析定位。
[0079]
(2)针对典型软件日志调试方法需保留对外uart调试端口的缺陷，本发明的方法不再需要使用uart端口作为软件日志输出接口，而是复用已有的coresight tpiu端口。既节约了芯片pad资源，又降低了封装成本。
[0080]
(3)针对典型软件日志调试方法数据传输速率较低的问题，由于典型tpiu的传输速率为500mhz*16bit＝8gbps，远大于标准uart波特率(常用为9600bps)，本发明的方法解决了软件日志程序由于受限于uart传输速率在调试过程中需要反复修改日志输出代码或等级以控制信息量大小的问题，在单位时间内能够提供更多的调试信息，降低了软件维护及调试时间成本。
[0081]
(4)针对典型coresight trace数据和软件运行关联性弱的问题，由于本发明的方法得到的trace数据同时包含软件日志数据和硬件trace数据，通过timestamp信息将两者关联起来，测试人员便于获取错误场景下的硬件trace数据和系统运行期间最直观的调试信息，即各模块寄存器状态值或软件标记等，更有利于系统问题的定位分析。
[0082]
(5)针对典型coresight trace数据不支持自定义格式以及灵活性较差的缺陷，本发明的方法中软件日志生成程序是针对实际系统应用场景进行开发维护和灵活编写的，所生成的日志信息能够较直观的反映系统运行状态和具备较强的可读性和灵活性，更符合测试人员的使用习惯，能够大幅提高产品调试效率。
[0083]
由此可见，采用本发明的方法，能够有效解决传统软件日志调试方法和传统coresight trace数据分析方法存在的局限性和不足，通过软硬件信息关联定位分析，能够更精准地再现错误场景，获得更丰富、更有效的调试信息，极大地提高了系统问题分析能力和节约了芯片调试成本。
[0084]
尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理
解，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。