Why wasn't any of the DAC modes suitable for testing this?
There are three DACs in each pin:
1) 8-bit 1k/600-ohm parallel resistor DAC that drives the pin
2) 8-bit 120/75-ohm parallel resistor DAC that drives the pin
3) 8-bit High-Z R-2R DAC that drives the analog comparator
That last DAC doesn't output to the pin, only to an internal comparator. So, I was able to make it 'output' by going into a DAC comparator mode where the inverse of the comparator is output on the pin through a 1.5k resistor, forming a negative feedback loop which causes the pin to reflect the R-2R DAC voltage.
20 ms seems okay for the power-on delay. That's minimum of two charge cycles of a full wave rectifier, and probably a third (30 ms) from the power switching on and regulator above threshold, before the load can be brought to bare.
The one-shot could be 8-10 ms as mid ground. I don't have any reason other than 1 ms is pretty big change. Did someone have a reason for the 24 ms?
I suppose watchdog tripping should be factored in here. A long one-shot delay will limit the minimum watchdog time-out. On the other hand, a tight watchdog might cause overly rapid pulsing so maybe it's not so good to have it too small a minimum value.
One of my go-to setups for high frequency work is to solder on a short twisted pair made using wire-wrap wire from the signal and PCB ground to the probe tip and probe ground. I can extend it out 1-3 inches and got fast clean signals. This assumes you can't directly touch the probe tip to the circuit, and touch a local ground with a little ground spring. Another option for high drive signals is to make a "Low-Z" probe with a 450ohm resistor feeding 50ohm coax terminated at the oscilloscope. As long as it's built small, a Low-Z probe has good signal quality up into the 1-2GHz range and minimal capacitance. (I've got a footprint with a W.FL coax connector and resistor so I can build permanent test points into the PCB as well)
Marty
Indeed. I'm no EE and only fairly recently rekindled my interest in electronics, but the picture of the probe's ground spring being used as a support for a several inch long extension of the signal path prompted a WTH moment. http://cds.linear.com/docs/en/application-note/an47fa.pdf might be helpful (particularly the probe tutorial section contributed by Tektronix).
I know these times may be kind of slow, but they are very conservative.
I think it would be safer to shorten the 24ms one-shot time than the power-up detector time.
I can see the one-shot going down to 1ms, while the power-up detector could maybe go down to 20ms.
What do you guys think might be reasonable adjustments here? Are any adjustments needed?
Faster (re) boot from a watchdog should always be a strong focus.
POR to 20ms(max) sounds good, but you can go lower even than 1ms on a Stable-Vss reset. (below has 50us)
There is a lot more to POR than just delay times, and here is a Silabs example
4.1.3 Reset and Supply Monitor
Table 4.3. Reset and Supply Monitor
Parameter Symbol Test Condition Min Typ Max Unit
VDD Supply Monitor Threshold V VDDM 1.95 2.05 2.15 V
Power-On Reset (POR) Threshold V POR Rising Voltage on VDD — 1.2 — V
Falling Voltage on VDD 0.75 — 1.36 V
VDD Ramp Time t RMP Time to V DD > 2.2 V 10 — — µs
Reset Delay from POR t POR Relative to V DD > V POR 3 10 31 ms
Reset Delay from non-POR source t RST Time between release of reset
source and code execution — 50 — µs
RST Low Time to Generate Reset t RSTL 15 — — µs
Missing Clock Detector Response Time (final rising edge to reset)
t MCD F SYSCLK >1 MHz — 0.625 1.2 ms
Missing Clock Detector Trigger Frequency F MCD — 7.5 13.5 kHz
VDD Supply Monitor Turn-On Time t MON — 2 — µs
They have broad 3~31ms Cold start, with a typical of 10ms, and a 50us restart time.
(other vendors have ~6us restart times, some can do as low as 2 SysClks )
Note they spec a Ramp time, and a Falling voltage to re-arm the POR.
It is fairly common to find blind-spots in Vcc/Reset specs, which is why those cold start times are in the milliseconds, as it allows the Vcc time to ramp above that low release voltage, to where the core can actually run.
With the P2 RC Osc, that is (well) below the fMax, this should also help.
Can you test on the Test Chip, what voltage the RC Fast starts at, and what the core can clock at ?
What is the largest counter on the test chip ? - the 4 bit PLL Divider ?
The RESn pin and its RESET output got checked, too.
Here are the RESn pin, or reset circuit, timings:
1) Power-up detector takes 40ms from power-on to release.
2) One-shot that extends any reset source takes 24ms.
My favorite stress-test circuit for MCU reset, is a triangle wave signal generator with amplitude and DC offset controls, fed to modulate the Vcc (connect to a LM1117 for example)
This allows you to easily vary the slew rates and the peak and valley.
The most reliable parts, have no dead-spots in their reset.
The worst, need something << 1V to recover their POR states, which means a simple brownout can cause a failure.
The really bad parts I've seen, will then not recover from a HW reset pin strobe, but need a full power cycle.
Some industry sectors favour Power-removal watchdogs because of all these issues.
I'm surprised more regulator companies do not offer this.
I re-simulated the analog blocks using the schematic that was used for the layout. The simulations comported quite well with what I've seen in the test chips. My earlier simulations seemed to use relatively simplistic resistor models that didn't account for effects on geometry for smaller drawn resistors. I'm using all the OnSemi symbols now with their much more elaborate parameters and things are much tighter.
I've made some minor changes which involve making some resistors and caps smaller and eliminating some structures. In other words, these changes are all subtractive, so will take little time to make in the physical layout. No need to make new room for anything.
Here is what I've done:
1) Power-up detector: Halved number of PMOS series devices that set time constant to reduce reset time from 40ms to 20ms.
2) Reset pulse extender: Eliminated 3 flops in one-shot to drop time from 24ms down to 3ms.
3) RC OSC: Shrunk two caps to make RC FAST run 20MHz at slow-process, high-temp, low-voltage corner.
4) Shortened resistors in fast DACs to make accurate 123.75-ohm and 990-ohm 3.3V DACs and 75-ohm and 600-ohm 2.0V DACs.
Numbers 1 and 2 get the chip to boot much faster, while number 3 ensures 2Mbaud serial on boot-up. Number 4 got the DACs into more accurate and sensible shape.
I still need to figure out why the VCO output duty is skewed somewhat on some test chips. This may be layout related, only. That's the last thing that seems to need any attention in the pad frame.
I re-simulated the analog blocks using the schematic that was used for the layout. The simulations comported quite well with what I've seen in the test chips. My earlier simulations seemed to use relatively simplistic resistor models that didn't account for effects on geometry for smaller drawn resistors. I'm using all the OnSemi symbols now with their much more elaborate parameters and things are much tighter.
I've made some minor changes which involve making some resistors and caps smaller and eliminating some structures. In other words, these changes are all subtractive, so will take little time to make in the physical layout. No need to make new room for anything.
Here is what I've done:
1) Power-up detector: Halved number of PMOS series devices that set time constant to reduce reset time from 40ms to 20ms.
2) Reset pulse extender: Eliminated 3 flops in one-shot to drop time from 24ms down to 3ms.
That 3ms still seems a long time for a watchdog to have to wait.. ? With Stable Vcc, there is little need for any added delay ?
3) RC OSC: Shrunk two caps to make RC FAST run 20MHz at slow-process, high-temp, low-voltage corner.
...number 3 ensures 2Mbaud serial on boot-up.
Cool. So that's ~ 26MHz nominal ?
Suppose a P2 ramps Vcc very slowly, with no BOD - what Vcc/MHz does the RC Fast start at, and how fast can the core run at that Vcc ?
- ie is there any part of the slow-ramp curve, where RC Fast can be too-quick for the core ?
I still need to figure out why the VCO output duty is skewed somewhat on some test chips. This may be layout related, only.
It seems strange it would be 'on some test chips' if it were layout related ?
Hard to think of a geometry effect that can happen only on some, but I can think of Power supply ripple effects that would vary duty, and that operating point will vary by sample.
How much exactly does the duty vary, and does it vary across the VCO range ? ie is this bad enough, to compromise the final device MHz ?
If you feed in a RF signal generator to the XtalIn pin, and sweep the PFD frequency, how does Duty Vary ?
Maybe it is time to look at a Divide by 2 after the VCO, so that local duty variations never make it to the clock trees ?
That does mean the VCO has to double, which is a less-small change.
This may be layout related, only. That's the last thing that seems to need any attention in the pad frame.
Is it worth giving users more control over the VCO/PLL ? - instead of the single 4 bit divider, and very wide VCO-Sweep you have now,
add
* Small (4-5 bit?) Post VCO Divider, so VCO only needs to sweep > 2:1. This relaxes the Analog-Side specs.
* Small (4-5 bit?) Post XtalIn divider - this allows more range on Xtal In
* Increase VCO-PFD divider from 4b to 7b, and lower PFD filter to allow lower PFD values.
All this gives much better frequency granularity, as you have M/N ratio.
These are all small digital blocks, so area cost is minimal, and they are a superset of what you have now.
Not sure on what size chip we want to make first, though.
Apple learned an interesting lesson when their laptop line was a bit more diverse - let pent-up demand sell the most profitable product by releasing the top of the line laptops first.
Release your most profitable product first! I'm assuming that would be the FULL 16 cog P2. Most people will want that version first anyways!
Not sure on what size chip we want to make first, though.
Apple learned an interesting lesson when their laptop line was a bit more diverse - let pent-up demand sell the most profitable product by releasing the top of the line laptops first.
Release your most profitable product first! I'm assuming that would be the FULL 16 cog P2. Most people will want that version first anyways!
Not only that, but the Press / Web Chatter / Review side should not be overlooked, which is another strong reason to release the top of the line first.
That establishes both the benchmark, and buzz, and simpler subsets can always follow, especially as customers arrive with firm specs and open cheque books !
Main reasons I see for a smaller one is that volume per dollar is probably higher as chip size should be smaller. Also, I think I remember that it can be put in a DIP package or at least be mounted to a PCB with a DIP format so as to be a drop in replacement for P1.
It's also been a while, and many design changes, since a 'fit confirmation' was done, so we may yet face a question over COG-RAM trade offs.
ie it is still certain 16 COGS and 512K RAM can both still fit ?
I noticed a lot of jitter when looking at the 20MHz RC FAST waveform today. I did some FFT checking and the frequency wanders in a 450 KHz range! I ran the SPICE simulation and the problem is there, too. I never realized this before, but it's good to catch this.
450KHz of wandering around 20MHz does not bode well for autobauding serial. It's fine for starting up and loading the internal ROM, etc., but we'll need a crystal in order to be accurate.
I think we might as well require a 20MHz crystal now. This will give us 20MHz frequency steps from 20MHz to 320MHz, which is way over the top. We could go with 10MHz, but then there's no chance of pushing the envelope and those crystals are larger.
I noticed a lot of jitter when looking at the 20MHz RC FAST waveform today. I did some FFT checking and the frequency wanders in a 450 KHz range! I ran the SPICE simulation and the problem is there, too.
450KHz of wandering around 20MHz does not bode well for autobauding serial. It's fine for starting up and loading the internal ROM, etc., but we'll need a crystal in order to be accurate.
Is that +/- 225kHz for a 450kHz total spread (+/- 1.125%), or 450kHz each way, for +/- 2.25%
Sound rather excessive - is that test with PLL/VCO off ?
I'm more used to RC osc being in the region of one part in 20k, or 50ppm of short term jitter.
It would be a shame to lose RC-Osc, as that gives a POST means to check with nothing else connected,
I think we might as well require a 20MHz crystal now. This will give us 20MHz frequency steps from 20MHz to 320MHz, which is way over the top. We could go with 10MHz, but then there's no chance of pushing the envelope and those crystals are larger.
The AutoBaud is still there, so the exact Cystal does not matter ?
The main change is to enable the Xtal as Source ?
IIRC, the new low cost, GPS derived TCXOs come >= 16MHz , with 19.2Mhz one std value & 26MHz another.
I'd be fine with that. I've never used a P1 without a crystal and I can't imagine using P2 without one...
I'd expect few to use RC Fast alone, but there are Programmable Clock source choices, such as Si5351, which may not output a P2 clock, until programmed.
Drop of RC-boot and force to an External Osc, for boot, constrains the choices.
Chip .... "450KHz" ??? .... Hmm what happens if you hover an old style AM radio near the PROP during that jitter ? That might mix with the IF frequency within the radio tuner which is typically 455kHz ... could be an audible beat frequency across all stations since it's so close to the IF
"The AutoBaud is still there, so the exact Cystal does not matter ?" - Good point .... with a reverse lookup of sorts and knowing/guessing what the Baud rate "should" be, you should be able to dynamically determine the amount of error. Auto-bauding should constantly look for the shortest bit width wile maintaining a "window averaging" or "ensemble averaging". A varying count on the average will translate to the timing error or jitter and could applied toward an error correction PID loop
In the 20KHz mode, the RC OSC is rock solid, as there is plenty of internal capacitance to regulate frequency. In the 20MHz mode, things are very whispy and the frequency averages ~20MHz, but is wandering above and below by ~225KHz. I guess that should be okay for autobauding, but I sure don't like the look of it.
This RC OSC was designed to be able to switch between 20MHz and 20KHz without a glitch. We actually have a nice deglitcher now in the clock selector, so this doesn't matter. In retrospect, I should have let this circuit just be a 20KHz OSC and then designed another, much more compact, circuit to run at 20MHz. We wouldn't have had such bad jitter then, as there would have been way less wiring and off-biased drains and sources to contribute parasitics.
In the 20KHz mode, the RC OSC is rock solid, as there is plenty of internal capacitance to regulate frequency. In the 20MHz mode, things are very whispy and the frequency averages ~20MHz, but is wandering above and below by ~225KHz. I guess that should be okay for autobauding, but I sure don't like the look of it.
Going from 20kHz to 20MHz, the C drops to ~1/10th and the R drops to ~1/100th.
I ran the 20MHz OSC simulation again with 100ps max timestep, instead of 10ns, and the jitter went away. I need to understand where the jitter is coming from in the test chip.
Comments
Why wasn't any of the DAC modes suitable for testing this?
There are three DACs in each pin:
1) 8-bit 1k/600-ohm parallel resistor DAC that drives the pin
2) 8-bit 120/75-ohm parallel resistor DAC that drives the pin
3) 8-bit High-Z R-2R DAC that drives the analog comparator
That last DAC doesn't output to the pin, only to an internal comparator. So, I was able to make it 'output' by going into a DAC comparator mode where the inverse of the comparator is output on the pin through a 1.5k resistor, forming a negative feedback loop which causes the pin to reflect the R-2R DAC voltage.
I can't find any of this in the Google Docs...
I think I understood that table once, but have since lost it...
Yes. The comparator modes can all be used as op-amps in one way or another.
I also checked the TESn pin and its TEST output.
The RESn pin and its RESET output got checked, too.
Here are the RESn pin, or reset circuit, timings:
1) Power-up detector takes 40ms from power-on to release.
2) One-shot that extends any reset source takes 24ms.
This means:
1) Cold reset takes 40ms + 24ms, or 64ms
2) Warm reset takes 24ms
I know these times may be kind of slow, but they are very conservative.
I think it would be safer to shorten the 24ms one-shot time than the power-up detector time.
I can see the one-shot going down to 1ms, while the power-up detector could maybe go down to 20ms.
What do you guys think might be reasonable adjustments here? Are any adjustments needed?
The one-shot could be 8-10 ms as mid ground. I don't have any reason other than 1 ms is pretty big change. Did someone have a reason for the 24 ms?
How does this work exactly ?
Is this a simple Gate-Cap R/C reset, or a BandGap voltage sense ?
What is the actual trip voltage, Up and down ?
Faster (re) boot from a watchdog should always be a strong focus.
POR to 20ms(max) sounds good, but you can go lower even than 1ms on a Stable-Vss reset. (below has 50us)
There is a lot more to POR than just delay times, and here is a Silabs example They have broad 3~31ms Cold start, with a typical of 10ms, and a 50us restart time.
(other vendors have ~6us restart times, some can do as low as 2 SysClks )
Note they spec a Ramp time, and a Falling voltage to re-arm the POR.
It is fairly common to find blind-spots in Vcc/Reset specs, which is why those cold start times are in the milliseconds, as it allows the Vcc time to ramp above that low release voltage, to where the core can actually run.
With the P2 RC Osc, that is (well) below the fMax, this should also help.
Can you test on the Test Chip, what voltage the RC Fast starts at, and what the core can clock at ?
What is the largest counter on the test chip ? - the 4 bit PLL Divider ?
My favorite stress-test circuit for MCU reset, is a triangle wave signal generator with amplitude and DC offset controls, fed to modulate the Vcc (connect to a LM1117 for example)
This allows you to easily vary the slew rates and the peak and valley.
The most reliable parts, have no dead-spots in their reset.
The worst, need something << 1V to recover their POR states, which means a simple brownout can cause a failure.
The really bad parts I've seen, will then not recover from a HW reset pin strobe, but need a full power cycle.
Some industry sectors favour Power-removal watchdogs because of all these issues.
I'm surprised more regulator companies do not offer this.
I've made some minor changes which involve making some resistors and caps smaller and eliminating some structures. In other words, these changes are all subtractive, so will take little time to make in the physical layout. No need to make new room for anything.
Here is what I've done:
1) Power-up detector: Halved number of PMOS series devices that set time constant to reduce reset time from 40ms to 20ms.
2) Reset pulse extender: Eliminated 3 flops in one-shot to drop time from 24ms down to 3ms.
3) RC OSC: Shrunk two caps to make RC FAST run 20MHz at slow-process, high-temp, low-voltage corner.
4) Shortened resistors in fast DACs to make accurate 123.75-ohm and 990-ohm 3.3V DACs and 75-ohm and 600-ohm 2.0V DACs.
Numbers 1 and 2 get the chip to boot much faster, while number 3 ensures 2Mbaud serial on boot-up. Number 4 got the DACs into more accurate and sensible shape.
I still need to figure out why the VCO output duty is skewed somewhat on some test chips. This may be layout related, only. That's the last thing that seems to need any attention in the pad frame.
Does the baby P2 cost less to fabricate, or is it a wash?
These minor tweaks are safe to use directly in production. Not sure on what size chip we want to make first, though.
Always good when simulations converge on reality
That 3ms still seems a long time for a watchdog to have to wait.. ? With Stable Vcc, there is little need for any added delay ?
Cool. So that's ~ 26MHz nominal ?
Suppose a P2 ramps Vcc very slowly, with no BOD - what Vcc/MHz does the RC Fast start at, and how fast can the core run at that Vcc ?
- ie is there any part of the slow-ramp curve, where RC Fast can be too-quick for the core ?
It seems strange it would be 'on some test chips' if it were layout related ?
Hard to think of a geometry effect that can happen only on some, but I can think of Power supply ripple effects that would vary duty, and that operating point will vary by sample.
How much exactly does the duty vary, and does it vary across the VCO range ?
ie is this bad enough, to compromise the final device MHz ?
If you feed in a RF signal generator to the XtalIn pin, and sweep the PFD frequency, how does Duty Vary ?
Maybe it is time to look at a Divide by 2 after the VCO, so that local duty variations never make it to the clock trees ?
That does mean the VCO has to double, which is a less-small change.
Is it worth giving users more control over the VCO/PLL ? - instead of the single 4 bit divider, and very wide VCO-Sweep you have now,
add
* Small (4-5 bit?) Post VCO Divider, so VCO only needs to sweep > 2:1. This relaxes the Analog-Side specs.
* Small (4-5 bit?) Post XtalIn divider - this allows more range on Xtal In
* Increase VCO-PFD divider from 4b to 7b, and lower PFD filter to allow lower PFD values.
All this gives much better frequency granularity, as you have M/N ratio.
These are all small digital blocks, so area cost is minimal, and they are a superset of what you have now.
Apple learned an interesting lesson when their laptop line was a bit more diverse - let pent-up demand sell the most profitable product by releasing the top of the line laptops first.
Release your most profitable product first! I'm assuming that would be the FULL 16 cog P2. Most people will want that version first anyways!
Not only that, but the Press / Web Chatter / Review side should not be overlooked, which is another strong reason to release the top of the line first.
That establishes both the benchmark, and buzz, and simpler subsets can always follow, especially as customers arrive with firm specs and open cheque books !
But, the full size is what I'd want too...
ie it is still certain 16 COGS and 512K RAM can both still fit ?
450KHz of wandering around 20MHz does not bode well for autobauding serial. It's fine for starting up and loading the internal ROM, etc., but we'll need a crystal in order to be accurate.
I think we might as well require a 20MHz crystal now. This will give us 20MHz frequency steps from 20MHz to 320MHz, which is way over the top. We could go with 10MHz, but then there's no chance of pushing the envelope and those crystals are larger.
Is that +/- 225kHz for a 450kHz total spread (+/- 1.125%), or 450kHz each way, for +/- 2.25%
Sound rather excessive - is that test with PLL/VCO off ?
I'm more used to RC osc being in the region of one part in 20k, or 50ppm of short term jitter.
It would be a shame to lose RC-Osc, as that gives a POST means to check with nothing else connected,
The AutoBaud is still there, so the exact Cystal does not matter ?
The main change is to enable the Xtal as Source ?
IIRC, the new low cost, GPS derived TCXOs come >= 16MHz , with 19.2Mhz one std value & 26MHz another.
I'd expect few to use RC Fast alone, but there are Programmable Clock source choices, such as Si5351, which may not output a P2 clock, until programmed.
Drop of RC-boot and force to an External Osc, for boot, constrains the choices.
Are we sure this is not a measurement error ?
"The AutoBaud is still there, so the exact Cystal does not matter ?" - Good point .... with a reverse lookup of sorts and knowing/guessing what the Baud rate "should" be, you should be able to dynamically determine the amount of error. Auto-bauding should constantly look for the shortest bit width wile maintaining a "window averaging" or "ensemble averaging". A varying count on the average will translate to the timing error or jitter and could applied toward an error correction PID loop
This RC OSC was designed to be able to switch between 20MHz and 20KHz without a glitch. We actually have a nice deglitcher now in the clock selector, so this doesn't matter. In retrospect, I should have let this circuit just be a 20KHz OSC and then designed another, much more compact, circuit to run at 20MHz. We wouldn't have had such bad jitter then, as there would have been way less wiring and off-biased drains and sources to contribute parasitics.
What is the Circuit, and R-C values for 20MHz ?
I ran the 20MHz OSC simulation again with 100ps max timestep, instead of 10ns, and the jitter went away. I need to understand where the jitter is coming from in the test chip.