iwjl的博客

引言：现有的嵌入式软件设计技术已经不能满足复杂的多处理器架构的通信(IPC)软件开发需求。本文介绍了一种基于功能事务级建模方法的虚拟原型设计技术，使用这种技术，所有的软件开发任务都能在硅片出现之前完成，提高了开发效率和缩短产品的面市时间。

图1：虚拟原型技术框图。

在当前的嵌入式系统中，为满足不断增长的计算需求、吞吐量以及集成的系统功能，多处理器架构正在开始广泛采用。例如，高端智能电话已经包含了很多的微处理器(MPU)和数字信号处理器(DSP)来提供先进的2.75G和3G调制解调器和应用处理功能，以及WiFi、GPS和蓝牙功能。

当前的嵌入式软件设计实际并没有为这些不同架构开发处理器间的通信(IPC)软件的复杂性做好准备。然而，虚拟原型设计技术正在出现，这种技术允许创建嵌入式系统的高性能功能性软件模型，这种软件模型非常完整，能完全反映出硬件功能。

基于功能事务级建模方法(F-TLM)，通过将高速处理器指令集仿真器与高级的全功能硬件构建模块的C/C++模型结合起来，可以产生一种虚拟的平台。产生的这种虚拟平台是一种高级的硬件模型，这种模型足够完善，软件开发者可以用来替代实际设备。

采用这种平台(见图1)，软件团队能在得到硅片之前的很长时间就可以开始开发、整合以及测试软件代码。这种技术促成了各层次软件的并行开发，包括ROM代码、固件代码、设备驱动程序、操作系统的移植、中间件和应用程序的开发。

F-TLM平衡了多处理器软件的要求

基于F-TLM的虚拟平台模型提供了指令集仿真器、硬件/外设模型和系统I/O之间的恰当平衡，这样就可以允许早期和并行的软件开发。F-TLM专注于与软件开发者相关的硬件方面，一般回避那些在软件编程模型中接触不到的硬件细节。正确的F-TLM环境结合了三种主要的元素：

1. 精确指令ISS：在一个典型的多处理器设计中，为不同设备而生成的基于F-TLM的CPU模型能对CPU状态进行建模以及执行目标程序二进制代码。生成的CPU模型包括MMU(内存管理单元)模型，它能与功能性缓存模型互补，提供运行时的缓存命中/错过的数目的统计信息。利用精确指令，它们能逐指令执行目标程序二进制码，因此与二进制代码兼容。然而，这种CPU模型没有包含CPU管线的模型，没有保持周期的细节。

2. 高级事务级总线模型：在多处理器设计中，复杂的总线传输信息流被简化成简单的读和写事务。这种抽象由许多方面组成，包括不同的总线阶段、芯片选择、重试、仲裁之后的总线转向等等。在简单的总线模型上以读和写函数调用来执行事务。这些总线模型对地址解码和不同总线单元(例如总线桥、仲裁器等)的控制寄存器进行建模。

3. 功能外设模型：针对多处理器设计中的每个硬件外设，对寄存器接口、编程模型、功能和与其它外设或者其系统I/O的通信建模。建模关注于软件和外设功能之间的相互作用和影响。例如，对一个相机接口控制器的某个控制/命令寄存器的编程可能启动来自第二个电话相机的数据流。

这种类型的交互和功能可以包含在功能模型中。硬件方面，例如内部管线、内部硬件加速器的仲裁、访问系统总线的流控制等等，从运行的软件来看，它们一般没有相关性，因此没有包含在平台模型中。

