[ Back ]   [ More News ]   [ Home ]
September 11, 2006
Midnight at the OASIS
Please note that contributed articles, blog entries, and comments posted on EDACafe.com are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
Peggy Aycinena - Contributing Editor


by Peggy Aycinena - Contributing Editor
Posted anew every four weeks or so, the EDA WEEKLY delivers to its readers information concerning the latest happenings in the EDA industry, covering vendors, products, finances and new developments. Frequently, feature articles on selected public or private EDA companies are presented. Brought to you by EDACafe.com. If we miss a story or subject that you feel deserves to be included, or you just want to suggest a future topic, please contact us! Questions? Feedback? Click here. Thank you!

"GDS, and then GDSII, became the defacto standard because it worked, and was a fairly efficient format for designs of the size and complexity of the day, but most importantly because EVERY IC designer and foundry had a CALMA design system. We owned the market. What wasn't designed on Calma was designed on proprietary systems (very few), or people hand-cut rubylith (in the old, old days). It's like Microsoft Word or PDF are today, except that Calma wasn't evil.


- Rob Kuhling, Calma veteran


"Why does all great journalism happen between midnight and dawn?"


- Anon




Midnight at the OASIS


The GDSII data stream format files that go from design to manufacturing in the IC industry are becoming ponderous, and something has got to be done. That "something" is probably OASIS - Open Artwork System Interchange Standard - although not everyone is completely sold on the idea. This column is about OASIS and includes comments from three different companies who are supporting it.


Last year, Jack Horgan wrote a column here in
EDA Weekly on the new OASIS format based on a conversation with Tom Grebinski, CEO of OASIS Tooling. Consider today's column to be Chapter 2 of that discussion. This time, however, it's a roundtable that also includes Tracy Weed from Synopsys and Steffen Schulze from Mentor Graphics. Joe Basques of VitalcomPR set up this roundtable, which was supposed to be a conference call between the participants.


Unfortunately, at the last minute Steffen found himself stuck in a plane on the tarmac in Macao, unable to access a phone. Because of that, the conference call went forward without Steffen, and I composed a set of questions, after the fact, which were sent to him by e-mail; Tom and Tracy also received the questions. Steffen responded the next day in writing from Taipei; Tom Grebinski also submitted some additional comments.


Because of the way this roundtable discussion evolved, there's a certain skew-ed-ness to the conversation here. Tom and Tracy's comments are organic and spontaneous - they did not have a set of questions before the phone call. Steffen's comments have a more studied air. This presents a problem if you, the reader, conclude anything about the three companies, or the three participants, based on these differences - so, please don't. Please do, however, read this column to completion and conclude something about the current status of OASIS, and its future in the industry.




Things you probably already know


Calma - per Wikipedia, "Calma Company, based in Sunnyvale, California, was, between 1965 and 1988, a vendor of digitizers and minicomputer-based graphics systems targeted at the cartographic and electronic, mechanical and architectural design markets. The company's best known products, both targeted at the integrated circuit design market, were GDS, introduced in 1971, and GDS II, introduced in 1978. By the end of the 1970s, Calma systems were installed in virtually every major semiconductor manufacturing company."


Cal and Irma Hefte - Calma founders and, hence, the company's name


GDS, GDSII - "Graphic Data System" layout design computers, and stream formats for representing geometric shapes and text labels; today only the stream formats remain in use


1978 - Calma purchased by United Telecommunications

1980 - Calma sold to GE

1988 - Some parts of Calma sold to Valid

1991 - Valid acquired by Cadence


Roger Sturgeon - led GDSII team at Calma; later founded Transcription Enterprises, which produced CATS (Computer-Aided Transcription System), which was acquired by Numerical Technologies (a.k.a. Numeritech or Numerical) in 2000, which was acquired by Synopsys in 2003.


Kevin MacLean - helped found Transcription Enterprises, was part of Numeritech after the TE acquisition, eventually joined Cadence after Numeritech was acquired by Synopsys, and now a VP at PDF Solutions.


CATS - Computer Aided Transcription System, originally produced by TE, then part of Numeritech's portfolio, now part of Synopsys' portfolio.


OASIS - new format designed to be a replacement for the GDSII stream format, developed by a SEMI technical committee


$75 - how much it will cost you to buy the SEMI P39-1105 OASIS standards spec


December 2003 - OASIS 1.0 specification first released

December 2004 - OASIS 1.0 update released


Tom Grebinski - CEO of OASIS Tooling, chairman of SEMI OASIS committee


Tracy Weed - CATS Product Manager at Synopsys


Steffen Schulze - Product Marketing Manager at Mentor Graphics, Calibre MDP and Platform applications




The Roundtable Discussion - OASIS Tooling & Synopsys


Peggy - Tom, please identify yourself and tell me what's wrong with GDSII that we need to go over to OASIS.


Tom - I'm Tom Grebinski and I'm CEO of OASIS Tooling. OASIS is a data format and next-generation replacement for GDS II stream. Our interest is in building OASIS infrastructures for companies who need it.


