电子系统级设计（ESL）：现实还是涂有外表之物

 

我经常问的一个问题是：谁在真正使用诸如可以建模的ESL方法，在流程中是否有一些阻碍？另一个通常的问题是：究竟什么是ESL？也许我们应该先说说第二个问题。

   对于一些人来说，ESL是指在做任何软硬件部分的决定之前的一个非常高的抽象层次的设计。相比之下，其他人认为ESL是硬件或软件的协同设计。还有一些人会说ESL是优于寄存器传输级（RTL）的更高的抽象层次。当然，我们应该注意到ESL并不一定意味着设计工具，因为一些验证应用可能进入ESL领域。

   在我的书架上有一本非常有用的书，它就是ESL设计和验证（国际书号：0-12-373551-3），作者是Brian Bailey, Grant Martin和Andrew Piziali。书的第二章介绍了模型分类（时序轴，数据轴，功能轴，结构轴）和ESL分类（并发，通信，配置）。就个人而言，我发现这一章对得起这本书的价格，但我们似乎有些离题。

   正如Justice Potter Stewart在Jacobellis v. Ohio（1964）中写到：“

我不能描述色情，但是当我看到的时候我能知道它。”在此基础上，这是我所倾向的方式来了解ESL，让我们思考一些不同类别的ESL。

  在某些情况下，ESL不是一个新方法。事实上，在某些领域它是一个饱和的市场。例如，数字信号处理（DSP）工具一直可以用来让你描述你在数学上想做的东西，然后生成C代码运行于一个处理器上。

ESL的一个较新的部分是现在称之为高层次综合（HLS）的工具，属于这一类的工具有Mentor的CatapultC，Auto ESL的AutoPilot，Cadence的C-to-Silicon编译器，Forte的Cynthesizer，脉冲加速技术的CoDeveloper，Synfora的PICO。

   这个类的大部分HSL工具使用C/C++/SystemC作为起点，但是在这个类中我们应该也包含BlueSpec，因为尽管它们以完全不同的方式来处理问题，最终他们仍在考虑采取一个高层次的描述并用它来生成执行级别的RTL。（事实上，Cadence的C-to-Silicon可以合成门级网表，但我们不要迷失方向，误入歧途。）

    ESL的伟大之处在于它的多样性。一个经典的例子是人们在Tensilica公司以及他们的Xtensa可定制处理器，可以被看作是完全不同的球赛。在这种情况下，我们所谈论的是一个可以分析你的C代码的工具，然后给您列出一个自定义处理器架构的选择，当然这个架构对于执行一个特定的算法或者一些算法的类十分高效。一旦你选择了最符合你要求的架构，Xtensa为处理器生成RTL连同一个相应的软件工具链。

    另一个ESL的“舞台”涉及处理器阵列特征的芯片。在这种情况下，我想到了MathStar的现场可编程对象阵列（FPOAs）的Arrix系列以及Ambric的大规模并行处理器阵列（MPPA）。这两家公司不再遗憾，但在不远的将来，我认为我们一定会看到更多类似的事情在市场上发生，例如Element CXI的元素计算阵列（ECAs）。当我们开始考虑这些工具把应用 整 合到这些平台上的时候，这是我认为这些元件会落入ESL领域的理由。

    然后我们有了虚拟平台（VPs）这个概念，这个平台用来作为架构开发和设计验证。我们立刻把VPs分成两个不同的组。首先VPs主要用来做软件开发和验证，这些非常快而且功能准确，但它们几乎没有时间的准确性。它们也十分有限的见到内部所发生的事情。（例如，你可以访问缓存的统计数据，确没有总线的统计数据。）一些例子是Synopsys的Innovator，CoWare的虚拟平台以及Virtutech的Simics。

    VPs的另一类针对架构分析。这是有点慢于“纯粹的”VPs，但提供了更高级别的硬件时机保真。（我们把这些归入“功能准确/时间近似”）在这种情况下，对于硬件在总线，调停等等所发生的事情，我们有更好的可见性。这方面的例子有Mentor的Vista架构师，Synopsys的CHIPit自动快速成型系统以及CoWare的平台架构师。

    但是各种不同的形式化验证又如何呢？它们也落入了ESL区域吗？实际上，我可能说不。这是因为ESL的一个定义是一种表示，表示时钟不再存在。换一种方式说，时钟是一个执行的显示，当你完成一个执行时，你将不在ESL领域。当然每个规则总有例外，此时，我将把Calypto的SLEC序列分析技术归类为一个ESL工具。

   正如一位业界专家和我说的一样，就在几天前我写了这些话：“ESL就像是一个连点游戏，问题在于现在虽然我们有众多的“点”，这些点是有价值而且迅速成熟的工具，在它们之间我们并没有太多的连接要求。”

    作为结尾，让我好好想想The MathWorks的MATLAB和Simulink。

当提到高级别算法评价和假设分析的时候，这些都是非常有用的工具。但是它们生活在自己的小“泡沫”里，因为它们生成的C并不是真正的C，你想放入一个HLS流中但通常它没有足够的效率直接运行在一个DSP上。因此，这些工具可能被认为是一些焦急等待合适连接的“点”。正如命运得知，在不远的将来这些事情可能会发生变化，但就目前而言，我有义务保密……

 

