第8章 Nios II系统高级开发

Nios II处理器是软核处理器，具有可定制性、性能可配置性。可定制性在前面的章节已经接触到了，有三种类型的内核可供选择，参数化的外围设备也可以进行配置。性能的可配置性，包括使用用户定制的指令，采用硬件加速器提升性能，本章将介绍用户定制指令和用户定制外设来提高系统的性能。然后介绍C2H（C-to-Hardware）编译器工具，使用它可以将C语言的程序转换成硬件加速器，并可集成到SOPC Builder的系统中。

8.1 用户定制指令

使用Altera Nios II 嵌入式处理器，系统设计者可以通过添加定制指令到Nios II指令集中，来加速处理对时间要求苛刻的软件算法。使用定制指令，用户可以将一个包含多条标准指令的指令序列减少为硬件实现的一条指令。用户可以在很多的应用中使用这个特性，例如，优化数字信号处理的软件的内部循环、信息包头的处理和计算密集的应用。Nios II 配置向导提供了图形化的用户界面用来添加多达256的定制指令到Nios II处理器。定制指令逻辑直接连接到Nios II 算术逻辑单元(ALU)，如图8-1所示。

图8-1 定制指令逻辑和ALU的连接

本节包括如下的内容：

Nios II 定制指令的特性。

实现定制指令的软硬件要求。

定制指令的体系结构类型的定义。

8.1.1 定制指令综述

使用Nios II定制指令，用户可以利用FPGA的灵活性来满足系统性能的需要。定制指令允许用户添加定制功能到Nios II处理器的ALU。

Nios II 定制指令是在处理器的数据路径上与ALU紧邻的定制逻辑模块。定制指令提供给用户通过裁剪Nios II处理器内核来满足特定应用需求的能力。用户具有将软件算法转化成定制的硬件逻辑模块来进行加速处理的能力。因为，很容易改变基于FPGA的Nios II处理器的设计，在设计过程中定制指令提供了简单的方法来测试软硬件的权衡。

图8-2是Nios II定制指令的硬件结构图。Nios II定制指令逻辑的基本操作是从dataa和/或datab端口接收输入，在result端口驱动输出，输出是由用户生成的定制指令逻辑产生的。

Nios II处理器支持不同的定制指令体系结构类型。图8–2 给出了用于不同的体系结构类型的另外的端口。不是所有端口都是需要的，有些端口只有在用于实现特定的定制指令时才存在。图8–2也显示了一个可选的与外部逻辑的接口。该接口允许用户与Nios II处理器数据路径之外的系统资源相接口。

图8-2 Nios II处理器定制指令的硬件框图

Nios II定制指令软件接口很简单，而且抽象了定制指令的细节。对于每一条定制指令，Nios II IDE在系统头文件system.h中产生一个宏。用户在C或C++ 应用程序中如同一个函数一样调用宏。用户不需要编写汇编程序来访问定制指令。当然，在Nios II 处理器汇编语言程序中也可以调用定制指令。

8.1.2 定制指令体系结构的类型

Nios II支持不同的定制指令体系结构来满足不同应用的要求。体系结构从简单的、单时钟周期组合指令结构到扩展的可变长度的、多时钟周期定制指令体系结构。选择的体系结构决定了硬件接口。表8–1给出了定制指令体系结构的类型、应用和硬件接口。

表8-1 定制指令的体系结构类型、应用和硬件端口。

体系结构类型应用硬件端口

组合逻辑（combinatorial）单时钟周期定制逻辑模块●dataa[31..0]

●datab[31..0]

●result[31..0]

多时钟周期（Multi-cycle）多时钟周期定制逻辑模块，固定或可

变的执行时间。●dataa[31..0] ●datab[31..0] ●result[31..0] ●clk

●clk_en

●start

●reset

●done

扩展的（Extended）能执行多个操作的定制逻辑模块。●dataa[31..0]

●datab[31..0]

●result[31..0]

●clk

●clk_en

●start

●reset

●done

● n[7..0]

内部寄存器文件（Internal Register File ）

访问内部寄存器作为输入和/或输出的定制逻辑模块。

● dataa[31..0] ● datab[31..0] ● result[31..0] ● clk ● clk_en ● start ● reset ● done

● n[7..0] ● a[4..0] ● readra ● b[4..0] ● readrb ● c[4..0] ● writerc

外部接口

同Nios II 处理器数据路径外部的逻辑相接口的定制逻辑模块。 标准的定制指令端口加上用户定义的与外部逻辑的接口。

1. 组合逻辑定制指令体系结构

组合逻辑定制指令体系结构包括一个能在一个时钟周期完成的逻辑模块。图8–3为组合逻辑定制指令体系结构的结构图。

图8-3 组合逻辑定制指令结构图

图8–3 组合逻辑定制指令结构图使用了dataa 和datab 端口作为输入，在result 端口驱动输出结果。因为逻辑可以在一个时钟周期内完成，所以不需要控制端口。

组合逻辑必需的端口是result 端口。dataa 和datab 端口是可选的。在定制指令需要输入操作数才有这两个端口。如果定制指令只需要一个输入端口，使用dataa 。

2. 多时钟周期定制指令体系结构

多时钟周期的定制指令包括一个需要2个或更多时钟周期才能完成操作的逻辑模块。对于多时钟周期定制指令需要控制端口。图8–4显示了多时钟周期定制指令的结构图。

图8-4多时钟周期定制指令的结构图

多时钟周期定制指令可以在固定或可变的时钟周期数内完成：

固定长度：在系统生成时用户指定需要的时钟周期数。

可变长度：在握手方案中使用start 和done 端口来决定定制指令何时完成。

端口名方向必需应用

clk 输入是系统时钟

clk_en 输入是时钟使能

reset输入是同步复位

start输入否命令定制指令逻辑开始执行

done输出否定制指令逻辑指示处理器执行完成。

dataa[31..0]输入否定制指令的操作数。

datab[31..0]输入否定制指令的操作数。

result[31..0]输出否定制指令的输出结果。

在表8–2中，对于多时钟周期的定制指令clk、clk_en和reset端口是必需的，而start、done、dataa、datab和result端口是可选的。只有定制指令的功能需要它们时才存在。

下面描述多时钟周期定制指令硬件端口的操作细节。图8–5给出了多时钟周期定制指令的时序图。

在第一个时钟周期，当ALU发出定制指令，处理器置start端口为高电平——有效，这时dataa和datab 端口具有有效的值，而且在定制指令执行的期间一直保持有效。

固定或可变长度的定制指令端口操作：

z固定长度：处理器置start有效，等待一个指定的时钟周期数，然后读result。

对于n个周期的操作，定制指令逻辑模块必须在start端口有效之后的第n-1时

钟上升沿提供有效的数据。

z可变长度：处理器一直等到done端口有效，done端口为高电平有效。处理器在done有效之后的时钟沿读result端口。定制指令模块必须done端口为有效

的同一个时钟周期向result端口上提供数据。

Nios II系统时钟提供给定制指令模块的clk端口，Nios II系统主reset提供给高电平有效的reset端口。reset端口只有当整个Nios II系统复位才有效。

定制指令模块必须将高电平有效的clk_en端口处理成传统的时钟使能信号，当clk_en无效时，忽略clk。

定制指令模块的端口中不是表0-2中的定制指令的端口都是和外部逻辑的接口。

用户可以进一步优化多时钟周期指令，可以是通过实现扩展的内部寄存器文件定制指令，或者是创建有外部接口的定制指令。

图8-5 多时钟周期定制指令时序图

3. 扩展定制指令体系结构

扩展定制指令体系结构允许一个定制指令实现几个不同的操作，扩展的定制指令使用N 域来指定逻辑模块执行哪个操作。指令的N域的字宽度可达8比特，使得一个定制指令可以实现多达256不同的操作。

图8-6是扩展定制指令的结构图，可以实现位交换、比特交换和半字交换的操作。图8-6的定制指令对从dataa 端口接收到的数据进行交换操作，它使用2比特宽度的n端口来选择多路复用器的输出，决定提供给result端口哪个输出。n端口的输入直接来自定制指令的N域字。这个例子中的逻辑是非常简单的，用户可以基于N域来实现任何用户想要的功能选择。

图8-6 交换操作的扩展指令

扩展定制指令可以是组合指令和多时钟周期指令，要实现扩展指令只要添加一个n端口到用户的定制指令逻辑。n端口的宽度由定制指令逻辑能够执行的操作数目决定。

扩展的定制指令占用多个定制指令索引。例如，图8-6中的定制指令占用4个索引，因为n是2个比特的宽度。因此，当该指令在Nios II系统中实现之后，Nios II系统还剩下256 - 4 = 252可用的索引。

n端口的行为同dataa端口类似。当在时钟的上升沿，start为有效时，处理器提供给n端口信号，n端口在定制指令执行的期间保持稳定不变。所有其它的定制指令端口操作保持不变。

4. 内部寄存器文件定制指令体系结构

