Archive for May, 2008

Using Open Virtual Platforms to build, simulate and debug multiprocessor SoCs

Thursday, May 22nd, 2008

Duncan Graham, EDA Tech Forum Article, May 22nd 2008

The Open Virtual Platforms (OVP) initiative aims to help resolve the difficulties that arise today when modeling multicore systems-on-chip (SoC) so that designers can perform early and timely test of the embedded software that will run on the end devices.

As architects continue to add more cores to meet hardware design goals, the complexity of embedded software continues to increase exponentially because of factors such as amplified software concurrency and shared on-chip resource bottlenecks.

The OVP-based platform enables early software test through powerful simulations that execute at hundreds of MIPS, that are aimed specifically at the challenge posed by multicore, and that incorporate appropriate application programming interfaces (APIs) for the modeling of processors, components and platforms.

This paper reviews the construction of a multicore SoC platform, describes how to…

[To read the article go here]

Why today’s virtual platforms aren’t the answer

Friday, May 2nd, 2008

By Larry Lapides, Imperas May/02/08

We’ve been hearing for a while now that virtual platforms are the answer to system-on-chip (SoC) embedded software development problems. But, what can yesterday’s virtual platforms –– hardware virtual platforms that run at 20 MIPS top speed and cannot handle multicore architectures without slowing down another 10X –– do for embedded software development?

If these hardware virtual platforms were the answer to software development problems, companies providing this technology would be doing quite well. But this technology has failed to address the real needs of end users. Why hasn’t the technology lived up to its potential? Is it due to lack of speed and model interoperability, or insufficient infrastructure to tackle growing system-on-chip (SoC) complexity, or proprietary languages? Let’s include SystemC in the list of proprietary languages, because language “flexibility” coupled with a lack of results from SystemC committees has resulted in different flavors of SystemC for each and every user.

SoC embedded software development teams want to know how they can…

[For more, read the article here, or if it is not there, download a copy here]