ESL: Reality, Or A Pigment Of Your Fig Neuton?

One of the questions I am often asked is: “Who’s really using ESL tools such as modeling and are there any hiccups in the flow?” Another common question is: “What actually is ESL?” Perhaps we should address the latter question first.

 

To some folks, ESL (electronic system level) means designing at a very high level of abstraction prior to making any hardware-software portioning decisions. By comparison, other folks would say that ESL refers to hardware/software co-design. Still others would say that ESL refers to anything that’s at a higher level of abstraction than register transfer level (RTL) representations. And, of course, we should note that ESL does not necessarily imply a design tool, because some verification applications might fall into the ESL domain.

 

One very useful book I have on my shelves is ESL Design and Verification (ISBN: 0-12-373551-3) by Brian Bailey, Grant Martin, and Andrew Piziali. Chapter 2 presents a Model Taxonomy (Temporal Axis, Data Axis, Functionality Axis, Structural Axis) and an ESL Taxonomy (Concurrency, Communication, Configurability). Personally, I found this chapter to be worth the price of the book alone, but we digress.

 

As Justice Potter Stewart wrote in Jacobellis v. Ohio (1964): “I can’t define pornography, but I know it when I see it.” This is the way I tend to approach ESL. On this basis, let’s ponder some of the different flavors of ESL that are out there.

 

In some cases ESL is not new. In fact, in some domains it’s a saturated market. For example, digital signal processing (DSP) tools have long been available to allow you to describe what you wish to do algorithmically and to then generate C code to be run on a processor. A newer segment of this is what is now being referred to as High Level Synthesis (HLS). Tools that fall into this category are CatapultC from Mentor, AutoPilot from Auto ESL, C-to-Silicon Compiler from Cadence, Cynthesizer from Forte, CoDeveloper from Impulse Accelerated Technologies, and PICO from Synfora.

 

Most of HSL tools of this class use C/C++/SystemC as a starting point, but we should also include Bluespec in this category, because although they go about things in a completely different way, at the end of the day they are still taking a high-level description and using it to generate implementation-level RTL. (Actually, C-to-Silicon from Cadence can synthesize a gate-level netlist, but let’s not wander off into the weeds.)

 

The great thing about ESL is its diversity. A classic example of this would be the folks at Tensilica with their Xtensa Customizable Processors, which may be considered a completely different ball game. In this case, we’re talking about a tool that analyzes your C code and then presents you with a selection of custom processor architectures that are extremely efficient with regard to executing a certain algorithm or class of algorithms. Once you’ve selected the architecture that best meets your requirements, Xtensa generates the RTL for the processor along with a corresponding tool chain.

 

Another ESL “arena” involves chips that feature arrays of processors. In this case I’m thinking of such beasts at the Arrix family of Field Programmable Object Arrays (FPOAs) from MathStar or the Massively Parallel Processor Array (MPPA) from Ambric. Both of these companies are sadly no more, but I think we’re certain to see more things like this appearing on the market in the not-so-distant future, such as the Elemental Computing Arrays (ECAs) from Element CXI. The reason I believe these components fall into the ESL domain is when we come to consider the tools used to map applications onto these platforms.

 

And then we have the concept of the Virtual Platforms (VPs) that are used for architectural exploration and design verification. We immediately have to split these into two distinct groups. First we have VPs that are intended primarily for software development and verification. These are very, very fast and are functionally accurate, but they have little if any timing accuracy. They also have limited visibility into what’s “happening inside” (for example, you may be able to access cache statistics but not bus statistics). Some example of this class are Innovator from Synopsys, Virtual Platform from CoWare, and Simics from Virtutech.

 

Another class of VPs are targeted toward architectural analysis. These are somewhat slower than “pure” VPs but provide a higher level of hardware timing fidelity (we might class these as “functional accurate / timing approximate”). In this case we have better visibility into the hardware in terms of what’s happening on the busses and arbitration and so forth. Examples of this class are Vista Architect from Mentor, the CHIPit Automated Rapid Prototyping System from Synopsys and Platform Architect from CoWare

 

But what about the various flavors of Formal Verification? Do they fall into the ESL domain? Actually, I would tend to say no. This is because one definition of ESL would be a representation in which clocks don’t exist. To put this another way, clocks are a manifestation of an implementation, and when you’ve reached an implementation you are no longer in the ESL domain. Of course there’s always an exception to every rule and, in this case, I would class the SLEC Sequential Analysis Technology from Calypto as being an ESL tool.

 

As one industry expert said to me just a few days ago as I pen these words: “ESL is like a game of Connect-the-Dots – the problem is that although these days we have multitude of ‘dots’ in the form of valuable and rapidly maturing tools, we don’t have a lot of the required connections between them.”

 

Which, in closing, leads me to ponder MATLAB and Simulink from The Mathworks. These are amazingly useful tools when it comes to high-level algorithmic evaluations and what-if analysis. But they sort of live in their own little “bubble” because the C code they generate is not the C that you would want to put into an HLS flow and it typically is not efficient enough to be directly run on a DSP. Thus, these tools might be considered to be “dots” that are anxiously waiting for the appropriate connections. As fate would have it, this is something that might change in the not-so-distant future, but for the moment I am bound to secrecy…