推荐！将软件编译并形成有效硬件的方法 [转帖] 硬件, 软件, 转帖, 编译, 形成

huishuming

IC设计复杂度和生产成本的不断上涨使继续提高设计工程师的设计产出率成为保持竞争优势的法宝，本文阐述的从“C语言”到“门”的编译方法和思路，能够使设计工作更简单、更高效，满足提高设计产出率的需求。

VHDL和Verilog是否已经过了它们的黄金时代，即将被诸如System C、Handel-C以及其它类似C的设计语言所替代？这样的变化也许即将来临，然而这背后存在的危机是什么将是一个很难回答的问题。不是因为没有危机，而是因为影响半导体工业的因素太多。这些危机包括制造先进芯片所需日益增长的成本、完成具有上亿个晶体管的设计所需的时间、吸引并留住能设计复杂芯片的骨干设计工程师、在流片之前就消除设计错误，以及在市场的时间窗口内及时推出产品等等。

因此，我们正面临着很多问题，归根结底，真正需要解决的就是：1. 如何在设计复杂度以指数速度增长的情况下进行高效而正确的设计？2. 如何在生产成本以指数速度增长的情况下用硅芯片实现这些设计？

幸运的是，这两个问题已都有解决方法，这些解决方法能扭转目前困境，并将问题的控制权交还给设计工程师和技术创新者以生产出新一代高附加值产品。问题的答案也许就是使用类似于普通C语言的设计语言。

实现中存在的危机

尽管设计深亚微米器件仍存在不少问题，但如果期望很快就打破过去四十年以来的半导体技术发展趋势是不明智的。实现先进芯片的成本已非常高，并且还在不断攀升。从ASIC设计项目的启动数量越来越少可看到了由此带来的必然后果，因为成本升高，未来可用于构建新系统的“标准”芯片将逐渐越少。过去那种集中很多优秀的工程师将一个创新概念发展到世界领先的技术公司的路线对新来者来说已经不太现实了。

半导体前景风云变幻，其两个最有趣的特点是：1. 随着单内核处理器达到其固有极限，处理器在向“多内核”的方向发展；2. 随着FPGA在片上集成越来越多的系统级元件，FPGA的使用数量不断增加。事实上，这两个特点是同一个潜在趋势的不同方面。对这两个特点进行推断，就会发现最终需要一个面向复杂计算的元件阵列结构，这个阵列结构与高速、灵活的通信网络连接在一起。可以预计ASIC的应用将减少(除了量非常大的产品以外)，FPGA和可重配置架构的应用将增加。

设计中存在的危机

假设一位首席芯片设计工程师用18个月时间完成一项设计并开始投产，如果认为这个项目还需花费大量资金重新设计那是不现实的。实际上，就丢失的市场份额而言损失将更多，因为产品出货时间要延迟10周。总之，同样的问题在下一个设计项目中仍困扰着首席芯片设计工程师，因为设计中晶体管的数量将增加一倍，但他并没有两倍数量的设计工程师或两倍的时间来完成这项工作，也不能犯两倍数量的错误。

由于我们无法摆脱日益增长的设计复杂度和静态资源，因此实现这样的设计只有一种途径，那就是提高设计工程师的设计产出率。电子设计自动化行业现已推出更好的工具和语言并鼓励设计复用，这使设计工程师的设计产出率在过去数十年内以每年23%的速度增长。然而问题是，设计产出率23%的增长速度远远低于设计复杂度每年将近60%的增长速度。这两个数据之间的差距就是一种“设计差距”。

过去是用手工设计芯片-多边形布局设计，不断增加的复杂度迫使设计工程师通过采用标准单元库和原理图捕获来获得更高的设计产出率，尽管这会损失控制和“效率”。大约十年以后，基于同样原因，芯片设计需要再次提高设计产出率，并放弃更多控制和效率，转向如VHDL和Verilog这样的硬件描述语言和逻辑综合。现在几乎所有设计工程师的设计产出率的增长都来自于设计复用。尽管可以很容易地预测到将来设计复用会更多，但它还不足以使公司保持竞争优势，因此设计产出率还需得到进一步提高。

我们至今用来解决这个设计差距的方法的效果并不足够好。其痛苦之大以至于行业中大多数人都知道需要进行一些改变。大量的争论出现在这种改变将意味着转到“系统级”设计。然而，“系统级”到底意味什么并没有取得一致认识。但是很明显，转换到系统级设计将是断断续续的过程，可能类似于VHDL/Verilog和标准单元的演变。

可能的解决方法

我自己相信可配置硬件是未来的发展方向，FPGA现在依然只是针对特定计算的通用、可配置基础的大概念的第一代体现。最终的应用程序将在该硬件上运行，因此找到一种直接在可重配置底层平台上进行程序编译的方法是很明智的。这样一来，当出现更强大的平台时，简单的再编译就能将其利用。

如果我们的目标就是把相对普通的程序编译成有效硬件，那么如果能用程序员现在使用的C语言编写编译器，并用它产生网表将是再好不过的。这就是从C程序到“门”的方法。不幸的是，由于硬件的并行特性，这种方法并不可行。因为在并行式计算机上优化顺序程序一直以来就被认为在计算上难以处理，编译器要从第一个源程序上产生一个完全优化的方案是非常困难的。

