WP_Term Object
(
    [term_id] => 15
    [name] => Cadence
    [slug] => cadence
    [term_group] => 0
    [term_taxonomy_id] => 15
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 598
    [filter] => raw
    [cat_ID] => 15
    [category_count] => 598
    [category_description] => 
    [cat_name] => Cadence
    [category_nicename] => cadence
    [category_parent] => 157
)
            
14173 SemiWiki Banner 800x1001
WP_Term Object
(
    [term_id] => 15
    [name] => Cadence
    [slug] => cadence
    [term_group] => 0
    [term_taxonomy_id] => 15
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 598
    [filter] => raw
    [cat_ID] => 15
    [category_count] => 598
    [category_description] => 
    [cat_name] => Cadence
    [category_nicename] => cadence
    [category_parent] => 157
)

Cadence ClosedAccess

Cadence ClosedAccess
by Paul McLellan on 09-11-2011 at 4:00 pm

There are various rumors around about Cadence starting to close up stuff that has been open for a long time. Way back in the midst of time, as part of the acquisition of CCT, the Federal Trade Commission forced Cadence to open up LEF/DEF and allow interoperability of Cadence tools (actually only place and route) I believe for 10 years. Back then Cadence was the #1 EDA company by a long way, in round figures making about $400M in revenue each quarter and dropping $100M to the bottom line. Cadence opened up LEF/DEF and created the Connections Program as a result.

Recently I’ve heard about a couple of areas where Cadence seems to be throwing its weight around.

Firstly, it seems that they have deliberately made Virtuoso so that some functions only operate with Cadence PDKs (SKILL-based) and not with any of the flavors of open PDKs that are around.

I’ve written before about the various efforts to produce more open PDKs that run on any layout system, as opposed to the Skill-based PDKs that only run in Cadence’s Virtuoso environment.

Apparently what is happening is this. OpenAccess includes a standard interface for PCells which is used by all OA PCells whether implemented in Skill, Python, TCL, C++ or anything else. There is also a provision for an end application to query the “evaluator” used with each PCell. In IC 6.1.5 code has been added to Virtuoso GXL which uses this query and if the answer is anything other than “cdsSkillPCell” then a warning message “whatever could not complete” is issued and that whatever GXL feature is aborted. Previous versions 6.1.4 and earlier, all worked correctly. In particular, modgen no longer works.

Apparently semiconductor companies are very annoyed about this for a couple of reasons. Firstly, they have to generate multiple PDKs if Cadence won’t accept any of the open standards (and Cadence has enough market share that they cannot really be avoided). Second, the incredibly complex rules that modern process nodes require are simply much easier using the more powerful modern languages used in the open PDKs (e.g. Python). At least one major foundry has said publicly that they can deliver modern-language PDKs to their customers weeks earlier than they can with Skill.

Cadence apparently claim that it is purely an accident that certain tools fail with anything other than Skill-based PDKs, as opposed to something that they have deliberately done to block them. But they won’t put any effort into finding what is wrong (well, they know). To be fair to them, they have had major financial problems (remember those Intel guys?) that has meant that they have had to cut back drastically on engineering investment and have to really prioritize what they can do.

One rumor is that this non-interoperability has escalated to CEO level and Cadence’s CEO refused to change this deliberate incompatibility. TSMC must be very frustrated by this since it causes them additional PDK expense. Relations between the two companies seem to be strained over Cadence not supporting the TSMC iPDK format. It would be an interesting battle of the monsters if TSMC took a stand to only support open PDKs, a sort of who’s going to blink first scenario.

The second rumor is that Cadence have changed the definitions of LEF/DEF and now demand that anyone using them license the formats. To be fair, Synopsys does the same with .lib. I don’t know if they are demanding big licensing fees or anything. Of course there may be technical reasons LEF/DEF have to change to accommodate modern process nodes, just as .lib has had to change to accommodate, especially, more powerful timing models.

It is, of course, ironic that Cadence’s consent decree came about due to its dominance in place & route. Whatever else Cadence’s can be accused of, dominance in place & route is no longer one of them. Synopsys and Magma have large market shares and Mentor and Atoptech have credible technical solutions too. It is in custom design with Virtuoso where Cadence arguably has large enough market share to fall under laws that restrict what monopolists can do. Things like the essential facilities doctrine which overrides the general principle that a company does not have to deal with its competitors if it chooses not to.

Obviously I’m not a lawyer, but it’s unclear if Cadence is doing anything it is not allowed to. But is certainly doing things that contradict its EDA360 messaging about being open, and that would probably have been illegal during the decade of the consent decree which recently ended. Plus apparently they have 50 people in legal (no wonder they are tight in engineering) but they seem to have their hands full with class action suits (funny thing: I just tried to use Google to see if there was any color worth adding to this and the #1 hit was a website called Law360!).

And then there is the Cadence “dis-connections” partner program. But that’s a topic for another time.

Related blogs: Layout for AMS Nanometer ICs

Note: You must be logged in to read/write comments

Share this post via:

Comments

0 Replies to “Cadence ClosedAccess”

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