Have a similar question regarding the LSXO temperature stability spec. Adding more notes in the replies...

We do intend this for RTC applications, and some kind of temperature compensation is implied; however, temperature compensation is usually done in the context of a larger system (e.g., requires input from a temperature sensor, and output is corrected on the other side of a PLL). It might not be appropriate to spec a temperature-compensated stability for the circuit itself.

There are other analog-only options, like thermistor-based or varactor-based tuning. I think those could work with the HSXO. I also would suggest the XO designs use topologies that allow a user to use an external oscillator, like a TCXO or OCXO.

Actually the

standby

input appears to be my error. I used that signal on my implementation of the HSXO because I found that I needed to ramp up the gain to get it to start up, so I made it an external pin so that I could lower the power after startup. But that wasn't even the LSXO, so it shouldn't be there (I did have an extra pin in my LSXO design which was also boosting the power, mainly because I didn't have much trust in my crystal model and didn't want to find that it wouldn't start up at all).

The PLL compensation technique is awesome - thank you for sharing! Would cut out the need for the RTC to do anything. So, no idle/startup functionality? Was under the impression that was a sort of "output enable", whereas the main

ena

signal kills the oscillator if inactive. That's what I associated with the two startup times (first for a rising edge on

ena

, second for a falling edge on

standby

(

oe_b

)).

There are plenty of options and all worth a longer discussion. I'll discuss with Andy what the use cases are. Having an idle mode allows for it to get stable after a cold start.

Got it. Thank you, Tim!

Yes, you probably want some kind of pad and package model in your simulation, since the crystal will be an external component. We do not have proper vendor-supplied package models, but the target package for this will be a 128-pin TQFP and you should be able to make some reasonable assumptions about the wire bonds and package leads. The padframe pads are expected to be the sky130 analog pad, which is basically just a pad + ESD diodes and nothing else. However, I do have other pad choices with varying amount of ESD diode area, so that's a variable we can play around with. So the answer to the 2nd question is yes, that's the rise/fall time with specified load cap, but the load cap number is really just a ballpark number for the padframe and package, and doesn't include the specified load cap from the crystal's datasheet, which normally be something like 8 to 12pF and would be the dominating factor.

Thanks for the package/ESD clarification. Isn't the output rise/fall time meant to apply to the internal clock signal, which would be sent to some on-chip buffers? I think it's achievable for both the HSXO and LSXO. This is the one I mean:

Yes, sorry. I am juggling with too many balls in the air. It is a bit hard to context-switch constantly between 20 different circuits. : ) Of course the rise/fall time refers to the digital CMOS clock output. I think likely there was some confusion between the input load and the output load in that spec. The 2pF load is about right for an estimate of the pad capacitance (which you would need to take into consideration for the input stage), but for an output load, the XO output is just going to go to a multiplexer input in the timing management unit, so I would dial it way back. I'll double-check with Andy, but I think a 200fF load would still have plenty of margin.

Sounds good. It'll be in a testbench schematic and very easy to change.

I expect that I just picked up that spec off of a board-level part.

I'm about halfway through a proposal for the LSXO, started writing this down there and realized I should escalate. The single parameter that I believe is not achievable is the startup time from power-down. MCU app notes are hyper-conservative, and they expect ~2 seconds for LSE startup across all C_L. New research on startup time suggests ~100 cycles (3 ms) is achievable with carefully timed injection and known crystal parameters [Esmaeelzadeh, 2017]. Obviously, there's a huge gap there. I'd estimate a consistent 500 ms is doable with limited effort, 250 ms is doable with quite a bit of coaxing, and further is approaching the new frontier. Optimizing for steady-state power and quick start-up will require some novelty. To be fair, there's a bit of slack in the on-state power budget. @Tim Edwards I'm not sure what the cold startup spec should be and am interested in your thoughts. (Gotta throw something about this IP in the channel every couple days. 😄)

I think the startup time from power-down is less important than the startup time from enable. I believe that Andy really wanted something on the order of 100 cycles but if that's either not achievable or takes multiple iterations, that's probably okay. But I'll check with Andy (he's the "director of new products" so he's the one defining what the chip should be able to do).

Sounds good. I'll keep looking into it either way. With a running crystal oscillator, getting an output clock on a rising edge of an output-enable is super fast. But starting up the dead crystal is what takes ages. I definitely see how a super fast startup would help a duty cycled IoT installation. It just makes things... atypical.

Make it as fast as you can get it with a reasonable amount of effort. No need to go overboard.