一个算子搞定所有数学函数?FPGA工程师：想多了

最近，一篇来自 arXiv 的论文火了——提出了一个叫 EML 的“万能算子”：

论文链接：https://arxiv.org/html/2603.21852v2

只用一个运算 + 常数，就能构造所有初等函数

听起来是不是有点像数字电路里的 NAND 门万能性?

👉 如果把这个想法搬到 FPGA 上，真的可行吗?

答案很工程师：理论很优雅，工程很骨感。

一、EML 到底是什么?

论文定义的核心算子是：

eml(x, y) = exp(x) – ln(y)

乍一看没什么特别，但关键在于——

这种方法的强大之处在于组合。由于指数和对数可以组合成乘法、除法、幂运算，最终形成三角函数，因此构建 eml(x, y) 运算符的树可以构造任何基本函数。

👉 通过不断组合 eml，可以构造所有初等函数

例如：

exp(x)：1层

sqrt(x)：4层

sin(x)：7层(甚至需要复数支持)

本质就是一个“函数生成树”。

📌 这就是它被称为“数学版 NAND”的原因。

二、问题来了：FPGA真的适合吗?

从FPGA工程师的角度来看，事情就变得有趣起来了。

虽然 eml(x, y) 在数学上具有通用性，但数学通用性并不意味着硬件效率高。每次 eml(x, y) 运算都需要计算 exp(x) 和 ln(y)。这些运算在硬件上并非易事。常见的 FPGA 实现方法包括：

CORDIC 以双曲线模式运行

带插值的查找表

多项式逼近

所有这些方法：

消耗DSP、BRAM和寄存器

需要多个时钟周期

引入较大延迟

关键在于，EML 树中的每个节点本身都是一个多周期、资源密集型的操作。当它们组合成树状结构时，延迟和资源消耗都会迅速增长。这使得该方法的效率远低于直接实现所需功能。

尤其当开发者可以利用以下优势时，情况更是如此：

厂商IP核

MATLAB 或 Simulink

HLS

这些工具通常在性能和资源利用方面提供高度优化的基本功能实现。

👉 而且注意：

一个 eml 不是一个“门”，而是一个“复杂模块”

三、树结构的灾难：资源和延迟爆炸

如果你把 eml 直接搭成计算树：

eml / \ eml eml / \ / \

…

问题会迅速失控：

延迟：层数 × 每个 eml latency

资源：节点数 × 每个 eml cost

📉 结果：

👉 比直接实现 sin / exp 还要慢、还要占资源

四、但它不是完全没用

在工程领域，我们永远不应该把话说死。虽然EML方法并非大多数FPGA设计所采用的方案，但它确实有其独特的应用场景。

在资源受限的设计中，这种情况就变得很有意思了：

灵活性比吞吐量更重要。

需要多种功能

硬件资源有限

与其在硬件中构建完整的 EML 树，更实用的方法是复用单个 EML 单元并按顺序执行操作。这实际上创建了一个微编码数学处理器，其灵活性是通过指令排序而非并行硬件实现的。

该架构由以下部分组成：

EML 单元，执行 exp(x) – ln(y)

用于中间值的堆栈

程序ROM，其中保存着每个功能的指令序列

控制执行的有限状态机

其思路是实现一个简单的指令集，例如：

push_1 将常量 1 压入栈中。

push_x 表示将输入 x 压入输入框。

push_y 参数用于推送输入 y。

使用堆栈值执行 eml(x, y)

停止执行

每个基本功能都以程序的形式存储在ROM的特定偏移量处。有限状态机(FSM)：

使用程序计数器获取指令

操作堆栈

触发EML单元

循环直至程序完成

 

 

这种架构的优点：

✔ 极高灵活性(函数随意扩展)

✔ 资源占用小

✔ 适合小 FPGA(如 Spartan-7)

缺点：

❗ 速度慢(多周期执行)

❗ 延迟高

❗ 吞吐量低

堆栈本身不需要很大，通常16到32个条目就足够了。它必须能够支持EML操作所需的两个输入。

五、FPGA探索

虽然可以直接在RTL中实现，但HLS非常适合这种架构。HLS允许：

快速探索

更容易实现控制逻辑

直接使用针对指数和自然对数运算优化的数学库

这样既避免了手动实现这些复杂功能，又能实现硬件实现。

在本例中，为了降低资源占用，采用了定点运算实现。程序ROM配置为实现：

exp(x)

ln(x)

使用自检测试平台扫描一系列数值并验证正确性。

结果：

C 仿真结果在可接受的精度范围内。

协同仿真结果与C仿真结果一致

硬件设计紧凑，可装入小型 Spartan-7 设备中。

 

 

然而，这样做的代价是性能：

每次计算都需要多个指令周期。

与专用服务器相比，整体延迟相对较高。

 

 

六、一个工程师该怎么理解这件事?

eml(x, y) 方法是一个引人入胜的概念，也是数学优雅的绝佳例证。

然而，从FPGA的角度来看：

它并非实现基本函数的最有效解决方案。

直接使用会引入显著的延迟和资源开销。

也就是说，当它被重构为微代码架构时，在某些特定场景下会成为一个有用的工具：

需要具备灵活性。

资源有限

吞吐量并不重要

虽然这不是一种常用的方法，但对于合适的应用来说，这绝对是FPGA工程师工具箱中值得保留的方法。

这篇文章其实讲了一个非常重要的工程原则：

👉 数学“可行” ≠ 工程“高效”

EML 就像：

数学上：优雅统一

工程上：性能灾难

但换个思路(微码 + 复用)：

👉 就变成一个“低资源万能计算单元”

八、总结一句话

👉 EML 不是用来替代传统实现的，而是用来扩展设计思路的

本文来源于微信公众号：OpenFPGA