Prop2 Analog Test Chip Arrived!

178101213

Comments

  • jmgjmg Posts: 13,845
    cgracey wrote: »
    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.
  • jmg wrote: »
    cgracey wrote: »
    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.
  • jmgjmg Posts: 13,845
    edited 2016-11-23 - 00:29:27
    cgracey wrote: »
    jmg wrote: »
    cgracey wrote: »
    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.

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • cgraceycgracey Posts: 11,655
    edited 2016-11-23 - 04:41:13
    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:

    VCO_sch_new.png
    1723 x 1324 - 53K
  • jmgjmg Posts: 13,845
    edited 2016-11-23 - 05:20:24
    cgracey wrote: »
    OnSemi has layout rules for fuses. They are of one type and one size, with certain contact patterns.

    The good news is they have something, and so they should also have test and drive data and yields for this.
    cgracey wrote: »
    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.
    cgracey wrote: »
    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.
  • cgraceycgracey Posts: 11,655
    edited 2016-11-23 - 15:46:30
    ....And just a post-divider wouldn't have much practical benefit.

    I think I'll just leave it as it is.
  • jmgjmg Posts: 13,845
    cgracey wrote: »
    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.

    cgracey wrote: »
    ....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.
  • Thinking about this more...

    - 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.
  • jmgjmg Posts: 13,845
    edited 2016-11-23 - 20:50:07
    cgracey wrote: »
    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)

    cgracey wrote: »
    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.
  • cgraceycgracey Posts: 11,655
    edited 2016-11-24 - 10:35:14
    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:

    VCO_RESISTOR.png

    Then I put two instances into the VCO. One sets the bias current and the other sets the loop filter resistance:

    VCO_sch2.png

    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:

    PLL_DIV2.png

    Here's reference/64 and VCO/64, which uses the high-impedance resistor setting of %000001:

    PLL_DIV64.png

    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.
    1741 x 2187 - 63K
    2484 x 2567 - 109K
    2092 x 850 - 41K
    2092 x 1119 - 47K
  • cgraceycgracey Posts: 11,655
    edited 2016-11-24 - 14:07:06
    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:

    VCO_sch3.png

    Here is the PLL locking 20MHz/2 : VCO/2 at the fastest loop rate (F=%111111):

    VCO_DIV2_FAST.png

    Same thing at the slowest loop rate (F=%000001):

    VCO_DIV2_SLOW.png

    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.

    2314 x 2019 - 99K
    2082 x 858 - 33K
    2094 x 852 - 36K
  • cgraceycgracey Posts: 11,655
    edited 2016-11-24 - 15:08:26
    The 20MHz/64 : VCO/64 test at the slowest loop rate (%000001) looks good:

    VCO_DIV64_SLOW.png

    Note that the markers are 160us apart.

    Here, again, is the 20Mhz/2 : VCO/2 test at the fastest loop rate (%111111):

    VCO_DIV2_FAST.png

    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.

    2096 x 876 - 35K
    2082 x 858 - 33K
  • So, with these changes to the PLL, does that affect our options for setting the PLL frequency in code?
  • cgraceycgracey Posts: 11,655
    edited 2016-11-24 - 16:08:37
    Seairth wrote: »
    So, with these changes to the PLL, does that affect our options for setting the PLL frequency in code?

    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.
  • jmgjmg Posts: 13,845
    edited 2016-11-24 - 21:55:34
    Wow, you have been busy....
    cgracey wrote: »
    ...
    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:

    Nice curves and nice numbers ! :)

    cgracey wrote: »
    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.

    cgracey wrote: »
    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




  • jmgjmg Posts: 13,845
    cgracey wrote: »
    ...The VCO output can be divided by 2..1024 to feed the variable input of the PLL.
    As a quick check, can that reloadable 10b counter, divide ok to the ~300MHz ? VCO upper ?

  • jmg wrote: »
    cgracey wrote: »
    ...The VCO output can be divided by 2..1024 to feed the variable input of the PLL.
    As a quick check, can that reloadable 10b counter, divide ok to the ~300MHz ? VCO upper ?

    I'm pretty sure, but I'll check it.
  • jmgjmg Posts: 13,845
    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 ?

  • jmg wrote: »
    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?
  • cgraceycgracey Posts: 11,655
    edited 2016-11-25 - 03:25:32
    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.
  • 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.
  • jmgjmg Posts: 13,845
    cgracey wrote: »
    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.
    cgracey wrote: »
    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)
  • cgraceycgracey Posts: 11,655
    edited 2016-11-25 - 03:51:21
    Ah, there is no Schmitt inside, just 4 series inverters (A connects to the XI pin):

    XTAL_IN_sch.png

    In my schematics, double-lined symbols are 3.3V circuits, while single-lined symbols are 1.8V circuits.

    942 x 583 - 9K
  • jmgjmg Posts: 13,845
    cgracey wrote: »
    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.

  • jmgjmg Posts: 13,845
    cgracey wrote: »
    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.

  • cgraceycgracey Posts: 11,655
    edited 2016-11-25 - 04:17:36
    jmg wrote: »
    cgracey wrote: »
    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.
  • jmg wrote: »
    cgracey wrote: »
    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.

    I'll think about this.
  • cgraceycgracey Posts: 11,655
    edited 2016-11-25 - 04:30:04
    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.
Sign In or Register to comment.