我经常问的一个问题是:谁在真正使用诸如可以建模的ESL
对于一些人来说,ESL是指在做任何软硬件部分的决定之前
在我的书架上有一本非常有用的书,它就是ESL设计和验证
正如Justice Potter Stewart在Jacobellis v. Ohio(1964)中写到:“
我不能描述色情,但是当我看到的时候我能知道它。”在此基础上,
在某些情况下,ESL不是一个新方法。事实上,
ESL的一个较新的部分是现在称之为高层次综合(HLS)
这个类的大部分HSL工具使用C/C++/SystemC作为起
ESL的伟大之处在于它的多样性。一个经典的例子是人们在Ten
另一个ESL的“舞台”涉及处理器阵列特征的芯片。
然后我们有了虚拟平台(VPs)这个概念,
VPs的另一类针对架构分析。这是有点慢于“纯粹的”V
但是各种不同的形式化验证又如何呢?它们也落入了ESL
正如一位业界专家和我说的一样,就在几天前我写了这些话:“ES
作为结尾,让我好好想想The MathWorks的MATLAB和Simulink。
当提到高级别算法评价和假设分析的时候,
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…
By Clive “Max” Maxfield,译者:与非网 吕勇