FPGA原型验证学习笔记——开篇之问:Simulation or Emulation?

一些叽里咕噜的话

新人报道!今天是我跳槽进入新公司的第一天,也是我从传统FPGA开发转变为FPGA原型验证的一天。一切重新开始,一切重新学习。

第一天无非就是装装电脑,配置下服务器,闲来无事,阅读了下S2C公司撰写的数字芯片与验证相关的白皮书《Prototypical II》,觉得很有收获。不知何故,突然涌现一种强烈的分享欲望,想着也正好趁着刚开始学习新东西,不如开个专栏,作为自己日常学习笔记,同时也为了更好的以一个初学者的视角去记录我的学习心得,为更多跟我一样的初学者提供一些帮助。如果我的笔记有帮到您,那是我的荣幸,也让我倍感舒心。

另外,我也把《Prototypical II》链接放在了文章最后,有兴趣的小伙伴可自取,不过该网站需要您注册一些信息才可获取,另外该网站还提供了很多其他的资料供大家学习。

开篇之问:Simulation or Emulation?

在入手一门新技术时,总是要先问what/why,再去学习how。所以在进入FPGA原型验证的技术学习之前,我们需要先问清楚:什么是FPGA原型验证?为什么需要用到FPGA原型验证?而今天的第一篇笔记就是抛开乱七八糟的技术点,从这两个问题出发去初步揭开FPGA原型验证的面纱,看看里面到底是个什么玩意儿。您大可不必让大脑整装待发,全副武装的来面对今天这篇笔记,甚至可以脱去外衣,躲到被窝里,以一种听故事的方式跟着我的文字进行一场放松惬意的旅程,而您的脑子,就让它在边上睡会吧。

在阅读《Prototypical II》过程中,我发现文章中的两个词出现频率特别高,“Simulation”和“Emulation”。查英文翻译会发现它们都包含“模拟”、“仿真”的意思,好像没有任何区别。但是了解了文中记录的一个小故事(可能也并不小,甚至很传奇),我对这两个词有了完全不一样的理解。

Quickturn传奇:开启硬件仿真时代的四幕剧

第一幕:诞生——当灵感遇见契机
1988年5月,美国硅谷一家不起眼的办公室里,三位EDA行业的资深人士——迈克·达穆尔、史蒂夫·桑普尔和汤姆·佩恩——正在讨论一个困扰整个芯片产业的难题。他们都是来自当时领先的EDA公司Daisy Systems和Silvar-Lisco的专家,深谙芯片验证之痛。汤姆·佩恩更是分区算法的专家,这个背景后来成为他们技术的核心。

当时的现实是残酷的:芯片设计越来越复杂,验证工作呈指数级增长,软件仿真(Simulation)消耗了英特尔等公司80%的EDA计算资源,一个复杂的处理器设计,仿真实例需要数周甚至数月,68%的芯片项目延期,只有32%能一次流片成功。

“如果我们不能改变验证的速度,”达穆尔在会议上说,“整个半导体行业的发展都会被拖慢。”

他们产生了一个在当时看来十分“离经叛道”的想法:为什么不直接用硬件来验证硬件

当时市面上已有FPGA,但仅限于小规模设计,且流程原始、手工操作。三位创始人想做的,是将多片FPGA组合成一个“门海”,通过自动化工具将芯片设计映射到这个可编程硬件阵列上,实现硬件级别的仿真。

他们给自己的第一个产品命名为“RPM”——快速原型机

RPM数据手册

第二幕:困局——无名之物的尴尬
产品有了,但一个根本性问题摆在面前:这到底算什么?

在早期的客户演示中,几乎每个客户都会困惑:

“是仿真加速器吗?”——“不,比那个快得多。”

“是FPGA原型吗?”——“不,比那个自动化程度高得多。”

当时的行业格局非常清晰:软件仿真是一类,硬件加速仿真是一类,手工FPGA原型是一类。他们的产品哪一类都不属于,但又都有点像。更尴尬的是,他们发现最需要这种技术的大型芯片公司,根本没有预算类别来购买这种“四不像”。

转折点出现在一次偶然的阅读中。有人推荐了一本营销经典——《定位:争夺心智之战》。书中的几句话如闪电般击中了他们:

