Emulation makes the What to See List

The analysts at Gary Smith EDA produce an annual What To See List for DAC and I quickly noticed that all three major EDA vendors were included on the list for the specific category of emulation. The big problem that emulation addresses is the ability to run in hardware an early version of your SoC so that software developers can get access and run lots of code or boot an OS, plus the hardware team can more quickly verify and debug the performance of their system to see that it will meet all specifications prior to first silicon. On the Wednesday at DAC I was able to watch a booth discussion at Mentor where Samsung, ARM and Starblaze engineers talked about their emulation experiences, moderated by Lauro Rizzatti.

The three panelists were:

• Rob Kaye, ARM
• Nasr Ullah, Samsung
• Bruce Cheng, Starblaze

Q&A

Q: There is In-Circuit Emulation mode and Virtual deployment mode for emulation. Which emulation use model have you tried and why?

A: Samsung – we are using emulation in three areas: Performance, are the projections correct? Did our implementation meet the requirements? Can we add a late feature? Our team needs to verify that the quality of service is sufficient so that they can make a phone call along with streaming video on a mobile device. Emulation helps us with meeting the power constraints, knowing that the chip runs cool enough and that the current levels fit the battery.

A: Starblaze – we need to run our real application firmware on the SSD controller. We have a PCIe connection in order to match the speed of our host. The NAND interface is affected by aging. We’re using 100% virtual peripherals with the VirtuaLAB toolkit, where PCIe is virtual and a simulator connects to the emulator through DPI (Direct Programming Interface).

The PCIe PHY in our ASIC is modeled with a virtual PCIe PHY in emulation. On the NAND interface we use fast memory models running on the host, making simulation fast. This is a pure virtual approach and allows us to change configurations, or system performance

A: ARM – both our IP validation and IP development teams use emulation. Our SW group does early development with virtual prototypes, the move key parts into emulation to run SW at a fully-timed level. Software-driven validation is another approach used where virtual and emulation combine to allow C code to run on the CPU model while debugging drivers and we develop validation flows for parts on the emulator.

Related blog – Listening to Veloce Customers: Emulation is Thriving

Q: Describe a verification challenge and how emulation came to the rescue.

A: Samsung – we had our design running in emulation, after four days of running Android and apps the performance slowly declined. Emulation uncovered a counter bug where the counter didn’t reset. Simulation would never have found that bug.

A: Starblaze – an application in our ASIC would run for five days then crash. We ran the modified application in our emulator to trace and debug the problem. Prototypes have been built with FPGAs, however they provide little visibility inside to help with debug and recompile times can be 10 hours or longer, so with emulation we have more convenient debugging.

A: ARM – running GPU benchmarks is sped up with emulation.

Q: Any recommendations to emulation users or vendors?

A: Samsung – start your emulation as early as possible. Have verification engineers start early with emulation in order to find and fix more issues.

A: Starblaze – emulation vendors need to make them run faster, because we’re not as fast as the ASIC yet. Keep improving and adding debug tools like VirtuaLAB PCIe. Would love a NAND or CPU analyzer.

A: ARM – we want context switching between virtual and emulator and then run to some point in the simulator or emulator.

Related blog – The Rise of Transaction-Based Emulation

Q: Will emulation be here in five years and will it be different?

A: Samsung – I like what ARM asked about context switching. We can run high-level simulation and mix/match it with emulation. We need the ability to switch between lower design details and the highest abstraction layer.

A: Starblaze – Our customers use a behavioral model of the chip to run firmware, it’s an SSD simulator. We want to link the SSD simulator to the emulator and be able to switch context. Verification is moving to higher levels of abstraction, so emulation has to follow that trend.

A: ARM – we see emulation being used in SW/HW integration for SW regression testing. Embedded software has grown in size, even Android uses about 20 billion instructions. Emulation lets us run lots of these tests of our software for both function and performance. More of our software development teams will use emulation in the future.

Related blog – Mentor Plays for Keeps in Emulation

Summary
After the panel questions concluded I did ask my own question, “Are you using other vendor emulators?”

Both Samsung and ARM replied yes, while Starblaze only uses the Mentor emulator.

Perhaps it is time for your group to consider using an emulator on the next SoC project and start getting the same kind of benefits that ARM, Samsung and Starblaze reported seeing in their design and verification flows.