Electronic – How are microchips designed

Ask Olin :-) - but wear a flame suit.

Unlike data sheets, which SHOULD be holy writ (but often don't quite make it), Application Notes are a very "mixed bag". It does not pay to just take what is in an AN as gospel, although you'd hope it was at least usable without magic smoke.

The following is opinion (of course).
people are most welcome to offer counterpoints to any assessment I make.

Code: When it comes to sample code that comes with AN's, you can expect that it is liable to be "somewhat rushed" if it was written speifically for the AN, and of perhaps grater quality if it builds on existing applications and libraries. Olin, who is far more qualified to speak on this than I am, will tell you that MOST AN code is poor or dangerous. It happens that Olin's company are top Microchip representatives and that Olin is the sort of perfectionist that you'd want as your developer and not want as your boss ;-). ie you can probably be slightly lss scathing about AN code that Olin is, but listen carefilly to his advice.

Hardware: With reference to hardware, you'd hope that an AN writer was highly competent. If the AN is regarding a reference design that they suggest you can use as the basis for a commercial product then you'd also hope they had put their top people on it. BUT if you make a lot of ICs and you want to suggest ways that people can use YOUR product then you can expect "the boy" to write at least some of them. SO be discerning - look at what is suggested and be prepared to find some bloopers.

Chip bloat: A factor which I recalled again tonight when looking at a TI app note is that there is a tendency to "gild the lily' - to use many ICs where fewer may do. Anyone would think they had some sort of interest in getting the IC's into circulation, or something.

Writer reputation counts for much - this is one place where "appeal to authority" has some merit. If Jim Williams wrote it then trust it. Jim died recently and all too many of the other classically trustable names have gone the same way.

Company reputation counts somewhat.

LT are usually good. Mainly with Jim to blame.

AD / Analog devices are usually very good.

NatSemi are a bit of a mixed bag with much good but nothing certain.

Microchip make great products but do rather tend to churn out the app notes.

Burr Brown tend to be keepers of the Holy Grail [tm} but having been acquired by TI the name could get used differently.

TI are usually quite good over many decades. They have acquired NatSemi and BurrBrown and others in recent years and will hopefully bring th average up and not down.

Zetex (acquired by Diodes Inc) make great great great parts (great!) but have been known to write less than perfect app notes.

Nichia tend not to write app notes but if they did you could probably frame them.

Luxeon/Lumileds / Ghost of Philips past write superb technical notes for LEDs. LLP understand LEDs unlike almost any others on the market and can be used to grow your knowledge base when looking at other products.

Atmel/AVR: Should stick to digital which they know very well. Actually usually very good - using body diodes as zero crossing detectors was a fit of momentary madness.

Hewlett Packard: Old School HP technical stuff was utterly utterly utterly superb. Utterly. Novo Riche HP if they produce app notes of relevance should be treated with care. Pass by on other side if in doubt. Agilent carries much of the mantle of the old HP and can largely be trusted.

Motorola of old not too bad at all. On Semi followed fairly well. Spun off children maybe also.

...

It is very likely CPU's and SoC's are used by hardware description languages like Verilog and VHDL (two major players).

These languages allow different levels of abstractions. In VHDL, you can define logic blocks as entities; it contains inputs and output ports. Within the block you can define the logic required. Say you define a block with input A, input B and output C. You could easily write C = A and B;, and basically you created a AND port block. This is possibly the simplest block you can imagine.

Digital systems are typically designed with a strong hierarchy. One may start 'top-level' with major functions a CPU requires: proccesor (multiple?) memory, PCI-express, and other busses. Within this level busses and communication signals between memory and procesor may already be defined.

When you step one level down, it will define the innerworkings of making something 'work'. Taken an example of a microcontroller, it may contain an UART interface. The actual logic required to make a functional UART is defined one level below.. In here, much other logic may be required to generate and divide the required clock, buffer data (FIFO buffers), report data to the CPU (some kind of bus system).

The interesting thing of VHDL and digital design is the reuse of blocks. You could for example, just copy&paste the UART block in your top-level to create 2 UARTs (well, maybe not that easy, only if the UART block is capable of somekind of addressing!).

This design isn't any kind of gate-level design. The VHDL can be also be 'compiled' in a way that it is finally translated to logic gates. A machine can optimize this far better than a human could (and quicker too). For example; the internals of block A requires an inverter before outputting the signal. Block B takes this output signal and inverts it once again. Well, 2 inverters in series don't do much right? Correct, so you can just as well leave them out. However, in the 'top-level' design you won't be able to spot the two inverters in series.. you just see two ports connected. A compiler can optimize this far quicker than a human.

Basically what digital system design contains is the description how the logic should 'behave', and the computer is used to figure out what the most efficient way is to lay out the individual logic gates.