Donald Cramb, Director of the Consulting Services Division, EVE
Donald Cramb is director of the Consulting Services Division of EVE-USA in San Jose, Calif., and is responsible for customer services, applications and design solutions to support specific customer requests. Previously, he was a partner at ArchSilc Design Automation, a company focused on … More »
April 17th, 2012 by Donald Cramb, Director of the Consulting Services Division, EVE
Recently, I’ve started to see an interesting trend cropping up in SoC development. Companies and teams are adopting or “inheriting” the emulation platform of their vendor, partner, or customer to accelerate the SoC realization effort.
Adopting a common emulation platform allows multiple organizations to share data and replicate development environments. Emulation tests for a critical block from an IP vendor can be replicated in-house, and later used as a golden reference model for verification at the system level. Leveraging a common emulation platform and use model enables partners, vendors, and customers to share a high-performance software development environment. Integration testing, along with driver and application software development can occur at multiple sites in parallel prior to tapeout.
Although there are many potential benefits to using a common emulation platform, there are also many potential issues. Failure to address these issues can result in increased project delays and costs, effectively erasing the advantages of using a common platform.
The first potential issue to be addressed is the choice of emulator. In many cases, the choice of the emulation platform to be shared is imposed by one company over another. For example, an important customer might demand that a vendor verifies its IP using the same emulator.
Alternatively, if both parties have an equal say in the choice of emulation platform, there are other potential difficulties. Each company may have a centralized IT or CAD team that demands its own evaluation, and each could have differing criteria for success. Each company may have differing budgets for the project and differing procurement policies, creating further complications in purchasing a common platform.
Once the common emulation platform has been agreed upon and acquired by both parties, there are still logistical and security issues that must be jointly managed. EDA vendors frequently release software patches, but IT and CAD teams can have vastly different procedures and schedules for implementing these updates. Losing software synchronization between emulation platforms can result in mismatched behavior and wasted debug cycles.
Data protection is another critical aspect to successful emulation inheritance. If blocks from multiple companies are being integrated together, those parties will need access to the source code for compilation into the emulator, which would require mutual non-disclosure agreements and involvement from legal departments. If the pre-compiled emulation model is being shared, then some form of secured network or cloud access is required, again requiring IT or CAD assistance.
Once all of these setup issues have been dealt with, each group can run their tests on the common platform—but what happens when they hit a bug? Joint debugging again presents potential issues with IT and data security. Will IT let the design team open a VNC session with a third party? Should a pre-compiled emulation model include visibility into the design for the customer? Who will be responsible for supporting the third-party user? The potential benefits of using an inherited emulation platform makes it a worthwhile endeavor to find the answers to these questions before a design team commits.