Imera’s is relatively unknown, but it was recently touted as providing secured communication channels between EDA vendors and their customers.

Imera has shut down its operations, leaving behind a number of customers (Broadcom, TSMC, Qualcomm, Sandisk, Infineon, Synopsys, Cadence, Mentor, etc).

Usually a customer requiring support means that some design data need to be sent over to a vendor for debugging. This is obviously a concern for most customers, who are unwilling to send sensitive data to any 3rd party. Thus debugging needs to happen on-site, which means the EDA vendor has to bring up its code source at the customer’s location. This is time consuming, and vendors are reluctant to move their source code outside of their premises for the same reason their customers want to keep their design data within their walls.

Imera’s solution enabled a secured end-to-end channel allowing an authorized 3rd party to access the customer’s data. Practically, the secured channel (aka “Virtual Fabric”) was obtained by installing two physical gateways, one at the customer site, and the other at the vendor’s. Once setup, a virtual private network is established, and data can be exchanged between these two endpoints only.

Of course, people liked having an actual piece of hardware: anchoring the security message into a physical medium made it more real.

However this solution was limited to very simple transactions, which may explain the company’s restricted outlook that led to its demise.

With more collaborative efforts between customers, vendors, and third party infrastructures (e.g., cloud providers), the need for secured data exchange is only becoming greater. Imera had pioneered a solution, however limited, in the EDA field. More will come, and will hopefully be more flexible.

Tags: , ,

4 Comments on Imera’s end is only a beginning

  1. The number of players in the EDA market is too small to make this a viable business, unfortunately. The on-site debug problem exists, but its more of a lawyer-induced inconvenience than an unsurmountable wall. We deal with it using VNC and a few clever problem isolation steps. At Magma I have never heard of cases where a critical bug persisted for weeks (as Maul McLellan’s article stated). And in those cases when it was big, economic realities forced one of the parties compromise and brought the source code and design data together on a single computer. That is the most sensible and flexible solution anyway.

    As for cloud and EDA: security is probably the least of the problems. Cloud is basically outsourced IT services and infrastructure. That can make economic sense for smaller companies, but by itself cloud does not make for better chips or increased design flow throughput.

  2. The fact that Imera had big players like Qualcomm, Broadcom or Sandisk means that there was a real need. I don’t know which EDA vendor Paul refers to in the article, but I can see how a direct, secured connection, helps both side sharing data quickly to debug problems.

    As for EDA in the cloud, this is not reduced to outsourcing IT and infrastructure. Peak usage is a reality that only the top semi can deal with by buying more servers. For everybody else, it is more practical to buy the extra computing power when needed. But then we need a whole different infrastructure to host EDA tools and design data in a secured, scalable framework.

    The leaders in physical verification predicts that you will need at least 8000 cores to verify a 20nm chip overnight. If you’re IBM or Intel, you use your own resources. But for most of the design houses, this calls for solutions where you can access computing resources securely and on-demand.

  3. Nitin Deo says:

    I have a contrary view to this. If this was a real problem, large customers like Qualcomm, Broadcom, TSMC, etc. would have paid a lot more for Imera’s solution – and if they had paid enough, Imera wouldn’t go out of business like this – IFF this is a real problem.

    By not being too well-known and still having all these Tier 1 customers, I would say Imera was doing things right. (Obviously better than the other way around!) But, there is more to it than just having these customers. Perhaps Imera’s value was limited to EDA vendors having access to customers’ sensitive data. Perhaps there was no clearly quantified financial benefit, i.e. ROI was low, hence ‘I’ quickly dried up and hence the result.

    But, if the need is real, I am sure someone will offer a solution that is viable, sustainable and growth-oriented. I just hope the Tier 1 players recognize it and open their wallets.

  4. Abhishek Ranjan says:

    Very interesting article. EDA product development has to not
    only focus on robustness but take care of debuggability from
    very early on. Majority of our customers don’t like to part
    with their designs but still want the bugs to be fixed right
    away. In a catch-22 situation like this, in-built debugging aids
    are the only saviors.

Leave a Reply