Peggy - What's wrong with GDSII?


Tom - There are file limitations in GDSII. With OASIS, we can compact data fields by as much as 10-to-50 times. [That's important] because there's a 32-bit implementation with GDSII that could possibly cause problems below 65 nanometers. It's related to a 32-bit spillover, and OASIS [has solved this].


Peggy - Why is this happening at 65 nanometers, and not 90 nanometers?


Tom - It has to do with data volume and how we represent data in design layout. As more and more data becomes required to express IC designs, the greater amount of that 32-bit capability is required. We're pushing things at 28 bits, but for many companies, they'll soon need 33 or 34-bit capability to build the next generation design. At 90 nanometers, the data files are at 20 or 30 gigabytes, but at 65 nanometers, they're at 80 gig. Down at 45 nanometers, they're even larger.


Peggy - Who else, besides you, is driving OASIS?


Tom - Intel, TI, Fujitsu, NEC, IBM, Mentor Graphics, of course … those are just a few.


Peggy - Are these all your customers, and are there any companies who aren't your customers who aren't driving the process?


Tom - There's at least one company on my list, and that's NEC which is not a customer of ours, but is driving an aggressive OASIS effort. [Editor's note: Neither is Mentor a customer.] TI says they'll be OASIS-ready this year. At least one mask company is building commercial masks using OASIS, and IBM is also building commercial masks using OASIS.


Peggy - Tracy?


Tracy - I am with Synopsys now, but I've been in the industry working on this for a number of years. The [SEMI] P39-1105 OASIS standard was the outcome of a number of folks driving the process. We're part of that committee and have been working on defining the standard. Tom, the standard is still at 1.0?


Tom - Yes.


Tracy - Moving to a higher version requires quite a bit of time from a committee standpoint, but OASIS has received a very good reception and responsiveness from our customers in the big IDMs. [We see] major customers looking at implementing OASIS. Synopsys has done a number of surveys … a year and a half ago, we did our first survey, and found that OASIS was on the horizon. A few months ago, we did another survey and found that about 10 percent of our mask data prep tool users with a high presence in the industry are using OASIS at some level. Our expectation is that [within several years] that number will be up to 30 to 50 percent.


Peggy - Are the Synopsys surveys available publicly, or are they proprietary?


Tracy - These are internal surveys of our customers.


Peggy - Can you name the customers?


Tracy - Not at this time, but they include all of the major IDMs, plus foundries and fabless companies.


Peggy - Tracy, I forgot to ask you to fully introduce yourself.


Tracy - My name is Tracy Weed and I spent a number of years with IBM before joining Numeritech, which focuses on the RET space. We were bought by Synopsys in 2003, and I was part of the transition of CATS into Synopsys. I'm responsible for the product, as well as the manufacturing tools that Synopsys is providing to the industry.


And, yes - I would say that 10 percent of the companies [now working with OASIS] is highly representative of what's going on in the industry.


Tom - I would agree. Oh, and another company I missed … TSMC is also using OASIS.


Peggy - Are these companies using OASIS exclusively, or in addition to GDSII?


Tracy - In addition to … for selected products, they're using OASIS, but they're not removing GDSII from their flow. I don't think anybody is migrating 100 percent over to the OASIS flow at this time.


Tom - There are a number of customers we're dealing with now, who state they're [using OASIS] on their existing designs. But some of the more key players say they will not move GDSII designs over to OASIS just because of the complexity of making the conversion, [and concerns] about whether the conversion is correct. They want to stay with GDSII as long as products are being made [that support it]. They'll work [later with OASIS] on more critical designs that require file-size reduction.


As Tracy said, the real transition point is at the 65-nanometer node. Companies working in that space are definitely looking at OASIS.


Peggy - Can you give me a ball park figure for the costs of the conversion?


[Long silence…]


Peggy - Tom? Tracy?


Tracy - Do you mean in terms of resources?


Peggy - Yes.


Tracy - Probably it's a 3-to-6 month period of time, depending on the design, the layout, how many layers, what system they're using. There are some internal, proprietary systems that drive some additional complexity … unique problems specific to some of those customers. But [in general], I think it's 3 to 6 months. For Synopsys, all of our tools applicable to this space are fully implemented now with production versions of OASIS.


Tom - My feelings on this are a little bit different than Tracy's. I would say it's more like a year to 18 months [for a customer] to get their OASIS implementation qualified in the terms that Tracy and I are thinking of. Our focus [at OASIS Tooling] is on verification and acceptance of various tools, external tools, and CAD tools. From our perspective, it's taking a little bit longer to fully qualify an OASIS flow.


Tracy - It may also depend on how much of the flow you're looking at, plus the aggressiveness of particular customers. Some customers have longer-range plans.


Tom - Exactly. Some IDMs and foundries have been working on OASIS for a couple of years, but it takes time. It [requires] an investment in resources, and it's not an insignificant investment.


Tracy - As both Tom and I have mentioned, there were starry-eyed panacea visions of OASIS [that it would help with reducing] file sizes and deal with the 32-bit restrictions. But some of the delay, and the fact that the number [of companies making the transition] is no higher than 10 percent, is related to the complexity of these flows.


Once you get in and look at the legacy tools, some folks across different sites don't even know what they have installed now in those various places. Translators are required, but also customers' internal tools have to be updated and implemented in OASIS. All of this adds to the varying degrees of time that might be required to implement such a vast change.


Peggy - Remind me again. Why do we have to go there?


Tracy - Because of the file sizes. We typically are seeing 50 gig OASIS files, [and those are] translations down from GDSII files of between 500 and 600 gig. The file sizes are incredible. We've even heard of one prediction from a customer of a terabyte [sized file] by later this year. [Clearly], most people will be going to OASIS … it's just a matter of time.


While file size is important, OASIS by itself isn't the total answer. There are [actually] a lot of issues we end up with once the file gets too big. If you're designing with a 1-terabyte GDSII file, that's a 200 gig OASIS file, and then we're right back in the [problem] realm. It's just huge!


Really, what takes a lot of time here, once you get those files, is the read/write [part of the process]. I've seen estimates that 80 percent of your time is taken up with reading and writing those files. How do you accomplish all that you need [to do with those files], when the read/write takes so long?


Peggy - So, are there other strategies that are better than OASIS?


Tracy - One thing we've looked at with more and more OPC, is [taking structures] from hierarchical to flat. If you try to do read/write in an hierarchical environment, it takes considerably longer than looking at a flat field. By addressing each of these cells, rather than going back and forth, we're seeing significant improvement … 10x improvement in read/write times.


Tom - What Tracy mentioned makes a lot of sense, but it's a step back from OASIS. [The discussion about OASIS is about] its progress in terms of its maturity.


One thing we all agreed on at our early [SEMI OASIS standard] working group sessions, is that it will take 5 years [for the industry] to take full advantage of what exists inside of the OASIS format. A number of OASIS vendors are not implementing everything [yet] … there's just too much there. But over time, OASIS and its capabilities will improve within these companies. There will be additional work and upgrades to implement OASIS as users understand what can be done [using the standard].


Also, there are database-level limitations. Databases were getting large even before OPC … there was a choking of the databases. OASIS has the ability, based on what you can and cannot do, to increase the compaction of a database and drop the file size. With that, comes acceleration of the database because the translation of the database is relatively simple when you're outputing the OASIS file. You speed things up as an OASIS database. The exchange from a GDS database to OASIS can improve compaction and performance.


Tracy - I think we're certainly aware of the additional capabilities [that will come with] the maturity of the OASIS standard, and a number of additional things which need to be addressed. Tom's products, the OASIS tools he offers, have been helpful in moving the industry in a much quicker fashion than we would have been able to do without them.


We're continuing to work on it - compression and compaction of a CBlock within the OASIS file that is associated with the compression. There are public algorithms available for that. We're working extensively on that, and on our algorithms that we're using in conjunction with what's being offered. Tom's right - there's lots to be gained from OASIS, [particularly] the handling of the turnaround time as we go from 65 nanometers to 45 and 32.


There are a lot of things, in addition to OAIS, that the industry is going to have to address. Still there's a lot of benefit in the technology.


Peggy - How many people does Synopsys have working on OASIS?


Tracy - I don't want to get into exact headcounts, but we have a team that's dedicated to OASIS that's tightly integrated into our overall R&D support activity. We've taken steps to improve [that support] as we've added new capabilities. We've also doubled our quality and our organization to support the complex code behind these new algorithms.


When I was at Numeritech, from 1999 to 2003, no one was really working on OASIS, although we were part of the committee. As you may know Transcription Enterprise was the original company of CATS, [including] Roger Sturgeon and Kevin MacClean. They have since moved on to other things. But before Synopsys took over, the CATS team had 12 to 15 people … a solid, industry-leading team.


Tom - Roger Sturgeon sat on the board of Numeritech. He was the founder of Transcription Enterprises, creator of CATS and GDSII, and played a role in what OASIS is today. Roger was at all of the meetings, and did a great job. It was really nice to have him there. All of the people from Numerical were very helpful … from when they were bought by Synopsys, up through to today.


Tracy - Like all things that I've been involved in, from a standards standpoint, there has been the fair share of yelling and arguing like at any standards organization. But what we ended up with, as far as an OASIS format is concerned, and how everybody was focused on the end result [was great].


Peggy - Can you remind me what OASIS stands for?


Tracy -Open Artwork System Interchange Standard.


Peggy - Who's working on OASIS in the EDA world?


Tom - Our customers are anyone who has made use of GDSII. We have EDA vendors, suppliers, DFM customers like Aprio, and mask makers. We're also working with foundries and IDMs. We're working with a broad spectrum of companies that need OASIS.


Basically, every IC design runs through GDSII before its actually manufactured as an IC, so you can imagine the impact that a transition from GDS to OASIS will have. As Tracy said, maybe 30-to-50 percent of the companies in the market today will be using OASIS. That's why this format is being treated so carefully. The complexity and implementation must be carefully considered, as increasingly sophisticated tasks will be asked of it.


Peggy - What will be the lifespan for OASIS?


Tom - We're hoping it will last 10 to 15 years.


Peggy - How did you get involved with OASIS?


Tracy - Tom was chairman of the OASIS standards committee.


Tom - I started the committee.


Tracy - That's one of the reasons that OASIS has been a success.


Peggy - Why is that?


Tracy - Because of Tom's knowledge of regressions and what not. [That technology] is available in OASIS in a way that allows regressions to run quickly, so we can concentrate on our algorithms, and the software can run better. It's really been useful … we've been happy to have the OASIS Tools products.


Peggy - Why doesn't Synopsys take all of this in-house?


Tracy - We always go through the make-versus-buy discussion. But as long as the innovation continues … as Tom says, there's plenty of room left in terms of OASIS that needs innovation. For the foreseeable future, we don't have any plans to not look at this type of product.


Peggy - Are these algorithms your secret sauce?


Tom - One of the facets of OASIS that is intriguing, and that allows for these other opportunities for database optimization, is called OASIS repetition, and there are a lot of them. These repetitions allow us to take a very large repetition out of the field, capture the repetition data records, and represent them by a canonical implementation.


We can take 10,000 rectangles in a design and represent them by one rectangle and one math function that tells where the other 9,999 rectangles are. There you can get a tremendous compaction, but also the expansion of the algorithm back out to the 9,999 rectangles is very fast … super fast!


Basically, by going to repetition, OASIS repetition builds up some significant speed up. It's not a secret sauce. It's a fact of OASIS that can be exploited [in a way] that allows for CAD tool acceleration in the future and allows for optimizing multi-core processors through canonical representation of data at the microprocessor level. It reduces the number of translations [and solves another design] bottleneck for microprocessors, which today are not optimized for IC design.


What would be unique to this would be to use a new type of library within a microprocessor that optimizes the chip. Then you would have a complete repetition-based flow.


Peggy - So are there other option than OASIS for solving these problems?


Tom - I'm not sure what Tracy has heard, but as chairman of the committee, I haven't heard any complaints.


Tracy - I agree, although you could probably refer to OASIS as GDSIII, because we're learning from the issues that folks had regarding GDSII … file-size explosion, constraints with 32-bit, and as Tom said, a bunch of other stuff. OASIS will carry us for quite some time. Will something come along to replace it?


Never say never. There's always somebody who's smarter, some [other solution] that may come along. But it always requires a lot of work within an industry to bring this type of thing to fruition.


Peggy - So remind me again what you predict the shelf life of OASIS will be … 10 years?


Tracy - Yes, 10 years … until 2011, at least. Maybe by the time designs get into 32 and 22 nanometers, [something else may come along]. As we went from 130 to 90 nanometers, we were faced with a number of different problems, and from 90 to 65 nanometers, a number of additional problems came along … [various solutions were considered]. At 32 and 22, if the data files go to terabytes, is what we have now going to be sufficient? [Who knows?]


Today, we're beginning to focus on GDSII and OASIS, but Synopsys is also looking at other stuff. Maybe optical lithography goes away, but you will still need data transfer, there will still be issues needing to be addressed there. How do you move that much data is the question.


Tom - There are other algorithms that I'm fairly certain some of the universities are interested in. These next generations of designs are looking at other types of compaction algorithms, or other types of repetitions that could improve compaction, so those options may be available as well. There are a couple of universities where there's work being done on other compaction strategies that don't exist in OASIS today, but that could possibly help.


Like Tracy said, if we were to look at OASIS 1.0, there will probably be another upgrade to OASIS in another couple of years.


Peggy - When did the OASIS effort start?


Tom - OASIS started in June 2001.


Peggy - When will the next committee convene that will be considering the next solution that comes after OASIS?


Tom - Nobody can think of anything at this point that will be replacing this format [in the near future]. At 65 nanometers, a stable process needs to be implemented. Almost every company needs to share data with other companies [in the design and manufacturing chain], and [OASIS will help make that happen]. People are moving along with OASIS [because it is stable].


Tracy - Tom makes a good point. There's general agreement that we're still implementing an initial version of OASIS. People are focusing on that right now. Once it picks up a few more users, over the next one or two years, and we can get data on those users and what they expected to get out of that, you may see some desire to reconvene the committee … or not.


Peggy - So then is OASIS still at a proof of concept stage?


Tracy - We're past the proof of concept point. We have customers who have used OASIS in production for very high-end stuff. I think it's just how many of those layers [of the standard] are utilized, and over what period of time, that will dictate [adoption]. But, we're well past proof of concept. It works as we expected it would, but there are still a lot of legacy tools that have to be converted over. That's just part of the infrastructure that has to be dealt with.


Tom - It's well beyond proof of concept. There are a few companies today who are already in production using it. These companies have some unique issues with the way they have set up their design flow. Integrating OASIS with that design flow has a unique complexity within those companies.


It takes time to bring all of these tools in. This is a multi, multi, multi-billion dollar industry and the design infrastructure has to be changed very carefully. For instance, we have a shift of less than half a nanometer, versus lengths in OASIS of 5 angstroms. That's how accurate these things have to be as we move from GDS to OASIS. It has nothing to do with proof of concept.


Tracy - On that point, right now we can work with a 20-to-30 gig OASIS file that's within the realm of compression for speed, timing, as so forth. But for 200 gig OASIS files, people will start to say, "Okay, what else do we need to do that we're not doing." It has nothing to do with whether it works as of of concept. [It has everything to do with] what will be the next stage of data size that we'll need to deal with.


Peggy - Can either of you distinguish for me between compaction and compression?


Tom - Compaction is a bit-by-bit process of scouring a data file and looking for repetitive data. It's model filtering. Compression is a non-selective way of reducing data. It's not related to looking at repetitive data.


Tracy - Compression is like zipping a file. There are not really a lot of complicated algorithms associated with compression, but there are complicated algorithms associated with compaction.


Peggy - Tom and Tracy, how long have you known each other?


Tom - Since 2003 … since the launch of OASIS, but I had heard of Tracy before that.


Tracy - [Laughing] Well none of it was true. I was not there and I didn't do it!


Peggy - Tracy, how does Synopsys distinguish itself from other EDA vendors with regards to OASIS?


Tracy - Our focus is on the full flow. We have more tools that have been implemented in OASIS. The flat field is unique, that's where the fields are going from an OPC standpoint. We're able to handle them in a more efficient way, and we're really looking at developing [that technology further]. We may not be unique in that … other folks may be looking at it as well.


Peggy - Is Synopsys a leader in this area?


Tracy - Without knowing what the competition are doing [in this area], I can't say. But, we have got good teams.




Answering questions by e-mail - Mentor Graphics


1) Your name and title and why you're involved in OASIS - personal history with the standards effort and/or GDSII, or companies that had previous associations with GDSII.


Steffen Schulze

Product Marketing Manager

Calibre MDP and Platform applications

Mentor Graphics Corporation


Mentor recognized the importance of a better file format before the OASIS WG was created. We volunteered a version of an internal development called SLF - standard layout format V 3.0 as the basic for the development. At the point of the renaming into OASIS, the working group had come to a version 16, which indicates the value of the joint effort of the group. Our key architect held the editorship in the WG for about one year. I was one of our three official representatives in the WG, and later in charge inside Mentor for the product management-related aspects of the OASIS support.


2) What's wrong with GDSII - and is it only at 65 nanometers and below that these flaws emerge?