Nios II处理器允许定制指令逻辑访问其内部寄存器文件，这提供给用户指定定制指令从Nios II 处理器寄存器文件或是从定制指令本身的寄存器文件读操作数的灵活性。而且，定制指令可以写结果到定制指令的本地寄存器文件而不是Nios II处理器寄存器文件。

内部寄存器访问定制指令使用readra、readrb和writerc来决定I/O访问发生在Nios II处理器文件还是内部寄存器文件。并且，端口a、b和c指定从哪个内部寄存器读数据以及写数据到哪个寄存器。例如，如果readra为有效(即，从内部寄存器读)，a提供了内部寄存器文件的索引。更多的Nios 定制指令实现的信息参考Nios II Processor Reference Handbook中 Instruction Set Reference章节。图8-7显示了一个简单的乘加定制指令逻辑。

图8-7 乘加定制指令逻辑

当readrb为无效时，定制指令逻辑对dataa和datab相乘，然后将结果存在accumulate（累加）寄存器。Nios II处理器可以将结果读出。通过将readrb置为有效，处理器可以将累加器中的值读出来，作为乘法器的输入。

表8–3列出了内部寄存器文件定制指令的端口。只用当定制指令的功能需要时，才使用这些可选的端口。

表8–3 内部寄存器文件定制指令端口

端口名 方向 必需 应用

readra 输入 否 如果readra为高电平，Nios II处理器提供dataa和datab。如果readra 为低电平，

定制指令逻辑读由a索引的内部寄存器文件。

readrb 输入 否 如果readrb为高电平，Nios II处理器提供dataa和datab。如果readrb为低电平，

定制指令逻辑读由b索引的内部寄存器文件。

writerc 输入 否 定制指令写结果到c索引的定制指令内部寄存器文件。

a 输入 否 定制指令内部寄存器文件索引。

b 输入 否 定制指令内部寄存器文件索引。

c 输入 否 定制指令内部寄存器文件索引。

readra、readrb、writerc和a、b和c端口的行为同dataa类似。当start端口有效，处理器在时钟的上升沿提供readra、readrb、writerc、a、b和c。所有的端口在定制指令执行的过程保持不变。为了确定如何处理寄存器文件I/O，定制指令逻辑读高电平有效的readra、readrb和writerc端口。定制指令逻辑使用a、b和c端口作为寄存器文件索引。当readra或者readrb无效时，定制指令逻辑忽略相应的a或b端口。当writerc为无效时，处理器忽略result端口上的值。其它的定制指令端口的操作是相同的。

5. 外部接口定制指令体系结构

图8-8显示Nios II定制指令允许用户添加一个同处理器数据路径之外的逻辑进行通信的接口。在系统生成时，任何的不被看作为定制指令端口的接口会出现在SOPC Builder顶层模块中，外部逻辑可以对其访问。因为定制指令逻辑能够访问处理器外部的存储器，这样就可以扩展定制指令逻辑的功能。

图8-8 具有外部接口的定制指令

图8-8显示的是一个具有外部存储器接口的多时钟周期定制指令。

定制指令逻辑可以执行不同的任务，例如，存储中间结果，或者读存储器来控制定制指令操作。可选的外部接口也提供了一个数据流入和流出处理器的专用的接口。例如，定制指令逻辑能够直接将处理器寄存器文件的数据传递给外部的FIFO存储器缓冲，而不是通过处理器数据总线。

8.1.3 软件接口

Nios II定制指令的软件接口从应用代码抽象了逻辑的实现细节，在编译过程中，Nios II IDE生成允许应用代码访问定制指令的宏。这一节介绍定制指令软件接口的细节，包括如下的内容：

定制指令例子。

内嵌函数和用户定义的宏。

1. 定制指令例子

例8-1显示了system.h头文件中的一部分，定义了位交换定制指令的宏。这个例子使用一个32位的输入，只执行一个功能。

例8-1，位交换宏定义

#define ALT_CI_BSWAP_N 0x00

#define ALT_CI_BSWAP(A) __builtin_custom_ini(ALT_CI_BSWAP_N,(A))

ALT_CI_BSWAP_N被定义为0x0，作为定制指令的索引。ALT_CI_BSWAP(A)宏被映射到一个只需要一个参数的gcc内嵌函数。

例8-2演示的是在应用代码中使用位交换定制指令。

例8-2，位交换指令的使用

1. #include "system.h"

2.

3.

4. int main (void)

5. {

6. int a = 0x12345678;

7. int a_swap = 0;

8.

9. a_swap = ALT_CI_BSWAP(a);

10. return 0;

11.}

在例8–2中，system.h 文件被包含，其中有宏的定义。该例声明了两个整数，a和a_swap。a作为输入传递给位交换定制指令，结果赋给a_swap。例8–2可以体现大部分应用使用定制指令的方法。

Nios II IDE在宏的定义中只使用了C的整数类型。有时，应用需要使用整数之外的其它输入类型，因此，需要传递期望的整数之外的类型返回值。

用户能够为Nios II 定制指令定义定制的宏，允许其它的32位的输入类型同定制指令接口。

2. 内嵌函数和用户定义的宏

Nios II处理器使用gcc内嵌函数来映射定制指令。通过使用内嵌函数，软件可以使用非整数类型的定制指令。共有52个唯一定义的内嵌函数来提供支持类型的不同组合。内嵌函数名具有下面的格式：

__builtin_custom_n

表8-4为定制指令支持的32位的参数和返回值的类型，和在内嵌函数中使用的缩写。

表8-3 定制指令支持的32位数据类型

类型在内嵌函数中的缩写

int I

float F

void*p

例8–3 内嵌函数

void __builtin_custom_nf (int n, float dataa);

float __builtin_custom_fnp (int n, void * dataa);

在例8–3中，_builtin_custom_nf函数需要一个整形（int）和一个浮点型（float）作为输入，不返回结果；相反，_builtin_custom_fnp函数需要一个指针作为输入，返回一个浮点数。

例8–4显示了应用中使用的用户定义的定制指令的宏。

例8–4 定制指令宏的使用

1. /* define void udef_macro1(float data); */

2. #define UDEF_MACRO1_N 0x00

3. #define UDEF_MACRO1(A) __builtin_custom_nf(UDEF_MACRO1_N, (A));

4. /* define float udef_macro2(void *data); */

5. #define UDEF_MACRO2_N 0x01

6. #define UDEF_MACRO2(B) __builtin_custom_fnp(UDEF_MACRO2_N, (B));

7.

8. int main (void)

9. {

10. float a = 1.7;

11. float b = 0.0;

12. float *pt_a = &a;

13.

14. UDEF_MACRO1(a);

15. b = UDEF_MACRO2((void *)pt_a);

16. return 0;

17. }

在第2到第6行，声明了用户定义的宏，并映射到相应的内嵌函数。宏UDEF_MACRO1需要一个浮点型的输入，不返回任何值。宏UDEF_MACRO2需要一个指针作为输入，返回一个浮点型的值。第14和15行显示这两个用户定义的宏的使用。

8.1.4 实现Nios II定制指令

本节介绍使用SOPC Builder元件编辑器实现Nios II定制指令的过程。元件编辑器使用户能够创建新的SOPC Builder元件，包括Nios II定制指令。有关SOPC Builder元件编辑器的更多信息，参阅Quartus II Handbook Volume 4:SOPC Builder Component Editor章节。

1. 在SOPC Builder中实现定制指令的硬件

实现Nios II定制指令需要下面的步骤：

打开Nios II CPU的定制指令设置窗口。

添加定制指令的设计文件。

配置定制指令的端口。

设置元件组的名字。

生成SOPC Builder 系统，在Quartus II软件中进行编译。（一）打开Nios II CPU的定制指令设置窗口

1. 打开SOPC Builder系统

2. 在Altera SOPC Builder System Contents中选择Nios II处理器。

3. 在Module菜单中点击Edit….，Nios II配置向导窗口出现。

4. 点击Custom Instructions页，出现如图8-9的窗口。

5. 在8-9的窗口中点击Import…，出现如图8-10的窗口。

图8-9 定制指令页面

图8-10 用户逻辑接口（二）添加顶层设计文件

1. 在图8-10窗口中，点击Add；

2. 切换到相应的目录，选择硬件设计的文件，设计文件可以是HDL文件、EDIF文件或BDF 文件，本例使用的是BDF文件，是实现CRC编码的逻辑，如图8-11所示，点击打开。

3. 设计文件会出现在图8-12所示的窗口中，软件会自动识别处顶层模块，本例显示的是crc。

4. 在图8-12中点击read port-list from files，将定制指令端口列出来，如图8-13。

图8-11 添加设计文件

图8-12 添加的硬件设计文件

图8-13 定制指令端口

（三）发布定制指令

1. 在图8-13中点击Next，进入图8-14的Publish页面。

2. 在Component Name栏中输入crc，在group栏中输入custom instruction。、

3. 点击窗口底部的Add to library，将定制指令逻辑添加到定制指令库中，如图8-15所示。

