Home > Community > Blogs > Functional Verification > eda360 is more than design ip plus software drivers
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Functional Verification blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

EDA360 Is More Than Design IP Plus Software Drivers

Comments(0)Filed under: Functional Verification, VIP, EDA360, IP, Phoenix, Sand, Virtual Chips, inSilicon

I checked my Linked-In messages the other day and saw a survey by Girish Patil with the provocative question "Is EDA360 the same experiment that Phoenix Technology tried a decade ago with the acquisition of Virtual Chips and Sand Micro?" Well, that was an interesting link between my past professional life and my role at Cadence today.

Phoenix Technologies was -- and remains -- a leading provider of BIOS for PC systems. In the mid-90s, the company had expanded into related software areas, including some types of drivers and embedded applications. Phoenix expanded further by acquiring Virtual Chips in 1996 and Sand Microelectronics two years later. Both companies provided synthesizable RTL cores for such standard interfaces as PCI, USB, and IEEE 1394, along with related verification IP.

A lot of people were puzzled by this move, but as the VP of engineering at Virtual Chips I was deeply involved in the transaction and subsequent actitivies as we merged together. I believed then -- and I still believe -- that Phoenix displayed a good example of thinking outside the box in these two acquisitions. Rather than view themselves as restricted by their current products, a few executives saw that their core expertise was in developing software that lay very close to the hardware.

Conversely, we in the cores business were developing hardware that lay very close to software, and as we worked on more complex protocols we realized that we would eventually have to get into the driver business or partner with software providers in order to provide a complete solution. Thus, the seemingly odd fit was driven by the vision of interface cores and accompanying drivers that would provide unique value when paired together. This vision was never fully realized for lots of reasons I won't go into here, and Phoenix spun the cores group out as inSilicon in 1999.

So why this history lesson? Girish is quite correct that one important aspect of the EDA360 vision is the tight link between design IP, drivers, and other "bare-metal" software. Interface protocols have grown incredibly more complex in the last decade, so hardware-software co-development and co-verification is a necessity. I believe that the Phoenix-Virtual Chips vision was valid, but ahead of its time.

However, it is most certainly not the case that EDA360 is "the same" vision. EDA 360 is much bigger, encompassing full-chip and full-system development, increased focus on IP integration, the role of application software, and more. So I voted "no" to the Linked-In poll, but the question sure prompted some memories for me!

Tom A.

The truth is out there...sometimes it's in a blog. 

 

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.