Well. Yes it is very common for a late change of specification where the client would say that it is not an option, has to be included or else....
I think the best way to do this is to reserve the pins for the XTAL and use the inernal clock. I'll also put the Xtal and capacitor on the PCB just not fitting the component. This would give you option for such a late change and no need to redo the PCB.
As usual: it depends. There are rewquirements for x-tals as usb or rtc oj even just precision. What are the costs for a pcb-area where two Cs and an xtal can be mounted? If space and and additional mm² pcb to pay for allows, I would suggest to develop the boards with a x-tal and put it on the bom when needed. So, as I would say, extending the flexibility of PSoCs to the board.
I typically go for an external crystal. It makes anything depending on proper (external) timing more reliable. Especially UART and USB require this.
After that, I look for the frequencies my components need. For example, if you want to get a specific sample rate for and (SAR) ADC, you need a specific clock (e.g. for 500ksps you need 9.5MHz). This creates the need for a specific main clock. And if you have multiple needs like that, you need to balance this out with the different clocks. For that I separate sometimes the PLL and the master clock. If I don't need that, I go with the highest clock for the PLL which suits my needs, and which compiles withour warnings (I have a design right now which goes only up to about 55MHz because of the digital logic. I ended up with a master clock of 38MHz which is 4 times what I need for the ADC).
Some great suggestions there.
I think it actually highlights the flexibility of the PSoC system - the internal clocks and PLLs etc are all very flexible.
When it comes to design I would agree - best to layout for a crystal and a couple of caps, which can be stuffed or not stuffed depending on requirments as they unfold in the product lifecycle.
You might add pads for one of the canned oscillators, as they have more
defined specs than a simple xtal - C network solution. Especially since
a xtal solutions accuracy, drift, does not include the active element issue
in the osc loop, hence is only a partial predictor of accuracy/drift. So if you
are asked for a 5 ppm solution that won't come from a bare xtal implementation.
You should be able to lay those pads out so that either xtal or canned osc
fit pretty much in same board area.
Just a thought.
Yes - thats another great solution. In the PSoC 5 design that I mentioned earlier that has a PIC doing the ethernet tasks, I use a canned oscillator for that chip.