图8-14 指令发布

图8-15 加入到定制指令库中的定制指令

（四）将定制指令加入系统

1. 在图8-15的窗口中，选中crc定制指令，然后点击Add，即将其加入到系统中，如图

8-16。也可以在图8-14中，点击Add to System，进行添加。

2. 在图8-16的窗口中点击Finish，完成定制指令的添加。

（五）生成系统

1. 生成SOPC Builder系统。

2. 在Quartus II 软件中对整个工程进行编译。

8.2 用户定制外设

本节讲述开发一个定制的SOPC Builder元件的设计流程，从创建定制外设、集成外设到系统中，最后将其下载到硬件。

讲述定制外设的开发流程之后，以Altera公司提供的一个设计实例作为练习。该实例展示了开发一个只具有Avalon从接口的外设。用户使用Altera提供的HDL设计，将其打包到成一个SOPC Builder元件，然后在系统中例化它。然后将工程编译下载到开发板上。

最后介绍怎样共享用户定制外设，这样用户设计的外设可以为其它的系统和设计者使用。

SOPC Builder提供元件编辑器使用户可以创建和编辑自己的SOPC Builder元件。

典型地，一个元件有下面的部分构成：

硬件文件：描述元件硬件的HDL模块。

软件文件：定义元件寄存器映射的C语言的头文件，元件的驱动程序。

元件描述文件(class.ptf)：定义元件的结构，提供给SOPC Builder将该元件集成到系统中必要的信息。元件编辑器根据用户提供的软件和硬件文件以及用户在元件编辑器的图形用户界面指定的参数自动产生这个文件。

在创建完描述元件的硬件和软件文件之后，用户使用元件编辑器将这些文件打包成一个SOPC Builder元件。如果用户更新了硬件或软件文件，用户还可以使用元件编辑器对这个元件进行再次的编辑。

8.2.1 元件开发流程

本节介绍元件开发流程，包括硬件和软件两方面，这里介绍只有一个Avalon从接口的元件设计流程，而其设计流程的步骤可以很容易地推广到具有主端口的元件或者多个主端口和

从端口的元件。

从外设的典型的设计顺序包括如下的步骤：

1. 指定硬件功能。

2. 如果微处理器要控制该元件，指定访问和控制该硬件的应用程序接口 (API) 。

3. 根据硬件和软件的要求，定义一个Avalon 接口，该接口要提供：

a. 正确的控制机制。

b. 足够的吞吐量性能。

4. 采用Verilog或者VHDL编写硬件设计。.

5. 单独测试元件的硬件，验证操作的正确性。

6. 编写C头文件，为软件定义硬件层次的寄存器映射。

7. 使用元件编辑器将硬件和软件文件打包成一个元件。

8. 例化元件为一个SOPC Builder系统的模块。

9. 使用Nios II处理器来测试对元件的寄存器级的访问，用户可以执行硬件的测试，或者是进行HDL仿真。

10.如果微处理器要控制该元件，编写元件的驱动程序。

11. 根据元件的在系统的行为，反复改进元件的设计：

a. 硬件的改进和调整。

b. 软件的改进和调整。

c. 使用元件编辑器更新元件。

12.编译完整的含有一个或多个该元件的SOPC Builder系统。

13. 执行系统级的验证，如果必要进行进一步的反复改进。

14. 完成元件的设计，发布该元件，其他设计者可以重用该元件。

主外设的设计的过程与之类似，只是软件开发方面有所差异。

8.2.2 硬件设计

同任何的逻辑设计过程一样，SOPC Builder元件的硬件开发在需求分析阶段之后开始。当用户根据需求说明编写和验证HDL逻辑时，其过程是一个迭代的过程。

典型元件的结构包括下面的功能模块：

任务逻辑（Task Logic）——任务逻辑实现元件基本的功能。任务逻辑是和设计相关的。 寄存器文件（Register File）—— 寄存器文件为任务逻辑内部的信号同外部通信提供了一条通路，反之亦然。寄存器文件映射内部的节点为可寻址的地址偏移量，Avalon接口可对其进行读写访问。

Avalon 接口—— Avalon接口提供标准的寄存器文件的Avalon前端。接口可以使用任意的Avalon信号类型，以访问寄存器文件和支持任务逻辑所需要的传输。下面的因素影响Avalon接口：

z要传输的数据宽度是多少？

z数据传输需要的吞吐量的要求是多少？

z该接口主要是为了控制还是数据? 即传输是零星的，还是连续的突发传输?

z硬件相对系统中其它的元件是快速还是低速元件？

图8-16为一个具有一个Avalon从端口的典型元件的原理图。

图8-16具有一个Avalon从端口的典型元件

8.2.3 软件设计

如果用户想要微处理器来控制用户的元件，用户则必须提供软件文件，软件文件定义了该元件的软件视图。在最小化的软件设计中，用户必须定义每个从端口的寄存器映射，以便处理器可以访问。元件编辑器允许用户将C语言的头文件和元件打包在一起以定义硬件的软件视图。

典型情况下，头文件声明读和写元件寄存器的宏函数，寄存器的地址相对于分配给元件的符号化的基地址。下面的例子是从Altera提供的用于Nios II处理器的UART元件的寄存器映射摘录的一部分。

例：元件的寄存器映射

#include

#define IOADDR_ALTERA_AVALON_TIMER_STATUS(base) __IO_CALC_ADDRESS_NATIVE(base, 0)

#define IORD_ALTERA_AVALON_TIMER_STATUS(base) IORD(base, 0)

#define IOWR_ALTERA_AVALON_TIMER_STATUS(base, data) IOWR(base, 0, data)

#define ALTERA_AVALON_TIMER_STATUS_TO_MSK (0x1)

#define ALTERA_AVALON_TIMER_STATUS_TO_OFST (0)

#define ALTERA_AVALON_TIMER_STATUS_RUN_MSK (0x2)

#define ALTERA_AVALON_TIMER_STATUS_RUN_OFST (1)

#define IOADDR_ALTERA_AVALON_TIMER_CONTROL(base) __IO_CALC_ADDRESS_NATIVE(base, 1)

#define IORD_ALTERA_AVALON_TIMER_CONTROL(base) IORD(base, 1)

#define IOWR_ALTERA_AVALON_TIMER_CONTROL(base, data) IOWR(base, 1, data)

#define ALTERA_AVALON_TIMER_CONTROL_ITO_MSK (0x1)

#define ALTERA_AVALON_TIMER_CONTROL_ITO_OFST (0)

#define ALTERA_AVALON_TIMER_CONTROL_CONT_MSK (0x2)

#define ALTERA_AVALON_TIMER_CONTROL_CONT_OFST (1)

#define ALTERA_AVALON_TIMER_CONTROL_START_MSK (0x4)

#define ALTERA_AVALON_TIMER_CONTROL_START_OFST (2)

#define ALTERA_AVALON_TIMER_CONTROL_STOP_MSK (0x8)

#define ALTERA_AVALON_TIMER_CONTROL_STOP_OFST (3)

软件驱动程序抽象了元件的硬件细节，所以软件可以在一个高的层次上访问元件。驱动函数，提供给软件访问硬件的API。软件的要求根据元件的需要而有不同。最普遍的函数类型初始化硬件、读数据和写数据。

驱动程序和目标处理器是相关的，元件编辑器允许用户方便地打包软件驱动程序到HAL，Nios II 处理器开发工具将使用HAL。提供驱动程序给其它的处理器，用户必须满足目标处理器的开发工具的需要。

为Nios II HAL编写驱动程序的更多信息，参阅Nios II Software Developer's Handbook。查看Altera提供的元件的软件文件也是很有帮助的。Nios II开发包提供很多元件，用户可以用作参考。路径为/components/

8.2.4 验证元件

当用户完成越来越多的设计，用户可以以增量方式验证元件。通常，用户首先以一个单元来验证硬件逻辑(这可能包括很多小的验证阶段)，然后在系统中验证元件。

单元验证

单独测试任务逻辑模块，用户使用喜欢的验证方法，如行为级或寄存器传输级(RTL)的仿真工具。类似地，用户使用自己擅长的验证工具来验证所有的元件逻辑，包括寄存器文件和Avalon接口。在使用元件编辑器将HDL文件打包成一个元件之后，Nios II开发包提供一个易用的方法来仿真元件的读和写的操作。使用Nios II处理器的强大的仿真环境，用户可以编写C代码让Nios II处理器向用户的元件发起读写传输。结果可以在ModelSim仿真器或是硬件上看到，如Nios 开发板。读者可以参阅AN351: Simulating Nios II Embedded Processor Designs 获取更多的信息。

系统级的验证

当用户将HDL文件打包成一个元件之后，用户可以在系统中例化该元件，并且验证整个系统模块的功能。SOPC Builder对RTL仿真器系统级的验证提供支持，如ModelSim。当SOPC Builder为系统级验证产生一个测试平台，仿真环境性能主要取决于系统中包含的元件。

8.2.5 设计实例：脉宽调制器从外设

