Why not put a crystal oscillator inside the microcontroller?

Question

Why not put the crystal oscillator inside the MCU itself, rather than using an RC internal oscillator? I could think of the following possibilities but not sure if they are valid:

1. MCU manufacturer wants to keep a low price of their product. A crystal will be more expensive than RC oscillator.
2. Designers might want to skip the crystal in a majority of the designs.
3. Designers need the flexibility to choose the right crystal for the same MCU depending upon their application.
4. Packing a crystal inside the MCU is not feasible.

I personally am unable to relate with 2 and 3. I typically use crystals in all circuits and just follow what they recommend in the application note. It will be great if they take the headache of layout, correct capacitor calculation, etc. away from me. It would save PCB space, and probably a packaged microcontroller would be cheaper than buying a microcontroller and crystal separately.

Are there other valid reasons for not putting the crystal inside the microcontroller?

I feel that having a precise internal crystal oscillator would be cost-effective and convenient to design, in general. At least for micrcontrollers that most probably need a crystal for functioning. Examples - any RF chip (wifi, BLE, zigbee.)

I recently came across what they call SIP modules for some wireless chips (EFR family from Silicon Labs and CC2652R from TI), where they make a 7 mm X 7 mm chip-like design containing a crystal, RF circuit etc. Designers just need to connect the antenna and other basic components.

I am wondering why not do it with general microcontrollers as well.

Answer 1

A crystal is very different in physical construction from an MCU, and most crystals are annoyingly large to integrate into a chip package. It's possible, however, to integrate other types of (smaller) resonators into a package, e.g. FBAR (Film Bulk Acoustic Resonator) devices that can be made as small as a few hundred microns on a side. Even in this case, it's two separate dies, with separate processes, packaged side-by-side.

Here's what this sort of FBAR co-packaging looks like (in this case for an RF application):

This particular image is from a chip-on-board integration for an academic research project. However, I'd imagine that for mass fabrication, the FBAR would be similarly bound to the die pad of the leadframe, next to the main die.

Compare this with the following crystal-based design:

The crystal is quite large compared to the silicon die, and requires packaging in a metal can with free air or vacuum around it. Getting these two devices co-packaged inside a single IC package would be much harder. You need a larger leadframe and die-pad, and a way of keeping an air/vacuum space around the crystal itself while still encapsulating the chip and wirebonds. On the other hand, we encapsulated our FBARs with epoxy without such considerations.

In addition to the fab/integration considerations in my answer, I highly encourage everyone to read Hearth's answer which discusses the overall system design aspects of the issue.

Both images are sourced from: Koo, J. Reference clock design for low power and low phase noise with temperature compensation, 2016.

Answer 2

A crystal is fabricated on a completely different process and from a completely different material than a microcontroller is. You can't integrate them both into a single chip, so you would have to have two co-packaged devices.

This is not inherently an issue, and could in theory be done, but it would make the MCU package physically larger (the crystal is going to need to be thicker than the silicon die, not to mention the space it takes up in the other dimensions) and it would significantly increase cost.

Additionally, it would severely limit the oscillator frequencies you can run the microcontroller at. A crystal's frequency can't be adjusted by more than a handful of ppm, so you'd need to include a fractional-N PLL (which limits the accuracy of your oscillator; you have to find a pair of [M,N] that are close enough, and sometimes 'close enough' means very close indeed. Not to mention taking up more silicon area and increasing power consumption!) in every microcontroller to generate different communication bus frequencies. If the oscillator is external, you can use an oscillator frequency that's easily multiplied or divided to the bus frequencies you're using, and just ignore any that you're not. Since most^{[citation needed]} microcontrollers are going to be used with some form of digital communication going on, whether that be CAN, USB, SPI, ethernet, or some bespoke protocol, this is a significant restriction.

Answer 3

Here's a crystal oscillator (source):

In order to work, a crystal must be suspended in free air (or inert gas) by the edges. It works like a tuning fork, it is a mechanical resonator with electrical input/output via the electrodes, so it must be free to wiggle. This means the packaging must be hollow, for example a ceramic base with a metal cap.

This is not compatible with epoxy-based chip packaging processes which encase the chip inside a solid block.

It is possible to make a ceramic package with a crystal and a chip next to it: that's what the crystal oscillator in the above photo is. However, it will be much more expensive than plastic, especially if it needs to be large with lots of pins.

So you get a micro with a cheap plastic package, and a tiny crystal with a suitable package.

Answer 4

The main reason is that MCUs and crystals use very different production processes. One is silicon etching in a photochemical process and the other is a mechanical machining one. Often you can't even integrate two silicon etching processes that use different materials. Analog and digital, for example, or MEMs.

It wouldn't make things cheaper. The reason things get cheaper when you integrate them onto a wafer is because it uses the same production process and the same wafer. That lets you get a two-for-one, but with a crystal you would just be building two things.

Answer 5

One issue with adding a crystal to a microcontroller is thermal considerations. The frequency of crystal oscillators varies with temperature, and they are typically tuned to be their designed frequency at 25°C.

Microcontrollers experience fairly rapid temperature changes as they wake up, do some work, and go back to sleep/idle. Thermally decoupling the crystal, and ideally encasing it in a package that has low conductivity for heat, helps produce an accurate frequency.

Answer 6

5. Total system cost would be higher than with an external crystal.

The IC supplier would have to source the crystal from another supplier most likely, one who could guarantee supply over the life of the IC product at an acceptable price, mount it on a special leadframe prior to encapsulation. It would have to have its own packaging anyway to protect the crystal from the high pressure transfer molding. Chip area might have to be devoted to load capacitors. They would have to mark up the cost of the crystal and other extra costs. The overall package might have to be thicker or larger.

MEMs processes are making inroads in replacing quartz in some applications, not without some hiccups such as the infamous iPhone failures.

Answer 7

Mostly because no one else does, why make an obscure non-standard product which can't be easily replaced.

1. Yes you could glue a crystal in top of MCU (or mold it inside the plastic package). It will be expensive and custom, and MCU would be bigger. And if you don't need the crystal, you would not buy this MCU, and so the MCU die would have to anyway contain the oscillator for crystal, and the RC oscillators.

2. True - if you don't need the crystal you don't want to pay for a MCU with built-in crystal.

3. True - You might have specific tolerance requirement over specific temperature range. So either you would have to manufacture MCUs with different tolerance and temperature ranges or have a very precise crystal which allows you to guarantee tolerance over temp range, but such crystals will be expensive.

4. Likely not feasible within MCU but with crystal right next to MCU. You can have separate chips like memory bonded to MCU chips and they can be in same package, likely possible but crystals being larger and bulkier as they need a sealed package over them.

Crystals are not that big headache you think. I have yet failed to get a crystal ticking even if the layout has not looked like theoretical ideal world examples. Generally MCUs and other ICs that require a crystal say an example crystal with example parameters and tolerance requirements if necessary. You might even get an example part number for the crystal. Yes it is difficult to estimate the stray capacitance for ending up with a capacitor value, but with general purpose MCUs, the deviation due to load capacitance mismatch is generally insignificant for normal purposes.

Answer 8

In conclusion to the above answers ... (and because noone explicitly mentiones it):

Cost would go up, size of target market would shrink.

Why do something which increases design and production costs significantly, while making the product less flexible and more expensive?

In the case that a customer wants a uC at absolute minimum cost, and doesn't need crystal accuracy, the RC oscillator is just fine and production cost is minimised. (Often they also want low power operation, which goes well with an integrated RC oscillator.)

Where crystal accuracy is needed, the actual frequency is always going to be important, so an external crystal makes perfect sense.

Integrating the crystal with uC would be a lose-lose proposition from the marketing point of view. You would significantly increase the cost, while at the same time reducing the utility to customers.

Answer 9

CC2652RB is an example of a SimpleLink™ Crystal-less BAW Multiprotocol 2.4 GHz Wireless MCU.

The datasheet contains:

The SimpleLink™ CC2652RB device is the industry’s first multiprotocol 2.4 GHz wireless crystal-less microcontroller (MCU) with integrated TI Bulk Acoustic Wave (BAW) resonator technology supporting Thread, Zigbee®, Bluetooth® 5.2 Low Energy, IEEE 802.15.4, IPv6-enabled smart objects (6LoWPAN), proprietary systems, including the TI 15.4-Stack (2.4 GHz), and concurrent multiprotocol operation through the Dynamic Multiprotocol Manager (DMM) software driver Integrated BAW resonator technology eliminates the need for external crystals without compromising latency or frequency stability.

BAW resonator technology has some more information on this technology. However, doesn't seem to describe the feature size.