表1显示了对于一个完整的板级仿真器来说，F-TLM可以获得的执行时间(绝对的时钟时间以及主PC每GHz的规格化MIPS(每秒百万条指令)。板级仿真器由基于多处理器的复杂系统级芯片(SoC)和几个板级分立器件组成。注意，在OS引导阶段，每GHz的有效MIPS数(OS对不同的外设编程，并等待外设在初始化之后返回结果)越低，则有效的MIPS额定值越低。

准确周期模型与F-TLM模型

相对于F-TLM模型，准确周期模型尽管提供了非常好的细节和时序规格，但非常难以评估，需要花费很多的时间来进行开发，并且执行速度也更慢，一般在每秒500k周期的数量级。尽管对于低级的软件开发任务(例如软件运行代码很少的ROM代码和固件开发)来说这种性能等级是可以接受的，但是对于高效率的高级操作系统移植、中间件整合以及应用程序开发来说还是太慢了。

基于F-TLM的虚拟原型方法在很多嵌入式消费类设备中采用的复杂多处理器环境中具有几个优势。

作为这种系统核心的高度集成的SoC包含数十个外设和多个片上和片外总线，由于引脚或者JTAG限制，其中一些在物理目标上可能是不可见的，使得对这些器件的编程和调试更加复杂。

提供对对象更高的可见性和控制对于提高这些新SoC的软件开发效率来说是很必要的。为了获得高的整体执行速度，以及观察发现95%的仿真速度用在CPU ISS以及存储器模块上，推动了仿真器开发向着CPU ISS和存储器模块这些关键器件使用本地的、编译的C++代码方向发展。

在这样的F-TLM环境中，为捕获外设和它们的功能，需要一种图形化的有限状态机(FSM)语言，例如“Magic-C”。“Magic-C”把一些规范与描述语言(SDL)的图形化描述能力与ANSI-C的执行能力结合起来。

图2：通信FSM执行范例截屏图。

并行的通信FSM执行范例(见图2)可以很容易地描述并行硬件实体，同时其图形化的特性能实现一种图形化的硬件调试器，这种调试器可连接到正在运行的仿真，还能支持如硬件断点和硬件单步调试的全新功能。

采用这种图形化的语言，开发者可以同时通过Magic-C硬件调试器调试硬件，通过一个与运行中的仿真相连接的软件调试器调试软件。仿真框架也应该尽可能多地利用标准的模型接口和API，促进器件模型的复用。通常，这意味着一组标准的事务级接口和一种标准的抽象层，所有的外设模型用这些与总线相连。

采用F-TLM构建一个多处理器SoC

图3：OMAP虚拟平台的截屏图。

通过了解怎样运用F-TLM方法在基于TI OMAP平台上进行应用开发，该方法在对多处理器架构进行建模中的功能显而易见。OMAP是一种具有鲁棒性的软件基础架构，具有对于快速开发互联网设备、2.5G和3G无线手机和PDA以及其它多媒体增强设备的全面支持网络。

为实现这些特点，这些SoC利用一种先进的不同的RISC/DSP架构，结合了专用的2D/3D图形加速器和图像视频加速器(IVA)，其中有些加速器包含一个额外的RISC核，产生不同的并行片上CPU网络。

仿真器使用模型-为加速OMAP架构的内部和外部软件开发，TI与Virtio合作开发了几个OMAP虚拟平台，这些平台早于硅片出现几个月。图3中显示了OMAP虚拟平台的截屏图。

通过协调内部软件开发阶段与OMAP平台提交时间，软件开发可以在平台开发开始后四个星期就开始。所有这些在架构规范和硬件设计还在确定的过程中就可以开始，从而实现真正的并行开发。

基于F-TLM的虚拟平台首先实现了能使用低级ARM(调试)工具提前开发开放的操作系统引导加载程序，其次是OS HAL的开发、内核移植，最后能使得设备驱动程序扩展集进一步开发，这些都是通过使用目前的目标开发工具，而不需要改变开发流程。

表1：几种嵌入式操作系统时钟时间的比较。

与此同时，DSP团队进行DSP/BIOS实时操作系统的移植与开发。在后期阶段，开发团队开发处理器间通信(IPC)层以及RISC内核与DSP之间的器件，并将这些添加到高级操作系统和DSP/BIOS端。

一旦板级支持包(BSP)开发完成并经确认，TI就将由OMAP虚拟平台和BSP组成的桌面开发环境提交给初始客户，使客户能开始整合设备中间件和关键应用，加速他们的设备开发。

处理器间通信的好处：对不同处理器组成的网络IPC软件开发一般是对这些SoC的全部软件开发中最具有挑战性的一个任务，虚拟平台的几个关键特性对加速这种开发提供了非常大的帮助，并提高了开发的效率。

虚拟平台提供了增强的系统可见性，这使开发者能更简单地隔离和调试IPC问题。Magic-C硬件断点和调试功能提供了在任何时间点对片上IPC硬件状态(例如片上信箱区和信号量)、整体的系统状态和CPU状态的可见性。

与物理开发对象相比不同的是，当CPU在与JTAG调试器连接的运行过程中停止工作时，整个系统包括硬件外设时钟(不仅仅特定的CPU实例)都会停止工作。这导致IPC硬件(以及所有的其它外设)停止工作，这些IPC硬件与CPU同步。这样一来，在任何时间点，系统状态不受影响，例如不会被中断触发破坏。像每当CPU停止工作时系统状态的维持不受影响这样的功能，有利于提高开发效率。

确定性仿真执行和多内核调度算法确保了可预测性，这可以使设计缺陷轻易再现，并可反复运行仿真。

此外，通过提供对对象的低级多内核JTAG式控制，仿真支持紧凑的多内核调试。例如，每当DSP或者RISC中发生一个值得关注的事件时，任何一个调试器都能停止整个平台的执行，工程师就可以查看DSP和RISC中的事件点。

由于采用先进的仿真技术，所有的软件开发任务，包括DSP/BIOS操作系统移植和IPC软件开发，都能在硅片出现之前完成。最初的内部软件开发效率调查显示，相比于使用物理对象的开发，测得的效率提升达2倍到5倍。

作者：Filip Thoen

首席技术官

Virtio公司

在设计群体越来越响的拍手叫好声中，IEEE近日表示已经批准了SystemC电子设计语言标准。IEEE标准化有助于将SystemC引入到更广泛的应用领域，并推动来自商用EDA工具更进一步的支持。

获得批准的SystemC，或称IEEE 1666，基于由OSCI(Open SystemC Initiative)开发的SystemC 2.1语言参考手册。该语言标准此前是于2005年6月提交给IEEE的。

据IEEE称，SystemC 2.1将硬件和软件建模功能拓宽至更高抽象级。它令工程师从头建造整个系统，从而加快设计，允许共享并复用知识产权。

据OSCI主席Alain Clouard称，标准化流程受到参考手册的推动。在IEEE发表的声明中，IEEE标准协顾问组主席Chuck Adams为OSCI “杰出的技术贡献” 致谢，并称标准在少于8个月内的快速出台为一项“重大成就”。Clouard表示，OSCI将继续努力，为SystemC添加add-on层，如该组织6月发布的交易级建模标准。

除了从软硬件的概念到实现扩展了设计和验证之外，IEEE表示，SystemC 2.1还提供了可互用的建模平台，用于开发并交换快速系统级C++模型。它还构筑了一条结构设计和寄存器传输级(RTL)实现之间的桥梁，为在丰富设计环境内创建可互用工具提供了平台。

IBM公司日前公布计划，将向研究员和学术界免费提供PowerPC 405内核。IBM表示，计划通过Power.org协调安排405内核的捐献。Power.org是围绕Power架构开发标准以及应用的开放式开发商、工具提供商和制造商社群，于一年前成立，旨在促成并推广Power架构技术成为电子工业优选的协作硬件开发平台。

Power.org主席Nigel Beck将该计划的发布作为开放Power架构的举措之一。这标志着IBM首次向学术研究界开放“零费用”的许可，使他们能获得Power RTL代码并且进行开发。Beck表示，“这与我们过去一年所推进的工作一致，”Power.org的策略是从基础设施的创建开始起步。

据IBM称，该举措是响应计算机科学领域参与协作性多内核处理研究项目的领先教育机构的要求，如Research Accelerator for Multiple Processors(RAMP)。RAMP由加州伯克利大学、斯坦福大学、麻省理工学院、卡内基梅隆大学(CMU)、德州Austin大学和华盛顿大学牵头。

IBM表示RAMP研究人员现在可以将该内核映射到他们的基于FPGA的系统或者新型芯片结构实验内。

He added: “The problem is how to move to a new level of abstraction. We need an era of more designs per engineer, and not more engineers per design.”
     
According to Kenn Lamb, CEO of Elixent, the only way to reduce this cost is to move design to a higher plane. “The lesson of history is to abstract up beyond the level of the problem. We’re moving into algorithms, and abstracting them above the silicon.”

Rudi de Winter, CEO of fabless semiconductor company Melexis, agreed. “From idea to first chip sold is at least three years, and most of that time is taken up by testing and qualifying.

"If it’s part of a completely new system, that goes out to four years. Only after five years does the chip enter significant volume, and it ramps down after 10 to 12 years,” he said.

According to Celoxica’s CEO, Phil Bishop, the company has a C-programmable system-level technology that can reduce design time by between 40 percent and 50 percent, but results in a 25 percent reduction in chip performance. “You can’t abstract away from the silicon and still get optimal performance,” said Bishop.

Wolfgang Rosenstiel of the University of Tubingen told the recent MEDEA+ Forum that the SpEAC project, aimed at moving design to a higher level of abstraction, had resulted in a 75 percent reduction in design time and 80 percent reduction in verification time, reducing the design to fab cycle from between nine to 12 months to between seven and 10 months.
      
Another approach to chip development cost is platforms. Graham Curren, CEO of Sondrel, argued: “People won’t design 65nm designs from scratch. They won’t put down 100 million transistors. Chips will be on-going devices which evolve over time.”

Elixent’s Lamb agreed: “Each new device has to target a wider number of applications.”

Vasishta pointed out that a platform derivative from STMicroelectronics delivered a chip which took 24 hours from RTL to tape-out.

Electronics Weekly is the London-based sister publication of Electronic News.

Edd Dumbill (edd@usefulinc.com), Chair, XTech Conference

06 Dec 2005

In this two-part series, Edd Dumbill examines the various ways forward for HTML that Web authors, browser developers, and standards bodies propose. This series covers the incremental approach embodied by the WHATWG specifications and the radical cleanup of XHTML proposed by the W3C. Additionally, the author gives an overview of the W3C's new Rich Client Activity. Here in Part 1, Edd focuses primarily on two specifications being developed by WHATWG: Web Applications 1.0 (HTML5) and Web Forms 2.0.

HTML isn't a very good language for making Web pages. However, it has been a very good language for making the Web.

HTML's ease of learning and the view source capability for browsers has bootstrapped the Web's popularity in an amazing way. The World Wide Web Consortium's (W3C) involvement in standardizing HTML has ensured that Web browsers all implement the same dialect, more or less. The emergence of CSS, and the corresponding growth of standards-based Web design as best practice has also averted HTML chaos and led to a better Web experience for users and developers alike.

This much you probably know. The resulting Web has probably made a positive impact on your life or business. Yet the fact remains, HTML isn't a very good language. Why, for instance, does HTML have headings H1 through H6? Who ever seriously used a six-level-deep heading hierarchy? And why, in this era of 3D-accelerated graphics cards and sophisticated user interfaces, are Web pages limited to clunky text boxes and radio buttons for user input?

No surprise then, that various groups are pushing again to develop HTML in a way that lets Web publishing and Web applications use more of the technology that's available in modern user interfaces. Who are these people? Broadly speaking, they fall into three groups. The first are those who use today's technology to make a difference. This is what the Asynchronous JavaScript and XML (Ajax) buzz is about: using JavaScript and the browser's XMLHttpRequest object to create dynamic user interfaces. The effects can be wonderful, but this is not a standard way to move forward.

The other two groups focus on future improvements. The W3C promotes XHTML 2.0, based on the requirements of a broad vendor base -- not just desktop browser makers. XHTML 2.0 is seen as a radical step. In contrast, the Web Hypertext Application Technology Working Group (WHATWG) promotes a set of incremental specifications, which evolve HTML to add the most immediately required functionality into the browser. Some WHATWG features are already implemented in Apple's Safari browser and Mozilla Firefox 1.5. (See Resources for more on W3C and WHATWG.)

These articles will examine the work of the latter two groups: W3C and WHATWG. Ajax has been covered elsewhere in developerWorks (see Resources). While no standards war has erupted yet on the scale that brought HTML into the W3C in the first place, these two organizations are not always in agreement as to where HTML should go. I'll explain and evaluate both approaches.

WHATWG, HTML 5, and Web Forms 2.0

As their Web page states, WHATWG is a "loose unofficial collaboration of Web browser manufacturers and interested parties who wish to develop new technologies designed to allow authors to write and deploy Applications over the World Wide Web." Two terms are of particular interest here: WHATWG's main players make browsers (Mozilla, Opera), and the focus of their improvements is towards creating Web applications.

WHATWG's figurehead specification is code-named HTML5, but is known more properly as Web Applications 1.0 (see Resources). HTML5 is intended to preserve backward compatibility with the current HTML standard, HTML 4.01, and also with XHTML 1.0, the XML version of HTML. The specification sustains both the HTML and XHTML strands of W3C HTML, although it notes that implementations may choose not to.

In addition to HTML5, the Web Forms 2.0 specification (see Resources) seeks to address many of the annoyances that developers find with the current state of HTML forms. Today's forms omit many basic features from regular desktop applications, such as validation and richer widgets.

So what's inside HTML5? In short, a lot. The Web Applications 1.0 specification is an evolving beast, and some of the features mentioned are more fully developed than others. Here's a 30,000-foot flyover of the new features:

• New layout elements, including a calendar control, an address card, a flexible datagrid, gauges and progress meters, drag and drop, and menus
• Programming extensions to the Document Object Model (DOM), including server-sent DOM events
• A formalization of the de-facto standard XMLHttpRequest object, the centerpiece of Ajax communication
• Dynamic bitmap graphics through the canvas element

You can see the heritage of many of these in features implemented as one-offs with JavaScript on the Web today. Indeed, the recent rise in popularity of Ajax toolkits has led to a proliferation of widgets such as gauges, calendars, and so on.

canvas

Traditional implementation of HTML5 features -- that is, as part of a Web browser -- is restricted today to just a few of the technologies mentioned above. The most well-known among these is the canvas element. Firefox 1.5 and Apple's Safari browser have also implemented canvas.

While the W3C's Scalable Vector Graphics (SVG) language already provides a way to show in-browser illustrations, Figure 1 shows a screenshot from a simple canvas demo. (See Resources -- you can view it with Apple's Safari browser or a pre-release of Firefox 1.5.) When the user moves the mouse over the shapes, the shapes slowly enlarge. Among other things, the demo shows that all the necessary ingredients for implementing user interfaces -- drawing, user input events, and timers -- are in place.