本节介绍脉冲宽度调制器(PWM)的设计实例，来介绍在系统中创建和例化元件的步骤。该元件只有一个Avalon从端口。

下面将介绍如下的步骤：

安装设计文件。

查看设计实例的说明。

将设计文件打包成一个SOPC Builder元件。

在硬件上例化元件。

在Quartus II中编译硬件设计，然后下载设计到目标板上。

使用Nios II软件测试硬件。

1. 安装设计文件

首先安装Nios II 开发工具，并且从Altera网站下载PWM设计实例。本节中使用的硬件设计是基于Nios II开发工具包中的standard硬件设计实例。

当安装设计文件时，不要在目录名中使用空格。如果路径包含有空格，SOPC Builder

可能不能访问设计文件。

建立设计环境要做如下的工作：

1. 解压PWM 压缩文件到一个目录。本节用目录来表示该目录。

2. 在用户的本地计算机文件系统中，进入目录：/examples//version>/standard。每个开发板都有VHDL和Verilog版本的设计。

3. 拷贝standard目录到一个新的位置。这样可以避免，破坏原始的设计。本节通过 目录来指代该目录。

2. 查看设计的说明

本部分讨论PWM设计实例的设计说明，会给出如下主题的细节：

PWM 设计文件。

功能说明。

PWM任务逻辑。

寄存器文件。

Avalon接口。

软件API。

典型的设计流程中，是由设计者来制定元件的行为。

PWM设计文件

表8-4列出了目录中提供的内容。

表8-4 PWM设计文件的内容

文件（夹）名描述

pwm_hw 包含描述元件硬件的HDL文件。

pwm_task_logic.v 包含PWM行为的内核。

pwm_register_file.v 包含读写PWM寄存器的逻辑。

pwm_avalon_interface.v 例化任务逻辑和寄存器文件，并提供一个Avalon从接口，该文件包含顶层

模块。

pwm_sw 包含描述元件软件接口的C文件。

inc 包含定义底层硬件接口的头文件。

avalon_slave_pwm_regs.h 定义访问PWM元件寄存器的宏函数。

HAL 包含HAL驱动程序。

inc 包含HAL驱动程序中包含的头文件。

altera_avalon_pwm_routines.h 声明访问PWM的函数的原型。

src 包含HAL驱动程序源代码文件。

altera_avalon_pwm_routines.c 定义访问PWM的函数。

test_software 包含测试元件硬件和软件的例程。

hello_altera_avalon_pwm.c 初始化PWM硬件，并且使用PWM来闪亮LED的main()。

功能说明

PWM元件输出调制占空比的方波，基本的脉宽波形如图8-17。

图8-17 基本的脉宽波形

本例中的PWM的功能有如下的要求：

任务逻辑按照一个单时钟同步工作。

任务逻辑使用32位的计数器提供PWM周期和占空周比的一个合适的范围。

主处理器负责设置PWM 周期和占空比的值。这就需要对控制逻辑有一个读/写接口。

寄存器单元来保存PWM周期和占空比。

主处理器可以使用使能控制位来停止PWM的输出。

PWM 任务逻辑

PWM的任务逻辑具有如下的特征：

PWM任务逻辑包含一个输入时钟(clk)，一个输出信号(pwm_out)，一个使能位，一个32bit的模n的计数器，一个32位的比较器。

clk驱动32位的模n计数器建立pwm_out信号的周期。

比较器比较模n计数器的当前值与占空比来决定pwm_out的输出。

当计数器的当前值小于或等于占空比的值，pwm_out输出逻辑0；否则输出逻辑1。

图8-18给出了PWM任务逻辑的结构

图8-18 PWM任务逻辑的结构

寄存器文件提供对使能位、模n的值和占空比的值的访问。如图8-18。设计将每个寄存器映射到一个Avalon从端口地址空间中唯一的偏移地址。

每个寄存器具有读和写访问，这意味着软件可以读取之前写入寄存器中的值。这种选择是以牺牲硬件资源为代价来获得软件上的便利。用户也可以设计寄存器为只是可写的，这会节省片上的逻辑资源，但是软件就不能读取寄存器的值。

表8-5给出了寄存器文件和偏移量映射。为了支持3个寄存器，要求两位的地址编码。这将导致第四个寄存器为保留。

表8-5 寄存器文件和地址映射

寄存器名地址偏移量访问描述

clock_divide 00 读/写PWM输出一个周期中包含的时钟周期数。

duty_cycle 01

读/写PWM输出一个周期为低电平时包含的时钟周期数。

enable 10

读/写使能/禁止PWM输出。将该比特设成1，使能PWM的输出。

Reserved 11 -

要读写寄存器只需要一个时钟周期，这影响Avalon接口的等待周期。

Avalon接口

PWM元件的Avalon接口需要一个从端口，使用了Avalon信号中的一个小的信号集合来处理寄存器的读和写的传输。元件的Avalon从端口具有如下的特性：

PWM从端口是与Avalon从端口时钟同步的。

PWM的从端口是可读和可写的。

PWM从端口的读写传输具有零等待周期，因为寄存器能够在一个时钟周期内相应传输。

PWM的从端口读写传输没有建立时间和保持时间的要求。

PWM从端口没有读延迟的要求，因为所有的传输可以在一个时钟周期内完成。

PWM从端口使用本地地址对齐方式，因为从端口是连接到寄存器而不是存储设备。

表8-6列出了实现传输属性需要的信号类型，也列出了在HDL文件中定义的信号名

表8-6 PWM信号名和Avalon信号类型

HDL中信号名 Avalon信号类型宽度方向说明

clk clk 1

输入同步数据传输和任务逻辑的时钟。

resetn reset_n 1

输入复位信号，低电平有效。

avalon_chip_select chipselect 1 输入片选信号。

address address 2

输入2位地址，只有3个编码被使用。

write write 1

输入写使能信号。

write_data writedata 32

输入 32位写数据值。

read read 1

输入读使能信号。

read_data readdata 32

输出 32位读数据值。

软件API

PWM设计实例提供定义寄存器映射的头文件和PWM在Nios II 处理器系统中的驱动程序。表8-4列出了这些文件，表8-7给出了驱动函数。

表8-7 PWM 驱动函数①

函数原型描述

altera_avalon_pwm_init() 初始化PWM硬件。

altera_avalon_pwm_enable() 激活PWM输出。

altera_avalon_pwm_disable() 禁止PWM输出。

altera_avalon_pwm_change_duty_cycle() 改变PWM输出的占空比。

注：①每一个函数都需要一个指定PWM元件实例的基地址的参数。

3. 打包设计文件为SOPC Builder元件

这部分，用户使用SOPC Builder元件编辑器将设计文件打包成一个SOPC Builder元件。用户要执行如下的操作：

（一）打开Quartus II 工程，启动元件编辑器。

（二）配置元件编辑器每个页面的设置。

（三）保存元件。

（一）打开Quartus II 工程，启动元件编辑器。执行如下的步骤：

1. 启动Quartus II软件。

2. 打开目录中的standard.qpf文件。

3. 选择Tools菜单中的SOPC Builder。出现SOPC Builder图形用户界面，显示一个现成的包含一个Nios II处理器和一些元件的设计实例。

4. 在File菜单中选择New Component。元件编辑器的图形用户界面出现，显示的是Introduction 页，如图8-19。在Introduction页面中，介绍了元件编辑器的工具，创建元件需要的文件，将元件用于其它工程的方法，以及获得元件编辑器更多细节的方法。

图8-19 新建元件的介绍页面

（二）配置元件编辑器每个页面的设置。

a．HDL文件页面

这部分是将HDL文件同元件联系起来。执行下面的步骤：

1. 在图8-19中点击HDL Files页，出现图8-20的页面。

在元件编辑器的每个页面上都提供在屏幕的信息，介绍怎样使用每一个页面。点击页面左上角的三角形来查看使用指导。

2. 点击Add HDL File。

3. 切换到/pwm_hw目录。三个Verilog的HDL文件存放这个目录。

4. 选中这三个HDL文件，点击Open。返回HDL Files页。元件编辑器立即分析每一个文件，从每个文件读取I/O信号和参数信息。

5. 确保所有文件的Simulation和Synthesis复选框都已被选中，如图8-21。这表示每个文件都适于仿真和综合的设计流程。

6. 选择pwm_avalon_interfave.v: pwm_avalon_interface在Top Level Module下拉框中，来指定顶层模块，如图8-21。此时，元件编辑器图形用户界面会显示错误消息，暂时忽略这些

信息，后面的步骤会解决这些问题。

图8-20 HDL Files页面

图8-21 HDL Files页的设置

b. 信号页面

对于顶层HDL模块中的每个I/O信号，用户必须将其信号名映射到一个有效的Avalon信号类型。这些工作在Signals页中进行。元件编辑器自动填写其在顶层HDL文件中发现的信号信息。如果一个信号名同Avalon信号类型同名(如write或address)，则元件编辑器自动分配信号的类型。如果元件编辑器不能判断信号类型，则将信号分配成export类型。执行如下的步骤进行元件I/O信号的定义：