* File size is large (that is already a phenomenon in the 130-nanometer node and below - in particular, post OPC)

* Can not represent flat data efficiently

* Has a 32-bit integer limit that is exceeded if the correction grid gets to 0.1 nanometer, and a whole 6" mask needs to be treated


3) Can we avoid the cost of moving to OASIS if super-compute capability can step up and handle massive amounts of mask data? Alternatively, what happens when even OASIS files become too big to handle at 45 nanometers and below?


* OASIS delays the file-handling problem by about 3 years

* Hardware to handle large files will be required; it is not necessarily the computing part as much as the transfer, storage, and access parts that requires attention.


4) What companies and/or committees/standards bodies do you believe are driving the move to OASIS?


* Mentor promotes the adoption of OASIS among their customers and has a public translator available for download.

* SEMI and Selete are organizations that host the standard.

* We believe the customer need is driving, and will continue to drive, the adoption.


5) Can you name any specific customers that are working with you to support the move to OASIS? If that is proprietary information, why is that?


We have a number of customers using OASIS. I can refer to publications: TSMC published a paper on a study at PMJ, DaiNippon Printing published papers at PMJ, so did Fujitsu. Intel had shared at the Semicon seminar in 2004 that it is considering the OASIS format as an important element for flow development in the future.


I think OASIS is an efficiency feature for internal data flows. It is not so much an achievement, like a new product that gets largely publicized. We published initially to make it known, but have it now well covered in our application documentation available to all of our customers.


