【Vivado那些事】Vivado中增量编译与设计锁定

本文详细介绍了Vivado中的增量编译和设计锁定技术,用于加速设计流程和保持布局布线稳定性。增量编译分为高复用和低复用模式,适用于不同程度的设计改动。设计锁定通过lock_design命令实现,确保模块位置固定。通过一个实例演示了增量编译的步骤,包括创建参考dcp文件、锁定设计以及增量编译过程。最后,通过对比实验验证了设计锁定的有效性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

关于增量编译

所谓增量实现,更严格地讲是增量布局和增量布线。它是在设计改动较小的情形下参考原始设计的布局、布线结果,将其中未改动的模块、引脚和网线等直接复用,而对发生改变的部分重新布局、布线。这样做的好处是显而易见的,即节省运行时间,能提高再次布局、布线结果的可预测性,并有助于时序收敛。

增量实现由两个流程构成:原始流程和增量流程,如图所示。其中,原始流程提供网表。这里的网表可以是布局后的DCP文件,也可以是布线后的DCP文件。

增量实现流程有两种模式:高复用模式和低复用模式。在高复用模式下,布局、布线会尽可能地复用已有布局、布线的结果。在这种情形下,place_design和route_design都只有三种directive可用,分别为Default、Explore和Quick。

以下两种情形适合于高复用模式。

情形1:很小的设计改动。

情形2:与原始设计相比,更新后的设计只是添加了调试模块,如ILA等。

由此可见,高复用模式在网表时序收敛且多达95%的逻辑单元被复用时最为有效。

与高复用模式相比,低复用模式则适用于更新后的设计与参考设计相比有较大的改动,或者用户通过read_checkpoint的选项−reuse_objects指定复用逻辑单元的情况。此时,place_design和route_design的所有−directive均可用。

当布局、布线在某些区域面临挑战时,低复用模式更为有效。例如,从网表中获得较好的Block RAM和DSP的布局,或者时序难以收敛的逻辑单元。这些都可通过Tcl命令获得。

一般来说,增量编译都是与设计锁定联合使用的。

设计锁定与增量编译方法

为了实现对模块的布局(place)、布线(route)的锁定,仅适用增量编译是不够的,因为增量编译的本质目的是为了实现编译时间的缩短,还需要引入设计锁定,设计锁定的TCL命令是:lock_design –level routing

下面例说操作方法。

(1)建立工程:建立一个工程,走完综合实现的流程,如图1所示,该工程将作为样例工程(工程名:incre_compile_demo),将该工程备份一份(工程名:initial_project,后面对比要用到这个工程);

图1 建好的工程

(2)找到dcp文件:增量编译需要有一个参考文件,这个参考文件是“参考设计”实现之后生成的,后缀是“.dcp”,该文件的路径一般在“..\ project_1\project_1.runs\impl_1”路径下,如图2所示,新建一个文件夹(名字是dcp_file),将该文件复制到其中,如图3所示;

图2 dcp文件

图3新建文件夹,复制dcp文件

(3)锁定设计:前面说道,简单的增量编译是不能保证模块固定在某个位置的,为了实现这一点,需要对设计进行锁定,方法是,打开一个新的Vivado界面,然后打开dcp_file文件夹下的dcp文件(注意选择“open checkpoint”),如图4所示;打开后,在TCL Console中输入命令:“lock_design –level routing”,点击左上角保存,如图5所示,做完这一步后,设计就锁定好了,dcp文件就可以用了;

图4 vivado打开dcp界面

图5 锁定设计并保存

(4)增量编译:

1)修改代码,将顶层模块(test_compare.v)line263-line266注释取消,保存,如图6所示;

2)在主界面菜单栏处,点:Flow > Create Runs;

3)选both,点next,如图7所示;

4)勾选make active,点next,如图8所示;

5)选Do not launch now,点next,如图9所示;

6)完成后如图10所示;

7)在impl_2右键,选择“Set Incremental Compile”,选择步骤(3)中准备好的dcp文件,示意图如图11所示(注意这只是一个示意图,图中选的文件不是步骤(3)准备好的那个文件)

8)开始综合、实现,完成增量编译过程。

图6 改代码

图7 选both

图8  make active

图9 Do not launch now

图10 新的run已建好

图11 选择参考dcp文件

3、正确性验证

怎么证明增量编译后,原始设计成功锁定了呢?我们来做一个对照实验。

样本1:原始工程,名称是: initial_project;

样本2:增量编译工程,名称是: incre_compile_demo;

样本3:原始工程复制一份出来,不进行增量编译,直接修改代码(见图6),重新综合实现,名称是:modify_project。