1. 点击Signals页，顶层HDL模块pwm_avalon_interface中的所有I/O信号自动出现。

2. 如图8–22所示来分配所有信号的类型。要改变某个值，点击Signal Type单元格，显示一个下拉列表，选择一个新的信号类型。在图8-22中，将pwm_out信号分配为export类型，因为它不是Avalon信号。它是SOPC Builder系统的一个输出信号。

当正确地分配每个信号类型之后，错误信息就应该消失了。

图8-22 PWM元件的信号类型的设置

c．接口页面

接口页使用能够户配置元件上所有的Avalon接口的属性。PWM元件只有一个Avalon接口。执行下面的步骤进行Avalon从端口的配置：

1. 点击Interfaces页 tab。元件编辑器显示一个默认的Avalon从端口，该端口是元件编辑器基于元件设计的顶层I/O信号创建的。

2. 在Name域中键入control_slave重命名该从端口，当用在SOPC Builder中户例化该元件时，该端口名出现在SOPC Builder 图形用户界面中。

3. 如表8-8所示修改control_slave接口的设置。图8-23给出了正确的设置的Interfaces页。

表8–8控制从接口设置

设置值描述

Slave addressing Registers 该设置适用于访问地址映射寄存器的从端口。

Read Wait 0 该设置表示从端口在一个时钟周期内响应读请求（即不需要读等待周

期）。

Write Wait 0 该设置表示从端口在一个时钟周期内捕获写请求（即不需要写等待周

期）。

图8-23 接口页面的设置

d．软件文件页

SW Files页使用户将软件文件同元件联系起来，并指定它们的使用方法。PWM设计实例提供了定义寄存器映射的头文件和驱动程序。执行下面的步骤将软件文件引入到元件中：

1. 点击SW Files页。

2. 点击Add SW File，出现打开对话框。

3. 切换到/pwm_sw/inc目录。

4. 选择altera_avalon_pwm_regs.h文件，点击Open。

5. 点击altera_avalon_pwm_regs.h的Type单元格，改变文件类型。下拉列表中，选择Registers (inc/)。

6. 重复2～5的步骤，添加files>/pwm_sw/HAL/inc/altera_avalon_pwm_routines.h文件，设置其为HAL (HAL/inc/)类型。

7. 重复2～5的步骤，添加files>/pwm_sw/HAL/src/altera_avalon_pwm_routines.c文件，将其设置为HAL (HAL/src/)类型。

图8–24显示了SW Files页的正确的设置。

图8-24 软件文件页的设置

e．元件向导页

元件向导页允许用户控制在SOPC Builder例化元件时，添加向导的样式。执行下面的步骤配置元件向导的样式：

1. 点击Component Wizard页。

2. 对于本例，不改变元件名，元件版本和元件组的默认值。

3. 在Parameters栏中，在clock_divide_reg_init的Tooltip单元格键入：Initial PWM Period After Reset。

4. 在clock_cycle_reg_init的Tooltip单元格中键入：Initial Duty Cycle After Reset。如图8-25

5. 点击Preview the Wizard 预览元件SOPC Builder例化时的元件向导的样式，如图8-26所示。

6. 关闭预览窗口。

图8-25 元件向导的配置

图8-26 元件向导预览

（三）保存元件

执行下面的步骤保存元件，并且退出元件编辑器：

1. 在图8-25中点击Finish，出现对话框，提示为元件创建文件，如图8-27。

2. 点击Yes保存文件。元件编辑器保存这些文件到目录中一个子目录。元件编辑器关闭，返回SOPC Builder图形用户界面。

3. 在Unkown组中可用的元件列表中找到pwm_avalon_interface新元件。用户可以在SOPC Builder系统中例化该元件。

图8-27 保存元件

4. 例化元件

此时，新的元件已经可以在SOPC Builder系统中例化了。元件的使用是和设计相关的，是基于系统的需要的。剩下的步骤演示例化和测试元件的一种可能的方法。然而，该元件在系统中使用方法数目是没有的。

这部分用户将添加新的PWM元件到系统中，重新编译硬件设计，重新配置FPGA。包括如下的步骤：

1. 添加一个PWM硬件到SOPC Builder系统，重新生成系统。

2. 修改Quartus II设计，连接PWM 输出到FPGA的一个引脚。

3. 编译Quartus II设计，使用新的硬件镜像文件配置FPGA。

添加PWM元件到SOPC Builder系统，执行下面的步骤建立SOPC Builder的元件搜索路径：

1. 在SOPC Builder图形用户界面中，在File菜单中选择SOPC Builder Setup。

2. 在Component/Kit Library Search Path中输入目录的路径。如果已经有一些路径存在，使用"+"来分隔这些路径。如图8-28所示。

3. 点击OK。

上面的这些步骤使得元件的软件文件对Nios II IDE可见。这些步骤对Quartus II 软件v4.2和Nios II IDE v1.1是必须的。

图8-28 元件搜索路径的建立

执行下面的步骤将PWM元件添加到SOPC Builder系统：

1. 在SOPC Builder System Contents页，在Unkown组中选择pwm_avalon_interface，然

后点击Add。PWM元件的配置向导出现，如图8-26。如果用户需要，可以修改配置界面中的参数。参数会影响PWM控制寄存器的复位状态。

2. 点击Finish。返回到SOPC Builder System Contents页，元件pwm_avalon_interface_0出现在活动的外设的列表中。

3. 右键单击pwm_avalon_interface_0 ，选择Rename，键入z_pwm_0 的名字，然后按Enter 键，如图8-29。

4. 点击Generate开始生成系统。

5. 系统生成成功之后，退出SOPC Builder，返回到Quartus II。

图8-28 添加了PWM元件的系统

5.在Quartus II中编译硬件设计，然后下载设计到目标板上。

此时，用户已经创建了一个使用PWM元件的SOPC Builder系统，用户必须更新Quartus II 工程才能使用PWM 的输出。.

standard.bdf文件是顶层的原理图设计文件，BDF包含SOPC Builder系统模块的一个符号，名字为std_，这里 代表的是目标板上的 FPGA，如std_2C35。

在之前的步骤中，用户添加PWM元件，则系统模块会产生新的输出。所以要更新系统模块的符号，并将PWM 的输出连接到FPGA的一个引脚。

1. 在Quartus II中，打开standard.bdf文件。

2. 在standard.bdf中右键单击符号std_ ，然后选择Update

Symbol or Block。更新符号或模块的对话框出现。

3. 选择Selected Symbol(s) or Block(s)，如图8-30所示。

4. 点击OK关闭对话框。std_ 符号已经被更新了，现在已经有了一个新的输出端口名为pwm_out_from_the_z_pwm_0。SOPC Builder为所有系统模块上所有的I/O端口创建唯一的名字，名字是将元件设计文件中的信号名同系统模块中元件的实例名。

5. 删除连接到port out_port_from_the_led_pio[7..0]端口的引脚。

6. 创建一个新的引脚命名为LEDG[0]。

7. 将新的引脚连接到pwm_out_from_the_z_pwm_0端口。现在可以对硬件进行编译了。

图8-30 系统模块的更新

编译硬件和下载到目标板的步骤在第二章已经讲解过，这里就不做赘述了。

6. 在Nios II软件中使用硬件

PWM设计实例是基于Nios II处理器，用户必须在Nios II处理器中执行软件来验证PWM 硬件。设计实例的设计文件提供了C语言的测试程序，该层序使用PWM的输出点亮LED，该程序会让PWM占空比渐变。测试程序访问硬件使用寄存器映射和调用驱动函数的方式。

关于软件工程的创建、源文件和头文件的引入以及程序的调试和下载等内容在第六章已经介绍过了，这里就跳过了。程序的运行会使开发板上的LED重复的亮灭，但是周期是渐变的。

8.2.6 共享元件

当用户使用元件编辑器创建了一个元件，SOPC Builder在当前的Quartus II工程目录中自动地保存该元件。为了促进设计的重用，用户可以在不同的工程中使用元件，用户也可以将自己的元件同其它设计者分享。

执行下面的步骤，可以分享一个元件：

1. 在用户的计算机文件系统中，将元件的目录移到一个Quartus II 工程目录之外的一个位置。例如，可以创建一个目录c:\\my_component_library 来保存用户的定制元件。目录路径中不能包含空格。

2. 在SOPC Builder中，在File菜单中选择SOPC Builder Setup。出现SOPC Builder Setup 对话框，在该对话框中用户可以指定SOPC Builder到哪去找元件的文件。

3. 在Component/Kit Library Search Path里添加包含元件目录的目录。例如，元件的目录为c:\\my_component_library\\pwm_avalon_interface\\，加入路径c:\\my_component_library。如果已经有路径存在，使用"+"来分隔路径名，如图8-28所示。

4. 点击OK。

8.3 C2H Compiler的使用