6) How are you gauging the interest in the industry with regards to OASIS? Surveys? Conversations with customers? Participation in standards groups?


The customers that experience the problem of large files recognize the value and work with us. That happens through the normal support channels of Mentor.


7) Which types of customers have the most to gain in the move to OASIS? EDA companies? Foundries? Fabless companies? Most to lose?


Nobody loses with OASIS in the data flows. It is a public format and has the potential to replace some proprietary formats in the data flow for data exchange, opening up these channels to other EDA tools. But the real benefit is smaller size, and the related benefits of shorter data transfer time. I think the end users can gain - IDM and mask houses. From Mentor's side, it is part of our continuous improvements that we provide to customers in the framework of our software support.


8) What level of resources - human and/or financial - are you throwing at the transition/translation from GDSII to OASIS? What do you tell your customers they should expect to be spending?


We do not have an estimate for that. The OASIS introduction commonly accompanies a larger reorganization/update of the data flow, tools, and automation aspects - hence it is not easy to split out what the effort is for OASIS specifically. With a 10x benefit in file size it may become the trigger point to start such an initiative.


9) How much time does it take for a company to make the transition from GDSII to OASIS, once the decision has been made to go that route?


Our internal development went parallel to the working group activities through beta implementations and customer interaction. We released in the summer of 2004 as a production-qualified feature meeting our software standards. On the customer side, it will likely be accomplished in a new node qualification cycle (See also No. 8)


