WP_Term Object
    [term_id] => 111
    [name] => Zentera
    [slug] => zentera
    [term_group] => 0
    [term_taxonomy_id] => 111
    [taxonomy] => category
    [description] => 
    [parent] => 14433
    [count] => 6
    [filter] => raw
    [cat_ID] => 111
    [category_count] => 6
    [category_description] => 
    [cat_name] => Zentera
    [category_nicename] => zentera
    [category_parent] => 14433

New Remote Access Standard

New Remote Access Standard
by Paul McLellan on 08-02-2013 at 10:13 am

 When I was running engineering at Compass Design Automation, one of our customers was the National Security Agency (NSA, you’ve heard of them, they’ve kind of been in the news recently). They had a huge problem which was that when they ran into bugs they couldn’t send us any data to reproduce the bug, even a small test case (and that is ignoring the common problem in EDA that the small test cases often all work and it is only the humungous design that breaks the tool). They would give us hints as to what the bug might be, rather like playing 20 questions. Is it bigger than a breadbox? But our other customers would usually send us test cases without much argument and we could debug them on our computers and fix the problem.

Today, lots of customers are more like the NSA. Intel is not going to send an EDA company their next generation microprocessor layout, Qualcomm is not going to send the next mobile processor, TSMC is not going to send 16nm layouts, Apple or Samsung is not going to give you the next iPhone SoC. But, of course, these people still run into EDA bugs. In fact, these people run into maybe more EDA bugs because they are the first companies to push the limits into the next process node: the first to need double patterning, the first to need FinFET extraction, the first to run into major variation issues, the first people doing designs so large they blow up the tools. Early in the design cycle there is slack in the schedule to allow time to fix the problem but during design closure and tapeout a bug can result in a “line down” situation where the entire design is basically unable to progress until a show-stopper bug is fixed. This is not a problem buried in engineering, it gets senior management’s attention.

On the other side of the fence, the big EDA companies (and the small ones for that matter) are not going to ship all their source code off to their customer, fly an engineer there and have them debug on-site.

What is required is a solution whereby the customer design never leaves the customer’s network, the EDA engineers don’t have to leave home, but the problem can be debugged. The big EDA companies have created various kluges to do this, as have some major customers and foundries. But since these are non-standard, the whole ecosystem does not scale and gets really messy when multiple EDA vendors are interfacing to multiple semiconductor companies and foundries.

The most sensitive player in this is the semiconductor company and so they are the ones who are most concerned that they themselves control the access and security. They already have security policies (which they are not about to change) and so the first rule is that everything has to comply with them.

Zentera is a newish (just over a year) company that is focused on creating a standard, scalable solution to this problem. They have a network and security infrastructure on which they have built zAccess which allows an external company limited access (through safe versions of the GDB debugger and the Linux shell) to a sandboxed environment at the semiconductor company that they call a cloud chamber (and not the sort in which you can study subatomic particles).

It is important to realize that there are a lot of stake-holders in this type of solution. An engineer cannot just give access to a design, it involves engineering management, legal, IT, security (if it is a separate organization, as it is in big companies), and management policy.

The important features of the Zentera solution are:

  • standard across the industry, so scalable to multiple vendors and all stakeholders
  • enables remote access but IP loss is protected, and IP never leaves the owner’s network
  • can be set up quickly on-demand to manage show-stopper problems by granting access to the engineers with deep EDA expertise in the tools
  • does not require extensive IT involvement each time
  • meets security, export control and compliance requirements

Zenter’s website is here. More details on their remote access platform here.

Share this post via:


0 Replies to “New Remote Access Standard”

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