EETimes article from STMicroelectronics typifies industry’s EDA360 shift; foretells the future of System Realization tools

Last month, EETimes published an article titled “Using simulation and emulation together to create complex SoCs,” written by Laurent Ducousso who is the IP Verification Manager for STMicroelectronics’ Home Entertainment Group. Ducousso’s article details the changes STMicroelectronics has made to its EDA processes to accommodate the increasing complexity of the company’s home-entertainment SoCs. Ducousso starts his article by writing:

“Two trends are conspiring to make complex modern chip development more and more difficult: the increasing amount of software content required for what are essentially monolithic embedded systems, and ever-shortening market windows, especially for consumer-oriented products. … But until you can test an overall system, including the software, there’s only so much you can do.”

This opening paragraph underscores the rise of the apps-driven SoC. Increasingly, Ducousso writes, “…modern chips are more or less the embedded systems of yesterday implemented in a single piece of silicon, and software is picking up more and more of the operational burden. Olden-day chips did everything through dedicated logic or analog circuitry; systems-on-chip (SoCs) get around this by including one or more processors for executing software. …increasingly, the silicon is acting simply as a platform for executing (and maybe accelerating) software, with additional pieces for getting the necessary signals to and from the processors.”

Because silicon is increasingly becoming a software execution platform, software-development considerations must now play a much larger role in the overall development process. As Ducousso says, “olden-day” chips dedicated far more circuitry to hard-wired digital and analog functions because processors were too big and too slow to use for most on-chip tasks. That’s no longer true. Now, we’re seeing a real flowering in the use of processors for all kinds of on-chip tasks. Communications and graphics blocks, for example, are rapidly evolving into software-driven subsystems on chip. This is the age of the multiple-processor SoC (MPSoC).

Why?

Ducousso’s answer is succinct and elegant:

“One huge benefit of using software instead of hardware is flexibility. As bugs need to be fixed or as additional features are desired, swapping old code for new can bring these changes about without a single mask change.”

Software-enabled flexibility helps system developers in several ways. It allows rapid prototyping of functions using TLM-based simulation at the earliest stages of the project. It permits bugs to be tackled and fixed without major hardware redesign and the costs associated with such redesigns. It permits the addition of new features—and many such new features are now required on an ongoing basis to keep a product design alive. And finally, system designers have discovered that processors’ multitasking and task-switching abilities can actually save hardware relative to hard-wired function blocks. (As Ducousso says, “…a processor uses much less silicon than would be required for the sum total of the software functions if they were rendered in hardware.”

To tackle this new world of apps-driven system and SoC design, STMicroelectronics has discovered that there are two critical elements needed from the associated development tools. Ducousso writes: “…we need to be able to develop software as early as possible, and we require smooth transitions between development phases as our ideas are realized ultimately on a chip.”

So STMicroelectronics needs platforms that support early system-architecture exploration and early software development. The company also needs System Realization flows that permit “smooth transitions” from one development phase to the next. These are clearly some of the most important characteristics needed for future System Realization tools.

Ducousso details the evolved System Realization flow STMicroelectronics currently uses:

“We manage all of this starting with our original architectural ideas, which can be modeled at the TLM level in order to experiment with various structures and configurations. An emulator system like EVE’s ZeBu platform has a role here for pieces of hardware IP that don’t come with a TLM model. Rather than suffering the slower speed of simulating hardware, such IP can be synthesized into the emulator, where, in this case, the emulator acts as a simulation accelerator. The high-level high-speed simulation afforded by TLM can now proceed apace without being overly burdened by the blocks having no TLM model, while still including those blocks in the simulations.”

In a different part of the article, Ducousso provides a succinct overview of STMicroelectronics’ System Realization needs:

“…we have invested in a process that attempts to minimize rework, focusing instead on gradual refinement of early models into working silicon. The process provides an example of how TLM technology, virtual platforms, and a good emulator make this possible.”

That’s the shape of things to come in System Realization.

Tip of the hat to Steve Brown at Cadence for bringing this article to EDA360 Insider’s attention.

About sleibson2

EDA360 Evangelist and Marketing Director at Cadence Design Systems (blog at https://eda360insider.wordpress.com/)
This entry was posted in EDA360, System Realization. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s