10) What year did your company decide to commit to OASIS?


2001/2002


11) Do you have the same team working on compression algorithms that's also working on compaction algorithms? Are all of those algorithms proprietary?


I am not quite clear what distinguishes compression and compaction for this purpose, but we do not disclose the algorithms in our software. CBlock compression relies on a publicly available standard (zlib).


12) If Cadence owns the GDSII format, is OASIS a move to 'open source' the situation?


Cadence has not taken any steps to constrain the use of GDSII. From that point of view, I think OASIS and GDSII are equally "open" from a practical standpoint.


13) What do you think the shelf life of OASIS will be? It was initiated in 2001. What year will it be fully implemented?


We anticipate a gradual implementation starting from the post-tapeout flows at the most aggressive ground rules (45 nanometers, 65 nanometers). It is well on its way. It may be that the expectations are raised too high - where it hurts, it will be used - but changing established and qualified data flows takes time and is best done with a new node. The design side is currently not suffering from the file size problem.


14) Is it time to start new committees to start working on the post-OASIS standard?


That has already occurred. Selete developed a mask-writer format that is a constrained subset of OASIS. It was announced as a standard in spring 2005, but leaves the current standard totally untouched. I believe a new revision of OASIS is not necessary, nor required at this point. It would, in fact, hinder the adoption, because depending on the enhancement/changes it would become a new version of the format.


