Automation and the smiley face of death
The pervasive trends of manpower reduction and the shift toward the use of foundry services have created a new set of challenges for designers attempting to bring a prototype design to reality.
By Pallab Chatterjee, Contributing Technical Editor -- EDN, July 9, 2009
The pervasive trends of manpower reduction and the shift toward the use of foundry services have created a new set of challenges for designers attempting to bring a prototype design to reality. The manufacturing-transfer process has gone from one with engineering oversight to one of almost complete automation. Although this automation allows for consistency in data structure and format and represents an attempt at minimal conformance to a set of design rules, it does not necessarily account for engineers' waivers and designers' assumptions and interpretation of the rules.
One demonstration of this trend is a design submission that “passes” an automated test and receives a “smiley face” indicating that the design transferred with no errors. More than 90% of the time, when a design has zero errors, there are a significant number of warnings. These warnings are lists of processing assumptions the automated-transfer process used to verify conformance to the design rules and tapeout guidelines. These warnings also include the design's data objects; the design's data layers; and information that the processing routines are ignoring, discarding, or both.
In most cases, if a design earns a smiley face, people release it to production without reading and understanding the impact or the extent of the warnings. But most designs with zero errors and multiple warnings end up functioning improperly and require many re-spins to fix. This issue is responsible for about 70% of design re-spins and presents the greatest challenge to product engineering on failure analysis. The product-engineering and yield-improvement groups are working from the assumption that the released design was correct relative to the design data, but the discrepancy between the actual released design and the engineering design can be significant.
|
In addition, most of the designs have a known block that does not conform to the designs' rules for devices. This block, usually called the “graffiti cell,” contains the chip name, the copyright information, and other data. These contents are not operating devices. They identify the chip and the data sets that make it through testing. The foundry's incoming-data procedure should be able to identify and exclude checking of this cell. Unfortunately, a number of foundries lack this “skip-a-cell” feature in the release flow. As a result, either the release team must release the design without the necessary design-marking layers, or it must bypass the automation in favor of manual processing.
Transferring the design data to the manufacturing facility can itself be a challenge. To transfer this data, designers typically use GDSII (Graphic Design System II), also known as stream data, and Oasis, which are both binary-file formats. Another means of transfer, CIF (common intermediate format), is a popular academic-edition and free EDA tool in ASCII (American Standard Code for Information Interchange) format. To reduce cycle time, physical media is no longer the method of choice. Rather, teams electronically transfer the designs. In the past, these electronic transfers have been in the form of e-mail attachments, but, with new designs having 10s of gigabytes, this method is impractical for most e-mail tools. Smaller designs—typically, CIF designs—can still use e-mail formats, in which you embed the design data in the e-mail body itself. This limitation makes FTP (file-transfer protocol) the protocol of choice. With FTP, the customer can drop the design into a designated secure FTP site at the foundry, or the designer can park the data at the customer site in a secure FTP location for a foundry autobot to collect.
In either case, most networks include significant security provisions that restrict or purposely corrupt the binary data to ensure security and avoid malicious attacks on the network. So design transfer is no longer an engineering task but a collaborative effort in which the involvement of the IT (information-technology) department is an absolute requirement.
Contact me at pallabc@siliconmap.net.
-
Hi Pallab. Some good points but its worth pointing out that file transfer is moving on from FTP in many production facilities now. With file sizes constantly increasing and the need for tighter Internet security a must for compiance in some industries and to counter espionage in others there are many options to deliver data more securely and quickly than FTP - UDP based solutions are to next great thing at the moment with a number of manufacturers products underpinned by this delivery protocol.
James Lewis - 2009-13-7 04:13:00 PDT -
Small nit -- CIF means 'Caltech Intermediate Format', not 'Common' intermediate format. Just want to see good work by the caltech folks to be recognized. Thanks.
Kevin - 2009-9-7 22:34:00 PDT
