The ESL Edge

I listened in today to a webcast titled EDA-ESL and More Ideas from DAC. Quite what this had to do with DAC I am not sure, but it contained speakers from Mentor (Shabtay Matalon), Cadence (Jason Andrews), and Synopsys(Frank Schirrmeister) talking about their ESL strategies.

Several things were common to all of the presentation including:

• They all talked about the need to perform concurrent engineering between hardware and software and the only way to do this is to make a prototype of the hardware available sooner
• It is not always possible to create a prototype out of models that execute in software only. Sometimes emulation and physical prototypes are necessary
• While all three companies now have synthesis solutions, none of them mentioned it except in a glancing manner
• While all three told roughly the same story, they are all based on very different levels of product support and differing levels of abstraction
• They are all SystemC based in terms of interfaces

One interesting question was raised which regarded the different levels of timing accuracy (PV, AT, LT in OSCI terminology). All of the vendors deferred to the standard bodies to say that they were defining these and that they supported them. But the real question really is: why are the standards bodies getting it so wrong by not defining what these terms actually mean? Thus as expected the answers were wishy-washy and basically said: use what ever level of timing accuracy makes sense, and the only note of caution said: it is possible that you may get models at different level of timing even though they are meant to be the same.

Towards the end the moderator (Don Dingy) asked each of the panelists what was clearly a canned question.

To Cadence he asked: What are the benefits of using a Virtual prototype when an FPGA is available. Answer: because it provides increased controllability and visibility and doesn’t suffer from intrusive debug.

To Synopsys he asked: What are the use-cases for a virtual prototype. Answer: 5 use-cases. 1) When RTL exists and you need to integrate it into a VP 2) To provide a balance of speed and accuracy for different tasks 3) Verification of implementation model. Using  the VP as a testbench for implementation 4) Connection to outside world. Integrate with real devices and 5) Remote access so that SW engineers don’t have to go into the lab.

To Mentor he asked: Why do you need real use-cases for power analysis. Answer: Need to actually run end-user applications to see real power profile. He started to claim that this was unique to the Mentor tool, but Synopsys chimed in with – we do that too.

So at the end of the day, it was an interesting set of product pitches, but little was accomplished.

——————————————-

Brian Bailey – keeping you covered