15) How do you see your company in the OASIS effort? Leader? Instigator? Supporter? Other?


Leader.


16) What universities are working on proposals that might be alternatives to OASIS? Are you supporting university research into these alternatives?


I am not aware of any.


18) How familiar are you with the history of GDS, GDSII, Calma, GE, Valid, Cadence, and the various technologists involved? Is it of any value to be familiar with that history?


We are very familiar with it since our tools have supported it for a long time (GDS/GDSII). Roger Sturgeon was in the working group, and I know him personally from there and previously through his company Transcription Enterprises.


19) How do the large EDA vendors distinguish themselves when it comes to their particular opinions, involvement, etc. with respect to OASIS?


Mentor Graphics has always been an open supporter and driver of the new format.


20) Is there a business opportunity for tool vendors and/or consultants to work with customers who need help comprehending and/or translating/implementing the OASIS standard?


(Also see No. 8) The effort outlined there is not insignificant. Depending on the strategy of implementing, customers may chose to involve external resources. If internal tools require updates, these may involve programming support. There can be a need for customer specific utilities depending on their data flows.




Answering questions by e-mail - OASIS Tooling, Tom Grebinski


1) Your name and title and why you're involved in OASIS - personal history with the standards effort and/or GDSII, or companies that had previous associations with GDSII.


We felt that there would be a need to outsource at least some of the OASIS implementation effort because of the added complexities demanded by OASIS at the more advanced nodes, because companies share their design and manufacturing efforts with other companies around the globe (leading to greater concerns about interoperability) and because of the speed at which the OASIS effort developed by those first implementers (there was little time to "do it all"). Essentially, the early companies did not have all the capabilities needed. This is where we fit in at first.


We knew in advance as well that other OASIS-based capabilities would be needed as the first implementations matured such as the removal of GDSII low-level primitives from existing layout databases and the replacement of similar GDSII primitives which exist today within the internal formats of CAD/EDA tools. These GDSII-like primitives if not removed will keep companies from realizing a performance gain from the use of OASIS at the file-level. We provide the roadmap and the technology today to help companies take advantage of OASIS' greater capabilities.


Before we started we knew that multi-core processing would become the compute processor of choice and knew as well that algorithms allowed by OASIS (restricted by GDSII) would help optimize the next generation microprocessors for EDA operations.


With the inevitable confluence of all these critical path items (such as OASIS at the file level, OASIS at the database level, OASIS at the CAD internal format level and OASIS at the microprocessor level) right now, we felt it important to assert our view on how the industry should think as each of these pieces develop. We believe that all these facets should be considered collectively today if the industry wants to maximize their use in integrated circuit design over the years to come. We developed this capability and offer it to companies who have a similar long-term vision for OASIS.