Nios II C-to-Hardware加速(C2H) 编译器是使得用户可以直接从ANSI C源代码创建定制外设加速器。硬件加速器是在硬件中实现C函数的逻辑模块，通常可以提高执行效率一个数量级。使用C2H编译器，用户可以在以Nios II 处理器为目标处理器的C程序中开发和调试一个算法，然后将C代码转化成在FPGA实现的硬件加速器。

C2H编译器通过将特定的C函数实现为硬件加速器，来改善Nios II程序的性能。C2H编译器不是将C作为设计语言来产生任意的硬件系统的工具。

C2H编译器建立在下面的前提之上：

ANSI C的语法足以描述计算密集或是存储器访问频繁的任务。

C-to-hardware工具一定不能打乱已有的软件和硬件开发流程。

基于以上的前提，C2H编译器的设计方提供下面的特性：

兼容ANSI C—— C2H编译器对ANSI C代码进行操作，支持大部分的C构造，包括指针、数组、结构、全局和局部变量、循环和子函数调用。C2H编译器不需要特殊的语法或者库函数来指定硬件的结构。

直接的C到硬件映射—— C2H编译器将C语法的每一个元素映射成一个定义的硬件结构，赋予用户对硬件加速器的结构的控制。

同Nios II IDE集成——用户通过Nios II IDE控制C2H编译器，不必去学习使用C2H编译器的环境。

基于SOPC Builder和Avalon交换架构—— C2H编译器使用SOPC Builder将硬件加速器连接到Nios II系统中。C2H加速器成为一个Nios II系统中的一个元件。SOPC Builder自动地产生Avalon交换架构将加速器连接到系统，省去了手动集成硬件加速器的时间。 报告生成的结果—— C2H编译器产生一个详细的报告：包括硬件结构、资源使用和吞吐量。

C2H编译器生成的硬件加速器有下面的特性：

并行时序—— C2H编译器认可并行发生的事件。的声明在硬件上是同时执行的。 直接存储器访问—— 加速器可以同时和Nios II处理器访问的相同的存储器。

循环流水线—— C2H编译器基于存储器访问延迟和并行执行的代码大小，将循环的逻辑实现流水线化。

存储器访问流水线—— C2H编译器采用流水线来访问存储器以降低持仓前延迟的效应。

8.3.1 C2H概念

这部分介绍一些支撑C2H编译器的基本概念。这些概念帮助读者更好地理解C2H编译怎样工作，以及怎样来获得更好的结果。

1. 简单和易于使用

C2H编译器将对现有的设计流程的影响降到最小。生成硬件加速器的流程和为加速器连接软件使用熟悉的Nios II IDE和 SOPC Builder设计工具。在Nios II IDE中编译的时候，用户可以指定是否一个C函数是作为处理器的指令还是硬件加速器进行编译。C2H编译器在后台调用其它的工具来处理硬件和软件的集成工作。特别地，C2H编译器在后台自动执行那个下面的任务：

1. 调用SOPC Builder指定硬件加速器怎样连接到系统，然后生成系统硬件。

2. 调用Quartus II 编译硬件设计，生成FPGA配置文件。

2. 快速的反复设计以找到最优的软硬件分配比例

C2H编译器允许用户在C代码中方便地更改硬件和软件的分界线，不需要很多的额外的设计工作。因此，用户可以很自由地进行重复的设计，实验多种结构。使用HDL文件来编写硬件加速器则需要很多的时间去创建逻辑设计和将加速器集成到系统中去。功能和性能需求的改变将会对设计实践产生很大的影响。

使用C2H编译器，用户可以加速必要的函数来获得需要的性能。用户可以通过简单的编辑C的源代码来平衡性能和资源的使用。

通过这些可用的工具，获得渴望的系统性能的过程经历了深远的改变。设计时间从创建、接口、调试硬件向完善算法实现和寻求最优的系统结构倾斜。

3. 加速对性能影响大的代码

C2H编译器只转化用户指定的代码。典型的程序中包含对性能影响大的代码以及其它的代码。对性能影响大的代码通常是重复和简单的，但是消耗了处理器执行的大部分时间。这些代码占用处理器来计算数值或移动数据，或进行以上的两种工作。硬件资源最好用来加速对性能影响大的函数，而不是将整个程序转换成硬件。

4. C2H 编译器工作在函数级

用户想要加速的代码必须是一个的C函数。C2H编译器将选中的函数内部的所有代码转化成硬件加速器模块。如果加速的函数中调用了子函数， C2H编译器也将子函数转化成硬件加速器。因此，用户必须注意，是否子函数也是适合C2H加速的。

如果用户想要加速的代码，不再一个函数中，那么要将这些代码放到一个函数中去。转换成的硬件加速器只完成处理器密集的任务，而不是处理器可以高效实现的设置和控制等任务。

5. 系统结构

图8-31显示了一个简单的Nios II 处理器系统的结构，其中包含一个硬件加速器。

图8-31 具有一个硬件加速器的系统拓扑

SOPC Builder自动将加速器逻辑以SOPC Builder的元件集成到系统中。系统中可以有多个加速器。加速器是和Nios II处理器分离的，但是可以访问Nios II处理器可以访问的存储器。用户能够在SOPC Builder中.手动配置加速器和系统的连接。

6. 硬件加速器的生成

C2H编译流程同传统的C编译器有很多共同的特征，但是声明的时序、优化和对象生成是不同的。当生成硬件加速器时，C2H编译器做如下的工作：

1. 使用GNU GCC预处理器分析代码。

2. 创建数据关联图。

3. 执行相应优化。

4. 确定执行每项操作的最佳次序。

5. 生成硬件加速器的目标文件。该目标文件是可综合的HDL文件。

6. 生成C打包函数，该函数隐藏了Nios II处理器同硬件加速器之间交互的细节。该函数

在软件连接的时候替换原来的词C函数。

生成的加速器逻辑包含如下内容：

一个或多个状态机用来管理C函数定义的操作的执行顺序。在任何一个时钟周期，任意数目的计算和存储器访问可能同时发生，这是由状态机管理。

一个或多个Avalon主端口，用于读取和存储状态机需要的数据。

一个Avalon从端口和一组存储器映射寄存器，允许处理器设置、启动和停止硬件加速器。7. 从C语法到硬件结构的一对一映射

C2H编译器将C语法的每一个元素映射为一个对等的硬件结构，C2H编译器使用直接翻译法则，基于输入的C代码直接例化硬件资源。一旦熟悉了C2H编译器的映射，用户可以通过改变C的源程序来控制生成的硬件结构。

下面是C2H编译器转换C到硬件的例子：

数算符(如+、-、*、>>) 转换成硬件的等效电路(如加法、减法、乘法和移位电路)。 循环(如for、while、do-while)转换成重复循环中的操作的状态机，知道循环条件不满足。 指针和数组访问(如*p、array[i][j])变成Avalon主端口，主端口和处理器访问相同存的储器。

不依赖之前的操作的结果的声明，被尽可能得向前调度，以允许最大程度的并行执行。 加速函数调用的子函数也使用相同的映射规则被转换成硬件。C2H 编译器只创建一个子函数的实例，不管子函数被调用多少次。将被加速的C代码放到一个子函数中，提供了一个在加速器内部创建共享的硬件资源的方法。

当C2H编译器基于资源共享可以减少资源的使用时，C2H编译器执行某些优化。参阅Nios II C2H Compiler User Guide中的C-to-Hardware Mapping Reference章节获得更多的C2H

编译器映射细节。

8. 性能依赖存储器访问时间

在处理器上运行的应用的性能瓶颈依赖处理器执行指令的速度。存储器访问时间影响执行时间，但是指令和数据缓存最小化处理器等待存储器访问的时间。

借助C2H硬件加速器，性能瓶颈发生了深远的改变。应用的性能瓶颈主要取决于存储器延迟和带宽。硬件加速器逻辑要给每个并行操作提供数据，如果硬件不能快速访问存储器，硬件将暂停等到数据，从而降低性能和效率。

要从硬件加速器获得最高性能通常包括检查系统存储器拓扑和数据流, 然后进行修改

以减少或消除存储器瓶颈。例如，如果用户的C代码随机访问存储器在低速SDRAM中一个大的缓冲器的中数据，性能会因为在SDRAM中不断的地址切换而降低。用户可以减轻这种瓶颈，首先将数据拷贝到片上RAM，然后允许硬件加速器访问快速、低延迟的RAM。注意用户可以创建DMA硬件加速器来加速拷贝操作。

8.3.2 适合硬件加速的C代码

本部分讨论判断C代码是否适合C2H编译器进行加速的指导方针。

1. 理想的加速候选

最小的代码量而消耗了CPU的大部分时间的C代码是最佳的加速候选。这些代码有如下特性：

包含相对小而简单的循环或是包含嵌套的循环。

对一组数据反复操作，每次对数据进行一个或多个操作，然后存储结果。

这种重复任务的例子包括存储器拷贝和修改、校验和计算、数据加密、解密和滤波操作。在以上的情形中，C代码对一组数据重复很多次操作，在每次重复过程中，要执行一或多个存储器读或写操作。