Figure 1. Screenshot of interactive canvas demo



canvas applications are already one step closer to their obvious conclusion (games!) with the implementation of a simple 3D maze, as illustrated in Figure 2. (See Resources for a link to the actual maze.)


Figure 2. Screenshot of simple maze game



To get a flavor of how you can program canvas, look at some simple code. Listing 1 shows a self-contained example, the end result of which is shown in Figure 3.


Listing 1. Simple canvas example


<html>
  <head>
    <title>Canvas demo</title>
    <script type="text/javascript">
      function draw () {
        var canvas = document.getElementById ('hello');
        if (canvas.getContext) {
          var ctx = canvas.getContext('2d');
          ctx.fillRect (25, 25, 50, 50);
        }
      }
    </script>
    <style type="text/css">
      canvas { border: 2px solid red; }
    </style>
  </head>
  <body onload="draw ();">
    <canvas id="hello" width="100" height="100"></canvas>
  </body>
</html>

Figure 3. Output of Listing 1

As canvas does not present any declarative semantics, it is likely that it will have more applications in the user interface implementation area than anywhere else. An intriguing scope for canvas is as a prototyping ground for new browser interface elements and features. The best example of this is Antoine Quint's partial implementation of SVG using canvas (see Resources). Using Quint's method, to render an HTML file with embedded SVG, you add a couple of lines that import his JavaScript SVG renderer. Figure 4 shows the familiar tiger image rendered using this method.