“与其在现有市场中争第一,不如创造一个新市场并成为其第一。”

他们豁然开朗:RPM既不是仿真,也不是传统原型,它需要一个全新的名字、全新的品类。

经过反复讨论,他们选择了 “Emulation”——硬件仿真

这个命名堪称天才:它既与仿真有词源联系,又暗示了其硬件属性,同时成功与“原型”区别开来。

第三幕:突破——英特尔改变一切
1989年一个阳光明媚的下午,英特尔的年轻工程师阿扎姆·巴尔卡图拉驾车经过山景城。他正为英特尔下一代处理器——奔腾P5的验证工作焦头烂额。突然,他看到了Quickturn的招牌。“硬件仿真?有点意思。”他停下车,走了进去。

会议室里,达穆尔向他展示了RPM的潜力:“想象一下,在硅片流片前几个月,你就能把处理器的‘数字替身’插到真实的PC主板上,启动操作系统,运行真实软件。”

阿扎姆的眼睛亮了。这正是英特尔最需要的——验证周期太长,已成为产品上市的最大瓶颈。

阿扎姆带着产品资料回到英特尔,说服了管理层。但合作面临巨大障碍:

  • 技术适配:英特尔的RTL代码是专有格式,不可综合,需要手工转换
  • 规模未知:没人知道奔腾设计需要多少台RPM
  • 成本风险:RPM单台价格昂贵

最终,双方达成一项创造性协议:英特尔按项目付费,获得“验证P5所需的所有RPM”,无需预先确定数量。

项目启动后,挑战远超想象。阿扎姆领导的四人团队每天工作18小时:

  1. 将英特尔的专有RTL手工转换为可综合代码
  2. 将设计分割成能放入RPM的模块
  3. 用14台RPM摆成U形,通过数十根扁平电缆连接
  4. 为嵌入式内存制作外部硬件适配模块

连接和调试如此复杂,团队甚至需要手动计算时序延迟。最终,仿真时钟被降到约300kHz——虽远低于目标频率,但已是当时仿真速度的数千倍。

1991年11月,在旧金山的一个行业论坛上,英特尔副总裁阿尔伯特·余通过拨号网络连接到实验室,在仿真的奔腾处理器上远程运行了Lotus 123电子表格。现场数百名工程师和行业高管震惊了。这意味着:

  • 奔腾设计在流片前就已能运行真实软件
  • 至少一个关键硬件bug被提前发现并修复
  • 产品上市时间预计提前数月

传闻当时正考虑转向RISC架构的康柏电脑,在演示后放弃了转换计划,选择等待奔腾。

第四幕:遗产——开创一个时代
Quickturn从奔腾项目中提炼出了他们最具说服力的营销武器:Time-to-Market(TTM)理论模型。

他们向客户展示一张简单的图表:产品收入曲线呈钟形,延迟上市意味着永久损失曲线下的面积。即使只缩短几周上市时间,避免的收入损失也远超仿真系统的购买成本。

TTM理论模型

这个模型完成了关键的视角转换:

  • 从工程师视角到商业决策者视角
  • 从成本支出到收入保护
  • 从技术工具到战略投资

Quickturn的故事不仅是技术创新史,更是关于如何定义问题、创造品类、将技术价值转换为商业语言的经典案例。他们面对的不是技术瓶颈,而是认知障碍;他们销售的不是机器,而是时间本身

初识FPGA原型验证

Quickturn产生的“Emulation”想法演进于软件仿真(software simulation)、硬件加速仿真(hardware accelerated simulation)、手工FPGA原型(manual FPGA prototyping)等验证方法,又脱胎于它们,并逐步发展到今天的FPGA原型验证。从我目前的认知来理解,它们的区别如下:

软件仿真(software simulation)

  • 原理:通过软件的方式模拟芯片的逻辑和时序,依靠CPU编译及运行,所有的信号变化均由CPU计算得到。
  • 类比:咱们需要造一栋高楼,软件仿真就是将重要的物理规律、造高楼所用的所有材料的参数输入进计算机,并且由计算机模拟搭建一个虚拟的完全一样的高楼,并模拟一些外来因素,比如地震、大风等去测试这个虚拟的高楼是否稳固。
  • 优点:1.调试能力强,可以100%查找内部任何问题(毕竟都是代码实现的);2.易于部署,不依赖硬件。
  • 缺点:仿真速度龟爬,运行频率从HZ到KHZ不等,运行一次可能需要数周甚至数月。

