Formality:原语(primitive)的概念

Formality:原语(primitive)的概念

相关阅读

Formalityhttps://blog.ZEEKLOG.net/weixin_45791458/category_12841971.html?spm=1001.2014.3001.5482


        原语(primitive)一般指的是语言内置的基本构件,它们代表了基本的逻辑门和构件,通常用于建模电路的基本功能,例如Verilog中的门级建模会使用and、or等关键词表示单元门。Formality也存在原语的概念,这一般出现在对门级网表进行建模时,本文将对此进行详细解释。

        假设以例1所示的RTL代码作为参考设计(可以看出添加了// synopsys sync_set_reset综合指令让Design Compiler将其实现为带同步复位端的D触发器),例2所示的综合后网表作为实现设计,其中data_out_reg原语是一个带同步复位端的D触发器(FDS2)。

// 例1 module ref( input clk, input reset, input data_in, output reg data_out ); // synopsys sync_set_reset "reset" always @(posedge clk) begin if (reset) begin data_out <= 1'b0; end else begin data_out <= data_in; end end endmodule
// 例2 ///////////////////////////////////////////////////////////// // Created by: Synopsys DC Expert(TM) in wire load mode // Version : O-2018.06-SP1 // Date : Fri Jun 27 15:52:09 2025 ///////////////////////////////////////////////////////////// module ref ( clk, reset, data_in, data_out ); input clk, reset, data_in; output data_out; wire n1; FDS2 data_out_reg ( .CR(data_in), .D(n1), .CP(clk), .Q(data_out) ); IV U4 ( .A(reset), .Z(n1) ); endmodule 

        在Formality中完成了参考设计、实现设计和库文件的读取后,参考设计的结构如图1所示(注意勾选Primitive),原理图如图2所示。

图1 参考设计的结构

图2 参考设计的原理图

        可以看出,就像Design Compiler读取RTL代码后会将其转化为GTECH网表那样(其实GTECH也可以被认为是一种primitive),Formality读取RTL代码后直接将其用内部原语实现了,其中date_out_reg原语是一个有同步使能SL,同步数据输入SD和时钟CLK的D触发器。

        实现设计的结构如图3所示(注意勾选Primitive和Tech Cells),原理图如图4所示。

图3 实现设计的结构

 

图4 实现设计的原理图

        从图3所示的结构,我们可以看到来自标准单元库的date_out_reg单元(注意,这与参考设计中的date_out_reg原语不是一个概念)和U4单元,但是可以看出它们是可以再分的,U4单元由cell0原语组成,date_out_reg单元则由包括*dff.00**在内的四个原语组成。

        date_out_reg单元的内部结构如图5所示。

图5 date_out_reg单元的内部结构

        *dff.00**原语就像参考设计中的date_out_reg原语那样是一个有同步使能SL,同步数据输入SD和时钟CLK的D触发器,但此时搭配cell2原语实现了一个带同步复位端的D触发器。

        总结一下就是,为了让等价性检查更标准化,Formality将直接用内部原语实现RTL代码,而用功能等效的方式用内部原语实现门级网表中的各个标准单元,并最终对内部原语进行比较。在工艺库列表中,可以查看各个标准单元是如何映射到内部原语的,如图6所示。

图6 查看标准单元库中每个标准单元原语映射方式

        这也解释了为什么在进行比较点验证时,会将参考设计中的date_out_reg原语和实现设计中的date_out_reg/*dff.00**原语进行比较了,此时它们才应该是比较是否等价的对象,如图7所示。

图7 比较点的验证

Read more

FPGA教程系列-Vivado AXI4-Stream Data FIFO核解读测试

FPGA教程系列-Vivado AXI4-Stream Data FIFO核解读测试

FPGA教程系列-Vivado AXI4-Stream Data FIFO核解读测试 FIFO depth (FIFO 深度): 定义了 FIFO 能存储多少个数据字(Data Words)。 注意:实际占用的存储资源取决于深度乘以数据宽度(TDATA width)。 Memory type (存储器类型): Auto * 决定用 FPGA 内部的哪种资源来实现 FIFO。 * Auto: 让 Vivado 综合工具根据 FIFO 的大小自动选择(通常小 FIFO 用分布式 RAM/LUTRAM,大 FIFO 用块 RAM/BRAM)。 * Block RAM: 强制使用 BRAM。 * Distributed RAM: 强制使用 LUT 搭建的

FPGA Flash烧写步骤深度剖析(基于Vivado)

FPGA Flash烧写实战全解:从比特流到可靠启动(基于Vivado) 你有没有遇到过这样的场景? FPGA设计在JTAG模式下运行完美,一切时序收敛、功能正常。可一旦断电重启,板子却“死”了——LED不闪、串口无输出、逻辑没加载。排查半天,最后发现是 Flash烧写配置出了问题 。 这并非个例。在嵌入式FPGA开发中, “能跑仿真”不等于“能上电自启” 。真正决定产品能否落地的关键一步,正是将.bit文件固化进QSPI Flash的全过程。而这一过程的核心,就是我们常说的 “vivado固化程序烧写步骤” 。 本文将以工程实践为视角,带你穿透Vivado界面背后的机制,深入剖析从生成比特流到成功启动的完整链路。不只是告诉你“怎么点”,更要讲清楚“为什么这么配”。 比特流不是终点,而是起点 很多人误以为综合实现后生成 .bit 文件就大功告成。但实际上,这个文件只是FPGA配置的“临时快照”,只能通过JTAG下载到易失性配置RAM中。断电即失,无法用于量产部署。 要想让FPGA“记住”

Nanbeige4.1-3B多轮对话效果展示:Chainlit中持续追问、记忆保持、角色扮演实录

Nanbeige4.1-3B多轮对话效果展示:Chainlit中持续追问、记忆保持、角色扮演实录 1. 引言:当小模型遇上大智慧 最近在测试各种开源模型时,我遇到了一个让人眼前一亮的“小家伙”——Nanbeige4.1-3B。说实话,刚开始看到“3B”这个参数规模时,我并没有抱太高期望。毕竟现在动辄几十B、上百B的模型太多了,3B能有什么表现? 但实际测试下来,这个模型给了我不少惊喜。特别是在多轮对话场景下,它的表现完全超出了我对这个参数规模模型的预期。 今天这篇文章,我就想带大家看看,这个“小身材”的模型,在Chainlit前端配合下,到底能展现出什么样的“大智慧”。我会通过几个真实的对话场景,展示它在持续追问、记忆保持、角色扮演等方面的实际效果。 2. 模型与部署环境简介 2.1 Nanbeige4.1-3B:小参数,大能力 Nanbeige4.1-3B是基于Nanbeige4-3B-Base构建的增强版本。简单来说,它是在基础模型上,通过进一步的监督微调和强化学习优化而来的。

腾讯云端Openclaw+飞书 多机器人配置全攻略(新手友好版)

前言:随着AI自动化工具的普及,Openclaw凭借强大的自主执行能力,成为很多人提升效率的首选;而飞书作为高效协同工具,其机器人功能可无缝融入日常工作流。当两者结合,配置多机器人实现分工协作(如办公提效、信息管理、场景化响应),能进一步释放AI价值。 本文将从前期准备、分步配置、实战调试到常见问题,手把手教你完成Openclaw+飞书多机器人配置,全程无复杂操作,新手也能快速上手,建议收藏备用! 一、配置前必看:核心说明与前置准备 1.1 核心价值 Openclaw+飞书多机器人配置,核心是让多个飞书机器人分别绑定Openclaw的不同Agent,实现「分工协作、各司其职」——无需切换工具,在飞书内即可完成所有操作,大幅提升工作效率。 ✅ 典型分工场景: * 1个机器人负责日常指令响应 * 1个机器人负责定时推送资讯 * 1个机器人负责办公流程自动化(会议整理、报表生成等) 1.2 前置环境准备(必做) 提前准备好以下环境和工具,避免配置过程中卡顿,所有工具均为免费可用: * 基础环境:云端安装Openclaw;