huishuming

实际上很容易构建一个能将任意的C程序转换成硬件网表的编译器，这样一个编译器甚至可能较好地实现程序的并行处理。然而，这些系统一般仅对小型设计实例有效，当在大型设计实例中效果不好时，设计师将没有办法来帮助改善。智能编译器事实上对于设计师来说太过智能，以致设计工程师不能对其设计进行控制，并缺乏明显的进一步办法。

我们所能选择的是，放弃编译器该输出什么或者该输入什么的概念。假设硬件不是免费的，那么要求从编译器后端持续产出有效硬件还是很有必要的。这种选择迫使我们改变必须为编译器提供什么作为输入的观念。如果不是序列C语音，那么它必须是一种设计工程师可用来表达想得到的并行性的语言，这种并行性是当前编译器不能产生的。

这种方法的问题是需要程序员采用会增加他们工作难度的并行方式来表示算法和应用。但至少这种方法是可能实现的，而且优势很明显。采用这种方法，我们可以利用编程技术将复杂软件变成好的硬件，并写出能很好完成这项工作的编译器且不会让设计工程师失去控制。

这样一来，程序员所作的事就类似于电子工程师用两个处理器、四个存储模块和20个累加器填充芯片的二维空间这样的工作。软件方法提升了抽象等级，以至于我们都在谈论计算(算法和程序)，而不是硬件功能单元。然而，本质上我们还是在用它们填充二维空间，只是现在我们故意放弃将它们放到哪里的控制要求。如果程序员想用两个a算法和3个b算法来填充硅片，他只需简单地写下这样的语句：

par {a; a; b; b; b; }

如果编译器将每个计算转换成一块独立的硬件，那么程序员仅需像电子工程师一样做相同的基本工作，即利用总体方案有用部件填充可用的硅区域。两者的区别是，程序员是在更高的抽象级上来做这样的工作。因此，程序将更短，更易于编写、修改、恢复正常以及维护。

时间、空间和通信的问题

实际情况要比前面描述的更复杂一些。为了在硬件中嵌入复杂算法，需要仔细注意时间、空间和通信问题。对于空间，前面谈论的是并行性。对于通信，我们关注的是总体方案的不同元件用来相互传递数据和同步信息的方法(稍后讨论)。

对于时间，工程师通过考虑传输延时、时钟偏移、门延迟、管线长度等特性将他们的解决方案嵌入到时域里。然而用同样的方法，我们不知道如何构建一个能自动并行化的编译器，也不知道如何使编译器实现能有效嵌入到时域的计算。假设目前无法用自动编译器很好并可靠地产生这些计算，用相似论据可推断出输入语言必须也具有表达程序的暂态行为(temporal behavior)的能力。

刚才提到的许多时间概念实际上都很复杂。如果希望将非常复杂的计算嵌入到时域，必须找到一个更高级、更抽象的方法来描述它，特别是如果希望具有软件背景的设计工程师来完成部分或者全部设计。无论设计工程师是什么背景，在他们将设计嵌入到时域的时候，这些概念都可以让他们不必过多担心细节，而是更多关注大的方面。

几乎所有程序设计语言都来自于同一个强制性的编程模型。在这个模型里，表达式被求值计算，其结果被赋值(存储)到一个变量(寄存器或者存储位置)里。事实上，仅仅是赋值语句引起计算，其他语句都用于控制。程序中的控制语句，例如if和while语句、程序调用等都只是确定哪个赋值语句将被执行，因而哪个变量将被更新。

将时间概念融入到软件语言的一个方法，是通过假定在计算中时间以时钟周期为单位以及执行赋值只占用一个时钟周期来连接这两个概念。如果想知道一个程序的时间行为，只需看看正在执行的赋值语句。每个赋值语句占用一个时钟周期，其它计算不占用时间。因此，三个连续的赋值占用三个时钟周期，{a=x; b=y; c=z;}，而并行执行的三个赋值只占用一个时钟周期，如par{a=x; b=y; c=z;}。

从这个例子可得到用于构建进程并列执行的架构。尽管这些进程可以通过共享变量相互通信，但我们仍然希望一种更直接的通信模式，这样进程可以相互发送数据和同步信息。如果希望进程局部同步，尤其需要做这样的改变，但是全局异步可以减少当前高速全局时钟的规模效应。

尽管有很多概念在为成为通信的广义模型而竞争，但我对它们当中的CSP/occam系统通道概念更感兴趣。通道概念具有扎实的通信顺序进程(CSP)代数学理论基础以及丰富的实践应用经验。一个通道有两个端，一个在发送进程中，另一个在接收进程中。一个企图利用通道(发送或者接收通道)进行通信的进程将被阻止，直到另外一端的进程也准备就绪。只有当两端的进程都准备就绪时，一组数据(或者任何指定的类型)才能进行通信，这时两个进程被释放并自由运行。因此，这些通道具有点对点、定向、阻塞(blocking)和同步的特性。

综合以上思路，我建议让所有的程序员(除了他们必须作的任何事情以外)针对并行性(空间)、时钟周期(时间)和通道(通信)积极地设计他们的程序。

作者：Ian Page
Email: ipage@iee.org
Celoxica公司

vincent

不错！