I can only give a 'blow' signal from outside the chip, which fully turns on a big PMOS FET that dumps lots of current into the fuse. The only variability would be in lowering or raising the 3.3V supply.
You may be able to pulse the drive as well ?
Can this connect to a smart pin, or is it Software Drive only ?
With an effective thickness value, you can calculate the MA/cm2 value that elector migration uses.
There is probably also an estimate possible on 'C/ns thermal slope as well.
I think you could approach electro-migration from below, eg derive that 'C/ns and use that to keep below melting (and avoid those Debris and Shards) , and count the resulting low-duty pulses needed to elevate the resistance.
Vcc vary can help control the 'C/ns if needed, as that will be a square law.
I can only give a 'blow' sjignal from outside the chip, which fully turns on a big PMOS FET that dumps lots of current into the fuse. The only variability would be in lowering or raising the 3.3V supply.
You may be able to pulse the drive as well ?
Can this connect to a smart pin, or is it Software Drive only ?
With an effective thickness value, you can calculate the MA/cm2 value that elector migration uses.
There is probably also an estimate possible on 'C/ns thermal slope as well.
I think you could approach electro-migration from below, eg derive that 'C/ns and use that to keep below melting (and avoid those Debris and Shards) , and count the resulting low-duty pulses needed to elevate the resistance.
Vcc vary can help control the 'C/ns if needed, as that will be a square law.
That is a great idea I must get more test boards built, so we'll have more fuses to blow.
I can only give a 'blow' sjignal from outside the chip, which fully turns on a big PMOS FET that dumps lots of current into the fuse. The only variability would be in lowering or raising the 3.3V supply.
You may be able to pulse the drive as well ?
Can this connect to a smart pin, or is it Software Drive only ?
With an effective thickness value, you can calculate the MA/cm2 value that elector migration uses.
There is probably also an estimate possible on 'C/ns thermal slope as well.
I think you could approach electro-migration from below, eg derive that 'C/ns and use that to keep below melting (and avoid those Debris and Shards) , and count the resulting low-duty pulses needed to elevate the resistance.
Vcc vary can help control the 'C/ns if needed, as that will be a square law.
That is a great idea I must get more test boards built, so we'll have more fuses to blow.
Trying to get rough ballpark numbers for ˚C/ns, the Specific heat is one path.
That indicates 100mW for 1us, will heat 1 nano-gm by 100˚C
or 100mW for 100ns and 100 pico-gm will heat by 100˚C
Effective mass is harder to nail down, I can get values like 1 or 3 or 10 pico-gms, but that region means 1us is looking long, in heating terms.
Maybe test something like 30~100ns pulses every 10us, and count pulses to blow ? & move up from there..
Capturing the current shape, for every pulse, could help confirm the ˚C/ns values, and track the resistance changes.
With luck, OnSemi will have some test info themselves around this.
I did some contract work for a company specializing in things like this. They had me lay out a die, filled with fuses and a lot of test pads.
They would apply various processes to them, blowing them electrically, zapping them with a precision laser, etc...
A lot of what I was asked to make involved different geometries for controlling what blew up. Many were simply bars of various thicknesses, but some had notches, or simply bits missing to control the behavior better.
It may be worth thinking about the fuse geometry in addition to the electrical and thermal factors.
OnSemi has layout rules for fuses. They are of one type and one size, with certain contact patterns. I just don't know if these were intended to blow up and make a mess, or be modified through high current to cause the metal atoms in the poly silicide to get smeared in one direction, upping the resistance. The guy I talked to this morning at OnSemi didn't know for sure, but thought that they were meant to blow up. We're waiting for someone at OnSemi with some certain knowledge to say something. I'm kind of nervous about the whole thing.
Meanwhile, I didn't like the way the PLL was working, so I made it better, with an active load to switch the VCO bias sources to when they are not driving the bias up or down. It cuts switching noise down to a few millivolts and prevents the phase distortions that were occurring due to charge sharing when the UP or DN signals went high. Those layout changes will be more complicated than the others.
Here's the new VCO, which is the heart of the PLL:
I just don't know if these were intended to blow up and make a mess, or be modified through high current to cause the metal atoms in the poly silicide to get smeared in one direction, upping the resistance. The guy I talked to this morning at OnSemi didn't know for sure, but thought that they were meant to blow up. We're waiting for someone at OnSemi with some certain knowledge to say something. I'm kind of nervous about the whole thing.
Looking closely at the picture in the link I gave above, I think they progress as Electro Migration initially, and as that high current density results in a neck-down or weak spot, then it likely becomes thermally regenerative and locally melts, to pull back (round the ends?) and give a small gap.
That's a little more finesse, than a 'whack it with a big hammer', which is more of the "blow up and make a mess" end.
Meanwhile, I didn't like the way the PLL was working, so I made it better, with an active load to switch the VCO bias sources to when they are not driving the bias up or down. It cuts switching noise down to a few millivolts and prevents the phase distortions that were occurring due to charge sharing when the UP or DN signals went high. Those layout changes will be more complicated than the others.
Here's the new VCO, which is the heart of the PLL:
Sounds good.
Did you manage to work in the small Post-VCO divide and Xtal Dividers ? - to give better ranges and reduce the swing asked of the VCO itself.
I would only feel confident adding a post-divider for the VCO. A pre-divider for the crystal could slow feedback too much.
Yes, but most systems do specify a PFD MHz limit to cover this issue.
The main benefit of a Crystal divider, is it allows the more common higher frequency sources, to still have good granularity. ie more frequency choices.
....And just a post-divider wouldn't have much practical benefit.
? A post divider has multiple practical benefits
* It gives a much wider fSys, & allows 'sloth-modes' for lowest system power
It is common to see 8-bit fSys dividers even in very cheap MCUs for this reason.
* It gives more choice on the VCO operating point
Users are no longer forced to lower the VCO to higher jitter operating area, if they need a lower fSys
* It gives production protection insurance - if you find the jitter-degrade is worse on a final device, a post divider gives a means to limit the VCO range to ~ 2:1, without a serious limit on the user fSys. (This one alone is worth it.)
* It expands the useful VCO sweep, and also improves granularity
The divider will work to the VCO limit, and this adds >200MHz/2 as a valid point
You specify in the data a fCpu MHz max and a PFD MHz min, and a VCO MHz max, and the user can look for solutions with 3 numbers ( Xtal/K)*N/M, not just Xtal * N
If you want to default K=1 and M=1, then the operation is simplified to as-now.
- If we fed the XI input to a 6-bit divider
- If we fed the VCO output into a 10-bit divider
- If we fed both divider outputs into the phase frequency detector
XI divided by 6-bit value into the reference input
VCO divided by 10-bit value into the variable input
- If we used the VCO output as the system clock source
...Then we could get all kinds of frequencies from a 20MHz crystal.
By setting the 6-bit XI divider to 40, we could get any useful frequency in 500KHz steps.
The digital side of this is really simple. I'd just increase the current divider from 4 bits to separate 6 and 10 bit instances.
The worrisome part is the loop filter that drives the VCO. That is hard to prove, as simulations would take a long time to cover for XI/64. Also, it would probably be necessary to have 4 bits worth of feedback tuning in the loop filter. I think the design would be really simple, just determining those feedback strengths would be challenging. For each bit, it would just be a NMOS and a resistor. The four bits would drive R, 2R, 4R, 8R resistors. I don't think, and hope not, that the capacitors would have to become variable.
By setting the 6-bit XI divider to 40, we could get any useful frequency in 500KHz steps.
The digital side of this is really simple. I'd just increase the current divider from 4 bits to separate 6 and 10 bit instances.
Yes, that's the idea. (A post VCO divider is still useful to limit the VCO range)
The worrisome part is the loop filter that drives the VCO. That is hard to prove, as simulations would take a long time to cover for XI/64. Also, it would probably be necessary to have 4 bits worth of feedback tuning in the loop filter. I think the design would be really simple, just determining those feedback strengths would be challenging. For each bit, it would just be a NMOS and a resistor. The four bits would drive R, 2R, 4R, 8R resistors. I don't think, and hope not, that the capacitors would have to become variable.
You can specify a range for the PFD, if that is required.
eg 500kHz ~ 5MHz
The NXP MCUs have a PLL/CCO design and the LPC17xx quotes values like
The input frequency is multiplied up to a high frequency, then divided down to provide the actual
clock used by the CPU.
The PLL0 input, in the range of 32 kHz to 25 MHz, may initially be divided down by a
value ‘N’, which may be in the range of 1 to 256.
Following the PLL0 input divider is the PLL0 multiplier. This can multiply the input divider
output through the use of a Current Controlled Oscillator (CCO) by a value ‘M’, in the
range of 1 through 32768. The resulting frequency must be in the range of 275 MHz to
550 MHz.
So they are a little extreme, in including 32kHz (likely with a custom PFD filter), but that has appeal since it allows use of a RTC to operate the PLL.
VCO range is limited to 2:1 and they use post CCO dividers for fSys.
That data does not nail down a PFD min, but I think I've seen it somewhere ... **
There is also a XLS calculator, which seems to have 'undocumented' limit checks on values...
** The user manual has more values.
Confirms 32kHz is a special case.
They mention < 1MHz as one fRef special case point, then < 400KHz, and they mention for 100kHZ~20MHz fRef range where PLOCK0 bit in the PLL0STAT register, is valid, outside that range the lock bit is less valid, and they suggest a time-based wait-to-lock.
A 100kHz ~ 20MHz fRef sounds quite good.
I realized something about PLL's today: The weaker the bias adjust current, the higher the resistance must be in the bias loop filter to keep it properly dampened. And the same resistor value that is used in the loop filter can be used to generate the bias adjust current. This simple fact has eluded me until today. Once I realized that the goal is to maintain proper dampening in the loop filter, regardless of impedance, it all came together.
To keep this simple, I made a resistor that is settable to 1Megohm/R, where R is a 6-bit input value ranging from 1..63:
Then I put two instances into the VCO. One sets the bias current and the other sets the loop filter resistance:
The reference clock (20MHz, XI pin) can be divided by 2..64 to feed the reference input of the PLL. The VCO output can be divided by 2..1024 to feed the variable input of the PLL. The phase frequency detector (PFD) generates UP/DN pulses proportional to the divided reference clock. The bigger the division, the less frequent and longer are the UP/DN pulse outputs from the PFD, necessitating proportionally weaker bias drive and higher filter loop resistance. That's where the 6-bit settable resistor comes in. For reference dividers of 2..64, resistor settings would be 63..1, which keeps things nicely proportional.
Here's reference/2 and VCO/2, which uses the lowest-impedance resistor setting of %111111:
Here's reference/64 and VCO/64, which uses the high-impedance resistor setting of %000001:
You can see the dampening factor remains somewhat constant at these frequency extremes, while time scales proportionally to the divided reference. You can see the 32x time difference.
I improved the UP/DN current generator by putting in an op-amp to pull the 1M/R resistor up to a stable voltage. This arrangement generates a PMOS bias voltage which is used in the UP/DN switch section.
Also, the loop filter C was increased by 4, which seemed to help everything. I didn't want to make the resistor any bigger, so I made the C bigger.
Here's the new VCO schematic:
Here is the PLL locking 20MHz/2 : VCO/2 at the fastest loop rate (F=%111111):
Same thing at the slowest loop rate (F=%000001):
I'm now running a test for 20MHz/64 : VCO/64. I think it will work pretty well.
The only thing I need to do now is simulate at the corners and try FAST+HIGHV+HOT, as that should show the leakiest devices possible. When very gentle currents are flowing, device leakages can swamp them out. That would be a problem, but can be gotten around by designing so that OFF transistors are not just Vgs=0, but as negative as possible. Those little transistors connected to BIASp and BIASn, with Ep and En on their other pins, pull the biases back when the VCO is disabled, and also turn super-OFF when the VCO is enabled.
I just measured the UP/DN currents at only 17 nanoamps in the slow (%000001) mode.
The 20MHz/64 : VCO/64 test at the slowest loop rate (%000001) looks good:
Note that the markers are 160us apart.
Here, again, is the 20Mhz/2 : VCO/2 test at the fastest loop rate (%111111):
If you measure time at the same humps as marked in the upper test, and compare them, they are almost exactly 63:1. This is good news. Also, the dampening factor looks identical and appropriate. The voltage spans are almost identical, too. In case you're wondering (Jmg) how come the settling voltage is always different, it's because the VCO's power is coming through an RC filter and with each different setting, the current changes a little.
Tomorrow I will simulate cases where leakage should be at its worst, in case the design needs changing. This is it for the PLL. The dividers are purely digital circuits and they are done. I think I will make this 6-bit loop time setting independent of the XI and VCO dividers, as there could be some advantage to keeping things untangled.
...
To keep this simple, I made a resistor that is settable to 1Megohm/R, where R is a 6-bit input value ranging from 1..63:
...
The reference clock (20MHz, XI pin) can be divided by 2..64 to feed the reference input of the PLL. The VCO output can be divided by 2..1024 to feed the variable input of the PLL.
...
Here's reference/2 and VCO/2, which uses the lowest-impedance resistor setting of %111111:
Here's reference/64 and VCO/64, which uses the high-impedance resistor setting of %000001:
I think I will make this 6-bit loop time setting independent of the XI and VCO dividers, as there could be some advantage to keeping things untangled.
Yup, I'd agree.
It also gives some production insurance in place, in case a real device has issues at either analog extreme.
I've also seen PLL's coded where they use varying filter values during Lock and Run.
Q: How hard is it to add a Lock-Bit ? - in simplest form this uses the ever-narrowing error widths on UP-DN, and drives a low-pass RC pulldown -> Schmitt.
Code then looks for Lock-Bit stable for > some min time.
The dividers are purely digital circuits and they are done.
I still think a Post-VCO SysCLK divider is needed, to finish this, but of course that can be outside the PAD Ring, and done in the Verilog. 8 bits seems to be a common value, NXP have that (/N ), some little MCUs have 7-bit /2^N, but I would favour the more granular /N as that improves the ppm numbers.
Some examples of what this change has gained:
Suppose you have 19.2MHz TCXO, and want 24/48MHz multiple.
In the older design, you were rarely lucky, and 19.2 * 5 = 96MHz, but that was it...
In the new design, if 96MHz is found late in the design to be too slow, now you can
try 144MHz -> (48*3)/19.2 = 7.5 (48*3)/(19.2/2) = 15 - Select 2 & 15
or, imagine the P2 Chip does not quite make 144MHz, (or you want to save power) but you still need > 96 ?
48*2.5 = 120, (48*2.5)/(19.2/4) = 25 - Select 4 & 25
Now let's get a little harder, imagine supply or management dictates you use a 26MHz TCXO....
Solutions are 26M/2 for a 0.69% error or 26M/13 for 0ppm - Select 13 and 72 (or 13 & 60, for 120MHz)
.. and another example, getting harder again...
You want 25.175MHz * 4 as a SysCLK.... from a 26MHz TCXO .. hmmm ?
Solution A: (25.175M*4)/120 PFD = 839.166kHz (Select 31 and 120 )
Error is = -544ppm
Solution A':
(25.175M*4)/62 = 1.624193MHz PFD ( select 16 and 62 )
Error is slightly better at +496.277ppm
Both are well under 1 pixel/line, but still not sure if that is a problem ? You can test with this
Solution B: (25.175M*4)/244 = 412.70491kHz PFD ( Select 244 and 63)
Error is = 15.762ppm
Addit: Another example, (target 29.760MHz * 4 )
Web gives this // 800x480 @ 60 Hz
.pixel_clock_kHz = 29760,
.hpixels = 800, .hfp= 24, .hsw= 72, .hbp= 96, // 992 total
.vlines = 480, .vfp= 3, .vsw= 10, .vbp= 7, // 500 total
From 26MHz TCXO ( Select 87 and 19)
1-87*26M/19/(29.760M*4) = -106.112ppm (appx 1/12 of one pixel)
PFD = 26M/19 = 1.368421MHz
From 19.2MHz TCXO (Select 31 and 5)
1-31*19.2M/5/(29.760M*4) = 0.0ppm
PFD = 19.2M/5 = 3.840MHz
While you have Spice open & running, there is one other small test worth doing...
The TCXOs I mention above and before, are all Clipped Sine, which actually means 0.8v p-p Low pass Square Wave as a signal source. (roughly, tr~tf~th~tl)
This would AC couple (100pF~1nF) into a standard Crystal Amplifier, with smallest CL selected.
Lower CL will help here.
There will be some limit MHz, where the Gain of the Xtal Buffer is not enough to exceed the schmitt buffer threshold, when driven this way.
Lowest Vcc and Highest Temp will be the worst corner.
My Spice runs here on a rough appx of HCU04 and 2.7V, show < 20MHz is ok, and something > 30MHz looks marginal.
Can you run with the actual Xtal Buffer + CL models, and check where this MHz limit is ?
While you have Spice open & running, there is one other small test worth doing...
The TCXOs I mention above and before, are all Clipped Sine, which actually means 0.8v p-p Low pass Square Wave as a signal source. (roughly, tr~tf~th~tl)
This would AC couple (100pF~1nF) into a standard Crystal Amplifier, with smallest CL selected.
Lower CL will help here.
There will be some limit MHz, where the Gain of the Xtal Buffer is not enough to exceed the schmitt buffer threshold, when driven this way.
Lowest Vcc and Highest Temp will be the worst corner.
My Spice runs here on a rough appx of HCU04 and 2.7V, show < 20MHz is ok, and something > 30MHz looks marginal.
Can you run with the actual Xtal Buffer + CL models, and check where this MHz limit is ?
The XI input is not Schmitt, just logic level. It sounds like you're thinking it's a Schmitt input.
I think we would just capacitively couple the clipped sine osc into the XI pin, right?
To make these slow feedback loops work best, we'd really need a VDD_PLL pin on the package, where a filtered VDD could be applied just for the PLL. Right now, the internal RC power filter slows down VDD changes so that the circuit can actively adjust, but for reference-clock feedback occuring at 312.5 KHz (20 MHz / 64), there may be some issues. The VCO inverters are designed to be VDD-independent, as they work in current modes, but straight MOSFETs are not perfect current sources, as they do vary slighty with Vgd. Slow VDD changes will cause some frequency change. I need to do a simulation where I step the power supply by 200mV after lock is achieved, to see what happens.
The XI input is not Schmitt, just logic level. It sounds like you're thinking it's a Schmitt input.
Not the XI - The XOsc stage itself (XI to XO) is an unbuffereed P/N pair, but it should drive into a Schmitt buffer internally, to square up the sine wave, for the SysCLK ?
It is when the XO drops below that internal schmitt buffer threshold, that the clock effectively dies.
Usually that's roughly where XI-XO has unity gain, or a little less. ( Depends on the Hysteresis wrt 0.8v, and how threshold matched it is)
We could add a lock bit, but I've always figured that there could be simple rules to predict how long the lock would take, at a maximum.
NXP do both - the appeal of a lock bit is for most cases, it can give faster start times, and it (pretty much) proves you have a valid clock source, before switch-over.
At extreme cases, NXP do give time-formula too..
If the Crystal or VCO fails, how can a user know ?
ISTR there are some software quality standards that require this 'confirm before change' approach to clock management.
Some MCUs have a Clock Fail detector, which can be a small monostable >> slowest expected clock.
Ah, there is no Schmitt inside, just 4 series inverters (A connects to the XI pin):
I guess you check using that circuit then ?
A Schmitt gives some noise and RF immunity, as small added signals are ignored.
It also reduces the chances of a too-narrow runt clock pulse getting through.
Ah, there is no Schmitt inside, just 4 series inverters (A connects to the XI pin):
I guess you check using that circuit then ?
A Schmitt gives some noise and RF immunity, as small added signals are ignored.
It also reduces the chances of a too-narrow runt clock pulse getting through.
That's how the Prop1 works, too. The 15pF/30pF loading caps are each split in two and half are to VIO (3.3V) and half are to GIO (GND). Any power supply noise gets applied equally to XI and XO, which gives pretty good consistency for edges occurring when you'd expect them. I kind of like the current arrangement and I imagine that a Schmitt would mainly increase phase noise. If there's just a crystal connected, it's a pretty private matter, but I could see external signals coming from without having issues.
We could add a lock bit, but I've always figured that there could be simple rules to predict how long the lock would take, at a maximum.
NXP do both - the appeal of a lock bit is for most cases, it can give faster start times, and it (pretty much) proves you have a valid clock source, before switch-over.
At extreme cases, NXP do give time-formula too..
If the Crystal or VCO fails, how can a user know ?
ISTR there are some software quality standards that require this 'confirm before change' approach to clock management.
Some MCUs have a Clock Fail detector, which can be a small monostable >> slowest expected clock.
David at Parallax had a neat idea about making COGINIT be able to launch cogs with some flags that restrict the started cog's usage of hub memory and I/O pins, as well as doing COGINITs and COGSTOPs. The idea is to be able to have a bullet-proof mode, where during development, things can be limited to not allow a rogue cog to crash the whole chip. This would be good for on-chip development. I always pictured one Prop2 being the development tool and another being the slave. Dave was saying that it would be much nicer to have immediate access to the memories and things. I agree. It would also mean that you wouldn't wind up needing two monitors and two mice for most projects, as they could be on the same system. Think of a PLC that runs while you can make modifications to it, even storing the source code locally on it.
Taken to the extreme, this would entail memory protection by range and a bunch of other things, but we don't need that now. Just some simple limiters to allow cog development without jeopardizing the development system's processes. This could be maybe ten flops per cog.
Comments
Can this connect to a smart pin, or is it Software Drive only ?
With an effective thickness value, you can calculate the MA/cm2 value that elector migration uses.
There is probably also an estimate possible on 'C/ns thermal slope as well.
I think you could approach electro-migration from below, eg derive that 'C/ns and use that to keep below melting (and avoid those Debris and Shards) , and count the resulting low-duty pulses needed to elevate the resistance.
Vcc vary can help control the 'C/ns if needed, as that will be a square law.
That is a great idea I must get more test boards built, so we'll have more fuses to blow.
Trying to get rough ballpark numbers for ˚C/ns, the Specific heat is one path.
That indicates 100mW for 1us, will heat 1 nano-gm by 100˚C
or 100mW for 100ns and 100 pico-gm will heat by 100˚C
Effective mass is harder to nail down, I can get values like 1 or 3 or 10 pico-gms, but that region means 1us is looking long, in heating terms.
Maybe test something like 30~100ns pulses every 10us, and count pulses to blow ? & move up from there..
Capturing the current shape, for every pulse, could help confirm the ˚C/ns values, and track the resistance changes.
With luck, OnSemi will have some test info themselves around this.
They would apply various processes to them, blowing them electrically, zapping them with a precision laser, etc...
A lot of what I was asked to make involved different geometries for controlling what blew up. Many were simply bars of various thicknesses, but some had notches, or simply bits missing to control the behavior better.
It may be worth thinking about the fuse geometry in addition to the electrical and thermal factors.
Meanwhile, I didn't like the way the PLL was working, so I made it better, with an active load to switch the VCO bias sources to when they are not driving the bias up or down. It cuts switching noise down to a few millivolts and prevents the phase distortions that were occurring due to charge sharing when the UP or DN signals went high. Those layout changes will be more complicated than the others.
Here's the new VCO, which is the heart of the PLL:
The good news is they have something, and so they should also have test and drive data and yields for this.
Looking closely at the picture in the link I gave above, I think they progress as Electro Migration initially, and as that high current density results in a neck-down or weak spot, then it likely becomes thermally regenerative and locally melts, to pull back (round the ends?) and give a small gap.
That's a little more finesse, than a 'whack it with a big hammer', which is more of the "blow up and make a mess" end.
Sounds good.
Did you manage to work in the small Post-VCO divide and Xtal Dividers ? - to give better ranges and reduce the swing asked of the VCO itself.
I think I'll just leave it as it is.
Yes, but most systems do specify a PFD MHz limit to cover this issue.
The main benefit of a Crystal divider, is it allows the more common higher frequency sources, to still have good granularity. ie more frequency choices.
? A post divider has multiple practical benefits
* It gives a much wider fSys, & allows 'sloth-modes' for lowest system power
It is common to see 8-bit fSys dividers even in very cheap MCUs for this reason.
* It gives more choice on the VCO operating point
Users are no longer forced to lower the VCO to higher jitter operating area, if they need a lower fSys
* It gives production protection insurance - if you find the jitter-degrade is worse on a final device, a post divider gives a means to limit the VCO range to ~ 2:1, without a serious limit on the user fSys. (This one alone is worth it.)
* It expands the useful VCO sweep, and also improves granularity
The divider will work to the VCO limit, and this adds >200MHz/2 as a valid point
You specify in the data a fCpu MHz max and a PFD MHz min, and a VCO MHz max, and the user can look for solutions with 3 numbers ( Xtal/K)*N/M, not just Xtal * N
If you want to default K=1 and M=1, then the operation is simplified to as-now.
- If we fed the XI input to a 6-bit divider
- If we fed the VCO output into a 10-bit divider
- If we fed both divider outputs into the phase frequency detector
VCO divided by 10-bit value into the variable input
...Then we could get all kinds of frequencies from a 20MHz crystal.
By setting the 6-bit XI divider to 40, we could get any useful frequency in 500KHz steps.
The digital side of this is really simple. I'd just increase the current divider from 4 bits to separate 6 and 10 bit instances.
The worrisome part is the loop filter that drives the VCO. That is hard to prove, as simulations would take a long time to cover for XI/64. Also, it would probably be necessary to have 4 bits worth of feedback tuning in the loop filter. I think the design would be really simple, just determining those feedback strengths would be challenging. For each bit, it would just be a NMOS and a resistor. The four bits would drive R, 2R, 4R, 8R resistors. I don't think, and hope not, that the capacitors would have to become variable.
You can specify a range for the PFD, if that is required.
eg 500kHz ~ 5MHz
The NXP MCUs have a PLL/CCO design and the LPC17xx quotes values like
The input frequency is multiplied up to a high frequency, then divided down to provide the actual
clock used by the CPU.
The PLL0 input, in the range of 32 kHz to 25 MHz, may initially be divided down by a
value ‘N’, which may be in the range of 1 to 256.
Following the PLL0 input divider is the PLL0 multiplier. This can multiply the input divider
output through the use of a Current Controlled Oscillator (CCO) by a value ‘M’, in the
range of 1 through 32768. The resulting frequency must be in the range of 275 MHz to
550 MHz.
So they are a little extreme, in including 32kHz (likely with a custom PFD filter), but that has appeal since it allows use of a RTC to operate the PLL.
VCO range is limited to 2:1 and they use post CCO dividers for fSys.
That data does not nail down a PFD min, but I think I've seen it somewhere ... **
There is also a XLS calculator, which seems to have 'undocumented' limit checks on values...
https://www.lpcware.com/content/nxpfile/lpc17xx-pll0-calculator
** The user manual has more values.
Confirms 32kHz is a special case.
They mention < 1MHz as one fRef special case point, then < 400KHz, and they mention for 100kHZ~20MHz fRef range where PLOCK0 bit in the PLL0STAT register, is valid, outside that range the lock bit is less valid, and they suggest a time-based wait-to-lock.
A 100kHz ~ 20MHz fRef sounds quite good.
To keep this simple, I made a resistor that is settable to 1Megohm/R, where R is a 6-bit input value ranging from 1..63:
Then I put two instances into the VCO. One sets the bias current and the other sets the loop filter resistance:
The reference clock (20MHz, XI pin) can be divided by 2..64 to feed the reference input of the PLL. The VCO output can be divided by 2..1024 to feed the variable input of the PLL. The phase frequency detector (PFD) generates UP/DN pulses proportional to the divided reference clock. The bigger the division, the less frequent and longer are the UP/DN pulse outputs from the PFD, necessitating proportionally weaker bias drive and higher filter loop resistance. That's where the 6-bit settable resistor comes in. For reference dividers of 2..64, resistor settings would be 63..1, which keeps things nicely proportional.
Here's reference/2 and VCO/2, which uses the lowest-impedance resistor setting of %111111:
Here's reference/64 and VCO/64, which uses the high-impedance resistor setting of %000001:
You can see the dampening factor remains somewhat constant at these frequency extremes, while time scales proportionally to the divided reference. You can see the 32x time difference.
Also, the loop filter C was increased by 4, which seemed to help everything. I didn't want to make the resistor any bigger, so I made the C bigger.
Here's the new VCO schematic:
Here is the PLL locking 20MHz/2 : VCO/2 at the fastest loop rate (F=%111111):
Same thing at the slowest loop rate (F=%000001):
I'm now running a test for 20MHz/64 : VCO/64. I think it will work pretty well.
The only thing I need to do now is simulate at the corners and try FAST+HIGHV+HOT, as that should show the leakiest devices possible. When very gentle currents are flowing, device leakages can swamp them out. That would be a problem, but can be gotten around by designing so that OFF transistors are not just Vgs=0, but as negative as possible. Those little transistors connected to BIASp and BIASn, with Ep and En on their other pins, pull the biases back when the VCO is disabled, and also turn super-OFF when the VCO is enabled.
I just measured the UP/DN currents at only 17 nanoamps in the slow (%000001) mode.
Note that the markers are 160us apart.
Here, again, is the 20Mhz/2 : VCO/2 test at the fastest loop rate (%111111):
If you measure time at the same humps as marked in the upper test, and compare them, they are almost exactly 63:1. This is good news. Also, the dampening factor looks identical and appropriate. The voltage spans are almost identical, too. In case you're wondering (Jmg) how come the settling voltage is always different, it's because the VCO's power is coming through an RC filter and with each different setting, the current changes a little.
Tomorrow I will simulate cases where leakage should be at its worst, in case the design needs changing. This is it for the PLL. The dividers are purely digital circuits and they are done. I think I will make this 6-bit loop time setting independent of the XI and VCO dividers, as there could be some advantage to keeping things untangled.
Yes. You can divide the crystal frequency by 2..64 and then multiply it by 2..1024. Any resultant frequency from 20MHz to 160MHz+ is okay.
Nice curves and nice numbers !
Yup, I'd agree.
It also gives some production insurance in place, in case a real device has issues at either analog extreme.
I've also seen PLL's coded where they use varying filter values during Lock and Run.
Q: How hard is it to add a Lock-Bit ? - in simplest form this uses the ever-narrowing error widths on UP-DN, and drives a low-pass RC pulldown -> Schmitt.
Code then looks for Lock-Bit stable for > some min time.
I still think a Post-VCO SysCLK divider is needed, to finish this, but of course that can be outside the PAD Ring, and done in the Verilog. 8 bits seems to be a common value, NXP have that (/N ), some little MCUs have 7-bit /2^N, but I would favour the more granular /N as that improves the ppm numbers.
Some examples of what this change has gained:
Suppose you have 19.2MHz TCXO, and want 24/48MHz multiple.
In the older design, you were rarely lucky, and 19.2 * 5 = 96MHz, but that was it...
In the new design, if 96MHz is found late in the design to be too slow, now you can
try 144MHz -> (48*3)/19.2 = 7.5 (48*3)/(19.2/2) = 15 - Select 2 & 15
or, imagine the P2 Chip does not quite make 144MHz, (or you want to save power) but you still need > 96 ?
48*2.5 = 120, (48*2.5)/(19.2/4) = 25 - Select 4 & 25
Now let's get a little harder, imagine supply or management dictates you use a 26MHz TCXO....
Solutions are 26M/2 for a 0.69% error or 26M/13 for 0ppm - Select 13 and 72 (or 13 & 60, for 120MHz)
.. and another example, getting harder again...
You want 25.175MHz * 4 as a SysCLK.... from a 26MHz TCXO .. hmmm ?
Solution A: (25.175M*4)/120 PFD = 839.166kHz (Select 31 and 120 )
Error is = -544ppm
Solution A':
(25.175M*4)/62 = 1.624193MHz PFD ( select 16 and 62 )
Error is slightly better at +496.277ppm
Both are well under 1 pixel/line, but still not sure if that is a problem ? You can test with this
Solution B: (25.175M*4)/244 = 412.70491kHz PFD ( Select 244 and 63)
Error is = 15.762ppm
Addit: Another example, (target 29.760MHz * 4 )
Web gives this // 800x480 @ 60 Hz
.pixel_clock_kHz = 29760,
.hpixels = 800, .hfp= 24, .hsw= 72, .hbp= 96, // 992 total
.vlines = 480, .vfp= 3, .vsw= 10, .vbp= 7, // 500 total
From 26MHz TCXO ( Select 87 and 19)
1-87*26M/19/(29.760M*4) = -106.112ppm (appx 1/12 of one pixel)
PFD = 26M/19 = 1.368421MHz
From 19.2MHz TCXO (Select 31 and 5)
1-31*19.2M/5/(29.760M*4) = 0.0ppm
PFD = 19.2M/5 = 3.840MHz
I'm pretty sure, but I'll check it.
The TCXOs I mention above and before, are all Clipped Sine, which actually means 0.8v p-p Low pass Square Wave as a signal source. (roughly, tr~tf~th~tl)
This would AC couple (100pF~1nF) into a standard Crystal Amplifier, with smallest CL selected.
Lower CL will help here.
There will be some limit MHz, where the Gain of the Xtal Buffer is not enough to exceed the schmitt buffer threshold, when driven this way.
Lowest Vcc and Highest Temp will be the worst corner.
My Spice runs here on a rough appx of HCU04 and 2.7V, show < 20MHz is ok, and something > 30MHz looks marginal.
Can you run with the actual Xtal Buffer + CL models, and check where this MHz limit is ?
The XI input is not Schmitt, just logic level. It sounds like you're thinking it's a Schmitt input.
I think we would just capacitively couple the clipped sine osc into the XI pin, right?
Yup. That's the AC couple (100pF~1nF) part above.
Not the XI - The XOsc stage itself (XI to XO) is an unbuffereed P/N pair, but it should drive into a Schmitt buffer internally, to square up the sine wave, for the SysCLK ?
It is when the XO drops below that internal schmitt buffer threshold, that the clock effectively dies.
Usually that's roughly where XI-XO has unity gain, or a little less. ( Depends on the Hysteresis wrt 0.8v, and how threshold matched it is)
In my schematics, double-lined symbols are 3.3V circuits, while single-lined symbols are 1.8V circuits.
At extreme cases, NXP do give time-formula too..
If the Crystal or VCO fails, how can a user know ?
ISTR there are some software quality standards that require this 'confirm before change' approach to clock management.
Some MCUs have a Clock Fail detector, which can be a small monostable >> slowest expected clock.
I guess you check using that circuit then ?
A Schmitt gives some noise and RF immunity, as small added signals are ignored.
It also reduces the chances of a too-narrow runt clock pulse getting through.
That's how the Prop1 works, too. The 15pF/30pF loading caps are each split in two and half are to VIO (3.3V) and half are to GIO (GND). Any power supply noise gets applied equally to XI and XO, which gives pretty good consistency for edges occurring when you'd expect them. I kind of like the current arrangement and I imagine that a Schmitt would mainly increase phase noise. If there's just a crystal connected, it's a pretty private matter, but I could see external signals coming from without having issues.
I'll think about this.
Taken to the extreme, this would entail memory protection by range and a bunch of other things, but we don't need that now. Just some simple limiters to allow cog development without jeopardizing the development system's processes. This could be maybe ten flops per cog.