( ESNUG 457 Item 6 ) -------------------------------------------- [10/05/06]
Subject: ( ESNUG 456 #2 ) the untold backstory behind Oasis vs. GDSII
> Editor's Note: After I saw this letter from the PR guy for Oasis Tooling,
> I didn't know how to interpret it because I have no idea what the untold
> backstory for the "new" OASIS standard is. For example, Cadence created
> the OpenAcess database to counter the Milkyway monopoly Synopsys got from
> the Avanti aquisition. Start-ups wanting to be bought out by Cadence
> should build their tools on OpenAcess. But what's the unspoken backstory
> of wanting OASIS to replace GDSII? Who's pimping it? Who's opposing it?
> What are the hidden motivations here? Anyone? (Feel free to be anon.)
> Is OASIS something a day-to-day chip designer should actually care about?
> I'm not questioning Oasis Tooling, Inc., but the OASIS standard. - John
From: Mike Santarini <michael.santarini=user domain=reedbusiness not mom>
Hi, John,
Something's strange here because Ron Wilson and I did an interview with
the bigwigs at TSMC a month or two ago regarding their 65 nm silicon and
tool flow. They said emphatically they aren't using OASIS -- that they
are strictly using GDSII for 65 nm. What struck me was they did NOT say
the usual neutral marketing stuff like "we're evaluating it" or "we're
looking at it," let alone that "Oasis looks promising." They said
"we're not using Oasis" period. What gives?
- Michael Santarini
EDN Magazine San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: [ Been There, Done That ]
Hi, John,
As I understand, OASIS started as one of the fab equipment guys (not sure
who) asked someone in the industry to see about developing an upgrade to
GDS-II. Eventually, it got into open discussion and landed in Sematech.
Mentor took over, with Mentor sensing an opportunity to strongly influence
an industry standard (just like Cadence with OpenAccess and Synopsys with
its .lib stuff). Mentor's main Calibre tech dude (Lawrence someone) and
Carl Vickery (tech guy from TI) were the main drivers of the format.
If I were you, I'd call Carl Vickery at TI and ask him the real story. I
think you and Carl are a lot alike (tech guys, no-PC-zone attitude). He's
a good guy, no bullshit, won't put up with marketing BS.
Now, for some of the OASIS back story:
- Mentor is trying to own OASIS, while keeping it in the public domain,
just like Cadence with OpenAccess.
- Cadence officially really owns "GDS-II", having bought the leftovers
from Calma.
- At one point, the standards committee along with Synopsys, who were now
involved, differed from Mentor on the implementation of a couple of
things, so the "standard" splintered. Mentor ran to its sandbox. It's
all good now though.
- Si2 (the OpenAccess guys) view OASIS as a competitive "standard". It's
not, but I think they are paranoid about it. Therefore, it's but a
small step to see that Cadence doesn't like OASIS. Have you seen many
announcements for the support of OASIS from Cadence?
- The biggest impetus for the GDS to OASIS switch is that the GDSII files
are getting huge at 65-45nm. 200GB-300GB is not uncommon. Equivalent
OASIS files are 70%-80% smaller.
As you'll learn from others, GDS-II is long in the tooth, and has problems
in meeting the needs of 65nm and 45nm.
- [ Been There, Done That ]
---- ---- ---- ---- ---- ---- ----
From: Carl Vickery <carlv=user domain=ti spot mom>
Hi, John,
The OASIS format was adopted as a SEMI standard in early 2003. Some EDA
vendors offered support from the start, others waited until customer demand
appeared. Although interest is picking up, OASIS is still not widely used.
When asked when OASIS would be widely adopted, my usual reply has been "when
the cost of using GDSII is too painful to bear". IMO this occurs at 65 nm,
where the amount of data transmitted to a mask vendor can be in the
neighborhood of 1 terabyte. At least this is the motivation at my company.
The slow rate of OASIS adoption is (again, IMO) a sign that (for once) the
industry managed to anticipate a problem and get out ahead of it. Engineers
processing large datasets (OPC/RET/fracture) have the most to gain and are
likely to be early OASIS adopters. Cell/block designers may never care.
I expect to see OASIS to start moving upstream towards the designers over
the next 2-3 years. OASIS is an *interchange* format -- not a database.
In most areas OASIS complements rather than competes against *integration*
vehicles like OpenAccess and the proprietary EDA databases.
- Carl Vickery
Texas Instruments Dallas, TX
---- ---- ---- ---- ---- ---- ----
From: [ Mr. Brightside ]
Hi, John,
OASIS from my understanding is from Mentor Graphics.
I don't really see it as a push for proprietary stuff, like OpenAccess.
It's dealing with an issue Mentor (doing Calibre and OPC stuff) is
facing... database sizes for GDS files are getting HUGE. We routinely
have 10+ gig GDS file sizes. I couldn't even imagine how this translates
to for guys doing mask stuff.
If you want a good example, look at my ESNUG 455 #12 post comparing
Mentor to Mojave on DRC... I was talking run times for large die on the
order of an hour. Run a simple experiment... how long does it take to
write out a 10 gig file? How long does it take to read a 10 gig file?
One of the "hidden" numbers in my benchmark was that in some cases, GDS
creation took almost as long as Mojave's DRC did... at bare minimum it
wasn't a "don't care". But for the simple case of Calibre DRC, I'm
guessing the user could see better "run time" simply by having a much
more efficient representation of their input database... my CPUs can be
used for things like polygon checking, rather than waiting on disk IO.
I won't even go into our disk requirements nowadays.
We've shown using Mentor's GDS->OASIS tool that OASIS files can be 10x
smaller than the comparable GDS... just using a dumb translator and not
having any design knowledge or who knows what. I don't know all the
details, but one obvious thing we know GDS does... when you have a cell
instantiation in GDS, it uses text (rather than a pointer) for that
instance. That means, for the same database, if I call my inverter
"INVX1" versus "inverterx1" I can see signficant database savings for
the same database. I believe OASIS gets around this via a table lookup...
this alone should account for a large amount of their database savings.
Anyways, as as user, I would consider OASIS "a good thing". Right now
there is a Catch-22 in that you need to get everyone to support this
format (implementation, verification, foundry). So they can all point
at each other and say they will do it once others do.
- [ Mr. Brightside ]
---- ---- ---- ---- ---- ---- ----
From: Peter Buck <peter.buck=user domain=photomask spot mom>
Hi, John,
This is something I know about. We were early advocates of a new stream
format to replace GDSII (which explodes with the flat files we encounter)
and proprietary CATS formats (that can't be read by other EDA tools).
Who uses OASIS today? In general, you'll know quite abruptly when you need
it - when your single-level post-OPC tapeout is 10s to 100s of gigs in size,
it takes days to transfer the file to your mask supplier and they can't
fracture it. Until this occurs you probably don't need OASIS. In general
you don't need it at 90 nm; somewhere between 65-nm and 45-nm our customers
start to become interested in sending us OASIS data.
Internally, Toppan Photomasks uses OASIS extensively to represent mask
layouts in a mask MRC application. The value of OASIS here is efficient
representation of flat data and the transportability of a non-proprietary
format between software tools. (GDS2 represents flat data inefficiently;
for instance, a rectangle is represented by five 4-byte signed integer
pairs when at most two would do.)
Support for OASIS from the tools we use (Mentor Calibre and Synopsys CATS)
is good. We have run upwards of 8,000 mask data sets through our MRC
application using OASIS. If we assume each mask has on average 10 patterns
that are translated to OASIS we estimate we've created on the order of
80,000 OASIS files with no apparent problems. For most EDA suppliers I
suspect that OASIS support is a non-event - it's just another translator.
- Peter Buck
Toppan Photomasks, Inc. Gresham, OR
---- ---- ---- ---- ---- ---- ----
From: [ Someone in Holland ]
Hi John,
Here my reasons to use OASIS:
1) OASIS is smaller and safer then GDS. Roughly 3-4x comparing gzipped
files, if the writer makes good use of the format. Clearly not the
10x/20x factors stated by marketing guy's comparing unzipped GDS
versus unzipped OASIS, but who's using not gzipped files these days?
But 4x is not too shabby when storing/transfering GB files.
It has built in compression (CBLOCK) and CRC/checksum; no need to run
external programs to confirm the consistency of GDS any more.
compressed uncompressed ratio
673 MB 4500 MB 81.4% GDS
176 MB 239 MB 26.1% OASIS
412 MB 2208 MB 81.3% GDS
118 MB 173 MB 31.5% OASIS
Reading/writing/compressing less data is also faster.
2) OASIS is a well defined public standard. Most problems that GDS2OASIS
converters faced were how to handle the undocumented variations and
the cornercases of GDS out there.
3) One format to rule them all. OASIS is suited not only to replace GDS,
but also all the variations of MEBES and friends. OASIS is not only
smaller (by 2x) then the multitude of proprietary formats for fractured
data, but also an open standard.
Free converters. SoftJin's Anuvad OASIS tools and Mentor's GDS2OASIS help
to adopt OASIS and Calibre/CalibreDRV read/write it. No need to write
GDS/OASIS to text converters any more, go to SoftJin webpage and download
their excellent Anuvad tools.
- [ Someone in Holland ]
---- ---- ---- ---- ---- ---- ----
From: George Chandler <george=user domain=shearwater spot mom>
Hi, John,
Now that you have probably received lots of email about GDSII and OASIS,
let me introduce you to Saratoga Data Systems and their Bantam GDSII
Optimization tool. Bantam takes GDSII input, optimizes it, and outputs
legal GDSII v. 6 format. Files that have been through the Bantam process
can be anywhere from 50% to 95%+ smaller. Empirical data from 80 GB+
designs has demonstrated these numbers. Plus, downstream applications
can run significantly faster on Bantam optimized files. Synopsys CATS,
for example, has been demonstrated to run 2x - 18x faster, as well as
Synopsys Proteus. Not all downstream apps run faster though.
Bantam enables users to more easily manage the transition to OASIS. They
can stay in GDSII longer, better manage the older GDSII designs, and
interface to vendors who still have GDSII flows.
- George Chandler
Shearwater Group, Inc. Dallas, TX
---- ---- ---- ---- ---- ---- ----
> For example, Cadence created the OpenAcess database to counter the
> Milkyway monopoly Synopsys got from the Avanti aquisition. Start-ups
> wanting to be bought out by Cadence build their tools on OpenAcess.
From: Steve Schulz <schulz=user domain=si2.org>
Hi, John,
Here's a minor (but critical) factual correction on your comment above: A
collection of 9-10 big user companies (such as Intel, IBM, Freescale, Sun,
HP, LSI, etc.) drove for an open API / data model / database environment
to move over from SEMATECH to Si2 back in 2000. This became OpenAccess
under Si2, including their substantial funding and domain expertise. Part
of the "lessons learned" from the SEMATECH exercise was the need for better
commercial EDA vendor buy-in -- this lead to an RFT process. Cadence won
the RFT, and the Si2 members aligned on a new database re-write (Genesis v2)
as the starting point for the OpenAccess Coalition SW, managed under Si2.
I'll not comment on Cadence's motivations for contributing OpenAccess code,
however these large IDMs created the OpenAccess Coalition effort long before
the Cadence-contributed database even existed. Cadence was responsive to
this group, and has since lived up to their commitment with strong continued
support of the database software used by the OpenAccess Coalition. The
OpenAccess standard API and data model remains under shared control of the
elected "Change Team".
I'm sure many start-ups have anticipated the exit strategy you've noted,
as has Cadence for integration efficiencies; but OpenAccess is an even
broader opportunity, as each of the "Big 4" EDA vendors are members in
the OpenAccess Coalition.
- Steve Schulz
Silicon Integration Initiative (Si2) Austin, TX
Index
Next->Item
|
|
