鉴于这个问题,我想知道是否有一个相当标准的过程可以将软件解决方案转变为硬件实现。原谅我和我的想象力,但是是否有一个编译器可以接受一个 C 程序并根据晶体管、电阻器等的原理图进行编译,甚至可能是众所周知的 PCB?
我意识到我可能从错误的角度看待这种情况。根据我自己的经验,从历史上看,通常你有一些硬件,有人已经将其作为软件解决方案实现(想想硬件仿真)。反过来这个概念还存在吗?这些大公司是如何做到的,例如软件与硬件 IP 路由?
鉴于这个问题,我想知道是否有一个相当标准的过程可以将软件解决方案转变为硬件实现。原谅我和我的想象力,但是是否有一个编译器可以接受一个 C 程序并根据晶体管、电阻器等的原理图进行编译,甚至可能是众所周知的 PCB?
我意识到我可能从错误的角度看待这种情况。根据我自己的经验,从历史上看,通常你有一些硬件,有人已经将其作为软件解决方案实现(想想硬件仿真)。反过来这个概念还存在吗?这些大公司是如何做到的,例如软件与硬件 IP 路由?
不,没有将软件转化为硬件的标准解决方案。一般来说,如果没有考虑到硬件实现,就不能轻易地将软件转换为硬件,而不会造成巨大的浪费和低效。通常,最好的办法就是制造一个具有 CPU 和 ROM 的芯片——并将软件放入 ROM 中。
多年来,已经有编译器可以采用“C-Like”代码并将其编译到硬件中——这与 VHDL 或 Verilog 可以编译到硬件中的方式非常相似。但关键是它是“C-Like”,而不是 C。例如,您仍然不能将计算 PI 的 C/C++ 程序神奇地转换为计算 PI 的硬件。这些 C-Line 语言中的大多数已经消失,或者没有大量使用。更流行的版本之一是SystemC,但重要的是要注意它不是 C/C++ 并且对于通用的“让我们编写软件然后将其编译成硬件”没有用处。您仍然需要“编写一些硬件,也可以将其编译成软件”。
交换机和路由器通常具有执行大多数常用的硬件并在硬件中加速关键路由器功能(在路由表中查找内容、管理队列等),然后使用 CPU 执行所有不常见的功能(处理异常、错误、路由表更新等)。在许多方面,这类似于现代 CPU 的工作方式,其中最常见的操作码是在硬件中完成的,有时某些操作码实际上是在软件中实现的(例如,当 FPU 不存在时的浮点指令)。
最接近的是 Altera 的C-to-Hardware (C2H) Compiler。它可以做一些你建议的事情。但有明显的警告。您不能将任何 C 代码转换为硬件,您也不想这样做。但是特定的功能工作得相当好,你可以看到性能的显着提高。
通常,您会将 NIOS II 软核处理器实现到 Altera FPGA 中。然后,您将像编写任何其他处理器一样为其编写一些 ANSI C 代码。然后说您编写的其中一个 C 函数涉及一些繁重的数学运算,这些数学运算将从某些并行执行中受益。您调用 C2H 编译器,例如“在硬件中实现”,它实质上将该功能转变为 NIOS II 软核处理器的外围设备。
下面是一个用 ANSI C 编码 Mandelbrot 计算然后在硬件中实现它的例子:
与使用编译器优化级别 2 (-O2) 在最快的 Nios II 处理器上运行的相同算法相比,C2H 编译器加速的 Mandelbrot 算法的速度至少提高了 60 倍。这种速度提高是因为硬件可以提供的并行性和快速迭代速度,这是通用处理单元无法实现的。
回到您的示例,NIOS II 处理器可以运行 Linux。执行路由任务所需的某些功能可以从硬件加速中受益。它很可能比纯软件路由器性能更好。但它永远无法达到专门设计的专用 ASIC 的性能。
您在标题中提到了“C to Silicon”,并在正文中提到了板级产品。我将只关注该方程式中确实存在的部分->“C 到硅”设计流程。C 语言本身并不适合描述硬件,因为它缺乏对硬件内在并行性、防止竞争条件和其他问题的基本支持,并且在表示这些概念方面没有特别的表现力。或者不如 Verilog 和 VHDL 那么多。
可合成的 C 代码(即可以呈现为硬件描述)并且这里的硬件 = 数字逻辑,不会赢得任何由软件开发人员判断的编码竞赛。
以下是一些著名供应商的列表,他们为 ASIC 流程人群提供 C -> 硅工具。
Forte 合成器
导师弹射器
蓝色规格 C
Synopsys Synphony(前 Synfora)
Cadence C-to-Silicon
如果您期望合理的硬件,那么将软件转变为硬件并不是一项完全微不足道的任务。硬件往往需要更多的架构来仔细管理与面积/成本相关的资源使用。话虽如此,有许多工具以某种形式采用 C,允许您添加硬件特定信息(例如,硬件接口是什么?),并生成优化的硬件。与手工编码的 RTL 相比,熟练的用户可以在更短的时间内轻松获得更好的结果。