In my last blog post,
I described the Cadence Verification Alliance (VA) and how it provides value to
customers, VA members, and us. I've been pleasantly surprised at the readership
numbers given that this is what radio commentator Paul Harvey used to call
"shop talk" when he discussed his own industry. I believe it's important for
EDA users to know that their vendors and ecosystem partners put a great deal of
effort into working together. We don't do this work just to sit around and sing
"Kumbaya" with our competitors -- we do it because our customers need us to do it. The truth is that very few customers have a single-vendor
EDA environment. For any number of technical or business reasons they have
tools, design IP, verification IP, and libraries from multiple sources. Users
look to the EDA industry to reduce their integration effort by validating that
products from different vendors interoperate and work well together. Virtually
all EDA vendors have agreements with complementary suppliers as well as
competitors, often exchanging tools so that each pair of products linked together
can be validated by both vendors.
At Cadence, our EDA interoperability program is called
Connections, and it's one of the largest such alliances in the industry. We
have roughly 80 member
companies today; that number moves up and down a bit over time as existing
companies merge or fail and as new startups emerge. Scan through the list, and
you'll see that we are quite inclusive. Many Connections members have products
that are directly competitive with Cadence offerings, but that is not a
fundamental barrier to joining the program. As noted above, we do what our customers
need us to do.
The most important criterion for joining Connections is
identification of mutual customers who are asking for the interoperability testing
possible only when two vendors exchange tools. Sure, I would love it if every
one of our simulation customers used only Cadence solutions. But that's not
reality; we have some e customers who run Specman with
other simulators, some mixed-signal customers who run our digital simulator
with someone else's analog simulator, and vice-versa. We always try to offer a
better combined solution ourselves, but that will never satisfy everyone.
Of course, there are also some Connections members whose
products are mostly or entirely complementary with ours. In my series on
automatic assertions I mentioned NextOp
and Zocalo
as examples of vendors in this space, and we recently presented a joint Webinar
with Duolog.
All three companies are in Connections and are fine examples of partners with
complementary offerings and with whom we do joint marketing activities. If we
can offer customers a broader solution by working together with another vendor,
we're glad to do so.
If you haven't read about EDA alliances before, you may be
surprised that we have so many of each other's tools. The agreements are
carefully written so that we don't reverse-engineer our competitor's products
or otherwise take unfair advantage of having them. In my dozen years in EDA, I
can recall only one incident in which a partner blatantly violated such an
agreement by benchmarking my company's tool against their own competitive
offering. That's the exception; these alliances work because we focus on
interoperability testing (only) for the benefit of our mutual customers.
So now I've shared the "secrets" of both the Verification
Alliance and the Connections Program. You can read about a closely related
program, the System
Realization Alliance, from my colleague Steve Brown and see the complete
scope of our ecosystem activities on our Web site. If you
have any questions or wish to suggest additional partners or ideas for
alliances, please comment. As you can imagine, we bloggers are a lot happier
when we see a few comments rolling in, so don't be shy!
Tom A.
The truth is out there...sometimes
it's in a blog.