An interesting article in the Embedded Technology Journal by Bryon Moyer

It better be fast.

Whatever it is, whatever it does, it’s all good as long as it’s fast.

We live for speed in our supercharged world.

…

Software simulation is not really new; instruction-set simulators (ISSs) have been around forever. But we’ve gone from cross-development between platforms to building software for traditional (meaning PC-board-based) embedded systems to development of software for single-chip embedded systems.

The costs of getting it wrong when developing across desktop platforms are in time and annoyance. Similarly with traditional embedded systems; you might have to do a PC-board spin, but, while not desirable, it’s not a deal-killer.

…

Maybe I’ve been asleep for a while as the world passed me by, but something slapped me upside the head a couple weeks ago at DAC when talking with Imperas. They have just announced that their software simulation speed has improved by 50%. Now… that’s a pretty good speedup by typical measures, but, then again, it’s yet another press release with yet another performance improvement. One of a dozen such releases that get issued on any given month. A good thing, to be sure, but, unless it affects you specifically, it’s something of a yawner.

Until you realized one thing: the simulator is running faster than the actual system will run.

Maybe much faster. They’re claiming that their OVPsim provides ISS speeds of 2 GIPS.

Perhaps this …

To read the full article please visit the Techfocus media site here.

An interesting contributed blog on the changes in the virtual platform space by John Cooley of ESNUG and DeepChip

John Cooley, though focused on the EDA simulation, synthesis, and RTL areas collected some information regarding the recent acquisitions.

There are contributions from

• Jay Vleeschhouwer of Ticonderoga Securities
• Simon Davidmann of Imperas
• Bill Neifert of Carbon
• Brett Cline of Forte Design
• and several annonymous contributors

[To read the full article, please visit the blog on deepchip.com here]

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]

We need to develop tools for those brave enough to develop multicore systems.

A guest column by By Larry Lapides, Imperas Ltd.

In a column a year ago (www.embedded.com/201800330), Bernie Cole compared the state of multicore software tools to the Charge of the Light Brigade: current tools “are as outdated and useless as the sabers, one-shot pistols, and horses of the ill-fated 600 were against cannon, repeating rifles, and mechanized equipment they rode against.”

While it’s not a bad comparison, perhaps a better analogy may be navigating by sea. First, we figured out that the world was round. Then we developed tools to measure longitude to actually figure out where we had come from, where we were, and where we were going. Prior to that, sailors mostly kept within sight of shore or risked getting lost and foundering on some unexpected rocky shore. Those famous sailors, such as Columbus, Magellan, and Cook who successfully navigated large distances over open water, owed their success to luck and pluck more than knowing with certainty where they were and where they were going. And for all the successes we learned about in our history books, there were many more navigational failures.

In addition to death and human suffering due to scurvy, as Dava Sobel points out in her book Longitude, ” the global ignorance of longitude wreaked economic havoc on the grandest scale.” Ships crossing the oceans were confined to a few well-known passages, well known by the pirates and navies in addition to the merchants.

Similarly with multicore, designers have kept close to shore, adding more processing power only to use it for a new, specified application. No sharing of those…

[To read the full article at Embedded.com, please visit here]