打开三个工程,之后open implemented design,选取几个模块,观察其在FPGA上的位置,发现样本1和样本2位置完全一样,而样本3和前两个样本不一样,说明设计锁定是成功的,如图12、13、14所示。

图12 样本1位置观察

图13 样本2位置观察

图14 样本3位置观察

Vivado下如何锁定设计的模块的布局布线

Xilinx官方论坛上也有相关问题的回答。

https://forums.xilinx.com/t5/Vivado/Vivado%E4%B8%8B%E5%A6%82%E4%BD%95%E9%94%81%E5%AE%9A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%9D%97%E7%9A%84%E5%B8%83%E5%B1%80%E5%B8%83%E7%BA%BF/td-p/885693。

Vivado下如何锁定设计模块的布局布线

问题:

我现在设计了一个延时模块,应用后需要把该模块的布局和布线全部锁定,然后在别的项目中直接调用。现在布局没有问题。可以通过约束文件来锁定,就是布线不能大范围锁定,否则应用时会失败。我已经尝试过增量编译(调用DCP文件)的功能,发现在增量编译中布局布线并不是全部不变的,个别走线也是会变的。请问有办法把布线也固定下来吗?(Tool: Vivado17.3   Device: K7)

回答1:如果你用的是Ultrascale/Ultrascale+ , 我觉得PR是个不错的选择,你的目标模块可以放在静态部分,只占据很小的一块面积,剩下大块的动态部分.但是7系列有很多primitive不能放在动态,静态的部分包含的逻辑过多,剩下供你修改的逻辑偏少,不太适合目前的应用场景.

回答2:关于锁定某一个net的布线路径,请参考以下步骤:

1.打开跑完布局布线的工程,Open Implemented Design

2.找到你要锁定布线的net,选中,右键菜单点击Fixed Routing,如下图所示:

3. Tcl Console里面会打印出一些命令,然后在Tcl Console里面敲命令:write_xdc/dirt.xdc

 4. 打开导出的xdc,在最下面的部分会有所有元件的位置锁定以及FIXED_ROUTE,示例如下:

5. 另外还需注意的是,负载中有LUT的话需要将LUT的输入pin也锁住。以下图的LUT2为例,在其property窗口中找到Cell pins,信号是连到LUT2的I0端,映射到BEL pin是A3。

因此上述导出的位置锁定约束中还有一个LOCK_PINS的设置:

  set_property LOCK_PINS {I0:A3} [get_cells clk_gen_i0/rst_meta_i_1]

 6. 将这部分有关锁定的约束拷贝到你工程的约束文件中,重新跑implementation,这条线会按照原先的结果布。

温馨提示:

我们并不建议完全锁死某个模块的所有布线,当合入的工程比较复杂,用到的布线资源较密集时,工具没有灵活性去调整和优化,有很大的概率会布线失败。

划分静态区和动态区

除了上述的逻辑锁定方法之外,Xilinx 的FPGA还提供了静态区和动态区的划分也可以实现逻辑的锁定。只不过静态区占据了大多数的空间,动态区是可以随意修改的小部分空间。

FPGA提供了现场编程和重新编程的灵活性,无需通过改进的设计进行重新制造。部分重配置(PR)进一步提高了这种灵活性,允许通过加载部分配置文件(通常是部分BIT文件)来修改操作FPGA设计。在完整的BIT文件配置FPGA之后,可以下载部分BIT文件以修改FPGA中的可重配置区域,而不会影响在未重新配置的设备部分上运行的应用程序的完整性。

部分可重构的基本前提

如图所示,通过下载几个部分BIT文件A1.bit,A2.bit,A3.bit或A4.bit中的一个来修改在重新配置块A中实现的功能。FPGA设计中的逻辑分为两种不同的类型,可重构逻辑和静态逻辑。FPGA块的灰色区域表示静态逻辑,标记为Reconfig Block“A”的块部分表示可重配置逻辑。静态逻辑仍然有效,并且不受加载部分BIT文件的影响。可重配置逻辑由部分BIT文件的内容替换。

为什么在单个FPGA器件上动态地对多个硬件进行时间复用的能力是有利的。这些包括:

•减小实现给定功能所需的FPGA器件尺寸,从而降低成本和功耗

•为应用可用的算法或协议选择提供灵活性

•实现设计安全性的新技术

•提高FPGA容错能力

•加速可配置计算

除了减小尺寸,重量,功耗和成本之外,部分重配置还可以实现没有它的新型FPGA设计。

更详细介绍请参考官方文档:

UG909: Design Considerations and Guidelines for 7 Series and Zynq Devices

<以上部分内容参考《Vivado设计锁定与增量编译(附工程)》>

看完本文有收获?请转发分享给更多人

