The reason to do this is the markup on mil-spec parts. I am working with a TI DSP, it costs around $8 for the commercial version, around $30 for the "Enhanced Plastic" version that goes from -55 to +125, and about $300 for the full spec part in a ceramic package. The availability is often low on mil-spec stuff, so that also plays into it - people will pay a premium to not wait 20 weeks for a production order to come through.

It must be really cheap to remark things. I've run across counterfeit MOSFETS - the original part was only $0.50, but were in short supply. Purchasing bought some through a 'broker' (pretty much scumbags as far as I can tell).

We kept blowing them up, and finally sent some off for failure analysis. The xray showed the replacement part was totally different and only had one bond wire in places where the real part had 3.

A bit old, but a book called "How You Really Get Hired" has a great section about how to handle the 'do you have any questions' part of the interview(s). The basic idea is to use the time to show them you're interested, that you've done your homework about the company, and how to use the time as an opportunity to sell yourself or address perceived weaknesses.

Sounds like an argument against VHDL to me... Verilog PLI (programming language interface) was for years one of the things that made verilog better than VHDL. (And it's not just C, there are PLI bindings for scripting languages, too). Not to mention using a simulator like ModelSim you can write Tcl code to interact with the simulation without resorting to tricks like this.

I assume the intent is to teach about how to get your logic into an FPGA, what the internal structures look like, how synthesis maps from language into implementation, etc.

Any good designer has a mental model of what logic is going to get synthesized by a particular snippet of code, I find verilog gets in the way of expressing that model a lot less than VHDL, so I would say verilog is a better choice, in that you can get to the subject you want to teach much faster. Way less time explaining all the VHDL verbosity just to get to a working example.

I'd guess there's at least a few billion dollars difference between a reasonably up-to-date fab and the people/infrastructure it requires, and what is required to cast and CNC chunks of metal (unless it's something like sub propellers). If Apple was throwing around that kind of cash it wouldn't be a secret.

Flash memory requires additional processing steps in wafer fabrication and is usually run on a special process optimized for making floating gate transistors. Controller chips are usually run on a logic process. Mixing the two styles usually results in a bunch of compromises.

Making the NAND flash generic also gives economies of scale to the memory mfg. The memory on a USB stick is just like that on a SD card, a CF card, and inside an mp3 player. Many of them seem to work on the "we'll make the losses up in volume sales" model

google 'tin whiskers' and 'RoHS solder failures'

There's no redundancy or self healing in the hardware of a common USB flash stick. The illusion that there is comes from a flash controller chip that does a mapping between disk sectors and flash sectors and shuffles things in and out so you don't notice the failures until it can't compensate for them anymore.

Conceptually at least, there are several parts to worry about:

1 - the OS & storage driver
2 - the USB driver
3 - the flash controller
4 - the flash memory

At the flash memory cell level the usual failures are breakdown of the dielectric materials and trapping charges in the memory cell that prevent an erase from happening and yield 'stuck' cells. This is normal for /all/ flash chips and is why they all have an erase cycle rating. There are certainly more exceptional ways for the chips to fail (soldering, wire bond failure, static damage, etc).

The flash controller is supposed to be doing wear leveling, error detection and correction on the flash, to get around those problems with the flash chips, and also talking USB. These chips usually have a microcontroller in them somewhere, and there's probably bugs in that code, no doubt more in the parts that get exercised the least, like error paths :-)

The OS and drivers just have the garden variety bugs and features that we all know and love...

Looking at what they're doing, it doesn't look like these are really new parts, just requalified for an extended temp. range and put in a package that is more robust and less expensive to use.

It failed because of bad soldering? Methinks our lab techs must be moonlighting again...

the OP just said an "Atom" COM express module.

Atom comes in two variants, the 'netbook' and the 'embedded' (can't remember the marketing-speak for them right now)

Given that he is coming from Xscale, I'd bet it's one of the embedded modules using the US15W chipset, which are quite different from the netbook ones.

There are a few patches from moblin required to get the 2.6 kernel fully running on the US15W. AFAIK those patches haven't been backported. I would recommend starting from 2.6.