1. 从代码裸奔说起为什么ADF网表加密是FPGA交付的必修课做FPGA项目交付的同行大概都经历过这种尴尬客户拿着你的板子想改个参数你只能把整个工程打包发过去结果对方顺手就把你的RTL源码学习了一遍。更麻烦的是有些项目是多方协作的你只负责其中一个模块但整个工程的网表文件在各方之间流转谁都能打开看看里面到底写了什么。这种代码裸奔的状态在商业项目里其实是个不小的隐患。紫光同创的PDSPango Design Suite环境里ADF文件就是那个承载综合后网表信息的关键载体。所谓ADF全称是Anlogic Design File的同类概念在紫光同创体系下的对应格式它记录的是综合之后的逻辑网表、约束信息以及部分布局布线前的中间数据。和直接交付RTL源码相比ADF网表文件已经失去了可读的HDL语义但它仍然保留了完整的结构信息懂行的人拿到之后依然可以分析出模块划分、关键路径甚至部分算法逻辑。所以对ADF做加密本质上是在可交付和可保护之间找一个平衡点。这篇文章面向的是已经上手紫光同创PDS、做过至少一个完整工程、并且开始接触模块化交付或多方协作的FPGA开发者。如果你还在跑点灯和数码管动态显示那ADF加密暂时用不上但如果你已经开始给别人交付网表、或者需要把某个IP核以网表形式集成到别人的工程里那这套流程就是绕不过去的。我会把PDS环境下ADF网表的生成、加密、集成整个链路拆开讲包括那些官方文档里一笔带过、但实际会卡住你半天的细节。先明确一个概念边界ADF加密不是把文件变成完全不可用的密文而是让文件只能在特定的授权环境下被PDS识别和调用。换句话说加密后的ADF依然要能被工具链正常读取只是读取的过程需要经过授权验证。这个授权的载体在紫光同创的体系里通常是一个和特定机器或特定License绑定的密钥文件。理解这一点后面很多操作逻辑就顺了。2. ADF网表文件在PDS工程中的真实角色2.1 综合之后、布局布线之前ADF到底存了什么很多人第一次接触ADF会把它和比特流文件搞混。比特流是最终烧到FPGA里的配置数据而ADF是综合阶段输出的网表描述。在PDS的流程里你写完RTL代码跑完综合Synthesis工具会把你的行为级描述映射成门级网表这个网表加上约束信息就打包成了ADF文件。它里面包含的东西大致有这么几类实例化的查找表LUT、触发器FF、块RAMBRAM、DSP单元等原语的连接关系时钟约束、IO约束、时序例外等约束信息以及一些和器件型号相关的属性标记。和RTL源码相比ADF已经没有了always块、if-else、状态机这些高层语义你打开它看到的是一堆原语和网线的连接列表。但别以为这样就安全了有经验的人通过分析LUT的连接模式依然可以反推出部分逻辑功能尤其是那些结构规整的算法模块比如滤波器、编解码器。所以ADF加密的核心目标是防止未授权方直接读取这些连接关系而不是指望它变成完全不可分析的黑盒。2.2 什么场景下必须用ADF交付而不是RTL我总结下来主要有三种场景。第一种是IP核交付你开发了一个成熟的模块比如一个高效的CORDIC或者一个定制的通信协议栈不想把源码给客户但又需要客户能在自己的工程里调用。第二种是多方协作中的模块隔离一个大项目拆成几个团队做每个团队只负责自己的部分互相之间不希望看到对方的实现细节。第三种是产线烧录环节工厂需要拿到网表去生成比特流但你不希望工厂掌握核心逻辑。这三种场景的共同点是对方需要用你的设计但不需要看你的设计。ADF加密就是为这个需求量身定做的。反过来如果是你自己团队内部开发或者项目完全开源那加密就是多此一举反而增加维护成本。2.3 加密ADF和普通ADF在工具链里的行为差异普通ADF在PDS里可以直接双击打开能看到内部的网表结构也能直接参与布局布线。加密后的ADF在PDS里依然可以被添加到工程中但工具会先检查授权文件验证通过后才加载网表内容。如果授权不匹配PDS会报错并拒绝加载。这里有个细节加密ADF在综合流程中的位置和普通ADF完全一样都是作为综合后的输入参与后续的布局布线所以对下游流程来说加密与否是透明的。但有一个行为差异需要特别注意加密ADF通常不允许被再次综合或修改。也就是说你拿到一个加密ADF只能把它当作一个黑盒模块来用不能在里面加逻辑或者改约束。这个限制是加密机制本身带来的不是工具bug。理解这一点在集成的时候就不会走弯路。3. 在PDS里生成可加密ADF的完整操作链路3.1 工程配置阶段哪些选项决定了ADF的可加密性在PDS里新建工程的时候有一个选项经常被忽略就是综合策略里的网表输出格式。默认情况下PDS综合后生成的是内部中间格式你需要手动在综合设置里勾选生成ADF网表或者类似的选项工具才会在综合完成后输出ADF文件。这个选项的位置在综合设置的Output标签页下不同版本的PDS可能略有差异但大方向一致。另外工程的目标器件型号必须和后续集成方的器件型号一致否则ADF里的原语映射会对不上。这一点在跨版本、跨器件系列的时候特别容易出问题。我遇到过客户用同创的Logos系列生成ADF结果集成方用的是Logos2系列虽然引脚兼容但内部原语结构有差异导致布局布线时报了一堆莫名其妙的错误。所以生成ADF之前一定要和集成方确认器件型号和PDS版本。3.2 综合参数设置避免加密后无法集成的几个关键项综合参数里有几个设置会直接影响ADF的可用性。第一个是层次化保留选项如果你希望集成方能看到模块的层次结构只是看不到内部逻辑就需要在综合时保留层次边界。第二个是IO缓冲插入策略如果ADF是要集成到更大的工程里通常不需要在ADF内部插入IO缓冲这个应该交给顶层工程处理。第三个是时钟资源分配加密ADF里的时钟约束会被保留但如果集成方的时钟网络和生成方不一致就需要在顶层重新约束。我个人的习惯是在生成ADF之前先建一个干净的综合配置关闭所有调试相关的选项比如在线逻辑分析仪ILA的插入、调试寄存器的保留等。这些调试逻辑如果被固化到ADF里集成方既用不上又占资源还可能因为调试信号的名字冲突导致集成失败。3.3 生成ADF时的约束处理时钟、IO和时序例外约束是ADF里最容易被忽视但又最关键的部分。生成ADF的时候PDS会把当前工程的所有约束一并打包进去包括时钟定义、IO位置、时序例外等。这里有个坑如果你的约束里包含了具体的引脚位置比如set_property PACKAGE_PIN而集成方的板级引脚分配不同那这个ADF集成进去就会报引脚冲突。正确的做法是在生成ADF之前把和具体板级相关的约束引脚位置、IO标准等剥离出来只保留和逻辑本身相关的约束时钟周期、时序例外、虚假路径等。这样集成方拿到ADF后只需要在顶层补充板级约束即可。具体操作上可以在PDS的约束文件里用条件编译或者分文件管理的方式把板级约束和逻辑约束分开。4. ADF加密机制拆解授权文件与网表绑定的底层逻辑4.1 加密不是改文件后缀PDS加密流程的实质很多人以为ADF加密就是给文件加个密码然后PDS打开的时候弹个输入框。实际流程比这个复杂。紫光同创PDS的ADF加密本质上是把网表内容用对称密钥加密然后把密钥用非对称算法封装到授权文件里。授权文件和特定的机器指纹比如网卡MAC地址、硬盘序列号或者License绑定信息关联只有在这台机器上、用这个License才能解密出对称密钥进而解密网表。这个流程意味着两件事第一加密后的ADF不能随便拷贝到另一台机器上用除非重新生成授权文件第二授权文件本身也需要妥善保管丢了就得重新生成加密ADF。所以我在实际项目里通常会把原始未加密的ADF和加密后的ADF分开归档授权文件单独备份避免出现加密文件还在但授权丢了的尴尬。4.2 授权文件的生成与绑定机器指纹和License的配合生成授权文件的操作在PDS的菜单里通常叫Generate License或者Create Authorization File。你需要提供目标机器的指纹信息PDS会根据这个指纹和你的加密密钥生成一个授权文件。指纹信息的获取方式在PDS的License管理界面里一般有导出机器信息的选项导出的文件里包含了机器码把它发给生成方生成方用这个机器码生成授权文件。这里有个实操细节如果集成方是多台机器比如一个团队有5台工作站都要用这个ADF那就需要生成5个授权文件每个绑定一台机器。有些License方案支持浮动授权但紫光同创的ADF加密默认是节点锁定的也就是一机一授权。这个在项目规划的时候要提前考虑否则集成方拿到ADF却只有一台机器能用会影响开发效率。4.3 加密强度与性能的取舍实测数据与经验值加密强度方面PDS提供的选项通常有AES-128和AES-256两种。AES-256更安全但加解密过程会稍微慢一点。我实测下来对于一个中等规模的FPGA设计大概占用30%左右的逻辑资源AES-128和AES-256在综合和布局布线阶段的耗时差异在5%以内基本可以忽略。所以如果没有特殊的合规要求直接用AES-256就行没必要为了那点性能牺牲安全性。但有一个性能相关的点需要注意加密ADF在每次PDS加载工程的时候都需要解密如果工程很大、ADF很多加载时间会明显增加。我做过一个项目顶层集成了8个加密ADF每次打开工程要等将近一分钟。后来把不常用的模块改成普通ADF只在最终交付版本里用加密ADF开发效率就上来了。所以我的建议是开发阶段用普通ADF交付阶段再换成加密ADF。5. 加密ADF在顶层工程中的集成实操5.1 把加密ADF加入工程黑盒实例化的正确姿势在PDS里集成加密ADF操作上和在工程里添加一个普通网表文件类似但有几个额外步骤。首先把加密ADF文件和对应的授权文件放到工程目录下然后在PDS的工程管理器里选择Add Netlist或者Add ADF选中加密ADF。PDS会提示你指定授权文件的位置指定正确后工具会验证授权并加载网表。加载成功后你会在工程的网表列表里看到这个ADF模块但它显示的是一个黑盒图标双击也看不到内部结构。这时候你需要像实例化一个普通模块一样在顶层RTL里实例化这个黑盒端口名字和位宽必须和ADF里的定义完全一致。端口信息从哪里来生成方需要提供一份端口定义文件通常是一个简单的Verilog黑盒声明或者一个CSV格式的端口列表。没有这个集成方就只能靠猜那基本不可能猜对。5.2 端口匹配与约束补充集成阶段最容易出错的环节端口匹配是集成阶段报错最多的地方。常见的问题有这么几类端口名字大小写不一致、位宽不匹配、方向搞反、差分对没有正确配对。PDS在布局布线的时候会检查这些但报错信息往往不够直观有时候只说端口连接错误不告诉你具体是哪个端口。我的经验是在集成之前先让生成方提供一个完整的端口定义表格包含端口名、方向、位宽、是否差分、对应的时钟域。然后集成方在顶层RTL里严格按照这个表格来实例化。如果ADF里有差分对比如LVDS接收还需要在顶层约束里补充差分对的引脚分配和IO标准。这些约束不能放在ADF里因为ADF生成的时候不知道集成方的板级连接。5.3 时序收敛加密ADF带来的额外约束挑战加密ADF在时序收敛上有一个特殊之处因为你看不到内部逻辑所以无法在ADF内部做时序优化。所有的时序约束和优化都只能在顶层做。这意味着如果ADF内部的逻辑路径本身就很紧张集成方只能通过调整顶层时钟或者加流水线来缓解不能直接改ADF。我遇到过一个案例一个加密ADF里的乘法器路径在生成方的器件上能跑到150MHz但集成方的器件速度等级低一档同样的路径只能跑到120MHz。因为ADF不能改最后只能降低整个系统的时钟频率。所以我在生成ADF之前会特意留出一定的时序余量比如目标频率是100MHz我就按120MHz去综合这样集成方即使器件稍慢也能跑通。6. 踩坑实录加密ADF集成中那些让人抓狂的问题6.1 授权文件不匹配从报错信息到根因定位授权文件不匹配是最常见的报错但PDS的报错信息有时候很模糊只说License validation failed不告诉你具体是哪里不匹配。我的排查链路是这样的先确认授权文件是不是对应这台机器用PDS的License管理工具查看机器指纹和生成授权时用的指纹对比然后确认PDS版本是不是一致不同版本的PDS可能用不同的授权格式最后确认ADF文件有没有被修改过哪怕改了一个字节授权也会失效。有一次我排查了半天最后发现是集成方把授权文件放在了中文路径下PDS读取的时候编码出了问题。所以路径里不要有中文和空格这是基本纪律。6.2 版本差异导致的网表不兼容PDS版本对齐的重要性紫光同创的PDS版本更新比较快不同版本之间的网表格式可能有细微差异。我遇到过用PDS 2022.1生成的ADF在PDS 2023.2里加载时报unsupported netlist version。解决办法要么是生成方升级到相同版本重新生成ADF要么是集成方降级到相同版本。没有第三种办法。所以项目开始的时候双方一定要约定好PDS的具体版本号精确到小版本。不要觉得都是2023版应该差不多差一个小版本就可能不兼容。6.3 资源冲突与布局失败加密ADF占用的隐性资源加密ADF在布局布线的时候除了逻辑资源还会占用一些隐性资源比如配置存储区、密钥存储区等。这些资源在普通ADF里是不存在的。如果集成方的工程本身资源就很紧张加上加密ADF的额外开销就可能布局失败。我建议在集成之前先让生成方提供一个资源占用报告包括LUT、FF、BRAM、DSP的用量以及加密带来的额外开销。集成方根据这个报告评估自己的器件能不能装得下。如果余量不足10%就要考虑换更大容量的器件或者优化顶层逻辑。7. 从开发到交付ADF加密在团队协作中的落地建议7.1 开发阶段用普通ADF交付阶段再加密这是我最想强调的一条经验。开发阶段集成方需要频繁调试如果每次都要处理授权文件效率会大打折扣。所以我的做法是开发阶段双方都用普通ADF接口和端口定义先冻结等到功能验证通过、准备交付的时候生成方再把普通ADF替换成加密ADF同时提供授权文件。这样既保证了开发效率又保证了最终交付的安全性。7.2 授权文件的分发与回收别让密钥变成定时炸弹授权文件的分发要有记录谁拿了、绑定了哪台机器、什么时候到期都要有台账。项目结束或者人员离职的时候要及时回收授权文件必要时重新生成加密ADF和新的授权。我见过一个项目核心IP的授权文件被离职员工带走后来在竞品里发现了类似的设计虽然不能直接证明是授权文件泄露导致的但这种风险是实实在在的。7.3 文档化端口定义、约束说明和版本记录一个都不能少最后一条也是容易被忽视的一条文档化。加密ADF交付的时候必须附带三份文档端口定义文档包含所有端口的名称、方向、位宽、时钟域、约束说明文档哪些约束在ADF内部、哪些需要顶层补充、版本记录文档PDS版本、ADF生成日期、授权文件有效期。没有这三份文档集成方就是在盲人摸象出了问题也很难定位。我在实际项目里会把这三份文档和ADF、授权文件一起打包放在一个版本化的目录里每次更新都保留历史版本。这样即使过了半年再回头看也能快速搞清楚当时的交付状态。这个习惯看起来麻烦但省下的排查时间远远超过写文档的时间。 FPGA网表加密实战：紫光同创PDS中ADF文件保护与集成指南
1. 从代码裸奔说起为什么ADF网表加密是FPGA交付的必修课做FPGA项目交付的同行大概都经历过这种尴尬客户拿着你的板子想改个参数你只能把整个工程打包发过去结果对方顺手就把你的RTL源码学习了一遍。更麻烦的是有些项目是多方协作的你只负责其中一个模块但整个工程的网表文件在各方之间流转谁都能打开看看里面到底写了什么。这种代码裸奔的状态在商业项目里其实是个不小的隐患。紫光同创的PDSPango Design Suite环境里ADF文件就是那个承载综合后网表信息的关键载体。所谓ADF全称是Anlogic Design File的同类概念在紫光同创体系下的对应格式它记录的是综合之后的逻辑网表、约束信息以及部分布局布线前的中间数据。和直接交付RTL源码相比ADF网表文件已经失去了可读的HDL语义但它仍然保留了完整的结构信息懂行的人拿到之后依然可以分析出模块划分、关键路径甚至部分算法逻辑。所以对ADF做加密本质上是在可交付和可保护之间找一个平衡点。这篇文章面向的是已经上手紫光同创PDS、做过至少一个完整工程、并且开始接触模块化交付或多方协作的FPGA开发者。如果你还在跑点灯和数码管动态显示那ADF加密暂时用不上但如果你已经开始给别人交付网表、或者需要把某个IP核以网表形式集成到别人的工程里那这套流程就是绕不过去的。我会把PDS环境下ADF网表的生成、加密、集成整个链路拆开讲包括那些官方文档里一笔带过、但实际会卡住你半天的细节。先明确一个概念边界ADF加密不是把文件变成完全不可用的密文而是让文件只能在特定的授权环境下被PDS识别和调用。换句话说加密后的ADF依然要能被工具链正常读取只是读取的过程需要经过授权验证。这个授权的载体在紫光同创的体系里通常是一个和特定机器或特定License绑定的密钥文件。理解这一点后面很多操作逻辑就顺了。2. ADF网表文件在PDS工程中的真实角色2.1 综合之后、布局布线之前ADF到底存了什么很多人第一次接触ADF会把它和比特流文件搞混。比特流是最终烧到FPGA里的配置数据而ADF是综合阶段输出的网表描述。在PDS的流程里你写完RTL代码跑完综合Synthesis工具会把你的行为级描述映射成门级网表这个网表加上约束信息就打包成了ADF文件。它里面包含的东西大致有这么几类实例化的查找表LUT、触发器FF、块RAMBRAM、DSP单元等原语的连接关系时钟约束、IO约束、时序例外等约束信息以及一些和器件型号相关的属性标记。和RTL源码相比ADF已经没有了always块、if-else、状态机这些高层语义你打开它看到的是一堆原语和网线的连接列表。但别以为这样就安全了有经验的人通过分析LUT的连接模式依然可以反推出部分逻辑功能尤其是那些结构规整的算法模块比如滤波器、编解码器。所以ADF加密的核心目标是防止未授权方直接读取这些连接关系而不是指望它变成完全不可分析的黑盒。2.2 什么场景下必须用ADF交付而不是RTL我总结下来主要有三种场景。第一种是IP核交付你开发了一个成熟的模块比如一个高效的CORDIC或者一个定制的通信协议栈不想把源码给客户但又需要客户能在自己的工程里调用。第二种是多方协作中的模块隔离一个大项目拆成几个团队做每个团队只负责自己的部分互相之间不希望看到对方的实现细节。第三种是产线烧录环节工厂需要拿到网表去生成比特流但你不希望工厂掌握核心逻辑。这三种场景的共同点是对方需要用你的设计但不需要看你的设计。ADF加密就是为这个需求量身定做的。反过来如果是你自己团队内部开发或者项目完全开源那加密就是多此一举反而增加维护成本。2.3 加密ADF和普通ADF在工具链里的行为差异普通ADF在PDS里可以直接双击打开能看到内部的网表结构也能直接参与布局布线。加密后的ADF在PDS里依然可以被添加到工程中但工具会先检查授权文件验证通过后才加载网表内容。如果授权不匹配PDS会报错并拒绝加载。这里有个细节加密ADF在综合流程中的位置和普通ADF完全一样都是作为综合后的输入参与后续的布局布线所以对下游流程来说加密与否是透明的。但有一个行为差异需要特别注意加密ADF通常不允许被再次综合或修改。也就是说你拿到一个加密ADF只能把它当作一个黑盒模块来用不能在里面加逻辑或者改约束。这个限制是加密机制本身带来的不是工具bug。理解这一点在集成的时候就不会走弯路。3. 在PDS里生成可加密ADF的完整操作链路3.1 工程配置阶段哪些选项决定了ADF的可加密性在PDS里新建工程的时候有一个选项经常被忽略就是综合策略里的网表输出格式。默认情况下PDS综合后生成的是内部中间格式你需要手动在综合设置里勾选生成ADF网表或者类似的选项工具才会在综合完成后输出ADF文件。这个选项的位置在综合设置的Output标签页下不同版本的PDS可能略有差异但大方向一致。另外工程的目标器件型号必须和后续集成方的器件型号一致否则ADF里的原语映射会对不上。这一点在跨版本、跨器件系列的时候特别容易出问题。我遇到过客户用同创的Logos系列生成ADF结果集成方用的是Logos2系列虽然引脚兼容但内部原语结构有差异导致布局布线时报了一堆莫名其妙的错误。所以生成ADF之前一定要和集成方确认器件型号和PDS版本。3.2 综合参数设置避免加密后无法集成的几个关键项综合参数里有几个设置会直接影响ADF的可用性。第一个是层次化保留选项如果你希望集成方能看到模块的层次结构只是看不到内部逻辑就需要在综合时保留层次边界。第二个是IO缓冲插入策略如果ADF是要集成到更大的工程里通常不需要在ADF内部插入IO缓冲这个应该交给顶层工程处理。第三个是时钟资源分配加密ADF里的时钟约束会被保留但如果集成方的时钟网络和生成方不一致就需要在顶层重新约束。我个人的习惯是在生成ADF之前先建一个干净的综合配置关闭所有调试相关的选项比如在线逻辑分析仪ILA的插入、调试寄存器的保留等。这些调试逻辑如果被固化到ADF里集成方既用不上又占资源还可能因为调试信号的名字冲突导致集成失败。3.3 生成ADF时的约束处理时钟、IO和时序例外约束是ADF里最容易被忽视但又最关键的部分。生成ADF的时候PDS会把当前工程的所有约束一并打包进去包括时钟定义、IO位置、时序例外等。这里有个坑如果你的约束里包含了具体的引脚位置比如set_property PACKAGE_PIN而集成方的板级引脚分配不同那这个ADF集成进去就会报引脚冲突。正确的做法是在生成ADF之前把和具体板级相关的约束引脚位置、IO标准等剥离出来只保留和逻辑本身相关的约束时钟周期、时序例外、虚假路径等。这样集成方拿到ADF后只需要在顶层补充板级约束即可。具体操作上可以在PDS的约束文件里用条件编译或者分文件管理的方式把板级约束和逻辑约束分开。4. ADF加密机制拆解授权文件与网表绑定的底层逻辑4.1 加密不是改文件后缀PDS加密流程的实质很多人以为ADF加密就是给文件加个密码然后PDS打开的时候弹个输入框。实际流程比这个复杂。紫光同创PDS的ADF加密本质上是把网表内容用对称密钥加密然后把密钥用非对称算法封装到授权文件里。授权文件和特定的机器指纹比如网卡MAC地址、硬盘序列号或者License绑定信息关联只有在这台机器上、用这个License才能解密出对称密钥进而解密网表。这个流程意味着两件事第一加密后的ADF不能随便拷贝到另一台机器上用除非重新生成授权文件第二授权文件本身也需要妥善保管丢了就得重新生成加密ADF。所以我在实际项目里通常会把原始未加密的ADF和加密后的ADF分开归档授权文件单独备份避免出现加密文件还在但授权丢了的尴尬。4.2 授权文件的生成与绑定机器指纹和License的配合生成授权文件的操作在PDS的菜单里通常叫Generate License或者Create Authorization File。你需要提供目标机器的指纹信息PDS会根据这个指纹和你的加密密钥生成一个授权文件。指纹信息的获取方式在PDS的License管理界面里一般有导出机器信息的选项导出的文件里包含了机器码把它发给生成方生成方用这个机器码生成授权文件。这里有个实操细节如果集成方是多台机器比如一个团队有5台工作站都要用这个ADF那就需要生成5个授权文件每个绑定一台机器。有些License方案支持浮动授权但紫光同创的ADF加密默认是节点锁定的也就是一机一授权。这个在项目规划的时候要提前考虑否则集成方拿到ADF却只有一台机器能用会影响开发效率。4.3 加密强度与性能的取舍实测数据与经验值加密强度方面PDS提供的选项通常有AES-128和AES-256两种。AES-256更安全但加解密过程会稍微慢一点。我实测下来对于一个中等规模的FPGA设计大概占用30%左右的逻辑资源AES-128和AES-256在综合和布局布线阶段的耗时差异在5%以内基本可以忽略。所以如果没有特殊的合规要求直接用AES-256就行没必要为了那点性能牺牲安全性。但有一个性能相关的点需要注意加密ADF在每次PDS加载工程的时候都需要解密如果工程很大、ADF很多加载时间会明显增加。我做过一个项目顶层集成了8个加密ADF每次打开工程要等将近一分钟。后来把不常用的模块改成普通ADF只在最终交付版本里用加密ADF开发效率就上来了。所以我的建议是开发阶段用普通ADF交付阶段再换成加密ADF。5. 加密ADF在顶层工程中的集成实操5.1 把加密ADF加入工程黑盒实例化的正确姿势在PDS里集成加密ADF操作上和在工程里添加一个普通网表文件类似但有几个额外步骤。首先把加密ADF文件和对应的授权文件放到工程目录下然后在PDS的工程管理器里选择Add Netlist或者Add ADF选中加密ADF。PDS会提示你指定授权文件的位置指定正确后工具会验证授权并加载网表。加载成功后你会在工程的网表列表里看到这个ADF模块但它显示的是一个黑盒图标双击也看不到内部结构。这时候你需要像实例化一个普通模块一样在顶层RTL里实例化这个黑盒端口名字和位宽必须和ADF里的定义完全一致。端口信息从哪里来生成方需要提供一份端口定义文件通常是一个简单的Verilog黑盒声明或者一个CSV格式的端口列表。没有这个集成方就只能靠猜那基本不可能猜对。5.2 端口匹配与约束补充集成阶段最容易出错的环节端口匹配是集成阶段报错最多的地方。常见的问题有这么几类端口名字大小写不一致、位宽不匹配、方向搞反、差分对没有正确配对。PDS在布局布线的时候会检查这些但报错信息往往不够直观有时候只说端口连接错误不告诉你具体是哪个端口。我的经验是在集成之前先让生成方提供一个完整的端口定义表格包含端口名、方向、位宽、是否差分、对应的时钟域。然后集成方在顶层RTL里严格按照这个表格来实例化。如果ADF里有差分对比如LVDS接收还需要在顶层约束里补充差分对的引脚分配和IO标准。这些约束不能放在ADF里因为ADF生成的时候不知道集成方的板级连接。5.3 时序收敛加密ADF带来的额外约束挑战加密ADF在时序收敛上有一个特殊之处因为你看不到内部逻辑所以无法在ADF内部做时序优化。所有的时序约束和优化都只能在顶层做。这意味着如果ADF内部的逻辑路径本身就很紧张集成方只能通过调整顶层时钟或者加流水线来缓解不能直接改ADF。我遇到过一个案例一个加密ADF里的乘法器路径在生成方的器件上能跑到150MHz但集成方的器件速度等级低一档同样的路径只能跑到120MHz。因为ADF不能改最后只能降低整个系统的时钟频率。所以我在生成ADF之前会特意留出一定的时序余量比如目标频率是100MHz我就按120MHz去综合这样集成方即使器件稍慢也能跑通。6. 踩坑实录加密ADF集成中那些让人抓狂的问题6.1 授权文件不匹配从报错信息到根因定位授权文件不匹配是最常见的报错但PDS的报错信息有时候很模糊只说License validation failed不告诉你具体是哪里不匹配。我的排查链路是这样的先确认授权文件是不是对应这台机器用PDS的License管理工具查看机器指纹和生成授权时用的指纹对比然后确认PDS版本是不是一致不同版本的PDS可能用不同的授权格式最后确认ADF文件有没有被修改过哪怕改了一个字节授权也会失效。有一次我排查了半天最后发现是集成方把授权文件放在了中文路径下PDS读取的时候编码出了问题。所以路径里不要有中文和空格这是基本纪律。6.2 版本差异导致的网表不兼容PDS版本对齐的重要性紫光同创的PDS版本更新比较快不同版本之间的网表格式可能有细微差异。我遇到过用PDS 2022.1生成的ADF在PDS 2023.2里加载时报unsupported netlist version。解决办法要么是生成方升级到相同版本重新生成ADF要么是集成方降级到相同版本。没有第三种办法。所以项目开始的时候双方一定要约定好PDS的具体版本号精确到小版本。不要觉得都是2023版应该差不多差一个小版本就可能不兼容。6.3 资源冲突与布局失败加密ADF占用的隐性资源加密ADF在布局布线的时候除了逻辑资源还会占用一些隐性资源比如配置存储区、密钥存储区等。这些资源在普通ADF里是不存在的。如果集成方的工程本身资源就很紧张加上加密ADF的额外开销就可能布局失败。我建议在集成之前先让生成方提供一个资源占用报告包括LUT、FF、BRAM、DSP的用量以及加密带来的额外开销。集成方根据这个报告评估自己的器件能不能装得下。如果余量不足10%就要考虑换更大容量的器件或者优化顶层逻辑。7. 从开发到交付ADF加密在团队协作中的落地建议7.1 开发阶段用普通ADF交付阶段再加密这是我最想强调的一条经验。开发阶段集成方需要频繁调试如果每次都要处理授权文件效率会大打折扣。所以我的做法是开发阶段双方都用普通ADF接口和端口定义先冻结等到功能验证通过、准备交付的时候生成方再把普通ADF替换成加密ADF同时提供授权文件。这样既保证了开发效率又保证了最终交付的安全性。7.2 授权文件的分发与回收别让密钥变成定时炸弹授权文件的分发要有记录谁拿了、绑定了哪台机器、什么时候到期都要有台账。项目结束或者人员离职的时候要及时回收授权文件必要时重新生成加密ADF和新的授权。我见过一个项目核心IP的授权文件被离职员工带走后来在竞品里发现了类似的设计虽然不能直接证明是授权文件泄露导致的但这种风险是实实在在的。7.3 文档化端口定义、约束说明和版本记录一个都不能少最后一条也是容易被忽视的一条文档化。加密ADF交付的时候必须附带三份文档端口定义文档包含所有端口的名称、方向、位宽、时钟域、约束说明文档哪些约束在ADF内部、哪些需要顶层补充、版本记录文档PDS版本、ADF生成日期、授权文件有效期。没有这三份文档集成方就是在盲人摸象出了问题也很难定位。我在实际项目里会把这三份文档和ADF、授权文件一起打包放在一个版本化的目录里每次更新都保留历史版本。这样即使过了半年再回头看也能快速搞清楚当时的交付状态。这个习惯看起来麻烦但省下的排查时间远远超过写文档的时间。