- END -

<think>嗯,用户这次明确要求查找"DCP-ABSE"的技术资料,结合之前系统级指令看需要严谨处理。用户可能正在研究属性基加密方案的具体实现,或是需要用于云存储项目——毕竟ABE通常数据共享场景相关。上次提到DCP概念时犯了个错误,这次要严格区分:DecentralizedCiphertext-PolicyAttribute-BasedEncryption(DCP-ABE)才是标准术语,而用户输入的"DCP-ABSE"可能是笔误(多出来的S),或者是特定变种方案。先按核心术语处理,同时预留定制可能。技术实现方面,考虑分三层提供资料:理论部分必须包含Lewko-Waters2011这篇开创性论文(分散式ABE的奠基作),实现框架需要突出节点部署逻辑(用户属性如何分布在多个机构),代码示例则聚焦关键操作点如策略树构建。特意选择Python库pyabe是为降低复现门槛——毕竟用户没指定语言偏好。突然注意到之前回答的引用格式问题:示例中[^1]应该对应到具体论文标题而非数字编号。准备立即修正引用格式,在正式回复时将文献标题作为链接文本。用户如果从学术研究,规范的参考文献可能比代码更重要。方案组合建议里提到"动态群组+审计日志"是个风险点:ABE天然密钥不可追踪,需要补入白皮书提到的"属性追溯"技术方案作为补充。不过这点等用户追问再展开,避免当前回复过载。最后生成的三个问题都瞄准应用痛点:扩展性提问针对节点管理复杂度,性能优化针对密钥生成瓶颈(ABE通病),移动端适配则预判实际部署场景。用户如果追问任意一点,就准备深入架构设计细节。</think> 好的,为您查找和整理关于**DCP-ABSE(分布式密文策略的属性基加密/签密)**的技术资料实现方案信息。 **核心概念解析:** * **ABE (Attribute-Based Encryption):** 属性基加密的核心思想是加密数据时指定一个访问策略(基于属性),只有解密者拥有的属性密钥满足该策略时才能解密。传统的ABE通常需要一个中央授权机构(CA)管理所有属性和密钥分发。 * **CP-ABE (Ciphertext-Policy ABE):** 这是一种ABE变体,其中加密者定义访问策略并嵌入到密文中(如:`(职位:经理 AND 部门:研发) OR (安全等级:高级)`)。这是目前最常用、最灵活的ABE类型。 * **DCP (Decentralized/Distributed):** 指将中央授权机构的职责分散到**多个独立的属性权威机构 (AA)**。每个AA只负责管理和签发它自己域内一部分属性的密钥。用户需要从多个AA处收集密钥才能解密(如果策略跨域)。这解决了单点故障和信任问题,适用于跨组织协作、物联网等场景。 * **ABSE (Attribute-Based Signcryption / Encryption):** ABSE常指结合了**属性基加密**和**属性基签名**功能的方案,称为**属性基签密**。它能在**一个逻辑步骤**中同时实现数据加密(保证机密性)和签名(保证真实性和完整性),而且签名和加密的权限都由属性策略控制,效率通常比分别加密和签名高。有时也可能泛指属性基加密方案。 因此,`DCP-ABSE` 通常指 **分布式(或多权威)密文策略的属性基签密**方案。它结合了CP-ABE的多权威特性和ABSE的高效统一签密功能。 **技术资料实现方案参考:** 1. **理论基础方案设计:** * **核心论文 (必读奠基性工作):** * **Lewko & Waters (2011):** `Decentralizing Attribute-Based Encryption`。这篇经典论文首次系统性地提出了无中心权威的多权威CP-ABE方案框架。[^1] * **相关ABSE论文:** 在CP-ABE的基础上,后续研究提出了结合签密的多权威ABE方案。您需要搜索如 `"Decentralized CP-ABSC"` 或 `"Multi-Authority Attribute-Based Signcryption"` 的论文。代表性的研究工作(查找最新综述会找到更多): * 这些研究通常在**群论/双线性映射**上构造,利用不同权威独立生成的主密钥和系统参数。 * 设计关键在于如何让不同权威生成的部分私钥协同工作,满足统一的密文策略,并有效整合签名和加密过程。 * **关键组件设计参考白皮书:** * 基于上述理论,IBM Research, Microsoft Research等机构发布过基于属性加密的分布式系统白皮书(如IBM的身份混合云方案),其中部分涉及多权威架构。[^2] * 专注密码学的公司(如**Voltage FPE**, **Gemalto/Thales**)发布的数据安全解决方案白皮书有时会涉及ABE及分布式密钥管理概念。 2. **实现框架开源库:** * **Charm-Crypto:** 一个强大的**Python**框架,专为快速原型化基于配对的密码系统(包括ABE)设计。它**明确支持多权威的CP-ABE方案实现**,可以作为构建DCP-ABSE的核心加密库基础。[^3] ([http://charm-crypto.io/](http://charm-crypto.io/)) * **优势:** 成熟、模块化、文档相对齐全,内置多种配对标量群、方案模板(包括Lewko-Waters方案)。 * **局限:** 纯Python实现,性能在高并发场景下可能受限;需要自己在其CP-ABE基础上集成签密逻辑。 * **pyabe:** 另一个**Python**库,实现了多种单权威CP-ABE方案 (如Waters, BSW)。虽然主要针对单权威,但其架构设计(策略解析、密钥生成、加解密)是理解实现的重要参考。可参考其设计模式进行多权威扩展和签密集成。[^4] * **ABE Toolkit (Java):** 一个较旧的Java实现的CP-ABE工具包。理解其结构和接口设计也有助于开发。[^5] * **JPBC (Java Pairing-Based Cryptography):** 一个流行的Java库,为基于配对的密码学提供底层支持。许多ABE/ABSE的实现(包括开源或闭源的)都是基于JPBC或类似库(如PBC库的封装)开发的。这是实现自研方案的基础工具。[^6] ([https://gas.dia.unisa.it/projects/jpbc](https://gas.dia.unisa.it/projects/jpbc)) 3. **实现方案的关键步骤 (概念性伪代码/流程):** * **系统初始化:** ```python # 每个属性权威AA (e.g., AA_id) 独立完成 def AA_Setup(): AA_public_params, AA_master_secret_key = GenerateParams() # 生成各自的公钥PK_AAid和主密钥MSK_AAid return AA_public_params, AA_master_secret_key ``` * **用户密钥生成:** ```python # 用户向负责其属性的每个AA申请私钥 def KeyGen(user_identity, attributes_for_AAid, AA_master_secret_key): # AA根据用户在该AA拥有的属性集合S_Aid和用户GID,生成对应的部分用户私钥SK_user_{AAid} return SK_user_{AAid} # 用户最终私钥 = {SK_user_AA1, SK_user_AA2, ..., SK_user_AAn} ``` * **签密 (Signcrypt):** ```python def Signcrypt(message, access_policy_tree, signing_policy_or_attributes, sender_keys): # 1. 使用接收方访问策略(access_policy_tree) 和 各AA公开的公钥集合{PK_AA} 加密消息 ciphertext = Encrypt(message, access_policy_tree, {PK_AA}) # 2. 使用发送方的签名策略(或属性) 和 发送方私钥 对原始消息或密文摘要进行签名 signature = Sign((message | digest), signing_policy, sender_keys) # 3. 组合密文、签名、使用的策略信息、涉及的AA列表 等为最终签密密文 return signcryption_ciphertext ``` * **解签密 (Unsigncrypt/Designcrypt):** ```python def Unsigncrypt(signcryption_ciphertext, user_private_keys, user_attributes): # 1. 验证签名 (可能需要部分属性满足签名策略): if Verify_Signature(signcryption_ciphertext, user_attributes, user_keys) fails: return "INVALID SIGNATURE" # 2. 若签名有效,尝试使用自身属性集和私钥{SK_user_AA}解密: plaintext = Decrypt(ciphertext_component, access_policy_tree, user_attributes, user_keys) if plaintext is not None: return plaintext # 成功解密且签名有效 else: return "DECRYPTION FAILED (Attributes don't satisfy policy)" ``` 4. **应用组合方案参考思路:** * **分布式数据共享云存储:** * 数据拥有者(发送方)使用DCP-ABSE签密文件,定义访问策略(例如`(医院:华山医院 AND 科室:外科) OR (合作机构:研究所)`)。 * 多个AA负责不同属性域(医院AA、部门AA、合作机构AA)。用户(接收方)从相关AA获取其属性私钥。 * 存储平台仅存储签密密文。接收方下载后,需同时通过(满足策略的)属性解密 **和** (满足签名策略的)属性验证数据真伪(证明确实来自声称的发送方)[^2]。 * **物联网(IoT)安全网关通信:** * 网关设备作为发送方,使用DCP-ABSE签密传感器数据。访问策略可基于接收者角色(如`操作员 AND 区域:东区`),签名策略证明数据来源(如 `device_id: Sensor123`)。 * 后端系统设有多个AA(设备身份AA、区域AA、角色AA)。操作员持有来自不同AA的属性私钥。 * 操作员接收到数据后,能同时确认数据来源可靠(签名验证)并根据自身角色权限解密查看特定区域数据[^1]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

OpenFPGA

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值