Sr. Vice President of Engineering, Si2
Once upon a time, there was a project called Open Kit Initiative (OKI) at Accellera that had some very far-reaching goals. Unfortunately, it was much too early for such lofty aspirations and the project ended prematurely. However, by agreement between Accellera and Si2, all of the output from this short-lived project was transferred to Si2. Two good things occurred next: first, prominent within the project files were a set of analog symbols donated by Cadence that we at Si2 felt would serve well as a standard offering; so we posted them for all to use. We were proven right and it serves today as one of the more popular downloadable items from our web-site.
The second bit of good news involved a small user-focused task force we led to determine if it was indeed time for a standard for an open Pcell infrastructure. The message we got back was bimodal – there was no need to rush then, they were happy with what they had, despite the uncomfortable fact that all were saddled with large numbers of legacy Pcells written in a proprietary environment over many, many years. An open, standard environment would be worth having, but, not now. Like "solving world hunger", to quote one of the contributors, an open solution, we were told, was an aspiration for the future that we would have to monitor till the time was right to pursue it.
Three to four years later and a few technology nodes since, the terrain is much changed. PDKs that only feed proprietary tool environments have increased in numbers and complexity so much that it is now a burden on the PDK providers (i.e., foundries) and the PDK users (i.e., the EDA companies, the IP companies and the end-users). Furthermore, unlike the time of the OKI project, there is now an open, industry-standard platform called OpenAccess, also supported by Si2, that can serve as the platform for an open PDK. The semiconductor industry is now ready to cast aside proprietary approaches and is ready to accept standard specifications of the contents of a PDK, even if we are still no closer to solving world hunger.
So, what are we doing about this at Si2? At Si2, where the users' interests are paramount, we have spoken with a wide variety of stakeholders and defined the minimum set of items that would define the structure and parameter types of a PDK. It would be based on OpenAccess and capitalize on its rich content. At a very high level, we have defined how some of the items would interoperate. We have begun the process of bringing all stakeholders to the table to drive this forward. And we have begun to define a request for technology which we expect to send to the entire industry to seek contributions of specifications for the PDK contents so we can get a running start on creating standards based on already-proven concepts and trusted, open decision processes appropriate for a broad industry standard. We expect this to kick into high gear in January, 2010, so we are calling on all interested parties to join in this effort. This is an inflexion point for the industry and we ask all to join to make this a success story for all involved.
This is an excellent idea.
The time is right and the complexity of libraries has sky
rocketed over the last 3-5 years. I do have one question, will
there be a migration path for existing PDKs to migrate to the
open architecture? I believe this would go a long way to
lowering the barrier for users to move to an open
architecture. I agree that this is an idea whose time has
Regards, Dale Neidhammer
Our current plans do not include any automatic translator to convert old PDKs (Pcells included) for several reasons. First, according to many domain experts, it is not possible to create trustworthy and lossless converters since there are many, many subtle "tricks" embedded in the code that would require expert intervention. Secondly, most PDKs are written to-date in a proprietary format where considerable IP is included. Since Si2 operates in the pre-competitive space to create open standards, a translator inevitably would entail stepping on some form of IP or another. In light of these and other reasons, an automatic translator is not part of our plans.