Home > Community > Blogs > System Design and Verification > getting ready for esl with emulation
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 System Design and Verification blog (individual posts).


* 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: *

Getting Ready for ESL with Emulation!

Comments(0)Filed under: System Design and Verification, Acceleration, Emulation, ESL, low power, embedded software, Cadence, Gary Smith, System Development Suite, Virtual System Platform, Palladium XP, Verification Computing Platform, Schirrmeister, GSEDA, FPGA Based Prototyping, dynamic power analysis, low power optimization, System to Silicon Verification, Atrenta

Next week on Monday, August 19th, Gary Smith will run a webinar called "ESL - Are You Ready?" Atrenta's Mike Gianfagna, fellow co-blogger Jason Andrews, and I have had discussions with Gary since DAC in Austin about how the ESL flow has changed. One of the key new items is that hardware-assisted verification, especially emulation, has become the heartbeat of system design flows. Gary will give an interesting system design overview and update with Mike, Jason, and myself standing by for questions and discussion during the webinar.

You may remember that Gary introduced during DAC 2012 four different software virtual prototypes and two silicon virtual prototypes. They fit well into the schematic hardware / software design flow as illustrated in the graph below.

The different virtual prototypes are shown in the illustration, and Gary has described them as follows:

  • Software Virtual Prototype 1 (SWVP 1): The Architect's Workbench used by the architectural team for design formation and exploration, usually modeled in C/C++ or M (Mathwork's language). At this stage the microprocessors, foundation platforms, and some applications platforms are selected.
  • Silicon Virtual Prototype 1 (SVP 1): The design has started, hardware accelerators are added, transactional models are developed, and in-house platforms are designed.
  • Silicon Virtual Prototype 1 (SVP 2): Existing RTL blocks are inserted, System C blocks are synthesized, and the design is completed and verified. The "Golden Netlist" is the output of this phase. The two different types, SVP 1 and SVP 2, could be developed by the same team.
  • Software Virtual Prototype 2 (SWVP 2): Applications code is written on a higher level virtual prototype.
  • Software Virtual Prototype 3 (SWVP 3): Firmware is written and applications code is run on the SVP, checking for latency and power.
  • Software Virtual Prototype 4 (SWVP 4): This prototype is used by product marketing and sales to check out the design with prospective customers for possible modifications.

One key, according to Gary, was that the four different SWVPs serve four different functions and, therefore, have four different users, four different specifications, and four different price points!

Well, it turns out that the interrelation between the different prototypes is quite intricate and, over the last two years or so, it has become increasingly difficult to keep them all in sync. Power-related issues - and Gary will explain that in more detail - have, in particular, caused some interesting effects. As a result, emulation and hardware-assisted verification acceleration have moved into the center of system design and have become its heartbeat, to interact with the different types of prototypes and to allow development of software and hardware at different levels.

But I won't spoil the fun and give everything away. Instead, join us next week for the webinar called "ESL - Are You Ready?". You can sign up directly here.

Talk to you next week!

Frank Schirrmeister 



Leave a Comment

E-mail (will not be published)
 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.