i got an engine check light, so i took the car to the dealer. He charged me $55/, just to hook up to the onboard computer and get the diagnostic code.
So why can’t the car manufacturers just display the diagnostic code on one of the displays in the car ? Then i can go look up the exact message on the web, or an automated phone number somewhere.
i can’t believe those greedy scumbags are able to get away with crap like that in today’s connected world
DFT, of course stands for Design for Test
DFD then ought to stand for Design for Debug, good guess.
DFT is the ability to catch a failure in the chip during testing, were it to manifest itself on the chip. DFD is the ability to ID the root cause of the failure, once the failure has manifested itself. DFD is very important for deep submicron (DSM) designs because of vast variety of faults contained in DSM designs, that are not adequately covered by stuck-at-fault model, which is still the mainstay of the Test world.
For example, there’s nothing that can model a voltage sensitivity, whereby a part doesn’t work at some extremes of the operating voltage. Let’s talk about memory BIST (MBIST). Ability to BIST the memory arrays, and deal with all issues related to testing memories, is called DFT. If anyone wants more details on that, you can contact me separately.
Now let’s say that your MBIST is out and working on the actual chips in full swing, and 1 fine morning, some parts from some wafer from some lot decides to fails at low voltage. Your manager and some lean/mean six sigma black belts are kicking your rear end. What will you do now. The answer …….
Run like Hell.
Of course, i am just kidding. In this case. you need to be able to do the following:
In this whole process, the ability to execute steps #3, #4 is called DFD. If you are a fabless startup, and if tester timing/cost is an issue, you probably need to be able to cook the whole debug enchilada on lab stations, preferably through JTAG. Such an ability is also part of DFD.
By the way, if you can’t even do step #3, call me. CHeers,
Last week i went to Seattle, Washington to visit Boeing factory and to look at the Hiram Chittenden Locks similar to the ones used in Panama Canal. The vast spread of the Boeing factory is mind boggling. Various aircrafts like 777, 787, 737 were being assembled in various stages, all in the same huge building. Boeing calls it a moving assembly line. i also had an interesting discussion with the tour-guide regarding 787 Dreamliner problems
According to the guide, this is similar to any other Engineering project, where bugs are discovered at different stages in the project and have to be fixed. Except in Boeing’s case, millions of dollars are also involved. The Dreamliner fuselage that is having problems is really a leap of engineering faith.
A Panam fuselage displayed over there has literally thousands of rivets, with each rivet increasing the failure risk. In comparison, Dreamliner fuselage is a composite, a single big and long tube. Once the bugs are worked out, Boeing and its customers will realize true savings in quality, reliability and energy savings.
It takes tremendous amounts of team work to build big planes and keep this Boeing mini-city running 365 x 24 x 7 non-stop. These days, Boeing is focused on system improvements, energy savings and customer comfort. Each new plane is developed through continuous customer participation and is highly customized for each order. i personally drew following lessons from Boeing experience:
- Complex debug problems can be solved by due collaboration between test, design, bring-up and process teams
- Costs can be optimized out of the entire DFT process. For example, if Memory BIST is implemented on a chip, there’s no reason to also target memory shadow logic through ATPG tools. Of course, care should be taken to design a BIST engine with wide enough collar to cover the shadow logic, and also BIST coverage should be proven with targeted fault grading. BIST provides at-speed and free soverage and should be relied upon to eliminate memory-related ATPG patterns.
More later. … CHeers,
i want to stand up and shout about silicon debug because the true importance and value of silicon debug is not being realized. In last 5 years i have debugged countless silicon fails in most advanced BIST designs, as well as lowly DC scan shift fails. In each case, as soon as the debug was finished and lessons documented, they were immediately forgotten.
Quite often, we fail to grasp the true importance of debug. We expect silicon to just work. Consequently, when silicon fails, we are unprepared. The DFT engineer is stuck with the debug bill, who rises to the debug challenge, works his/her butt off and solves the problem. For management, such efforts are NRE costs, all pain and no gain.
Management, Engineers, and EDA companies, we all are responsible for making debug a NRE chore. Debug reduces the total cost of ownership for the chip’s consumer. When the end user wins, we all win.
i am going to do my part to preach debug and strive for improvements. Hope you’ll come along for a ride. Please, let’s keep all confidential information out of this blog. CHeers,
