把 Vivado 项目放心交给 Git:一篇 FPGA 工程师必读的实战指南

之前分享过一篇文章《FPGA 版本管理三种方式:你会选哪一种?》,评论区很多人都推荐使用Git进行版本管理,今天这篇文章主题就是使用Git进行备份指南。

在 FPGA 开发中,掌握 Git 等源码管理工具已经是必备技能。

当然,在使用 Vivado 时,我们不仅需要处理源代码控制,还需要处理以 IP 为中心的设计产品。

Vivado 的工程通常是 IP 为中心 的设计,包含:

  • IP Integrator Block Diagram
  • 各类 IP 实例(独立 IP 或 BD 内 IP)
  • 自动生成的包装文件与工程产物

这让很多 FPGA 工程师一开始会觉得:

“Vivado 项目到底该怎么和 Git 一起用?”

好消息是,从 Vivado 2022.1 开始,这一切已经变得非常清晰、也非常容易。

Vivado 2022.1 之后最重要的变化:源文件与生成文件分离

在 Vivado 2022.1 之前:

源文件和生成文件全部混在同一个 .srcs 目录中。

而从 Vivado 2022.1 起,工程目录被明确拆分为:

  • .srcs:源文件
  • .gen:生成文件

这一点非常关键。

👉 这意味着:

只要我们保存 .srcs 目录 + .xpr 工程文件,就可以在任何地方完整重建 Vivado 工程。

示例工程说明

示例使用 Vivado 2024.1 创建了一个新工程,目标板卡为 Avnet ZU Board。

IP Integrator 设计包含:

  • Zynq MPSoC Processing System
  • Smart Interconnect
  • AXI BRAM Controller

此外还加入了 自定义 RTL 文件,通过 UART 提供 AXI 访问,用来演示 自定义 RTL 与 IP 设计共存 的情况。

完成后的 Block Diagram 如下:

Vivado 工程目录结构解析

1️⃣ .srcs 目录

imports/ 下是用户添加的 VHDL / Verilog 源文件

bd/ 下是 IP Integrator 的 Block Diagram

ip/ 下是各个 IP 的 .xci 配置文件

👉 这些都是必须纳入 Git 管理的内容

2️⃣ .gen 目录

.gen 中包含:

自动生成的顶层 wrapper

IP 的生成文件

综合与仿真所需的中间文件

👉 这些文件不需要提交到 Git

将 Vivado 工程加入 Git 仓库

假设你已经在 GitHub 上创建了一个空仓库,下面是核心的步骤。

初始化仓库

git init

添加 Vivado 工程文件

只需要添加两部分:

git add git_demo.srcs/* git add git_demo.xpr

提交到本地仓库

提交这些文件并附带一条消息。

git commit -m "initial issue"

你会看到:

.xpr

RTL / VHDL 文件

IP .xci 文件

都已经被 Git 跟踪。

绑定远程仓库并推送

git remote add origin <url> git push -u origin master

此时在 GitHub 网页上,就可以看到完整的 Vivado 工程源文件了。

从 Git 仓库重建 Vivado 工程

为了验证流程是否正确,我们新建一个文件夹:

git clone <repo_url>

然后直接打开 .xpr 文件。

我们需要重新生成顶层 wrapper,重新生成 IP,正常完成综合与实现即可。

整个流程无需额外脚本,运行非常顺利。

小结

Vivado 2022.1 之后,工程结构已经非常适合 Git 管理

只需管理 .srcs + .xpr

IP、BD、RTL 都能自然融入 Git 流程

Vivado 工程终于可以像软件工程一样被“正常管理”

上面只是简单的使用,后续文章将继续介绍高级点的用法及 Vitis 与源码管理的协同方式。

Read more

openclaw 对接完飞书群机器人配置踩坑记:消息不回、Gateway 断开问题排查

openclaw 对接完飞书群机器人配置踩坑记:消息不回、Gateway 断开问题排查

前言 用 OpenClaw 配飞书机器人,踩了两个坑:群消息不回、Gateway 总是断开。排查了好一阵子,总算搞定了,记录一下希望能帮到遇到同样问题的朋友。 发现问题 飞书消息不回复 在飞书群里 @ 了机器人,完全没反应。一开始以为是网络不好或者机器人没上线,但状态显示明明是连接着的,这就奇怪了。 Gateway 频繁断开 每次改完配置跑 openclaw gateway restart,或者根本什么都没干,Gateway 说断就断。再想启动就报错,必须跑一遍 openclaw doctor --fix 重新安装才能用。太影响使用了。 查看原因 飞书机器人 ID 搞错了 翻日志看到这么一句: receive events or callbacks through persistent connection only available in

Copilot权限设置全攻略:从入门到合规的7步落地路径

第一章:Copilot权限设置的基本概念 GitHub Copilot 是一款基于人工智能的代码补全工具,能够根据上下文自动建议代码片段。为了确保安全与协作效率,合理配置其权限至关重要。权限设置不仅影响开发者获取建议的能力,还关系到组织内代码的安全性与合规性。 权限模型概述 Copilot 的权限控制主要围绕用户身份、组织策略和资源访问三个维度展开。在企业环境中,管理员可通过 GitHub 组织设置统一管理 Copilot 的启用状态与访问范围。 * 成员角色决定是否能使用 Copilot 建议 * 组织策略可限制特定仓库禁用 Copilot * 私有代码内容不会被用于训练模型,保障数据隐私 基本配置步骤 管理员需登录 GitHub 并进入组织设置页面进行配置: 1. 访问“Settings” > “Billing and plans” > “GitHub Copilot” 2. 选择“Manage organizations”并为指定组织启用服务 3. 设定成员许可分配方式:自动分配或手动审批 API

DeepSeek-R1-Distill-Llama-8B效果展示:看看AI能写出多好的文章

DeepSeek-R1-Distill-Llama-8B效果展示:看看AI能写出多好的文章 你有没有试过这样提问:“请用鲁迅的笔调写一篇关于外卖小哥在暴雨中送单的短文”?或者“把《三体》第一段改写成适合小学生理解的科普版本”?又或者“帮我写一封既专业又带点人情味的辞职信,不卑不亢,留有余地”? 不是所有模型都能稳稳接住这些“有性格、有分寸、有温度”的请求。但今天我们要聊的这个模型——DeepSeek-R1-Distill-Llama-8B,它不靠参数堆砌,也不靠算力碾压,而是用一种更“聪明”的方式,把文字写得像真人一样自然、准确、有层次。 它不是最大的模型,也不是最贵的模型,但它可能是目前8B级别里,最会“拿捏语气”、最懂“写作分寸感”、最擅长“按需输出”的文本生成模型之一。接下来,我们不看参数表,不谈训练细节,就用最朴素的方式:直接看它写的文字。 1. 它到底是什么?一句话说清 1.1 不是“大而全”,而是“

使用 ChatGPT/Copilot 提升前端开发效率的 N 种方式

引言:AI 已经不只是副驾驶,而是你的开发团队 想象这样一个场景:凌晨 2 点,你盯着一个奇怪的 React 报错信息已经 3 小时,Stack Overflow 上所有相关答案都试过了,但问题依旧存在。这时候,你的“AI 队友”只需要 30 秒就提供了准确的解决方案,甚至解释了问题的根本原因和三种不同的修复方法。 这不是科幻场景,而是现代前端开发者正在经历的日常。ChatGPT 和 GitHub Copilot 已经从前沿技术变成了实实在在的生产力工具。但大多数开发者仅仅把它们当作“高级搜索引擎”或“智能代码补全工具”,这就像把瑞士军刀只用来开瓶盖。 今天,我要分享的是如何真正将这些 AI 助手融入前端开发工作流,让它们成为你的代码导师、调试伙伴和创意合伙人。 第一部分:代码生成与智能补全 1.1 从自然语言到可运行代码 传统方式: javascript