Figure 4. SVG tiger image rendered using JavaScript and the canvas element

Time will show whether canvas is useful in a mainstream Web setting. Its functionality is something akin to that of Java applets, yet its JavaScript interface makes it much easier to use and interface with other browser elements.

Web Forms 2.0

The WHATWG forms specification's version number indicates its intent to build on the specification of forms in HTML4. In contrast to the Web Applications (HTML5) specification, it is in a mature state. Web Forms 2.0's scope is also more limited -- focusing directly on improving the form widgets available in the browser.

What does this new revision of forms add? Among other things:

• Validation constructs to allow the browser to do more checking before the form is submitted. New attributes include required, min, and max.
• DOM support for validity, with a validity attribute for form elements, and a new invalid event.
• Control over auto-completion for form elements, allowing document authors to indicate whether the browser should remember field values and offer to autocomplete them. Predefined values can be passed with the list attribute.
• An autofocus attribute to indicate which form element should receive input focus when the document is loaded.
• An inputmode attribute that allows the hinting of appropriate language input modes for text-holding form elements.
• File upload control improvements, including specifying the expected file type and limits on file size.
• Repetition of templated form elements.
• New types of input controls: datetime, number, range, email, and url. Addition of patterns for restricting input values.

Web Forms is a more consistent specification than HTML5, and is already finding some implementation:

• Beta releases of Opera 9 include Web Forms 2.0 support
• An open-source Web Forms project has a DHTML+Behaviors implementation for Internet Explorer

The W3C's answer to the next generation of forms is XForms (see Resources). XForms differs from Web Forms 2.0 in that it develops a new model of browser-server interaction, based on passing XML documents. By contrast, Web Forms 2.0 is an incremental update to the existing form models intended to make current browser forms more usable. The two specifications address different needs, though obviously share some commonality. In the words of the Web Forms specification:

[T]his specification attempts t add some of the functionality of XForms with a minimum impact on the existing, widely implemented forms model. Where appropriate, backwards compatibility, ease of authoring, and ease of implementation have been given priority over theoretical purity.

Other implementations

canvas is the main WHATWG feature with browser implementation. The rest of HTML5 is still at an early stage, and may never be implemented in its entirety.

However, the Web Applications and Web Forms specifications are taking on a new significance that probably wasn't anticipated when they first took shape. In recent months, several full-featured projects for developing user interface toolkits for Web applications have emerged. These implementations use HTML plus JavaScript technology, or Flash. Many of them might well take the obvious view that it is pointless to reinvent the wheel, and look to aspects of WHATWG specifications to standardize, for example, their form implementations.

Conclusion

The Web Forms 2.0 specification, by virtue of the obvious need and the completeness of the specification, stands a good chance of receiving implementation and making its way into an accepted standard. Indeed, Web Forms 2.0 has been submitted to the W3C for comment, having the effect of being a position statement and building block from the WHATWG collaborators.

However, it is difficult to glean a coherent view of the future of HTML from the WHATWG specifications alone. Some parts merely describe current innovations -- XMLHttpRequest, canvas -- while others seem vague and lack the same drive from implementers. Additionally, motivation for HTML5 is mainly for desktop, application-centric, use. A great deal of HTML is now found on non-PC devices, and that is in need of direction too.

Some of the richer ideas specified in HTML5 might now be made obsolete by the rise of Ajax-based browser interface toolkits. Why should developers be content with the restricted set of widgets specified in a document when they have an extensible toolkit to play with? It might well be that richer Web interfaces are standardized more by the market than by committee.

I'm glad to see progress made in describing commonly-implemented, but as-yet-unstandardized, technologies such as canvas and XMLHttpRequest, and hope that this will promote the interoperability of these important features. To move browser technology forward itself, HTML5 needs more clarity, and would benefit from being divided into three specifications, covering available now, available soon, and imagineering features.