I don’t have any data to prove this, but it is my conjecture that very few of the people doing marketing in high tech have any formal marketing training. I’m not even saying whether this is a good or bad thing (you could argue it either way). But the result is that certain basic lessons get learned over and over.

For example, we get it drilled through our heads repeatedly: people don’t care about features; they want the benefits that accrue from those features. We remind ourselves of this from time to time, nodding sagely, committing to a new and better round of marketing efforts.

And then we go write about features.

Or perhaps we describe the benefits in terms so vague that you have to ask for features to get any useful information: “Reduces time to market.” Um… OK, perhaps a tad more specific?

And then a fresh round of engineers that like the promise of talking to real people and the glamour of travel <snicker> move into marketing seats. And they learn all over again. Eventually. Perhaps when a consultant points out for the umpteenth time that they’re talking only about features, not benefits.

Again, I’m not being a hater here; I was that guy once upon a time.

The features/bennies thing may be the most prominent marketing concept that requires us to get a periodic cattle-prodding to keep us on track, but there’s another one not far behind: technology doesn’t matter; only solutions do.

If you don’t provide a solution that solves a problem, then no one cares what your technology is. At least, that’s the official line. In reality, lots of geeky engineers will revel in your technology’s geeky goodness. They may write about it, blog about it, tweet it, dink with it on weekends, paying homage in all kinds of wonderful ways. There’s only one thing they won’t do if you don’t solve a real problem: pay for it.

And that’s kinda where the funders start shifting in their seats a bit.

There’s one space in EDA where this has been a perennial problem: formal analysis. That’s because formal analysis is a technique, a technology; it’s not a solution. It can be used to solve problems, but the thing is that it’s so specialized that several companies have been formed based on their ability to do it. But the sale has almost always put the technology at least at the same level as the solution because the company identity is rooted in the technology.

In fact, I recently saw a call for a discussion on figuring out new places that formal analysis might be useful. Now, there’s nothing wrong with that discussion, and it could turn up some good ideas. But you have to admit it’s kind of backwards: it’s the dreaded solution-in-search-of-a-problem. I’ve personally lived that life too many times, with customers –er, actually, “prospects” – nodding their heads at the skill and expertise that the team has clearly demonstrated, asserting that the product will be great… for someone… just not them.

Even when the technology does indeed solve a problem, focusing on the technology tends to muddy the marketing message. Especially when the product offering is structured around the underlying technology rather than the problems it solves. It gets harder to say when you should get what module or which precious metal version you should purchase.

Jasper has apparently come to the same conclusion: they recently announced new products that move from an older technology-driven arrangement to one that now focuses squarely on solutions and specific tasks. That’s one of the tough things about formal: it gets sprinkled here and there into a verification program to address particularly knotty problems. But, like the dollop of sour cream that may finish a dish with flair, you can’t make an entire meal out of it. So you end up having to list the 50 ways you can use it.

They haven’t quite gone as far as Real Intent, which has completely separate products for different jobs. Jasper still has one basic product architecture, but the modules that fit into it are driven specifically at well-defined tasks.

It starts with their JasperGold-INT, which is the GUI that holds it all together. From there, they offer multiple modules – which they call “apps.”

• There’s an app for verifying end-to-end properties (as distinct from low-level assertions). These are properties that tie into the high-level architecture in terms of inputs and outputs, with the internal low-level stuff remaining transparent.
• There’s an app for determining connectivity equivalence, whether structural, Boolean, or temporal.
• There’s an app for checking X-propagation. The concept of the unknown value “X” has its place, but it doesn’t really exist in the wild. It’s actually a 1 or a 0; you just don’t know which. And, as they tell the story, simulation can’t always give an accurate picture of how uninitialized values might work their way through the circuit, possibly wreaking mischief along the way. So their app provides more thorough coverage.
• There’s an app intended to assist designers writing RTL. It allows them to check their code against high-level behavioral expectations, running different scenarios and doing what-if analysis, all without a testbench.
• There’s an app for doing high-level architectural work. They describe it as essentially building an executable spec to verify high-level protocols in a manner that will create a baseline for RTL verification once development starts. Their focus is on complex protocols like cache coherency and on looking for nasty problems like deadlocks.
• There’s an app specifically for verifying control and status registers.

They also say they have about six more apps in the pipeline, including one for synthesizing properties, one for assisting with RTL debug, and “intelligent proof kits,” which appear to me to be analogous to “formal IP” that captures the interface behaviors of well-known protocols for use in verifying implementations of those protocols.

From what I can tell, the underlying technology hasn’t changed (other than the usual efforts to make things smaller and faster). What’s changed is the wrapping of the technology into flows and methodologies – supported by context-relevant GUIs – that customize the application of the technology for a specific task. Rather than having to study your problem to figure out which technology bits you need to purchase, it says “if you want to do this, then this module provides everything you need to accomplish that goal.”

It’s not an easy thing to redefine a product portfolio along lines that are more or less orthogonal to how it’s been done in the past. It will be interesting to see whether this results in a higher level of uptake than they were able to manage in the past. If so, it can provide a useful case study for all those bright-eyed, eager engineers-turning-marketeers that have no idea what they’re in for.

More info:

JasperGold Apps