2) What's wrong with GDSII - and is it only at 65 nanometers and below that these flaws emerge?


The driving factors behind the move away from GDSII to a more advanced format (OASIS) was larger projected file sizes and a 16/32-bit integer limitation imposed by GDSII.


3) Can we avoid the cost of moving to OASIS if super-compute capability can step up and handle massive amounts of mask data? Alternatively, what happens when even OASIS files become too big to handle at 45 nanometers and below?


Super-compute capability has its limits as everything else does, with time, in this industry. Adding more microprocessors eventually becomes less efficient with the addition of each additional processor. Super compute capability is only as efficient as the data structure defining how the data is processed. OASIS allows for a far more efficient means to run the same processes with far less effort (energy, etc.) and greater speed and without adding as much compute capability in the future.


Data structures (like OASIS) drive the performance of super-compute capabilities.


OASIS files do rise by size as do GDSII files with each node. It is believed that OASIS has a greater capability than being used today which will likely handle larger OASIS file sizes. It is likely that only 20 percent of OASIS' greater capabilities are being used today.


4) What companies and/or committees/standards bodies do you believe are driving the move to OASIS?


OASIS is a standard owned by the Trade and Standards Organization, SEMI (
www.semi.org) which has 3,000 members from the semiconductor industry.


6) How are you gauging the interest in the industry with regards to OASIS? Surveys? Conversations with customers? Participation in standards groups?


Generally, the gauging comes at the 65-nanometer node. There is no other alternative. Tracy's projections seem fairly realistic. As more companies launch 65-nanometer designs, they will be faced with the move to OASIS.


7) Which types of customers have the most to gain in the move to OASIS? EDA companies? Foundries? Fabless companies? Most to lose?


Most companies working at the 65-nanometer node stand to gain the most. The greatest benefactors are the IDMs, mask shops, and foundries at the leading edge. The EDA/DFM companies are the ones being pushed to build OASIS implementations.


The companies who have the most to lose are those who are suppliers to companies which need OASIS but cannot afford to do so.


8) What level of resources -- human and/or financial -- are you throwing at the transition/translation from GDSII to OASIS? What do you tell your customers they should expect to be spending?


For most companies building their own OASIS implementation, it has been a 1.5-to-2 year project (from start to acceptance). The amount invested depends on the number of tools that need integrating, the type of tool flow, the number of external relationships having varied OASIS capabilities and the support required. OASIS is far more complex than GDSII in its implementation yet far more efficient and faster than GDSII once implemented.


9) How much time does it take for a company to make the transition from GDSII to OASIS, once the decision has been made to go that route?


Same as above


10) What year did your company decide to commit to OASIS?


July 2004.


11) Do you have the same team working on compression algorithms that's also working on compaction algorithms? Are all of those algorithms proprietary?


There are compression algorithms freely available such as z-lib. Compaction algorithm development takes more time and effort to do correctly and then optimally for performance.


12) If Cadence owns the GDSII format, is OASIS a move to 'open source' the situation?


OASIS is an open-source format owned and maintained by
www.sem.org.


13) What do you think the shelf life of OASIS will be? It was initiated in 2001. What year will it be fully implemented?


The format was not initiated in 2001. We started the development of the format in 2001. It (the format) was made available publicly March 2004. The first implementations, generally, are not complete. Few, if any, companies are in production with OASIS. Therefore, the shelf life of the technology has yet to start. It is not soup yet.


OASIS is being implemented in pieces. There is too much to do to make a fully optimized implementation. Doing it this way does not mean it will not be used. OASIS capabilities are scalable in terms of performance but requires more skill, resources and knowledge to get there. The greater capabilities will come on line over the next five years.


14) Is it time to start new committees to start working on the post-OASIS standard?


It is not. We all agree that the format is stable and now is the time to build stable OASIS software and code around that format. There is nothing wrong with the format as it sits today. We have found it difficult to find anything we believe needs to be changed, period. Therefore, no effort exists to change OASIS in the foreseeable future.


15) How do you see your company in the OASIS effort? Leader? Instigator? Supporter? Other?


Leader, instigator, and supporter.


16) What universities are working on proposals that might be alternatives to OASIS? Are you supporting university research into these alternatives?


There are no universities working on OASIS alternatives. There are universities looking at algorithms, based on OASIS, which can further compaction and boost performance, etc.


18) How familiar are you with the history of GDS, GDSII, Calma, GE, Valid, Cadence, and the various technologists involved? Is it of any value to be familiar with that history?


Very familiar. Roger Sturgeon (the creator of GDSII) helped lead the OASIS format development effort. The history of GDSII was of great value. This is why I invited Roger to be part of the working group.


19) How do the large EDA vendors distinguish themselves when it comes to their particular opinions, involvement, etc. with respect to OASIS?


I think that currently, companies distinguish themselves by being OASIS-ready and (strictly) to their customer's satisfaction, and no more. The nature of the beast drives the development of OASIS in this fashion.


