企业官网建设流程全解析

PLFM_RADAR 如何用 build_50t.tcl 构建 50T 生产板 bitstream 并理解其 DRC 豁免？

【免费下载链接】PLFM_RADAROpen-source, low-cost 10.5 GHz PLFM phased array RADAR system项目地址: https://gitcode.com/GitHub_Trending/pl/PLFM_RADAR

本文针对一个具体任务：为 AERIS-10 雷达的 50T 生产板（XC7A50T，FTG256 封装）生成可烧录的 FPGA bitstream，并弄明白 build_50t.tcl 里为什么要把四条 DRC 检查降级为 Warning。脚本入口是 scripts/50t/build_50t.tcl，约束文件在 constraints/ 目录，构建需要在 Vivado 的 batch 模式下运行。

构建前：脚本替你固定了哪些文件与配置

build_50t.tcl开头的一组set决定整个构建的输入，不需要手动改参数：

RTL 收集方式是取9_Firmware/9_2_FPGA/目录下的全部.v文件（add_files -norecurse），并跳过*_te0712_*和*_te0713_*两个 Trenz 开发板 wrapper，避免误用 dev 顶层。

radar_system_top_50t.v 是理解整个 50T 构建的关键文件。XC7A50T-FTG256 只有 69 个可用 IO，而核心顶层radar_system_top声明了很多在 50T 板上没有物理连接的端口（FT601 USB 3.0 相关、status/debug 输出等）。这个 wrapper 只暴露板上实际连接的端口，并把未用输入系到固定电平、未用输出接到_nc内部线，完整雷达流水线仍然保留在网表中。它同时通过.USB_MODE(1)强制选择 FT2232H 8 位 USB 2.0 接口（245 Synchronous FIFO 模式，60 MHzCLKOUT）。constraints/README.md 明确提醒：USB_MODE 是编译期选项，不能运行时切换；50T 生产构建必须使用radar_system_top_50t作为顶层，而不是直接使用radar_system_top。

adc_clk_mmcm.xdc是补充约束，文件头注明须在主生产 XDC 之后加入工程（脚本里正是这个顺序），它处理 MMCM ADC 时钟路径的 CDC 约束。

执行构建

在 FPGA 源码目录下运行（脚本头注释给出的用法）：

cd 9_Firmware/9_2_FPGA vivado -mode batch -source scripts/50t/build_50t.tcl 2>&1 | tee build_50t/vivado.log

需要注意的副作用：

• 脚本用create_project $project_name $project_dir -part $fpga_part -force建工程，-force意味着已有的同名build_50t/工程会被覆盖重建；
• write_bitstream -force会强制覆盖目标位置的旧 bitstream 文件。

脚本的执行流程是：launch_runs synth_1 -jobs 8综合 →open_run synth_1打开综合结果 →在当前进程直接执行opt_design -directive Explore、place_design -directive ExtraNetDelay_high、phys_opt_design -directive AggressiveExplore、route_design -directive AggressiveExplore，再跟两遍phys_opt_design -directive AggressiveExplore→write_bitstream。

实现阶段不走launch_runs/wait_on_run的 run 机制，而是直接在父进程里下命令。脚本注释给出了原因：DRC waiver 在父 Vivado 上下文中设置，直接用命令跑实现步骤，才能保证place_design等命令与 waiver 处于同一个 Vivado 上下文、豁免始终生效。这也是为什么脚本在open_run synth_1之后又重新执行了一遍四条set_property SEVERITY命令。

理解四条 DRC 豁免

脚本把以下检查从 Error 降级为 Warning，每一条都对应 50T 硬件的具体特征：

与PLIO-9配套还有一条直接命令（脚本第 119 行）：

set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets {ft_clkout_IBUF}]

Vivado 的 Place 30-876 检查要求时钟输入走专用时钟布线资源；时钟落在 N 型 MRCC 引脚时，必须设置CLOCK_DEDICATED_ROUTE FALSE才能完成布局。这条属性只压制 DRC 检查本身，时钟仍然经 IBUFG 进入时钟网络。

xc7a50t_ftg256.xdc 头部的 "DRC Fix History" 记录了这些检查的来龙去脉：clk_120m_dac曾从 C13（N 型）移到 D13（P 型 MRCC）来修 PLIO-9；adc_pwdn从 LVCMOS33 改成 LVCMOS25 来修 BIVC-1/Place 30-372。也就是说 waiver 是"先修硬件约束、再留降级兜底"的组合策略，而不是放任告警。

结果验证与产物位置

构建的成败可以直接从日志和文件判断：

1. 综合失败会立即终止：脚本读取synth_1的 STATUS，若不含*Complete*，打印CRITICAL: SYNTHESIS FAILED: ...并以exit 1退出，不会继续到实现和 bitstream 阶段。
2. bitstream 是否存在：成功后输出Bitstream: <path> (NNN KB)，路径固定为build_50t/bitstream/radar_system_top_50t.bit；若文件不存在则打印WARNING: Bitstream not generated!（脚本本身只打印警告，不视为错误退出）。
3. 末尾摘要：打印 Synth/Impl/Bit 三个阶段耗时，以及WNS/WHS（单位 ns）。WNS/WHS 读取失败时输出N/A——文档没有给出这两个指标必须达到的固定数值，请结合 timing 报告自行核对，不要只依赖终端打印。
4. 报告文件：脚本把报告写到build_50t/reports_50t/，包括：
   • 01_timing_post_synth.rpt、01_utilization_post_synth.rpt（综合后）
   • 02_timing_summary.rpt、04_utilization.rpt（最终时序与资源）
   • 06_drc.rpt（DRC 结果，确认四条检查以 Warning 形式出现而不是 Error）
   • 07_io.rpt（IO 分配）

限制与冲突说明

• Bank 14 电压存在文档冲突：xc7a50t_ftg256.xdc 头部注释和 build 脚本都按 LVDS_25 迫使 VCCO=2.5V 描述 Bank 14，而 constraints/README.md 的 Bank 电压表仍写 Bank 14 = 3.3V（ADC LVDS_33）。两处描述不一致，本文以 XDC 与 build 脚本的当前写法为准；如果你要基于 Bank 电压做修改，先确认哪份是最新的。
• status/debug 无读回通道：50T 板上 FPGA→STM32 只有 DIG_5/6/7 三根状态输出。XDC 注释给出三条扩展路径：在 DIG_5/6/7 上复用状态位、走 SPI 接口、或等 FT601 布线后走 USB。
• FT601 在 50T 上不可用：FT601 端口在 wrapper 中被系到 inactive 状态，50T 只有 FT2232H USB 2.0 数据通路；这与 200T dev 板（FT601，32 位）是两套构建路径，不要混用。

bitstream 生成并通过06_drc.rpt、02_timing_summary.rpt核对后，仓库的 scripts/utils/ 目录还包含program_fpga.tcl、ila_capture.tcl等脚本，可用于后续烧录与 ILA 抓取，具体用法以这些文件自身注释为准。

【免费下载链接】PLFM_RADAROpen-source, low-cost 10.5 GHz PLFM phased array RADAR system项目地址: https://gitcode.com/GitHub_Trending/pl/PLFM_RADAR