Prop2 Analog Test Chip Arrived!

13468913

Comments

  • Beautiful result Chip.

    Why wasn't any of the DAC modes suitable for testing this?
  • evanh wrote: »
    Beautiful result Chip.

    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.
  • Wow, so there's 64x3=192 flash-DACs in the floor plan! Damn!
  • evanhevanh Posts: 10,088
    edited 2016-11-11 - 12:38:58
    What do you mean by "parallel resistor"? EDIT: Ah, the "high-Z" I guess means it's more striped down, without any buffering, like a current-mode DAC.

  • Interesting... You basically made an opamp circuit, a non-inverting amplifier.
  • cgracey wrote: »
    Here are the pin modes, mentioned as %PPPPPPPPPPPPP in the

    I can't find any of this in the Google Docs...

    I think I understood that table once, but have since lost it...

  • Rayman wrote: »
    Interesting... You basically made an opamp circuit, a non-inverting amplifier.

    Yes. The comparator modes can all be used as op-amps in one way or another.
  • cgraceycgracey Posts: 13,124
    edited 2016-11-12 - 10:45:58
    I finished testing the analog pin modes tonight, or everything in that chart with the 13-bit configurations.

    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?
  • 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.
  • Lawson wrote: »
    cgracey wrote: »
    active_probe_setup.jpg

    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).


  • jmgjmg Posts: 14,539
    cgracey wrote: »
    1) Power-up detector takes 40ms from power-on to release.

    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 ?
    cgracey wrote: »
    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?
    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 ?
  • jmgjmg Posts: 14,539
    cgracey wrote: »
    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.
  • Is this good enough to go to production? Or, need another test chip?

    Does the baby P2 cost less to fabricate, or is it a wash?
  • Rayman wrote: »
    Is this good enough to go to production? Or, need another test chip?

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

    Always good when simulations converge on reality :)

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

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

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

    cgracey wrote: »
    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.
  • cgracey wrote: »
    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!
  • Seconded.
  • jmgjmg Posts: 14,539
    thej wrote: »
    cgracey wrote: »
    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 !

  • RaymanRayman Posts: 11,487
    edited 2016-11-17 - 23:47:12
    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.

    But, the full size is what I'd want too...
  • jmgjmg Posts: 14,539
    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 ?
  • cgraceycgracey Posts: 13,124
    edited 2016-11-18 - 00:19:46
    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'd be fine with that. I've never used a P1 without a crystal and I can't imagine using P2 without one...
  • jmgjmg Posts: 14,539
    edited 2016-11-18 - 01:30:51
    cgracey wrote: »
    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.
    How does Spice simulate jitter ?
    cgracey wrote: »
    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,
    cgracey wrote: »
    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.


  • jmgjmg Posts: 14,539
    Rayman wrote: »
    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.

    Are we sure this is not a measurement error ?

  • Beau SchwabeBeau Schwabe Posts: 6,432
    edited 2016-11-18 - 02:05:37
    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
  • cgraceycgracey Posts: 13,124
    edited 2016-11-18 - 15:54:22
    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.
  • jmgjmg Posts: 14,539
    cgracey wrote: »
    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.

    What is the Circuit, and R-C values for 20MHz ?


  • cgraceycgracey Posts: 13,124
    edited 2016-11-18 - 04:57:35
    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.
Sign In or Register to comment.