硬件加速仿真(hardware accelerated simulatio)

  • 原理:使用专用硬件(通常是包含FPGA的加速卡)来执行仿真中最耗时的部分(即“设计本身”的计算),而测试平台和调试控制仍运行在主机CPU上。
  • 类比:还是造一栋高楼,在设计虚拟高楼时,将计算最密集的“结构应力分析”部分,卸载到一个专用的、并行计算能力极强的硬件模块中。设计师仍在主计算机上操控整体模型、查看结果,但每次模拟地震或大风时,核心力学计算的速度得到了极大提升。
  • 优点:1.相比纯软件仿真,通常能快 10到1000倍。
  • 缺点:1.尽管速度有所提升,但仍受限于主机与加速卡之间的通信带宽,无法达到硬件理论的极限速度;2.专用加速硬件不好搞。

手工FPGA原型(manual FPGA prototyping)

  • 原理:直接使用FPGA开发板、分立元器件,通过手工设计电路板、飞线连接等方式,物理搭建一个目标系统的“样机”,本质是高度定制化的硬件系统。
  • 类比:不用计算机模拟了,而是直接去仓库找来木料、砖块、胶水等现成材料,手工搭建一个高楼的等比例缩小实物模型。可以用风扇吹(模拟风),用手摇(模拟地震)来测试它是否容易倒。
  • 优点:1.运行速度极快,可达到MHZ。
  • 缺点:1.尽管运行速度快,但架不住前期“搭建”的耗时,由于缺乏自动化,全部手工来,“搭建”周期可能耗费数周到数月;2.调试困难,内部结构如黑盒,不易探查;3.专项专用,用完即废,新项目又得重新手工搭建;4.最终测试结果可能与真实情况有差异(毕竟测的不是高楼本身)。

FPGA原型验证(FPGA prototyping/Emulation)

  • 原理:使用商业化、标准化的多FPGA系统平台,通过自动化软件工具将大型设计分割、编译并映射到FPGA阵列上运行。它融合了前几类的优点,致力于提供一个兼具硬件速度与软件可控性的专业验证环境。
  • 类比:这次多了个自动“搭建”的机器人(或系统),你只要把高楼设计图纸丢给它,它就能操控机械臂自动给你从现有的材料中挑选出匹配的材料进行“搭建”高楼模型,同时它还会在内部安装传感器,以测试应力情况。
  • 优点:1.运行速度极快,可达到MHZ,“搭建”速度同样质的飞跃;2.可通过标准接口连接到真实的外围系统,让“建筑模型”置身于真实的“城市环境”中测试;3.调试能力大大提升(虽然比不得软件仿真);4.标准化的FPGA系统平台可一直服务多个项目,只需要给机器人不同的图纸即可快速搭建新的模型。
  • 缺点:1.前期购买的FPGA系统平台价格昂贵(但是分摊到很多个项目上后其实就没什么了);2.虽然自动化,但面对超大设计时,分割、布线、时序收敛仍需专业知识和较长编译时间(这也是后续学习方向)。

总结

FPGA原型验证不是一个单一的技术点,而是系统性的,所需要学习和去理解的东西会很多,路漫漫其修远兮,我会尽可能在学习过程中记录下心得,供大家一起讨论学习。

FPGA原型验证所用的工具也同样很多,如Synopsys便提供了完整一套工具,如RTL综合软件Synplify/Synplify Pro/Synplify Premier、多FPGA分割优化软件Certify、整系统编译实现软件ProtoCompiler、专业调试工具Verdi等。工欲善其事必先利其器,后续我可能会先从工具入手,先熟悉工具的使用。

注:以上内容部分借助deepseek生成,当然大部分都是我自己的理解,毕竟也是刚进入这个领域的新人小白,准确性仅供参考,也希望各位大佬指正错误,一起讨论学习!

《Prototypical II》链接:www.s2ceda.com/ch/support-wpSynopsys

Read more

Windows下载、安装并运行MinIO,访问WebUI界面

Windows下载、安装并运行MinIO,访问WebUI界面

MinIO MinIO 是一款基于 Apache License v2.0 开源协议的对象存储服务,兼容 Amazon S3 云存储服务接口,可用于存储海量非结构化数据(如图片、视频、日志文件等)。本教程针对 Windows 系统搭建本地 MinIO 服务,适合开发测试、小型项目部署场景。 下载MinIO 官网下载 访问MinIO中文官网或MinIO英文官网,根据读者的操作系统选择相应的操作系统版本点击MinIO Server/AIStor Server和MinIO Client/AIStor Client的Download按钮下载对应文件。 说明:两版官网域名不同,Server/Client 的文字标题有差异,但下载文件一致;中文官网下载速度更快,优先推荐。 网盘下载 通过网盘分享的文件:Minio 链接: https://pan.baidu.com/s/

【前端】使用Vue3过程中遇到加载无效设置点击方法提示不存在的情况,原来是少加了一个属性

【前端】使用Vue3过程中遇到加载无效设置点击方法提示不存在的情况,原来是少加了一个属性

🌹欢迎来到《小5讲堂》🌹 🌹这是《前端》系列文章,每篇文章将以博主理解的角度展开讲解。🌹 🌹温馨提示:博主能力有限,理解水平有限,若有不对之处望指正!🌹 目录 * 前言 * 提示报错 * 问题分析 * 1. **Options API vs Composition API 风格差异** * ✅ **Options API 写法(方法直接放在外面)** * ✅ **Composition API 写法(方法必须在 setup 中定义)** * ✅ **`<script setup>` 语法糖(最简洁的 Composition API)** * 2. **为什么你的代码会报错?** * 3. **解决方案** * 方案 1:改用 **Options API**(适合从 Vue

从2025看2026前端发展趋势

🎨 从2025看2026前端发展趋势 一、📌 核心前言(2025铺垫→2026展望) 2025年前端行业已完成“基础成熟化”:Vue3、React18成为主流,TypeScript全面普及,工程化流程趋于完善,AI工具开始渗透开发环节,但也暴露了痛点——开发效率不均衡、跨端体验不一致、AI与业务结合浅显、性能优化门槛高。 ✨ 核心趋势:2026年前端将从「基础成熟」走向「深度融合」,重点围绕「AI原生开发」「跨端统一」「性能极致」「工程化提效」四大方向突破,同时Node.js等底层工具的升级(如2026年Node.js新特性)将进一步推动前端向全栈化、平台化转型。 二、✍️ 五大核心趋势(手绘重点·结合2025现状) 1. AI原生开发:从“辅助工具”到“核心生产力” 🤖(最重磅) (1)2025现状 2025年,前端AI工具多为“辅助层面”

Telegram bot & Mini-App开发实践---Telegram简单介绍与初始化小程序获取window.Telegram.WebApp对象并解析

Telegram bot & Mini-App开发实践---Telegram简单介绍与初始化小程序获取window.Telegram.WebApp对象并解析

➡️【好看的灵魂千篇一律,有趣的鲲志一百六七!】- 欢迎认识我~~作者:鲲志说(公众号、B站同名,视频号:鲲志说996)科技博主:极星会 星辉大使后端研发:java、go、python、TS,前电商、现web3主理人:COC杭州开发者社区主理人 、周周黑客松杭州主理人、AI爱好者: AI电影共创社杭州核心成员、阿里蚂蚁校友会技术AI分会副秘书长博客专家:阿里云专家博主;ZEEKLOG博客专家、后端领域新星创作者、内容合伙人 今天是2024年10月24日,又是一年1024程序员节。和往常一样,平淡的度过了一天,又和往常不一样,收到了人生第一束花花🌹值得纪念。就像两年前毅然决然的从电商行业进入一个零基础零认知的web3世界一样,都有第一次的刻骨铭心,选择了就勇敢的做下去,开花结果是期待,但过程也十分重要。也像2016年下半年第一次注册ZEEKLOG去检索问题的解决方案,经过多番查阅实践,终于解决;更像2017年9月27日我的第一篇ZEEKLOG博客文章潦草问世,当初不追求得到什么,只把ZEEKLOG文章当作是学习笔记,知识总结,一路写写停停,不知不觉间也悄然过去了7个年头,断然想不到博