2. Lattice FPGA器件与开发环境
Lattice FPGA 的产品线在近几年形成了比较清晰的分层：面向低功耗小尺寸的 CertusPro-NX、面向通用中端逻辑与接口桥接的 Nexus 平台（含 Certus-NX、Mach-NX、CrossLink-NX 等），以及面向更高逻辑密度与更高带宽的 Avant 平台（如 Avant-E、Avant-G）。理解这三类器件的架构差异，是后续做算法加速与性能评估的前提，因为不同系列的 LUT 结构、DSP 资源、存储块、时钟网络和高速接口能力，直接决定了哪些算法适合映射、能跑到什么频率、瓶颈会出现在哪里。
一、主流系列架构特点
Nexus 平台是 Lattice 目前最广泛使用的中端低功耗 FPGA 架构。它采用 28 nm FD-SOI 工艺，核心可编程单元为 4 输入 LUT 加进位链结构，每个逻辑单元（PLC）包含多个 LUT 与寄存器，适合实现组合逻辑、状态机和中等位宽的算术运算。Nexus 器件普遍集成较大容量的 EBR（Embedded Block RAM）和 LRAM（Large RAM），其中 EBR 适合做双端口缓存、行缓冲和查找表，LRAM 则适合做单端口大容量数据缓冲。DSP 资源方面，Nexus 提供 sysDSP 块，支持 18×18 乘法、乘加和预加器结构，是卷积、滤波、矩阵乘等算法加速的核心资源。此外，Nexus 器件内置硬核 IP，如 PCIe Gen2、SGMII、DDR3/DDR4 控制器等，可减少逻辑资源占用。
CertusPro-NX 是 Nexus 家族中面向“低功耗 + 高接口密度”的型号。它的逻辑规模通常在 25K～100K LUT 级别，强调小封装、低静态功耗和丰富的 SerDes 通道。其架构特点是：EBR 与 LRAM 配比更偏向数据缓存，DSP 数量适中，适合做多路视频、工业相机、传感器聚合等场景。对于算法加速而言，CertusPro-NX 更适合实现定点小规模卷积、图像预处理、协议转换等任务，而不适合承载大规模矩阵运算。
Avant 平台则定位更高。Avant-E 与 Avant-G 采用 16 nm FinFET 工艺，逻辑密度从 100K LUT 级起步，向上覆盖到 500K LUT 级别。Avant 的架构在 DSP 和存储带宽上明显增强：DSP 块支持更高频率的乘加运算，EBR 容量更大，并引入更高速的 SerDes 与 DDR 接口。Avant-G 还强调通用逻辑与高速接口的平衡，适合做中高端图像处理、网络加速和实时信号处理。若算法需要并行度较高的 MAC 阵列，Avant 比 Nexus 更容易在单芯片内完成映射。
选型判断要点：若算法以 8～16 位定点乘加为主、并行度在几十路以内，Nexus/CertusPro-NX 通常够用；若需要上百路 MAC 并行、或需要 DDR4 高带宽缓存，应优先考虑 Avant。评估时先看 DSP 数量、EBR 总容量和最大时钟频率，再看接口是否满足数据输入输出需求。
二、Radiant 与 Propel 工具链定位
Lattice 的开发工具分为两条主线：Radiant 面向传统 RTL 与原理图设计流程，Propel 面向基于 RISC-V 与可编程逻辑协同的嵌入式系统设计。Radiant 支持 Nexus、CertusPro-NX、Avant 等主流器件，提供综合、布局布线、时序分析、功耗分析和比特流生成。Propel 则把 CPU 子系统、外设和 FPGA 逻辑放在同一个工程中，适合做软硬协同的算法加速方案。
对于算法加速课程，建议以 Radiant 为主工具，因为算法映射、流水线设计、DSP 推断和时序收敛都在 Radiant 中完成；Propel 用于需要 CPU 调度、DMA 搬运或软硬接口控制的场景。两者可以配合使用：先在 Radiant 中把算法核做成可综合模块，再在 Propel 中集成到 SoC 环境。
三、Radiant 安装与工程创建
Radiant 的安装流程比较直接，但需要注意版本与器件库匹配。以 Windows 环境为例，从 Lattice 官网下载 Radiant 安装包后，运行安装程序，选择安装路径（建议不含中文和空格），在组件选择界面勾选目标器件系列，例如 Nexus、CertusPro-NX、Avant。若只做算法验证，可只安装对应系列，减少磁盘占用。安装完成后，首次启动需要加载 License，通常使用免费 License 或节点锁定 License，在 Help → License 中导入。
创建工程时，选择 File → New → Project，指定工程名与路径，选择器件系列和具体型号。例如选择 CertusPro-NX 的 LFCPNX-100，封装与速度等级按实际开发板填写。工程创建后，Radiant 会自动生成源文件目录、约束文件目录和实现目录。接下来添加 Verilog/VHDL 源文件，或使用 IP Catalog 例化 EBR、DSP、PLL 等硬核资源。
# 典型 Radiant 工程目录结构（示例）
project/
├── src/ # RTL 源文件
│ ├── top.v
│ └── mac_array.v
├── constraints/ # 约束文件
│ └── top.lpf
├── impl/ # 布局布线输出
└── sim/ # 仿真文件
约束文件使用 LPF 格式，用于定义引脚位置、时钟频率和时序例外。例如把系统时钟约束为 100 MHz，并指定输入输出引脚。完成约束后，依次执行综合（Synthesize）、映射（Map）、布局布线（Place & Route）、时序分析（Timing Analysis）和比特流生成（Bitstream）。每一步都可以在 Log 窗口查看警告和错误，时序报告重点看 WNS（最差负裕量）和 TNS（总负裕量），若 WNS 为负，说明当前频率下时序不收敛，需要优化流水线或降低频率。
四、Propel 工程基本流程
Propel 的工程创建与 Radiant 类似，但更强调 CPU 子系统配置。新建工程后，选择目标器件和 RISC-V 核，配置总线、外设和中断，再把算法模块作为 AXI 或 APB 外设挂到总线上。Propel 会自动生成地址映射和驱动框架，用户只需实现算法核的寄存器接口和数据通路。编译后生成比特流与固件，下载到开发板即可运行。
五、工具链使用中的常见问题
实际使用中，最常见的问题是器件库未安装导致无法选择型号、License 失效导致无法生成比特流、约束引脚与开发板不一致导致下载后无响应。排查顺序建议为：先确认器件系列与版本匹配，再检查 License 状态，最后核对 LPF 中的引脚和时钟约束。若综合后 DSP 或 EBR 没有被推断出来，应检查代码风格是否满足推断模板，例如乘法累加是否写成同步复位、是否使用了工具可识别的加法树结构。
六、面向算法加速的工程配置建议
在 Radiant 中做算法加速时，建议把算法核单独放在一个模块中，顶层只做接口和时钟管理。这样便于单独综合和时序分析，也方便后续移植到 Propel。时钟约束要按实际板级时钟填写，若使用 PLL 倍频，需在 LPF 中同时约束输入时钟和输出时钟。对于 DSP 推断，推荐使用同步复位、寄存器化输入输出，并避免在乘法器前后插入复杂组合逻辑，否则工具可能改用 LUT 实现，导致资源和频率都变差。
功耗评估方面，Radiant 提供 Power Calculator，可根据时钟频率、翻转率和资源使用量估算动态功耗。算法加速中若并行度提高，DSP 和 EBR 的使用量上升，功耗也会增加，需要在性能和功耗之间做权衡。对于 CertusPro-NX 这类低功耗器件，建议优先用时间换面积，减少并行路数；对于 Avant，则可以适当提高并行度以换取吞吐率。
实践建议：第一次使用某款器件时，先用一个简单的乘法累加模块跑通完整流程，确认综合、布局布线、时序和下载都正常，再逐步加入算法逻辑。这样可以把工具链问题和算法问题分开排查，减少调试时间。
总体来看，Nexus、CertusPro-NX 和 Avant 分别对应低功耗接口、低功耗高接口密度和中高端高密度三类需求。Radiant 负责从 RTL 到比特流的完整实现，Propel 负责软硬协同的系统集成。掌握器件资源与工具流程的对应关系，才能在后续算法加速中做出合理的映射决策和性能评估。