View this week's entry ad »
Part Inventory
powered by:
Part Finder
Go
powered by:
  • Quick Poll
What Social Networking site do you use the most?



VOTE VIEW RESULTS
Previous Polls
Hotspots » Analog & Mixed SignalPowerEmbedded

Premium Content

Editors' Picks

Featured Industry Resources

Reuse-Driven Methods Can Help Optimize Systems

New Codesign Techniques Are Needed To Allow Virtual-Component-Based Hardware And Software System Design

By Contributing Author

June 22, 1998

Print
Reprints Comment Subscribe

The escalating complexity of electronic-product design is focusing attention on significant gaps in the methodology and technology for design of complex system-chips and chip sets. New methods and tools are needed to help designers confirm critical architectural decisions, such as the hardware and software partitioning of system functionality early in the design of both first-generation and derivative products. This capability will allow system companies and silicon vendors to optimize product specifications, shorten development cycles, and capitalize on the increased capabilities offered by multimillion gate integrated circuits.

The need for new techniques and tools for the design of consumer products is heightened by the significant and rapid changes in the marketplace. Some of these changes are:

  • Product design times and lifetimes are not only shrinking rapidly, but the market windows defining the success of a product also have become fixed in time. If your product is not on the shelves by Christmas, you probably should not have started the design in the first place.
  • As a direct result of this, product iterations due to implementation errors are not allowed because failure to hit market windows usually equals product death.
  • System companies are increasingly focused on their core technological and market competence and are, therefore, opening up to bringing in complementary expertise.
  • Product consumerization emphasizes the creation of product derivatives, and the addition of small amounts of customization to differentiate products.
  • Products must conform to complex interoperability standards, either de jure (for example, type approval in communications markets) or de facto (by cable companies in the set-top box market).

The impact of these changes on design methodology is profound:

  • System-level decisions made very early in the design cycle determine the cost, performance and viability of the product.
  • Creating a "virtual prototype" of the product is vital to guarantee acceptance at type approval or product qualification.
  • Engineers must evaluate, combine, integrate, and verify pre-designed virtual components*often referred to as intellectual property*in order to meet design deadlines. Virtual components are needed in both the software and hardware domain.

The broad need for a new approach to both hardware (HW) and software (SW) codesign is evidenced by the wide range of electronic products that use embedded controllers. In consumer electronics these include CD players, single-chip PCs, and video games. In telecommunications, they are telephone switches, cellular phones, and high-speed modems. Multimedia applications are in digital cameras and set-top boxes. Automotive uses include engine controllers and anti-lock brake controllers

The Current Approach
Current approaches to virtual-component-based design are of limited use for complex system-chip architectures. They address mainly the hardware aspects of design, and they rely on highly detailed models, which are not suitable for rapid trade-off analysis at the system level.

For example, at the register transfer level (RTL)—the level at which many so-called "soft" virtual components are defined—architectures must be fully articulated or elaborated, with all signals instantiated on all blocks, all block pins defined, and in most cases, a full on-chip clocking and test scheme defined. Furthermore, designs at RTL have completely defined communications mechanisms.

This makes it very hard to change the on-chip control structures and communications mechanisms between blocks. Therefore, it is very risky at this stage to apply an architectural change, both because such a change will be very time-consuming, and because it might jeopardize the project schedule. When unavoidable, an RTL architectural change can only be applied by "ripping-up" and "re-routing" of the communications mechanisms, and rewiring of any new or substituted functional blocks to the communications structures.

A related effect is that it is difficult to "drop-in" or substitute a virtual component with another choice. Because dropping in a new microcontroller core requires detailed "rip-up" and "re-route" to link the block to the communications structure, it is extremely hard to effectively explore virtual component alternatives.

Furthermore, designs captured in RTL code mix both behavioral and architectural design together. Often, the only model of a virtual component block function is the synthesizable RTL code, which represents the implementation of the function. Similarly, the only model of a SW function may be the C or assembly language implementation of the function. This "intertwining" of behavior and architectural components together makes it extremely difficult to evolve the behavior of the design and its architectural implementation separately.

Finally, verification of embedded HW-SW designs in RTL requires nearly-complete hardware design and nearly-complete software code for the hardware interface (drivers), part of the RTOS, and the layered application(s) if the behavior of the system is to be verified.

Coverification at this level is clearly not fast enough to verify complete system application behavior in an HDL/C simulation environment. If major application problems are found during cosimulation, a time-consuming and tedious redesign process is required to repair the design. Re-partitioning is also difficult because the communications infrastructure will require detailed redesign. In addition, substitutions to the programmable architectural virtual components like new processors, or controllers, or custom hardware accelerators for part of the software implementation require significant changes to the application software.

The net result of today's limited methodology is that it is almost impossible to effectively explore the behavior and architecture as efficiently as required for modern system-chip designs. As a result, system partitioning and design is often done with manual, back-of-the-envelope techniques, and carries an inherent risk that major problems will emerge during downstream implementation and integration.

Providing solutions that overcome the major limitations in today's methodology and tools requires moving up to higher levels of design abstraction*to the "architectural" and "behavioral" levels. In this environment, the system designer first captures and verifies the functional behavior of the entire system at a pure behavioral level. This step relies heavily on the reuse of existing behavioral libraries and algorithmic fragments (see the figure).

Average ( Ratings):
Filed Under:

Check for price and availability on Source ESB:

Go
powered by  

Related Products

You must log on before posting a comment.

Are you a new visitor? Register Now

Acceptable Use Policy

Sponsored Links