Part 2 of 2:
We have based our warning alert due to actual experiences our customers have faced when trying to implement a hybrid approach as it was described in the original post. In a couple of serious cases now, a customer using PyCells in their design flow experienced unforeseen problems that resulted in schedule delays and non-deterministic results. Translation: non-forecasted delays and complications as back-and-forth ensued between all parties to determine root cause. Turns out root cause was not due to Cadence. In the end, this experience was not what the customer anticipated when they decided to try out a hybrid approach. As a result of cases like this we responded with our alert to help prevent these types of situations in the future.
At the end of the day, customers want to tape-out chips with predictability, the highest quality, on schedule, and with the least amount of hassle; and with a vendor that will stand behind them if and when the unexpected happens. We provide that level of service at Cadence, and using SKILL-based PCells with Virtuoso provides the most deterministic path to final design closure.
Product Management, Cadence
Because of character limitations, this comment is the first of 2 parts:
Multiple tens of thousands of customers use Virtuoso daily. These customers repeatedly tell us what matters most to them: stability in their full custom/analog design software and flows, that can span multiple process nodes, multiple projects, multiple geographies, and multiple design teams. Other vendors have a point of view that is understandable, but taking a customer-centric view, clearly customers need a dependable, production proven flow that drives the highest quality design with minimal risk.
When it comes to supporting customers for production design, it is critical that we can act quickly and comprehensively should a problem occur. This means having visibility into all aspects of the design and flow as needed in order to identify the root cause. Our ability to respond like this is a huge assurance to customers, and reflects our commitment to stand behind our products. It is important to note that TSMC’s iPDK does not equal PyCells. iPDK contains both full SKILL-based PCell support as well as Python-based PyCells. Thus Virtuoso users can use iPDK with unfettered success, and they do. Should a customer choose to use PyCells in their flow, we cannot and do not intend to prevent that, but as a means of full-disclosure, they need to understand the risks associated with the approach.
Product Management, Cadence
I needed to update my comment because I just learned that TSMC has built, qualified and shipped these cells as part of their iPDK. This really isn't a language issue, it is more a marketing ploy by Cadence to cast Fear, Uncertainty and Doubt (FUD) upon users.
Virtuoso users have to simply pick up the phone and let Cadence know that this warning message needs to be removed.
Now let's get back to innovating our products instead of scaring EDA users.
I think “format battle” is incorrect. Fundamentally this is an IP issue between EDA vendors and IC companies. PDK’s are a form of IP. Design teams, and also foundries, simply need to decide who they want to control their PDK IP – themselves, or somebody else.
Besides, IP is supported by IP providers. We don’t see a parallel message, “Warning – the use of Synopsys Designware is not supported in EDA360.” You’d be forgiven for suspecting the difference relates to Virtuoso market power.
The trendy analogy is smartphones and apps, but a better one is VAX/VMS and Unix. Yes VAX/VMS was everywhere, but in the end, Unix customers got more done. Similarly, Cadence customers use PyCells not to abandon Virtuoso, but because PyCells help them get more done at sub-65nm geometries. PyCell and iPDK users get more from Virtuoso, not less. If that’s a bad thing for Cadence, then EDA really does need a new business model. If you were a Virtuoso competitor, you’d thank Cadence every day for that warning message.
The reality is that Custom IC design has outgrown any one company’s control; 28nm takes an ecosystem of foundries, EDA companies, IP providers, DFM specialists etc. That means open systems and interoperability. Cadence has served the industry richly in the past and still has much to contribute beyond, “non-Skill object detected.” This is a trend Cadence ought to be leading themselves, not ceding to others.
Every EDA company has their own languages to extend and interact with tools:
Mentor: Ample, Tcl, Genie
Cadence: Skill, Tcl
I truly hoped that Tcl/Tk would take over as a defacto standard, yet it didn't.
Because of the proliferation of languages it is reasonable to issue a warning message by Cadence when Python code is detected by Skill. A compromise may be to allow customers to simply suppress these messages with a switch setting.
This is going to close battle. Though so many companies joined iPDK, some of the analog biggies like TI are shifting fully to Cadence by next year. Cadence is already feeling the competition heat and warning messages to the customers :).
This doesn't seem like Cadence is really doing anything unreasonable. It is likely that this was prompted by a customer demanding PyCells support. I believe that they would have served themselves better by not issuing the "warning."
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.