WP_Term Object
(
    [term_id] => 14
    [name] => Synopsys
    [slug] => synopsys
    [term_group] => 0
    [term_taxonomy_id] => 14
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 665
    [filter] => raw
    [cat_ID] => 14
    [category_count] => 665
    [category_description] => 
    [cat_name] => Synopsys
    [category_nicename] => synopsys
    [category_parent] => 157
)
            
arc v 800x100 High Quality (1)
WP_Term Object
(
    [term_id] => 14
    [name] => Synopsys
    [slug] => synopsys
    [term_group] => 0
    [term_taxonomy_id] => 14
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 665
    [filter] => raw
    [cat_ID] => 14
    [category_count] => 665
    [category_description] => 
    [cat_name] => Synopsys
    [category_nicename] => synopsys
    [category_parent] => 157
)

Getting out of DIY Mode for Virtual Prototypes

Getting out of DIY Mode for Virtual Prototypes
by Don Dingee on 09-26-2016 at 4:00 pm

Virtual prototyping has, inexplicably, been largely a DIY thing so far. Tools and models have come from different sources with different approaches, and it has been up to the software development team to do the integration step and cobble together a toolchain and methodology that fits with their development effort.

That integration step has scared away many teams that should be using virtual prototyping and capturing the benefits of earlier software creation and debug. Teams using virtual prototyping can have code running and tested months before their physical hardware platform is ready. What’s in the way? I know I can relate to the squiggly red line in this diagram:


To create a virtualizer development kit (VDK) with a set of transaction-level models (TLMs) for IP blocks has been a somewhat painful process. Software teams leave the cohesive world of C compilers, debuggers, and other tools often fully integrated into an Eclipse IDE, and step into a different parallel universe of SystemC for creating TLMs. Adding the rest of the metadata needed for a complete VDK – pin names, register maps, and connectivity – is another tedious step. The languages are different, the tools are different, and sometimes the process borders on manual labor with developers resorting to editing text with emacs.

Fortunately, many IP vendors have gotten the message and are creating VDKs for their supplied IP blocks. This is especially true in safety-critical environments where software testing tends to be more extensive. (Insert my favorite comment about IoT applications becoming -critical here.) As software grows to dominate schedules and resource loading, and more SoC starts are motivated by accelerating unique software algorithms with dedicated hardware, it’s a welcome development to have more IP suppliers providing VDKs.

The above chart was provided by Malte Doerper, product marketing manager for virtual prototyping at Synopsys. They have stepped back and asked the question why VDK integration has to be so hard. Part of the answer is the tools involved; productivity is lost whenever a team has to jump back and forth between non-integrated tools. Part of the answer is using automation to help the process.

The highly logical step here is to get the virtual prototyping environment into Eclipse. Synopsys has created Virtualizer Studio, an integrated Eclipse IDE that handles browsing, editing, debug, and static analysis chores for SystemC. Those who have worked with Eclipse-based tools know they can be easily extended, allowing software teams to pick and choose from best-of-breed plugins and customize their workflow. Doerper suggests that just bringing the environment together in Eclipse has cut development time for TLM models in SystemC in half.


The real hit Synopsys is after comes in VDK creation. That figure of 10x productivity improvement is based on initial observations from lead customers of Virtualizer Studio. It’s definitely #YMMV; for a huge design with many complex IP blocks, it might be a much larger figure, for a trivial design it might be less. Having off-the-shelf VDKs helps. Synopsys has been working with ARM and other providers for configurable reference VDKs, and supplies models for its DesignWare IP. Still, Doerper says that if VDKs need to be created, at least 50% of the source is stuff that can be autogenerated. The approach takes advantage of the fact that abstraction simplifies the input and the results.

There are also gains to be had in incremental development. Maybe integration testing shows that the models aren’t exactly right and need a bit of tweaking. Or, perhaps an IP supplier updates their models and that drives a slight change in a model of another IP block or the integrated SoC. In Virtualizer Studio, switching from the VDK debug perspective to the TLM creation perspective is a simple matter of selecting a different tab:


For more of the story on the new Synopsys Virtualizer Studio IDE, the full press release:
Synopsys’ New Virtualizer Studio Integrated Development Environment Accelerates Virtual Prototyping Productivity

More background on VDKs and what Synopsys is doing in segments such as automotive:
Synopsys Virtualizer Development Kits

To me, the development of an Eclipse-based environment for VDKs is a no-brainer. Software teams can quickly embrace the Synopsys platform and add their own extensions. Adding off-the-shelf reference VDKs to jump start productivity is also a big step. To get more SoC starts, the semiconductor industry needs to do more things to make the software developers comfortable, since those people will be the ones generating many of the new ideas.

Related Blogs:

Automotive Design and Virtual Prototyping

Embedded Agility

Developing ARM v8 Code…Today

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.