As caretaker of the venerable Gerber format, we at Ucamco I feel bound to react to the insightful blog An Embarrassment to the Electronics Community by Vince Mazur and especially the comment it generated.
I will restrict myself to the context of PCB fabrication, in which I have some experience.
What is the Gerber format? It is a PCB image file format. That is it. It does not pretend to be a cure for cancer, nor a solution for the problems in the Middle East. If you expect these from the Gerber format you are bound to be disappointed.
However, Gerber does pretends to enable transfer of PCB image data. And this it does very well. Gerber is an outstanding PCB image format. That is the reason for it's near universal use. Over 90% of PCB's, from the simplest to the most complex ones, are now manufactured based on Gerber. The industry practitioners are not all morons and would not continue to use something that does not work. We estimate that less than one in 100.000 Gerber files contain a format error that could lead to scrap. (There are of course far more poor designs, but this has nothing to do with the format.)
This is not a bad error rate, and we at Ucamco try to further improve it. When a format error is reported, we try to feed it back to the originating software vendor. We take a hard look at the specification to see if it can be improved. We have brought out a succession of revisions of the specification to make it clearer and more precise. We feel the Gerber file format specification – freely available at the Ucamco website – is now among the clearest and best specs in the PCB fabrication industry. This does not mean it is perfect. If you have questions or remarks about the spec, don't only complain, but please send them to email@example.com, they will be considered for the next revision.
When I refer to the Gerber format, I of course refer to RS-274X (Gerber X, Extended Gerber) and not to RS-274-D (Standard Gerber). D has been deprecated many years ago. D is no longer an official format. Today, the only format one can validly call Gerber is X, not D. A whole chapter in the specificaion is dedicated to explain why one should use X, and not D. If one wants to rile that some still use of D rather than X, we will join the chorus. However, one can lead a horse to water, but one cannot make it drink. If people insist to inflict a competitive disadvantage on themselves and a disservice by the industry by using D rather than X, there is nothing more we can do. We call on all industry practitioners and especially trade associations to continue to explain that X is the standard and is what should be used. Note that introducing a new format will not solve the problem of the continued use of D but make it worse. If some cannot be bothered or convinced to make the simple and straightforward step from Gerber D to Gerber X, then they will definitely not to move to a more complex and completely different format.
It is sometimes stated that Gerber is bad because of the use painting or stroking. We fully agree that painting is a harmful. However, there is nothing in the Gerber format that requires or even encourages painting. Ample proof is the vast number of Gerber files without painting. Actually, the macro apertures feature makes it easier to define any pad shape in Gerber than in any other PCB language. Painting is simply bad practice. It is a relic of a distant past. Painting was needed with the vector plotters in the 1970's and 1980's, devices that are not used since a long time. Painting is still around because some people have not bothered to make update implementations. Still using it today should be made a criminal offense! Painting is listed in the bad practices section in the specification. The application note Painting considered harmful on the Ucamco download page explains in detail why it should no longer be used. However, again, one can lead the horse to water, but one cannot make it drink. Again, a new fomat is not the solution. If people do not properly implement a simple format as Gerber, it will be worse in a more complex format. Actually, there are plenty of ODB++ or Barco DPF files with painting.
The Gerber format is perfectly suitable for reliable PCB image transfer. Of course, one can feel it would be better this or that feature were added. Actually, we at Ucamco have been tempted to add a few nice to have features to the language. However, a introducing a new feature creates an incompatibility with current implementation. We felt this disadvantage outweighs the benefits of the new features. We resisted the temptation to introduce these new features. This is our judgement, but of course we consider it possible we are mistaken. If someone needs a new imaging feature, of he feels that its benefits outweigh the disruption caused by it's introduction, please mail firstname.lastname@example.org . The proposal will be considered.
The most complex part of a PCB specification is the images. The extra information such as materials, layer structure, colors are of course equally essential, but they are far simpler to describe then the images. Due to the lack of a generally accepted standard for the extra information it is transferred in the notorious PDF files.
Fortunately there is a generally accepted and universally implemented standard for the complex part, the images: Gerber. Without computer readable image files PCB fabrication would not be possible. Instead of riling, I would rather say: "Homage to the Gerber format, the backbone of the PCB fabrication industry."
There are three major causes for riles about Gerber file:
- The use of D, an utterly obsolete version
- The use of painting, or poor use of the format
- The lack of a generally accepted standard for the information not handled by Gerber
What is broken is not what the Gerber format does, but about what is does not do, and was never intended to do. Gerber is not the problem, Gerber is part of the solution.
Of course that does not mean there is no problem. There is a desperate need for a practical, simple, compatible machine readable standard for the non-image extra information. The problem with proposed standards for extra information is that they force people must adopt the standard whole sale and adopt a new imaging model. To fix the 10% that is broken - the extra information – one must jettison the 90% that is well-tested, universally available, familiar, why new standards never got much traction. As industry practitioners are not morons, they are understandably reluctant to go down that path.
We propose to complement with a standard (a.o. a subset ofIPC-2581) for the extra information, keeping good old Gerber for the image transfer. These ideas are worked out in detail in the article IPC-2581 meets the Gerber File Format at www.ucamco.com/downloads This article proposes a the path of compatible gradual improvement. One keeps what works. The established workflows are not disrupted. Companies that do not want or cannot afford to upgrade their software can continue to work in the established way. Those that want to press forward can keep what works but automate and standardize what is not covered now.
Ucamco made a first concrete proposal along these lines in the article Extending the Gerber format with attributesat www.ucamco.com/downloads.. As we do not pretend to be omniscient, this is not a final, cast in concrete, specification but a document for discussion. We seek input from the industry before committing this to a formal specification.
Vince, this is a very interesting issue -- and the lack of standarization for PCB manufacturing files is a really huge problem!!
Some years ago, I worked for the R&D office of an EMS company and we faced a lot of problems when trying to put a new product in the SMD production line. If the third-party fab files --Gerber, pick & place... -- had been produced with an EDA tool for which our company had not purchased the license, we needed to convert from one standar to another using very prone to errors methods -- including doing it by hand ;-(
Frank, my comments are confined to board level design, but you make a very good point. I believe a primary reason for the more advanced state of IC data exchange is that the stakeholders in the IC development cycle are under considerably more business risk in terms of the prospect of having to re-spin silicon, or miss a key milestone. Contingency plans, enabled in part by data exchange, are a routine characteristic of the process. I understand that IC package design is a critical area, but I am not fluent on the state of data exchange in that domain.
I am less familiar with EDA for PCB design, but in the IC design world I would hardly lament the degree of standards and ability to exchange data between different tools or different users. It is not a perfect world, but it's close enough that it's quite possible to use tools from different vendors at various stages of the IC design process and change vendors for certain tools when there are good reasons to do so. IP providers understand this very well and have no real problems providing all the required CAD views of their IP to support whatever tool flows their customers happen to be using.
On another note, I got a chuckle when you mentioned EDIF. I haven't heard that acronym in 20 years, and back then when it was sometimes used for IC netlists, it was a nightmare. Is it really still used in the PCB world?
Duane, the Gerber file is time tested for what it was intended to accomplish. However, from a design process standpoint, Gerber is a late stage output file, focused on fabrication of a board. A reference design on the other hand is a very early stage tool.
Designers need a way to import the available aspects (schematic, PCB, etc.) of the reference design into their preferred EDA environment so that they can add or remove functionality and rapidly prototype. Authors of reference designs need an effective way to publish their designs so that the maximum number of potential users can leverage them in their EDA tools in an uncompromised manner.
I agree that either ODB++ or IPC-2581 looks promising as a standard data exchange foundation for the PCB aspect of a reference design, to the extent that they support early stage design together with licensing terms and ubiquity acceptable to the community.
Why does this article remind me of some similar article in a German eda magazine beginning/mid of the 1990s (this article complained about no advancement in EDA except faster and bigger machines in the decade before, and about ripoff sales tactics in EDA)
As far as I know the "design patterns" used in eda are:
two or more step initialization
having to use a debugger to find out what is failing and why
after 17 years of availability of working c++ exception handling (considerable less for most UNIXs except IBMs) the potential resulting revolution in software quality is still pending (e.g. Google style guide forbids usage)
UNIX problems like
buggy shared library handling (when multithreading is being used)
shared libraries sharing a single namespace scope (fixed recently)
programmer cannot write code using file locking since it may not be available on remote mounted disks
NFS not being deterministic
returning the error code of exec to the original process is quite advanced programming
not existing structured exception handling making writing into sparse files via memory mapped io impossible for complex applications
writing into remote files via memory mapped io causes the server to be busy since there is no notion of exclusive opening
write to a socket or pipe causing a SIGPIPE which has to be blocked in an way which does not assume anything about the calling environment (this SIGPIPE "dramatically" simplifies writing IO filters like grep/awk/sed)
managers in eda not having advanced programming experience
usually positions for programmers are titled as "looking for c/c++ programmers"
usage of dangerous functions from the c library
usage of global/static variables
repeated conversion of identical objects into different formats
usage of fixed sized buffers
manually pairing up code for do/undo actions
manually writing derivative code despite the method to let the C++ compiler do it is known since more than a decade
Actually, the point of this piece was not for us to bristle with pride about our chosen profession, but rather that the state of the EDA art is still primitive. Did anyone read past the first paragraph?
But then there's the other piece today about the 3D printing hype. Seems to me that entire PCBs can just about be sent across the Internet, and printed out in whatever size is feasible, by a 3D printer. That ought to be a step beyond the .pdf file, yes?
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.