Hi All,
I am from Valor, I should state that up front, but I would like to offer two
points for consideration:
1. In the mid-1980's the mainstream PCB manufacturers began to accept Gerber
(instead of film) into their tooling departments. In order to do this, they
had to make capital investments. These investments gave them a competitive
advantage, because they were able to cut costs overall, reduce lot-size due
to faster tooling cycles, and increase quality. Despite this, for many
years, the OEMs (their customers) continued to send the design to the
fabricator in two formats; Gerber, and film. The film was regarded as the
reference and ultimate specification of the design, but the fabricator could
use the Gerber if he so chose (those who could, did). What is going on now
between Gerber and ODB++ is basically the same, a transition of formats
which have uncertainties between them, and for each design somewhere down
the line somebody has to decide which format to believe in and work from. In
the case of Gerber, it took a few years for the average fabricator to have
unconditional confidence in the data rather than the film. These days, they
do not receive films at all, and they just work from the Gerber without a
second thought of what became of the film. In the case of ODB++, many
fabricators already have tools (as do the designers by the way) to compare
the graphics and netlist interconnect of the ODB++ versus the Gerber in an
automated fashion, reducing the risks substantially. The upside (as Mark
points out) is faster throughput and higher quality. The question is: who is
the beneficiary? The ultimate beneficiary of these gains is the consumer
(the designer), via the competitive business model of the
fabrication-outsourcing. From my observation, most fabricators do not
recover their actual tooling costs in the charges they make to the customers
anyway (they bury their tooling costs in their overheads), so it is probably
unrealistic to expect PCB fabricators to give tooling price-cuts to the
customers, since they are running their tooling operations at a loss
already. However, there are gains for the customer, albeit indirect: further
reduction in average delivery times, and higher quality over time; prices
are dropping anyway. To turn it around, if the designers continue to send
Gerber, the level of service received from the manufacturers could not
improve so fast as it can with a smarter interchange format.
2. Seth makes a good point about validation of ODB++ input and output
processors. Currently, ODB++ is not a formal standard, though we believe it
will be in good time (thanks to the industry-driven NEMI process). When the
formal standardization occurs, we hope that some independent
compliance-validation service will be offered by the standards-body. Just as
a side note, independent compliance-proving by an independent body never
happened (as far as I know) with Gerber RS274D, and RS274X never was a
standard anyway, the industry just went ahead and implemented the format
widely, though with considerable variation, as Seth points out. Between now
and formal standardisation of ODB++ or some further-developed version, Valor
offers a service of supporting third parties who implement ODB++, via its
3rd-party cooperation program, the "Open Systems Alliance". We do our best
to offer advice and support for interface testing to all organisations,
competitive or non-competitive, so that the format has the best chance of
practical implementation. Some 3rd-parties opt to stay away from this
service due to competitive reasons, which usually (in our view) results in
sub-standard implementation of the format, which is a pity. Those who join
get full support.
After many years of quasi-stability with Gerber, the industry is in
transition again. I do not sure that there is any clear way of accelerating
the shift to a new CAD/CAM format with price-breaks from the manufacturers
(fabrication or assembly), since they are all bleeding cash right now
anyway. The transition will happen steadily, and be driven top-down by more
subtle, but more powerful, factors such as time and quality.
I hope these comment contribute to the debate in a positive way, as
intended.
Julian Coates
Valor
-----Original Message-----
From: TechNet [mailto:[log in to unmask]]On Behalf Of Seth Goodman
Sent: 31 January 2002 06:24
To: [log in to unmask]
Subject: Re: [TN] ODB++
Hi Mark,
> I assume you are comfortable with your system outputting
> gerber, it's ODB that has to "prove" it can duplicate the
> gerber.
Thanks for bringing this up. I'm not suggesting that ODB++ needs to prove
itself, as its' market share among fab shops tells me that it does the job.
Given the choice, I would also opt for ODB++ as it can carry a lot more than
just bare board information. The problem I have is in archiving any data
object in more than one format for the reasons explained below.
> Here's what I have in mind, an experiment. You asked the
> question "The problem is how do you insure that both sets
> of output data are identical in every way?" Maybe one way
> to test that is to test the input and output capabilities
> of Genesis/Enterprise.
This will test, for one particular data set, the ability of the Valor tool
to translate back and forth between Gerber and ODB++ without accumulating
error. It really shows that their forward and reverse translators are
accurate inverses of each other. It doesn't show that the two data files
produce the same board. Even if we made a test to show that these two data
files were comparable, not very many designers use Valor tools to make their
output files. Instead, we typically use the data file generators built into
our CAD systems. If the CAD system doesn't produce ODB++ directly, and most
don't, then we use a third party tool (I use CAM350) to translate into
ODB++, either from the native CAD file or from Gerbers.
Even if the original CAD tool produced both output formats, the problem
remains. Producing an output file, either Gerber or ODB++, from a native
CAD database is a translation process. It is more difficult, though
fundamentally similar to translating Gerber into ODB++. In both cases, some
program looks at a series of data objects and translates them into another
series of data objects of a different format. That program is written by
human beings and therefore it has bugs. I have yet to own a piece of
bug-free software. The software that produces ODB++ is not the same as the
software that produces Gerber. It most likely has different bugs. My point
is that the two output files will not be exactly the same.
I know from experience that there are flaws in the Gerber data generators in
most CAD programs. The nastier ones are history but some subtle ones
remain. Similarly, different Gerber viewers can display the same data file
differently. Occasionally, I have to spend a lot of time working with a fab
shop because their Gerber viewers and my Gerber viewers show different
results from the same data. This is an unfortunate waste of both my time
and theirs, but it has to be done. Because we don't use the same brand and
version of software, it is unavoidable.
What I want to avoid is dealing with problems in ODB++ data in addition to
Gerber data. Also, consider that if ODB++ becomes the Gerber replacement,
there will be companies other than Valor writing software for it. That
means there will be some differences between how a Valor program and someone
else's program interprets the same ODB++ data. This may not come up very
often, but it will come up, especially when other vendors first start using
ODB++. Unless Valor achieves a 100% market share, we will all have to deal
with some subtle differences between vendors' software. This problem could
be lessened if an independent industry group produced a validation suite
that a program would have to pass to call itself ODB++ compliant.
I would be happy to support ODB++ as the single output format for any given
board. In fact, I would prefer almost any intelligent data format to
Gerber, which is truly a rotten old standard. But until my customers'
purchasing departments will accept ODB++ only, the only "universal" option
today is Gerber. Until ODB++ becomes as universally accepted by fab shops
as Gerber, or the fab shops start to give a big enough discount to offset
the extra costs of supporting two data formats, IMO most designers will opt
to stay with Gerber. If using ODB++ really saves the fab shops money, and
I'm sure it does, all they have to do is pass some of those savings on to
their customers who use it and it will become the de facto standard before
you know it.
Regards,
Seth Goodman
Goodman Associates, LLC
tel 608.833.9933
fax 608.833.9966
----------------------------------------------------------------------------
-----
Technet Mail List provided as a free service by IPC using LISTSERV 1.8d
To unsubscribe, send a message to [log in to unmask] with following text in
the BODY (NOT the subject field): SIGNOFF Technet
To temporarily halt delivery of Technet send e-mail to [log in to unmask]: SET
Technet NOMAIL
To receive ONE mailing per day of all the posts: send e-mail to
[log in to unmask]: SET Technet Digest
Search previous postings at: www.ipc.org > On-Line Resources & Databases >
E-mail Archives
Please visit IPC web site (http://www.ipc.org/html/forum.htm) for additional
information, or contact Keach Sasamori at [log in to unmask] or 847-509-9700
ext.5315
----------------------------------------------------------------------------
-----
---------------------------------------------------------------------------------
Technet Mail List provided as a free service by IPC using LISTSERV 1.8d
To unsubscribe, send a message to [log in to unmask] with following text in
the BODY (NOT the subject field): SIGNOFF Technet
To temporarily halt delivery of Technet send e-mail to [log in to unmask]: SET Technet NOMAIL
To receive ONE mailing per day of all the posts: send e-mail to [log in to unmask]: SET Technet Digest
Search previous postings at: www.ipc.org > On-Line Resources & Databases > E-mail Archives
Please visit IPC web site (http://www.ipc.org/html/forum.htm) for additional
information, or contact Keach Sasamori at [log in to unmask] or 847-509-9700 ext.5315
---------------------------------------------------------------------------------
|
