NanoSpice Pro X Webinar SemiWiki
WP_Term Object
(
    [term_id] => 157
    [name] => EDA
    [slug] => eda
    [term_group] => 0
    [term_taxonomy_id] => 157
    [taxonomy] => category
    [description] => Electronic Design Automation
    [parent] => 0
    [count] => 4010
    [filter] => raw
    [cat_ID] => 157
    [category_count] => 4010
    [category_description] => Electronic Design Automation
    [cat_name] => EDA
    [category_nicename] => eda
    [category_parent] => 0
)

Imera Virtual Fabric

Imera Virtual Fabric
by Paul McLellan on 01-10-2012 at 6:00 am

 Virtual fabric sounds like something that would be good for making the emperor’s new clothes. I talked today to Les Spruiell of Imera to find out what it really is.

Anyone who has worked as either a designer or as an EDA engineer has had the problem of a customer who has a problem but can’t send you the design since it is (a) too big (b) the companies crown jewels and (c) no time to carve out a small test case. I’ve even once had a bug reported from the NSA where they were not even allowed to tell us what the precise error message was (since it mentioned signal names).

But realistically, if the problem is going to be debugged then either the design company’s crown jewels (the design source code) or the EDA company’s crown jewels (the tool source code) need to be transferred so that both can get together on the same machine. But wait…Imera has another approach. Connect the EDA company to the design company in a way that all the EDA company’s source code remains behind their firewall, and all the design company’s proprietary design data remains behind theirs. But you can still step through a debuggable version of the code running on the problematic design.

For example, a major southern California communications company was having a problem with an EDA tool. By using the Imera Virtual Fabric they put breakpoints in the code and found the problem within 5 hours. A complete fix was implemented, tested and delivered in 5 days. This compared to 35 or more days before using the previous approach, where a version of the code would be created that logged internal progress, this was mailed back to the EDA company, who then created a new version and gradually homed in on the problem.

 It turns out that all of Cadence, Synopsys, Mentor and Magma are using this technology.

Another Imera technology that EDA companies are using is the capability to reach into their internal data center (or private cloud — I guess that is the new fashionable name for compute farms) and built a secure virtual vault with some number of machines siloed into the vault. These are then accessible only to the authorized users. But interestingly those could include an EDA vendor. So it is possible for a design company to set up a specific set of machines that, say, Cadence also has access to to enable collaborative work to debug a problem, for training, for beta testing and so on.

The approach is broadly applicable to other industries too. Volvo, for example, uses it to work with 3rd party vendors and thus ensure that the parts they are designing will fit in the space in the car where they need to go. Banks are using it to give very controlled access to sensitive data.

If you would like to learn more about Imera technology and how it is being used for remote debugging at Mentor Graphics, you might want to check into this seminar “Effective, Secure Debugging in a Fabless Ecosystem“, Jan. 31, San Jose.

Share this post via:

Comments

0 Replies to “Imera Virtual Fabric”

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