So I hear you’re going to try to build an SoC. Good luck; you’ve got lots of work ahead.

First you have to come up with an architecture. Then you need to design all of the blocks yourself. Then you need to write all of the software that’s going to run on this beastie. By yourself.

That’s the easy part. When you’re done with that, you have to verify the whole thing. Yes, you have to design everything and finish it all before you can start your verification. I just hope you don’t make any mistakes at the early architecture level.

So, okay then, off you go like a good lad.

…

…

OK, that wasn’t nice sending the poor newbs off on a snipe-hunt like that. It’s fine; they’ll be back. (And mad; they’ll get over it.)

So… meanwhile, back here in the real world, each of those things that needs doing above will, of course, be verified as we go. Not waiting until the end. However, “verified” can mean a lot of things, depending on whether you’re an architect, a hardware designer, or a software designer.

As an architect, you’re exploring. You’re trying to figure out how best to optimize the performance of computing engines and communications and storage resources. You want to make sure that cores aren’t tripping over each other when executing low- or high-level software. That caches perform efficiently. And that your system interacts well with real-world data traffic, like files from external storage and high-demand internet traffic like streaming porn YouTube and Netflix and the like.

As a hardware designer, you need to make sure your hardware functions correctly, but also that it meets speed, power, and area requirements.

And as a software writer, you need to prove your functionality (and that of your software) along with performance.

You want to do these things as early as possible. Specifically NOT right at the end. (In case it wasn’t clear, that was a ruse.) Problem is, there’s lots of the system that’s not yet in place, and your unfinished bit needs to work with all the other unfinished bits during verification.

Actually, if you’re an architect, you don’t even have a system defined yet – coming up with one is your job. Lucky you.

Fortunately, we live in the age of technology. That means we can replace the real with the virtual. We’re all about virtual these days. Heck, when I’m done here, I’ll be off to do some virtual shopping for a virtual pet for my virtual girlfriend. But enough about me; that’s not why you’re here.

What matters to us is virtual platforms. Or virtual prototypes. Or… wait, which is it, anyway? Carbon Design Systems’ Bill Neifert might step in here and say, “Exactly!” To understand that, first of all, as he notes, the word “platform” is hopelessly overloaded, meaning that it can mean everything and nothing at the same time. So he opts for “prototype.”

But this isn’t a story about simple semantics; it’s about that verification thing. In a virtual world. (Which can feel like it’s a few tequila shots short of virtual reality sometimes.) Which means models.

(No, not that kind of models, you troglodyte…)

Models for executing… stuff. Yeah, nothing new. We’ve had them forever, seems like. But they form the foundation of the news we’re discussing today. (Yes, yes – I will get to the point. Eventually. Consider this an homage to Family Guy if you must.)

Models are shortcuts. They’re ways of doing things without actually doing things. They’re the digital equivalent of looking busy. But in a useful way.

But because they’re shortcuts, they sometimes miss the nuance and detail of the longcut. That’s more or less the point; if you stopped to smell every flower along the way, it would take way too long to get where you’re going. So you tint the windows so you can’t really see the flowers that well and zoom on through.

Problem is, while there’s one, and only one, correct longcut, there can be many shortcuts – some shorter than others. Some might obscure all the flowers; others might let you stop to sniff the occasional marigold, but not the profusion of poppies.

Most models try to give the highest possible performance. But Carbon (capital C) started out sacrificing some performance in the interests of timing accuracy: cycle-accurate models. Of course, trying to build one of those by hand in C just by studying your RTL is a recipe for changing careers. Carbon approached it by literally converting the RTL into a cycle-accurate C model – so that it’s faster to create and correct by construction.

You can then plug these models together to create a system and run simulations in their SoC Designer Plus platform. (See? There’s that word again.)

But, of course, you might be interested in only one or two components in great detail; the others may be hooked in to provide realistic data sinks and sources. Cycle-accurate models do run somewhat slower than non-cycle-accurate, so you might want to speed up everything that doesn’t need cycle accuracy. Like with an ARM fast model.

So now you can mix cycle-accurate and high-level-behavioral models together. Actually, “now” isn’t a good word, since this capability has been around for a while. (Yeah, we haven’t gotten to the news yet. Patience, grasshopper…)

But building these systems out of models can still be time-consuming. So last year, Carbon Design Systems announced Carbon Performance Analysis Kits (CPAKs). The idea is to have a ready-to-go system pre-assembled for performance testing or benchmarking. You can pop some models out and others in, so it’s not a locked deal; it simply saves time. It also lets you simulate with realistic data traffic patterns. There are a number of them you can choose from, reflecting different processors and peripherals and end use cases.

Yeah, you read that right: last year. And this is this year, so…

So what they learned was that it was moderately difficult to sort through a list of CPAKs, ordered by name – potentially by cryptic name – in order to see if one met the searcher’s needs (or which of several might be the most appropriate). So – here we go, folks; actual news: They created and announced a separate portal for this called the Carbon System Exchange.

The CPAKs and the models you find in the CPAKs are, for the most part, created by Carbon’s partners. Carbon’s role is to handle the packaging and licensing (well, most licensing – using the Breker tools requires a license executed through Breker, for instance). And, of course, they provide the SoC Designer Plus tool and allow you to convert your own RTL into a C-level model that you can then use in the CPAK.

So there you have it. Why go through all that rambling? Cuz that’s what we do here. No, wait, scratch that: Because that’s how we explain why this is different from yet another IP exchange. The past is present. And all that.

Meanwhile, I wonder how those guys are doing on their SoC design… Oh, you’re back already? Come on, you can’t still be mad! You are? OK, I’ve got the perfect place for you to go relax in a peaceful setting while going on an adventure. See, there’s this graveyard right up the road…

More info:

Carbon System Exchange

(Top image credit: Rob Lavinsky)