20) Is there a business opportunity for tool vendors and/or consultants to work with customers who need help comprehending and/or translating/implementing the OASIS standard?


Historically, this has been the case with OASIS. There is too much that needs to be done (considered). Even the largest EDA, mask shops, IDMs, and foundries use outside help when working with OASIS. I know of no company that has not done this. I think that many companies started out thinking they could go it alone but quickly found it is next to impossible.




Additional comments by e-mail - Mentor Graphics


Steffen Schulze - There has been a number of inquiries on the OASIS usage in the public surrounding DAC and all were questioning the progress and why people supposedly do not know much about it.


As all participants in the roundtable indicated, progress is being made where the OASIS format is applicable and where people know about it. It is my impression that some of the ongoing discussions could also lead to a negative effect on the adoption when people feel it is not accepted for not knowing the details.


The discussion about the need to revise the spec can lead to the same perception - something that is deemed not stable will be looked at with caution even though that is not the case with OASIS. In fact there have been no changes to specification, only some clarifications to the description and correction of errors in the text. But the implementation work has not revealed any fundamental problems with the specification, which speaks for the quality of the result accomplished by the cross-company committee.


Important to note here that OASIS can replace GDSII, but that does not mean that GDSII will go away; our tools support it equally. When future needs will have to be addressed with a new format, it will likely be a complementary addition to the portfolio that people will transition to when the need arises, while maintaining their current approaches in qualified and stable technologies.


[Editor's Note: Mentor Graphics MarCom Manager Carol Thurmond was on the line during the original roundtable between OASIS Tooling and Synopsys and reported her impressions to Steffen Schulz, hence his additional responses here.]




Buying the SEMI P39-1105 OASIS standard document online


Buy the SEMI P39-1105 OASIS standard document at

http://webstore.ansi.org/ansidocstore/product.asp?sku=SEMI+P39-1105




OASIS - Open Artwork System Interchange Standard


Abstract: This standard was technically approved by the global Micropatterning Committee. This edition was approved for publication by the global Audits and Reviews Subcommittee on September 8, 2005. It was available at
www.semi.org in October 2005 and on CD-ROM in November 2005. Originally published in March 2004. The purpose of this specification is to define an interchange and encapsulation format for hierarchical integrated circuit mask layout information. Background -- In the fall of 2001, SEMI's Data Path Task Force formed a working group to define a successor to the venerable GDSII Stream format, which had served the I.C. industry as a de facto standard for layout interchange for more than two decades. The old format, limited by 16-bit and 32-bit internal integer fields, by its inefficient representation of cell-native
geometric figures, and by high structural overhead, was becoming difficult to use for leading-edge designs, and file sizes were becoming unwieldy, in some cases growing to many tens of gigabytes. The successor format was chartered with several overall goals:


- Achieve at least an order-of-magnitude file size improvement compared to GDSII Stream.


- Remove all 16-bit and 32-bit integer width restrictions-make the new format fully 64-bit capable.


- Efficiently represent cells with large payloads of flat native geometric figures.


- Provide a richer information palette to facilitate interchange of layout-related information between design and manufacturing.


In the months leading up to the formation of the SEMI Data Path Task Force, International Sematech sponsored a series of meetings focusing on Mask EDA issues. Many of the Task Force participants were also involved in these Sematech meetings, and carried forward much useful information from those sessions into the definition of this specification. This format is designed primarily to encapsulate hierarchical mask layout for interchange between systems such as EDA software, mask writing tools, and mask inspection/repair tools. This format is designed to be both hardware- and software-independent. NOTICE: This standard does not purport to address safety issues, if any, associated with its use.
It is the responsibility of the users of this standard to establish appropriate safety and health practices and determine the applicability of regulatory or other limitations prior to use. Use of extension records such as XNAME, XELEMENT, and XGEOMETRY may impair interoperability between tools. It is recommended that these extensions be used primarily for prototyping, and that interoperability be maintained through the formal inclusion of extensions to this specification.



***********************

Editor's Note:


J. Tracy Weed, PhD, earned his BS and MS in structural inorganic chemistry from the University of Connecticut and his PhD from the University of California at Riverside in the area of synthetic organo-metallic chemistry.


Tom Grebinski, CEO of Oasis Tooling Inc. and chairman of the Semiconductor Equipment and Materials International (SEMI) data path task force, holds a BS from Michigan Technological University. Two years later he founded a company based on his patented technology to treat and etch semiconductor surfaces. He has served in semiconductor microelectronics for 24 years in various executive for companies domestic and international, private and publicly held.


Steffen Schulze, PhD, is the product manager for the Calibre mask data preparation tools at Mentor Graphics. He worked at the Center for Microelectronics in Dresden, Germany. He received a PhD in electrical engineering from the Institute for Microsensors at the University of Bremen in Germany.


***********************


You can find the full EDACafe event calendar here.


To read more news, click here.



-- Peggy Aycinena, EDACafe.com Contributing Editor.


Rating: