基于代码的PCB设计工具对传统EDA的挑战 “ 一直想写一些关于新的设计范式(不只是 AI)的内容,但迟迟没有动笔(主要我自己也无法说服自己该怎么选)。其实用代码来进行电子设计在海外并不是什么新的概念,JITX 的商业化已运作了几年,YC 更是连续投资代码生成 EDA 图纸的初创公司。LLM 的飞速进步似乎又印证了这一范式的必然性。但事实真是如此吗?硬件工程师长期养成的习惯会在这波技术革新中被彻底颠覆吗? ”
立即报名参加 KiCon Asia 2025,与 KiCad 全球开发者和设计精英面对面,共同探索电子设计的未来!
会议官网:https://kicon.kicad.org/asia2025/zh-cn/ 国内的小伙伴可以在电子发烧友网站报名(可以提供发票):
https://bbs.elecfans.com/jishu_2495997_1_1.html引言在国内可能感觉不是很明显,但在欧美,电子设计自动化(EDA)领域正处在一场深刻的范式变革之中。传统的、以图形用户界面(GUI)为中心的点选式设计方法,正面临着一种源自现代软件工程实践的、以代码为先的全新设计哲学的挑战:“硬件即代码”(Hardware as Code, HaC),大家可能听我聊过 skidl:SkiDL:使用 Python 设计电路原理图,这是一个比较早期践行 HaC 并获得认可的个人项目。但在短短几年内,又迅速出现了大量类似的产品,比如商业化程度比较高的 JITX,采用“设计即服务”(Design-as-a-service)理念的开源王者 atopile、亦或是刚融了 1400万美金的新星 diode. computer。这些新工具与 KiCad、Altium Designer 等传统 EDA 巨头相比,不仅仅是工具的创新,更是一场设计理念的转变,其深度借鉴了成熟的“基础设施即代码”(Infrastructure as Code, IaC)和 DevOps 原则。代码驱动的方法在自动化、可重用性和设计验证方面展现出巨大潜力,但同时也面临着陡峭的学习曲线和传统工程师群体文化适应性的严峻挑战。
尽管在短期内完全取代传统EDA工具的可能性不大,但代码驱动和人工智能(AI)增强工具的融合已是不可逆转的趋势,它将重新定义未来十年电子工程的生产力边界。
硬件设计的“软件化”
现代电子系统设计的复杂性正以指数级速度增长,同时市场对产品迭代速度的要求也日益严苛。从高速接口、BGA 封装到复杂的片上系统(SoC),这些挑战正将传统的、依赖大量人工操作的图形化设计范式推向极限。在这种压力下,一种借鉴了现代软件工程思想的新方法应运而生,其核心是硬件设计的“软件化”。
这场变革的哲学和技术基础,源于软件开发领域一次成功的革命:基础设施即代码(IaC:Infrastructure as Code)。IaC 的核心理念是通过机器可读的定义文件来管理和配置计算基础设施,而非通过物理硬件配置或交互式工具 。这种方法将网络、虚拟机、负载均衡器等基础设施元素,用高级语言进行编码,从而实现了标准化、自动化和版本化管理 。
IaC为软件开发运维(DevOps)带来了革命性的效率提升,这些优势正是当前硬件设计领域所渴求的:
速度与效率:通过自动化取代耗时的手动配置,实现了基础设施的快速部署、拆除和扩展,从而加速了软件开发、测试和发布的整个生命周期 。
一致性与可靠性:通过代码定义基础设施,确保了开发、测试、生产等所有环境的一致性,从根本上消除了因手动操作失误或“配置漂移”导致的问题 。
版本控制与协作:将基础设施定义文件像应用程序代码一样纳入Git等版本控制系统,使得所有变更都有迹可循,支持同行评审(Pull Request)和快速回滚,极大地促进了团队协作。
模块化与可重用性:将基础设施分解为可重用的模块化组件,减少了代码重复,提高了可维护性,并简化了跨项目和环境的管理
“硬件即代码”(Hardware as Code, HaC)正是将 IaC 的原则应用于电子硬件(原理图、PCB)设计的过程。其目标是将设计流程从一种图形化的、命令式的过程(“在这里点击,画一条线”)转变为一种声明式的、基于代码的过程(“我需要一个具备这些参数的电源模块”)。
这一转变并非凭空出现,而是软件工程领域成功经验的必然延伸。当前硬件设计所面临的可扩展性、一致性和自动化等挑战,与十年前软件基础设施所面临的挑战在本质上是相同的。因此,HaC 运动并非从零开始创造一种新哲学,而是进行了一次成功的“领域迁移”:将一个更成熟领域(软件工程)中经过验证的、成熟的解决方案,应用到一个正面临类似复杂性挑战的领域(硬件设计)。这解释了为何 JITX、atopile 等新工具不约而同地使用“可重用模块”、“版本控制”和“自动化验证”等软件工程术语作为其核心卖点 ,因为这套行之有效的方法论早已被 DevOps 的成功所证明。
传统 EDA 工作流及优缺点
以 KiCad 为例,一个KiCad项目是一个包含原理图(.kicad_sch)、PCB(.kicad_pcb)、库文件和项目设置的文件夹,所有设计信息都集中于此。设计遵循以下路径:
优点和缺点传统EDA工具经过数十年的发展,形成了其独特的优势,但也暴露了难以克服的系统性缺陷。优点:现代与传统 EDA 比较
|
特性维度 |
传统EDA (KiCad/Altium) |
JITX |
atopile |
diode.computer |
|
主要范式 |
图形化,所见即所得 |
代码优先,声明式 |
代码优先,声明式 |
AI驱动的服务 |
|
真理源 |
可视化的原理图/PCB文件 |
源代码 |
.ato 源代码 |
高层级的规格说明 |
|
设计抽象 |
低 (层次化图纸) |
高 (参数化模块) |
高 (可配置模块) |
极高 (自然语言/规格) |
|
可重用性 |
手动 (复制/粘贴, 代码片段) |
高 (基于代码, 参数化) |
高 (基于代码, 包管理器) |
不适用 (服务内部) |
|
版本控制 |
差 (类二进制, 非语义差异) |
优秀 (原生Git工作流) |
优秀 (原生Git工作流) |
不适用 (内部管理) |
|
验证 |
离散 (手动运行ERC/DRC) |
持续 (代码内检查, 随变更运行) |
按需 (运行ato build时检查) |
持续 (AI + 人机回环) |
|
自动化 |
有限 (脚本, 基础自动布线器) |
高 (AI自动布线, 优化) |
中 (元件选择) |
端到端 (从规格到电路板) |
|
学习曲线 |
工具高, 范式低 |
范式和语言均高 |
范式和语言均高 |
用户低, 工具不适用 |
|
目标用户 |
电子工程师, PCB设计师 |
专业电子工程师, 企业团队 |
爱好者, 研发人员, 初创公司 |
希望外包设计的公司 |
|
生态系统 |
成熟, 库庞大 |
成长中, 与现有EDA集成 |
新生, 依赖KiCad |
封闭, 专有 |
|
商业模式 |
许可证/订阅(Altium), 免费(KiCad) |
订阅, 企业版 |
开源, 服务 |
设计即服务 |
是否能够可视化无疑是两种范式最大的冲突点,接下来我们再仔细分析下两种范式最核心的差异点:Git 的优势与真正的协作版本控制是新旧范式的另一个差异点。在传统 EDA 中,尝试用 Git 合并两个工程师对同一块 PCB 的不同修改,是一场灾难。由于文件格式的非语义性,Git无法理解设计的逻辑,合并操作极有可能导致文件损坏 。相比之下,JITX 和 atopile 的设计本身就是为版本控制而生 。整个电路板被描述为结构化的代码,每一次修改都是可读的、有意义的文本差异。这使得团队可以像开发软件一样,使用分支(branching)和合并(merging)等工作流,让多名工程师在同一块电路板的不同功能模块上并行开发,这在传统EDA流程中是几乎不可能实现的。构建即正确代码驱动工具正在推动一个从“事后检查”到“构建即正确”的范式转变。在传统流程中,DRC等验证步骤通常在布局设计的最后阶段才运行,错误可能在设计过程中潜伏数天甚至数周。而 JITX 的“永远正确”理念,将验证逻辑直接嵌入到设计代码中。这意味着许多类别的错误从一开始就被工具的结构所阻止,而不是在事后被发现。例如,当一个模块的输出电压范围与另一个模块的输入电压范围不兼容时,连接操作在代码编译阶段就会失败,而不是等到最终的 ERC 检查。抽象与可重用性新范式在设计重用方面实现了质的飞跃。在 Altium 或 KiCad 中,重用一个电源电路通常意味着复制一整张原理图纸或设计片段 snippet,然后手动修改元件编号和参数,这个过程繁琐且易错。在 JITX 或 atopile 中,重用一个电源模块则变成了在代码中实例化一个类,例如
my_psu = PowerSupply(output_voltage=3.3V, max_current=2A)
这种抽象级别将设计单元从“一组图形”提升为“一个可配置的对象”,极大地提高了效率和可靠性。设计师可以构建一个经过充分验证的内部IP库(以代码形式存在),并在新项目中以极高的置信度快速调用。用户体验的鸿沟: 可视性与功能性尽管代码驱动工具在技术上优势明显,但其最大的推广障碍来自于用户体验和工程师文化。对于许多电子工程师,尤其是那些在模拟和射频领域工作的专家来说,图形化的原理图不仅仅是连接关系的表示,它本身就是一种思考和调试的工具。信号的流动、功能模块的划分、元件的相对位置,这些视觉信息对于理解电路行为非常重要。在他们看来,用代码描述一个模拟滤波器是“难以理解的”,因为这迫使他们在大脑中将代码重新“编译”成他们熟悉的原理图形式。这是代码驱动工具最主要的劣势和采纳门槛,也是传统 EDA 工具最坚固的护城河。然而,对于具有软件背景的工程师来说,代码带来的自动化、版本控制和规模化能力,其吸引力远远超过了学习新范式的成本。
未来展望
超越工具本身,这场变革将对电子工程行业和工程师的职业发展产生深远影响。
何时采用代码驱动设计?
代码驱动设计并非万能灵药,其适用性取决于项目特性和团队文化。
理想用例:
参数化设计:需要生成大量相似但不同配置的系统,如为不同传感器配置生成测试板。
大型分布式团队:基于Git的协作成为刚需,以支持并行开发。
设计自动化:目标是以编程方式生成数百个类似设计,而非手动绘制。
快速原型迭代:当迭代速度比对布局的精细控制更重要时,尤其是在早期产品探索阶段。
不适用场景:
高性能模拟/射频电路:在这些领域,手动的、直观的布局本身就是电路性能的关键组成部分。
一次性的简单设计:对于非常简单的电路,建立代码驱动环境的开销可能超过其带来的收益。
不具备编程能力的团队:文化壁垒是真实的项目风险,强行推广可能适得其反。

结束语
向“硬件即代码”的转变,是电子设计领域一场深刻的、由软件革命力量驱动的演进。这场变革的核心权衡在于:牺牲传统 EDA 的视觉直观性和精细控制,以换取前所未有的自动化、可重用性和可验证的正确性。硬件工程与软件工程之间的界限将继续模糊。未来十年,最成功的组织,将是那些能够掌握融合这两种学科艺术的组织。他们将能够根据任务的性质,灵活地选择最合适的范式:无论是图形化的、代码驱动的,还是由AI生成的,从而在日益激烈的技术竞争中脱颖而出。全部0条评论
快来发表一下你的评论吧 !