A Viewpoint by Larry Lapides, Vice President of Sales, Imperas Ltd.

I have a soft spot in my heart for plays and poetry.  I couldn’t have made it through high school English classes without these forms of expression.

Moby Dick?  Have you ever read past “Call me Ishmael?”  There are loads of pages where nothing happens.  Give me e. e. cummings poetry any day.  Or Shakespeare, or Oscar Wilde.  The forms of these genres force playwrights and poets to be concise and precise with their thinking.

Writing poetry is actually a good exercise in that regard, forcing one to focus.  So, let’s apply it to multicore, the topic of the day in the SoC world, just for grins:

Silicon breakthrough:
Multicore SoC, but …
software the issue

Haiku is particularly challenging, with a formal structure of 5-7-5 syllables per line.  But still, you get the point, I hope, as multicore SoCs have been around for a while now.

Software is the issue for these SoCs.  It’s great that fabs keep pushing the silicon technology, enabling more and more functionality on a chip.  Additional processor cores are added continually to the SoCs, but as dedicated resources for specific features.  This isn’t really multicore processing; it’s just multiple processor cores on a chip.

Lest you think that poetry is all seriousness, there’s the limerick:  five lines, inherently humorous due to the vast library of humorous limericks that we’ve read.  (And if you haven’t, I highly recommend Isaac Asimov’s Limericks:  Too Gross as a good place to start.)

There once was a hot semi, fabless,
Thought software the beast from Loch Ness
Turned a great chip,
Multicore, the whole bit
No software? No one bought it, they confess

Back in the real world, semiconductor developers have been building multicore chips for a number of years.  But again, what has been done with them?  One dedicated application per core, which does not take advantage of multicore architecture benefits — namely, higher bandwidth due to more processing power, and lower power consumption due to running processors at lower speeds.

Why haven’t systems been taking advantage of the benefits of multicore?  To paraphrase Shakespeare, from the…

[To read the full article at DACeZine, go here]

A Viewpoint by Larry Lapides, Imperas

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 make the software verification process more efficient, more complete, more predictable and more measurable. This is the challenge platform vendors should be addressing. The answer is that verification, debug and analysis combined with a verification methodology, and built specifically for embedded software development, can do that.

This focus on verification is…

[To read the full article, please visit SCDsource here]