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

CarelessWhisper: Turning Whisper into a Causal Streaming Model——将 Whisper 转变为因果流式模型

CarelessWhisper: Turning Whisper into a Causal Streaming Model——将 Whisper 转变为因果流式模型

这篇题为《CarelessWhisper: Turning Whisper into a Causal Streaming Model》的研究论文,提出了一种将非因果的Transformer语音识别模型(如Whisper)改造为低延迟、实时流式语音识别模型的方法。以下是其主要研究内容的概括总结: 一、研究背景与问题 * 现状:Whisper 等先进语音识别模型在离线转录中表现出色,但由于其编码器的非因果性(需依赖未来上下文),无法直接用于低延迟实时流式转录。 * 挑战:现有流式化方法存在计算效率低、延迟高、需额外模块或多轮解码等问题。 二、核心方法 1. 因果编码器改造 * 在 Whisper 的编码器中引入因果掩码(causal masking),使其仅依赖过去和当前语音帧,不依赖未来信息。 * 提出分块注意力机制,支持以固定块大小(如 40、100、300 ms)逐步处理语音流。 2. 轻量级微调策略 * 使用 LoRA(

部署Qwen3-VL-32b的踩坑实录:多卡跑大模型为何vLLM卡死而llama.cpp却能“大力出奇迹”?

部署Qwen3-VL-32b的踩坑实录:多卡跑大模型为何vLLM卡死而llama.cpp却能“大力出奇迹”?

踩坑实录:多卡跑大模型Qwen-VL,为何vLLM模型加载卡死而llama.cpp奇迹跑通还更快? 前言:部署经历 针对 Qwen2.5-32B-VL-Instruct 满血版模型的部署实战。 手头的环境是一台配备了 4张 NVIDIA A30(24GB显存) 的服务器。按理说,96GB的总显存足以吞下 FP16 精度的 32B 模型(约65GB权重)。然而,在使用业界标杆 vLLM 进行部署时,系统却陷入了诡异的“死锁”——显存占满,但推理毫无反应,最终超时报错。 尝试切换到 Ollama(底层基于 llama.cpp),奇迹发生了:不仅部署成功,而且运行流畅。这引发了我深深的思考:同样的硬件,同样模型,为何两个主流框架的表现天差地别? 本文将围绕PCIe通信瓶颈、Tensor Parallelism(张量并行) 与 Pipeline

Continue插件实现本地部署一个“cursor”或“github copilot”

Continue插件实现本地部署一个“cursor”或“github copilot”

本地部署 AI 代码助手,制作一个 Cursor/GitHub Copilot 的替代版本 一 需求分析 * 本地部署的定义与优势(数据隐私、离线使用、定制化)。 * Cursor 与 GitHub Copilot 的功能(代码补全、对话交互、模型差异)。 * 本地部署的AI 代码助手适用场景:企业内网开发、敏感数据环境。 二 环境准备与工具选择 * 硬件要求:GPU 要对应上你所部署的模型大小 * 模型选择:qwen2.5-14b-instruct (这里选择千问的大模型) 三 部署开源模型 这里不详细介绍具体的大模型部署的具体过程,部署完成之后,你应该得到对应的模型的以下信息 model: "qwen2.5-14b-instruct" apiBase: "http://你的ip地址(自己的本机就写localhost)

蓝耘 × 通义万相 2.1,AIGC 双雄合璧,点燃数字艺术新引擎

蓝耘 × 通义万相 2.1,AIGC 双雄合璧,点燃数字艺术新引擎

目录 一、本篇背景: 二、蓝耘与通义万相 2.1 概述: 2.1蓝耘简介: 2.2通义万相 2.1 简介: 注册并使用蓝耘元生代智算平台: 完成通义万相 2.1部署并调用:  个人代码调用过程及感受: 环境准备: 代码实现: 保存生成的图像: 三、蓝耘与通义万相 2.1 结合的优势: 3.1强大的计算力支撑: 3.2高效的数据处理与传输: 3.3定制化与优化: 四、蓝耘调用通义万相 2.1 API 的实际代码演示: 4.1环境搭建: 4.2图像生成代码示例: 4.3文本生成代码示例: 五、蓝耘与通义万相 2.1