下面的例子演示了一个执行校验和计算的函数，这段代码摘录自TCP/IP协议栈，校验和计算的数据范围是网络协议栈的数据。校验和计算是IP协议栈中典型的耗时的部分，因为所有的接收和发送的数据必须要被验证，这要求处理器循环计算所有的字节。

例：校验和计算

u16_t standard_chksum(void *dataptr, int len)

{

u32_t acc;

/* Checksum loop: iterate over all data in buffer */

for(acc = 0; len > 1; len -= 2) {

acc += *(u16_t *)dataptr;

dataptr = (void *)((u16_t *)dataptr + 1);

}

/* Handle odd buffer lengths */

if (len == 1) {

acc += htons((u16_t)((*(u8_t *)dataptr)&0xff)<< 8);

}

/* Modify result for IP stack needs */

acc = (acc >> 16) + (acc & 0xffffUL);

if ((acc & 0xffff0000) != 0) {

acc = (acc >> 16) + (acc & 0xffffUL);

}

return (u16_t)acc;

}

加速上面的函数会对计算时间有很大的影响，尤其是花在循环上的时间。其余的代码每次调用执行一次，加速循环外的这些代码作用不大，除非standard_chksum()函数被另一个函数调用，而那个函数也是一个很好的加速候选。这段代码最有效的硬件加速器应是只替代for 循环部分。想要只加速for循环，需要将循环部分定义成一个单独的函数。

2. 不好的加速候选

加速某些代码会对性能产生负面的影响，或者不可接受地增加资源的使用，甚至以上两种同时效果出现。

使用下面的指导来确定不对其进行加速的函数：

包含很多顺序的操作，不能形成一个循环的代码，不是加速的好候选。处理器可以高效地执行这样的操作。

如果代码包含C2H编译器不支持的语法的话，代码不能被加速。例如浮点运算和递归函数。更多信息请参阅Nios II C2H Compiler User Guide中ANSI C Compliance and

Unsupported Constructs章节。

调用系统和运行时库函数的代码是不好的加速候选。例如，加速printf()或malloc()函数没有好处。这些函数的代码中包含一组复杂的顺序操作，不包括对性能大的循环。

也有一些例外情况，例如：

一些有经验的C程序员经常会将迭代的算法打开，实现为一组顺序的操作，为了能更好地配合C编译器工作。如果用户能够重新组合代码将其形成循环，那么对代码加速会有很好的性能提升。

一个内部的循环可能包含很多复杂顺序操作，如果对其加速会消耗很多逻辑资源。这就出现一个权衡，如果处理器在该循环花费了不可接受的时间，可能就值得使用硬件资源

来加速整个循环。

一些运行时库函数本质上是迭代的。这样的函数包括普通的数据搬移和缓冲器集合函数，如memcpy()或memset()。

3. 理解代码以发现加速的良机

使用C2H编译器获得最优的结果的最好的方法是理解自己的代码，去发现最关键的循环在哪里。如果用户从头自己编写代码，用户很可能会直到代码的关键部分。如果用户从已有的代码开始，使用C2H 编译器获得的性能提高的程度主要取决于用户分析和理解代码的程度。不管哪种情况，Nios II IDE的概况（profiling）特性可以帮助用户确定处理器在何处花费了大部分时间。

只是通过观察代码来确定关键的循环是很困难的，因为程序经常指示在几行代码上花费了大部分的时间。能够精确定位处理器在哪部分代码花费了大部分时间的唯一方法是对应用做概况分析，然后检查瓶颈函数。

参阅Altera的文档AN 391: Profiling Nios II Systems来获得更多信息。

8.3.3 C2H编译器设计流程

这部分讨论Nios II C2H编译器设计流程。会结合一个设计实例，一步一步地介绍创建自己的硬件加速器的过程。

设计实例的软件多次执行数据拷贝的函数。通过加速数据拷贝函数，可以获得10多倍的性能改进。获得的硬件加速器是具有DMA的硬件模块，可以在没有处理器干预的情况下拷贝数据。

C2H编译器的设计流程从一个或多个成功编译的C文件开始。在开始使用C2H编译器加速函数之前，用户必须：

确认需要加速的函数。

以Nios II处理器为目标处理器调试函数。

一、典型的设计流程

使用C2H编译器来加速函数的典型设计流程包括下面的步骤：

1. 使用C语言开发和调试应用或算法。

2. 概况代码来确认要加速的部分代码。

3. 将想要加速的代码形成一个单独的C函数。

4. 在Nios II IDE中指定要加速的函数。

5. 在Nios II IDE中重新编译工程。

6. 概况（profile）结果。

7. 如果结果没有达到设计要求，修改C源代码和系统结构（例如，存储器拓扑)。

8. 返回到步骤5，重复开始下面的步骤。

典型的C2H编译器设计流程一个反复迭代的过程，比较性能是否达到设计要求，修改C 代码来改进结果。如果C代码没有针对C2H编译器进行优化，第一次加速迭代的结果不会很明显地改进性能。接下来的迭代，修改C代码以产生最优的硬件结构，通常最后的结果比第一次的结果有很大的改进。

二、软件要求

C2H编译器是Nios II Embedded Design Suite (EDS)一部分。需要用户安装的软件有Quartus II，用户可以从Altera网站下载Quartus II网络版和Nios II EDS的试用版。

在设计过程中，会用到下面的工具：

Nios II (IDE)——控制函数加速的选项。加速的结果也在Nios II IDE中产生。生成的文件是可执行的文件 (.elf)。C2H编译器在后台调用SOPC Builder和Quartus II重新生成Nios II 系统和更新FPGA配置文件。

SOPC Builder——SOPC Builder管理C2H逻辑的生成和Avalon交换架构，将硬件加速器连接到处理器。在软件编译的过程中，Nios II IDE能够在后台调用SOPC Builder来更新更新硬件加速器和将其集成到Nios II硬件设计中去。输出文件是一组硬件描述语言文件（.v或.vhd)和SOPC Builder系统文件(.ptf)。该系统文件定义了用户的系统：Nios II处理器内核、外设、加速器、片上存储器和片外存储器接口。

Quartus II software——Quartus II编译和综合由C2H编译器和SOPC Builder工具产生的HDL文件，还有Quartus II工程中的其它定制逻辑。在软件编译过程中，Nios II IDE在后台调用Quartus II 编译Quartus II工程。会产生FPGA配置文件(.sof)，其中包含具有硬件加速器的更新的Nios II系统。

三、设计实例

这部分通过设计实例来指导读者使用C2H编译器加速函数的过程。用户将使用提供的设计实例的文件在Nios II IDE创建一个软件工程，加速一个函数，观察性能改进。

从C的源文件开始，到包含加速的函数的应用运行结束。其中的步骤包括

1. 建立硬件工程的硬件。

2. 创建工程的软件。

3. 只以软件来运行工程。

4. 创建和配置硬件加速器。

5. 重新编译工程。

6. 观察报告文件中的结果。

7. 观察SOPC Builder中的硬件加速器。

建立硬件工程和软件工程的步骤在前面的章节已经讲过，在这里只是简单介绍。硬件的设计是基于Nios II EDS提供的standard硬件的设计。软件设计文件是C 文件，文件名为dma_c2h_tutorial.c，该文件可以从Altera网站下载。用户可以在任何一款Altera提供的开发板上运行该设计。

dma_c2h_tutorial.c 文件包含两个函数：

do_dma() ——–该函数是用户将要加速的函数，它执行大块存储器拷贝。do_dma() 需要一个源地址指针，一个目的地址指针和一个拷贝的比特数。当以硬件实现该函数，do_dma()和DMA拷贝逻辑类似。

do_dma()的原型如下：

int do_dma( int * __restrict__ dest_ptr, int * __restrict__ source_ptr, int length )

main() ——main()调用do_dma()和测量需要多少时间，以便用户可以比较软件实现和硬件加速器。

main() 函数执行下面的工作：

1. 在主存储器中分配两个1 MB 缓冲。

2. 用递增的数值填充源缓冲。

3.使用全0x0填充目的缓冲。

4. 调用do_dma()函数100次。

5. 检查拷贝的数据，确认没有错误。

6. 释放以上分配的两个缓冲。

在调用do_dma()函数的循环附近有定时器函数来测量完成拷贝操作所需要的时间。在应用完成之后，在IDE的控制台会显示执行拷贝操作用了多少毫秒。

1. 建立工程硬件建立工程硬件执行下面的步骤：

1. 连接Nios开发板的电源，并且使用Altera的下载线将开发板与计算机相连。

2. 建立硬件工程的目录。

a. 找到用户开发板的standard 硬件设计实例，例如，Cyclone II的Nios 开发板的Verilog 文件，在/examples/verilog/ niosII_cycloneII_2c35/standard目录。

b. 拷贝standard 目录，并且将拷贝的目录命名为c2h_tutorial_hw。

3. 启动Quartus II。

