Correcting these problems now will increase our creditability for years to come.

This is my view points in a nutshell. Thanks!

Henry R. Leggette
FAA Retired

1) costs — owning hardware and locally installed software is noticeably cheaper than renting it, especially when you need performance. Since EDA applications often require maximum you can squeeze from hardware, local installs will always have an advantage.

2) network latency and throughput — cloud based resources are hardly usable for many demanding applications. One solution is to do local caching, but soon enough you end up with a need to cache everything, so you may wonder why you need the cloud based resources in the first place. The networks will be better with time, no doubt, but the demand is growing even faster. So cloud will always be relegated to the least demanding applications.

3) security — loss or corruption of data, unauthorized access, etc. Again, it’s easier and cheaper to solve these problems locally.

Prototyping is a tough challenge for 3D. You can’t really use FPGAs, since so much of the system performance is driven by the stack configuration and interconnect. An FPGA prototype can’t replicate that situation. On the other hand, I believe there will be a place for programmable slices in the stack, and that’s a new market for FPGAs.

The real challenge is how to validate the stack configuration *before* you start implementing it. We believe that’s where there will be new EDA software and a new market.

Mike

Toyota’s electronic throttle control is not unlike most modern autos: A Hall-effect sensor in the gas pedal affects a voltage on an integrated control circuit’s input. An analog-to-digital converter (ADC) translates the voltage to digital bits that, together with a number of other control inputs, are taken by an embedded processor to control the throttle. Almost everything is redundant and there are numerous checks and double-checks that will cause the throttle to shut off if any conceivable problem occurs. The trouble lies with problems not thought of. David Gilbert of Southern Illinois University Carbondale identified one: if the two (redundant) inputs from the gas pedal are shorted to a supply voltage through some resistance, the controller will cause the throttle to be full open and no alarms will go off. But this mechanism wasn’t very convincing; there just wasn’t any evidence of such shorting in the well designed wiring between the pedal and the controller.

Could there be a problem, though, within the chip? A problem that occurs just on occasion? There could. The controller is most likely implemented in CMOS, containing both analog and digital components. Such is a noisy and variable environment in which the temperature and supply voltage seen by some embedded circuit could be momentarily at values such that the circuit fails to function as intended. Timing could be off. An input voltage more than a forward diode bias than the supply voltage could cause latch-up. But, back in the lab, everything will work fine. Standard design methodology is to select some set of environment operating conditions that’s deemed adequate and verify that the circuit will work at each such corner. This does not guarantee that failures will never occur, just that they will be unlikely.

Even well designed circuits are subject to transient faults. Microelectronic circuits, by their nature, are all about very small electric charges and can be upset by events that affect such. Electrostatic discharge, electromagnetic interference, even cosmic rays. We need more from Toyota than a claim that everything checks out when they’ve got the runaway back in the shop.