Many years ago (at a company I am no longer with) the salesheads pressured engineering into a product modification which they them sold to customers prior to a repeat of RF emissions testing to FCC Part 15. My own project had been suddenly canceled and I got pulled into the mess when the subsequent RF emissions testing revealed that the modified product vastly exceeded allowable FCC radiated limits.
After I did much physical and mechanical redesign and got the product to pass FCC testing, sales response was "How do we explain to the customers why they need to make this change? Can't you fix the problem without having to make all these changes?"
To which I basically replied "That's YOUR problem. YOU decided to sell the modified product prior to emissions testing."
The fact is that while the customer is NOT always right, THEY ARE the ones with the money. I have showed customers that the "build to print" they supplied would not work, and that customer was grateful, responding with a PO to make the design work. But not all sales weasels are as cooperative as they were at that employer.
A coworker came up with a complement of the 5 Why process. The "5 Who" process used to determine "Who will pay?" First it got a laugh and then we realized that, more often than not, it reflected reality.
I know you probably won't name the ASIC company, but the flippant response they gave you really irks me. If I hear that someone has had problems with say a certain appliance manufacturer, car etc, they will never get my business. The ASIC company was at fault and should have owned up to it right away. Anything less is reason to go somewhere else.
We're totally on the same page. My reaction was, "Never again." Their ASIC business closed, but they still make other kinds of chips. I don't flat-out refuse to consider their product, but on the other hand, if there is an alternative, I do sort of lean that way.
Good question. The old 883C spec required testing with a fairly slow rise time. Actual air discharge ESD events have very fast rise times.
With the ESD protection structure on the wrong side of the input strucvture, a slow event could still safely discharge through the ESD structure. A really fast event (fast rise time) required a large current flow to discharge its energy in a short time.
The poor input gate was stuck between the bonding pad and the ESD structure. So the gate saw high voltage on the trace (between the pad and the ESD structure). That was enough to rupture the gate dielectric.
Not long after we learned all of this, MIL-STD-883C was replaced with -883D, which had a much faster rise time.
Could you show what's the difference of old 883C and 883D? I searched MIL-STD-883C and 883E and 883F, they all said the rise time of current waveform is less than 10 nanoseconds. I can't find the difference of them.
Hardware design guys are not without fault. I have a current design that I need to build that due to "a small error", when the substrate was layed out, has resulted in multiple capacitor insertions acting as leap frogging pads for bonding wires and in one part running a wire bond over top of the IC to the correct trace.
At another employer, several years ago, Same type of situation resulted in power jumping over ground on one of the devices. Things like that just don't make for a robust design and when pointed out, sales, and the design guy both responded with we'll fix it on the next rev. work around it for now.
Absolutely. On a similar note, at one company I found out that the previous year's biggest issue wasn't fixed in the new model year. Why? Because Sales was able to hit quota anyway! This was actually a massive effort by Sales to use personal relationships, incentives, discounts, freebies--anything they could pull out of their bag of tricks to get customers to accept the previous year model with the issue. So the overseas group, noting that "sales wasn't impacted", didn't fix it. Just goes to show, things can work quite smoothly until humans get involved.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...