4. 打开c2h_tutorial_hw目录中的Quartus II工程standard.qpf。

5. 配置Nios开发板上的FPGA。

a. 在Tools菜单点击Programmer。Programmer中出现FPGA配置文件standard.sof。

b. 选中Program/Configure复选框。.

c. 点击Start，下载配置文件到FPGA。

2. 创建软件工程

建立软件工程执行下面的步骤：

1. 启动Nios II IDE。

2. 创建一个新的C/C++应用工程，工程名起为c2h_tutorial_sw，选择Blank Project工程模板，目标硬件选为c2h_tutorial_hw目录中的 SOPC Builder系统文件。点击Finish IDE产生一个新的工程c2h_tutorial_sw和一个新的系统库工程c2h_tutorial_sw_syslib。

3. 从Altera网站下载软件文件dma_c2h_tutorial.c。

4. 引入C文件dma_c2h_tutorial.c到c2h_tutorial_sw工程中，最简单的方法就是采用外部的文件管理工具，如Windows Explorer，将该文件移到Nios II IDE中的C/C++ 工程视图的

c2h_tutorial_sw 文件夹中。

3. 只以软件运行该工程

运行该工程，执行如下步骤：

1. 在C/C++ 工程视图中，右键单击c2h_tutorial_sw工程，然后选择Run As，之后点击Nios II Hardware。Nios II IDE需要几分钟时间来编译和运行程序。

2. 在控制台视图中观察执行时间。在控制台试图中可以看到如下的信息：

This simple program copies 1048576 bytes of data from a source buffer to a destination buffer.

The program performs 100 iterations of the copy operation, and calculates the time spent.

Copy beginning

SUCCESS: Source and destination data match. Copy verified.

Total time: 39330 ms

可以看到以软件来运行该工程需要39330毫秒，这个数值因用户选用的开发板不同而可能不同。

4. 创建和配置硬件加速器

为do_dma()函数创建硬件加速器，创建硬件加速器执行下面的步骤：

1. 在 Nios II IDE编辑器中打开dma_c2h_tutorial.c文件。

2. 在源文件中，双击do_dma()函数名选中该函数。

3.右键单击do_dma，然后点击Accelerate with the Nios II C2H Compiler，如图8-32所示。C2H视图出现在Nios II IDE窗口的底部，如图8-33所示。

图8-32 选择要加速的函数

图8-33 C2H视图

本例中，为了简单化，do_dma()函数和应用其它的代码存在于同一个文件中。然而，一个好的做法是将要加速的函数单独形成一个文件。工程的makefile不能确定一个文件的哪个部分被改变了，因此，如果一个被加速的函数同其它未被加速的代码共存于一个文件，假设用户只编辑了未加速的代码，C2H编译器也会浪费时间在重新编译加速器上。

4. 设置新的加速器的编译选项，如图8-34所示。

a. 在图8-34中点击+图标，在C2H视图中展开c2h_tutorial_sw。

b. 选中Build software, generate SOPC Builder system, and run Quartus II compilation。当用户在Nios II IDE中编译工程，该选项会使C2H编译器在后台调用SOPC Builder和Quartus II 以生成新的FPGA配置文件。

c. 在C2H中展开do_dma()。

d. 在do_dma()下，选择Use hardware accelerator in place of software implementation. Flush data cache before each call。

在运行时，该选项使得程序激活do_dma()的加速器硬件。使用该选项，C2H的wrapper 函数在激活硬件加速器之前会刷新处理器数据缓存。wrapper函数需要在激活硬件加速器之前刷新数据缓存，如果处理器具有数据缓存，并且处理器和加速的函数写相同的存储器，不

刷新缓存可能会导致一致性问题。

图8-34设置加速器的编译选项

5. 重新编译工程

重新编译工程执行如下的步骤：

在C/C++ 工程视图中，右键单击c2h_tutorial_sw，然后点击Build Project。编译的过程需要20多分钟，取决于用户的计算机性能和目标FPGA。

在后台，Nios II IDE执行下面的任务：

1. 启动C2H编译器分析do_dma()函数，生成硬件加速器，生成C wrapper函数。

2. 调用SOPC Builder连接加速器到SOPC Builder系统。编译过程修改SOPC Builder系统文件(.ptf)，将新的加速器作为一个元件加入到系统中。

3. 调用Quartus II编译硬件工程，生成FPGA配置文件。

4. 重新C/C++ 应用工程，将加速器wrapper函数连接入应用。

进度信息在控制台视图中显示，编译过程创建下面的文件：

accelerator_c2h_tutorial_sw_do_dma.v (or .vhd)——该文件是被加速的函数的HDL代码。

该文件保存在Quartus II工程目录中，该文件名遵循格式：accelerator_name>_。该文件在Nios II IDE中不可见。

alt_c2h_do_dma.c ——该文件是加速器的wrapper函数，保存在软件工程的Debug或Release目录，名字遵循格式：alt_c2h_.c。

6. 在报告文件中观察结果

C2H编译器在C2H视图中产生一个详细的编译报告。编译报告包含硬件加速器性能和资源使用的信息，用户可以使用这些信息来为C2H编译器优化C代码。

下面介绍报告文件的主要特性，查看报告执行下面的步骤：

1. 在Nios II IDE中点击C2H视图，用户可以双击C2H页来在全屏模式下观看报告。

2. 在C2H视图中，展开c2h_tutorial_sw、do_dma()、Build report。

对于有多个加速器的设计，在C2H视图中列出的每个函数下都出现一个编译报告。

3. 展开Glossary部分。这部分定义报告中使用的术语。

4. 展开Resources部分和所有的子部分，如图8-35所示。Resources部分列出了硬件加速器所有的主端口。每个主端口对应源代码中的一个指针参照。本例中有两个主端口：一个是对应读指针*source_ptr；一个对应写指针*dest_ptr。

图8-35 C2H编译报告的Resources部分

5. 展开Performance 部分和所有的子部分。如图8-36所示。

Performance部分显示加速函数中的每个循环的性能特性。有两个标准来表征一个循环的性能：循环延迟和每个循环迭代的周期数(cycles per loop-iteration——CPLI)。循环延迟是需要填充流水线的时钟周期数。CPLI是假设流水线被填充并且没有延迟发生，要完成一次循环所需要的时钟周期数。通常为了更好的加速器性能优化应用就是要减少循环延迟和CPLI。

参阅Accelerating Nios II Systems with the C2H Compiler Tutorial来获得有关优化C2H编译

器结果的更多信息。

第8章 Nios II系统高级开发技术

图8-36 C2H编译报告的Performance部分

7. 在SOPC Builder中查看加速器

在C2H编译器添加硬件加速器到用户的SOPC Builder系统之后，加速器出现在SOPC Builder中。

要在SOPC Builder中查看新添加的加速器，执行如下的步骤：

1. 返回到Quartus II窗口。

2. 在Tools菜单点击SOPC Builder...打开SOPC Builder。

3. 在System Contents页注意到新的元件accelerator_c2h_tutorial_sw_do_dma，位于活跃的元件的列表底部，如图8-37所示。

4. 关闭SOPC Builder。

用户不能在在SOPC Builder修改加速器，必须在Nios II IDE中移出或修改它。当在Nios II IDE中使用C2H编译工程时，要关闭SOPC Builder。如果SOPC Builder没有关闭，在SOPC Builder窗口中显示的系统会变成过时，因为C2H编译器会在后台覆盖SOPC Builder系统文件(.ptf)。

SOPC技术基础教程

图8-37 包含加速器的SOPC Builder系统的元件列表

8．运行有加速器的工程

用户现在可以运行被加速的工程了，执行如下的步骤：

1. 返回到Quartus II窗口。

2. 使用新的FPGA配置文件配置FPGA，该文件包含硬件加速器。

3. 返回到Nios II IDE窗口。

4. 在C/C++ 工程视图，右键单击c2h_tutorial_sw工程，指向Run As，然后点击Nios II Hardware。Nios II IDE下载程序到开发板运行。

5. 在控制台视图观察执行时间。在控制台视图中可以看到如下的信息：

This simple program copies 1048576 bytes of data from a source buffer to a destination buffer.

The program performs 100 iterations of the copy operation, and calculates the time spent.

Copy beginning

SUCCESS: Source and destination data match. Copy verified.

Total time: 5010 ms

可以看到有硬件加速器工程运行时间大为减少了，该结果根据不同的开发板可能不同。

9. 移除加速器

用户可以从设计中移除加速器，在Nios II IDE中执行如下的步骤：

1. 在C2H视图中右键单击函数名，然后点击Remove C2H Accelerator，如图8-38所示。

2. 在Nios II IDE中重新编译工程。

移除加速器会从SOPC Builder中移出加速器元件，并且用原来的未加速的函数替代C2H 软件wrapper函数。必须在Nios II IDE中使用Remove C2H Accelerator命令来移除加速器。不要在SOPC Builder中手动来删除元件。

第8章 Nios II系统高级开发技术

图8-38 移除加速器