SA tracking generator as field-expedient P2 clock source?

2»

Comments

  • Yep, figured that's what you meant. And that's internal to XO, right. So a shorted XO externally won't have any effect on the inverting 1 MOhm performance, right?

  • evanh wrote: »
    Yep, figured that's what you meant. And that's internal to XO, right. So a shorted XO externally won't have any effect on the inverting 1 MOhm performance, right?

    The resistor goes directly between the XO and XI pins, actually. It was done that way to avoid any other interpretation of threshold. There is a single inverter with a 600 ohm output that goes from XI to XO. This inhibits crystals from oscillating in any overtone mode. Low gain.
  • jmgjmg Posts: 14,181
    edited 2019-12-07 - 19:46:58
    evanh wrote: »
    JRoark wrote: »
    ... the P2 seems happiest with a swing bigger than about 1.5 volts p/p at 20 mhz while the TG output is about 1.25 v.
    I hope you have a VIO/2 centre-bias divider on the XI input. Without the XO connected up it won't just float to 50%.

    Err ? the P2 has a 1M internal bias resistor, when the Xtal is enabled ?
    So AC coupling (1nF?) is all that is needed

  • jmgjmg Posts: 14,181
    JRoark wrote: »
    ... Judging from the results I got using a capacitively coupled freq generator as the clock input, the P2 seems happiest with a swing bigger than about 1.5 volts p/p at 20 mhz while the TG output is about 1.25 v.
    I've had clipped sine oscillators work fine (26MHz & 38.4MHz), and they are 0.8V MIN specs, usually just over 1V p-p, of a heavily filtered square output, source impedance ~ 180-200 ohms.

    I'd expect P2 to work well under 1Vp-p at low MHz, and need progressively more p-p as MHz climbs, and there may be a slew rate rule too..


  • So this 5P35021 that generates up to 500MHz will be integrated into an experimental P2D2 module that also includes the DAC trimmable 0.5ppm oscillator as well as other "enhancements" :)
    I will have this experimental "lab" version of the P2D2 ready for testing in the next few weeks.
  • @Peter Jakacki may very well beat me to an answer based on how poorly today went. No answers. Just more questions about why I cant drive this with the SA. Even downshifting to perfectly safe values like 80 mhz isnt working. That should be a no-brainer. So I need to start fresh with the basics tomorrow and see what I missed.

    And Peter... I really NEED one of your new crop. I already have a nice P2-sized copper heatsink and fan just waiting for a willing victim. :)
  • jmgjmg Posts: 14,181
    JRoark wrote: »
    @Peter Jakacki may very well beat me to an answer based on how poorly today went. No answers. Just more questions about why I cant drive this with the SA. Even downshifting to perfectly safe values like 80 mhz isnt working. That should be a no-brainer.

    I'd try even lower, like 20~26MHz, and then move upwards.
    One problem I think will be getting a clean RF signal into P2, due to gnd noise issues.
    Maybe a ferrite bead transformer can give a cleaner signal ? (and might give you some free gain too ?)

  • jmgjmg Posts: 14,181
    So this 5P35021 that generates up to 500MHz ....
    Nice part, but they spec only 160MHz for LVCMOS, the 500MHz is LVDS, but you may be able to usefully 'overclock' the pin drivers ?


  • jmg wrote: »
    So this 5P35021 that generates up to 500MHz ....
    Nice part, but they spec only 160MHz for LVCMOS, the 500MHz is LVDS, but you may be able to usefully 'overclock' the pin drivers ?


    SIngle ended differential output capacitively coupled is all you need to feed into the XI input.
  • jmgjmg Posts: 14,181
    SIngle ended differential output capacitively coupled is all you need to feed into the XI input.
    That will depend on what P2 sensitivity is, vs MHz.

    LVDS on that part specs > 247mV and LVPECL specs > 550mV on a single output, and 1.1V differential.
    I wonder if a balun allows more useful drive ?

    LVCMOS specs 1ns rise times (for 1.98V slew) into 5pF, so maybe that can still drive useful swings above that 160MHz spec limit.
  • cgracey wrote: »
    The resistor goes directly between the XO and XI pins
    Thanks. So definitely have to be careful what is hanging off the XO pin. Preferably nothing.

  • jmgjmg Posts: 14,181
    evanh wrote: »
    cgracey wrote: »
    The resistor goes directly between the XO and XI pins
    Thanks. So definitely have to be careful what is hanging off the XO pin. Preferably nothing.
    Yes, and at highest MHz, any skews in the XO drivers may 'walk' the DC bias point, but hopefully not by enough to be significant.
    That could be checked with a meter and a > 10K resistor to XO. Ideally, as MHz ramps, that does not change DC voltage.

    IIRC the internal XTAL buffer picks off XI, so the XO swing does not matter in these tests.


  • samuellsamuell Posts: 530
    edited 2019-12-08 - 12:31:57
    I'm curious to see the outcome of this. However, injecting 400MHz directly won't be easy. Either your source clock is placed very near the XI pin, or you'll have to devise a way to transmit a differential clock via a controlled impedance transmission line. Then you could use a differential to single ended clock buffer near the previous pin.

    By the way, what is the maximum clock attainable without the PPL? Is 500MHz feasable?

    Kind regards, Samuel Lourenço
  • Isn't that the very question of this topic? To find the fastest operating sys-clock rate.

  • Yup. The goal is to see how fast the P2 can be pushed using XIN directly, ie no PLL or crystal.
  • The PLL has always been the speed limiter. On an early test chip, the PLL's VCO was outpacing the PLL's divider, so I slowed the VCO down by slightly increasing its differential inverters' gate lengths. That got the logic under control, but the VCO now tops out at around 390MHz at room temperature. So, the PLL has always been the limiter.

    By the way, you will want to use clock mode %01_10, which doesn't enable any internal loading caps. The XI capacitance is still maybe 4pF including the package pin.

    P = F*C*V*V

    At 500MHz with a 2V swing, considering 4pF:

    P = 500M * 4pF * 2*2 = 8mW

    No much power needed.
  • evanhevanh Posts: 8,631
    edited 2019-12-08 - 14:02:06
    I went back and found my earlier attempt at this - https://forums.parallax.com/discussion/comment/1477026/#Comment_1477026

    The /1 column (XDIVP = 1) shows that heatsink below 35-40 °C the program would crash instead of PLL limited. EDIT: Err, maybe more like 25-30 °C. I missed this detail for 390 MHz:
    * = Cog crashed at 23 oC (PLL held lock)

    Program was simple 1/1000 pin toggle https://forums.parallax.com/discussion/comment/1476949/#Comment_1476949 It wouldn't produce much internal heat so the heatsink then should be reasonably representative of the die temperature.

  • evanh wrote: »
    I went back and found my earlier attempt at this - https://forums.parallax.com/discussion/comment/1477026/#Comment_1477026

    The /1 column (XDIVP = 1) shows that heatsink below 40 °C the program would crash instead of PLL limited.

    Program was simple 1/1000 pin toggle https://forums.parallax.com/discussion/comment/1476949/#Comment_1476949 It wouldn't produce much internal heat so the heatsink then should be reasonably representative of the die temperature.

    Ah, okay. So, it's not always the PLL.
  • I have to admit, before that particular testing, I did make some bogus speed tests just relying on the comport working to tell me all was okay.
  • evanhevanh Posts: 8,631
    edited 2019-12-08 - 14:55:11
    So that table shows that if you want to operate at 360 MHz from the PLL then the die temperature has to stay below 67 °C. That will be a challenge if the cogs are being worked hard.

    If using an external oscillator then there will be a little more temperature increase before reaching the crash limit but, to be honest, I wouldn't want to get any closer to that limit.

    PS: I estimate the crash limit will be around 75 °C die temp for 360 MHz sys-clock.

    PPS: And it looks like 400 MHz is very difficult to make non-crashing stable. That's one I'd thought I'd achieved at an earlier date but was fooled by not actually measuring the clock rate.

  • evanhevanh Posts: 8,631
    edited 2019-12-08 - 18:48:13
    Hmm, I've just tried again and the PLL is the limit all the way down for XDIVP = 1! I'm confused. Only explanation I can give is I must have been using a buggy loader previously. I've got PLL limited operating at 440 MHz sys-clock doing that simple toggle at -8 °C. A little faster still at -10 °C where I started. 430 MHz looks to be about -1 °C.

    I can no longer say what the crash limit is. It seems the door is open to an external oscillator. I can't imagine it's that far away though.

    EDIT: 420 MHz is 9 °C, 410 Mhz is 20 °C, 400 MHz is 31 °C, 390 MHz is 42 °C

  • evanhevanh Posts: 8,631
    edited 2019-12-08 - 17:31:00
    The numbers don't even line up any more. Grr. Another explanation would be I was using a more complex program that did more and produced a bigger temperature diff on the die. Dunno, doesn't really fit either since the old same results table is present as comments in the old test program I'm reusing now.

  • evanhevanh Posts: 8,631
    edited 2019-12-08 - 17:46:42
    evanh wrote: »
    The numbers don't even line up any more.
    It looks like the XDIVP slope is gone.

    Here's the actual source. You can see that I've got a bunch of duplicated blocks with small edits for each test case. I uncomment the one I want to test. Which means I've also accidentally got a slight log of the old HUBSET settings used. The only one I've re-edited for this round is the top most block. There is one other tiny change today - replaced the WAITX immediate with the "pause" variable.

  • evanhevanh Posts: 8,631
    edited 2019-12-08 - 18:51:04
    OH! DOH! It was all the revA board I was testing previously! I must have gotten distracted and never did the revB at all. EDIT: It wasn't as simple as shift the plugs over since the temperature probe is soldered to the bottom centre of the Eval Board. I couldn't find a spare set of plugs ready to make another thermocouple with so I had to move the existing thermocouple over.

    Okay, so sys-clock crash limits of the revB silicon are wide open then. :)

    PS: Here's the photos of the revA board between tests - https://forums.parallax.com/discussion/comment/1477027/#Comment_1477027
  • jmgjmg Posts: 14,181
    evanh wrote: »
    OH! DOH! It was all the revA board I was testing previously! I must have gotten distracted and never did the revB at all. EDIT: It wasn't as simple as shift the plugs over since the temperature probe is soldered to the bottom centre of the Eval Board. I couldn't find a spare set of plugs ready to make another thermocouple with so I had to move the existing thermocouple over.

    Okay, so sys-clock crash limits of the revB silicon are wide open then. :)
    Are the numbers posted above that sound like recent measurements all for Rev B ?
    (and older remembered values are for rev A?)
  • Yes to both.
  • evanhevanh Posts: 8,631
    edited 2019-12-09 - 13:00:04
    Chip,
    Now that I've caught up with revB reality ...
    cgracey wrote: »
    ... On an early test chip, the PLL's VCO was outpacing the PLL's divider, so I slowed the VCO down by slightly increasing its differential inverters' gate lengths. That got the logic under control, but the VCO now tops out at around 390MHz at room temperature. So, the PLL has always been the limiter.
    That post makes it sound like the revA crashes were possibly just from the PLL producing a garbage clock gen at the top end of range. And that even the revA silicon could run faster if clocked from an external clock source ... maybe?

  • evanh wrote: »
    Chip,
    Now that I've caught up with revB reality ...
    cgracey wrote: »
    ... On an early test chip, the PLL's VCO was outpacing the PLL's divider, so I slowed the VCO down by slightly increasing its differential inverters' gate lengths. That got the logic under control, but the VCO now tops out at around 390MHz at room temperature. So, the PLL has always been the limiter.
    That post makes it sound like the revA crashes were possibly just from the PLL producing a garbage clock gen at the top end of range. And that even the revA silicon could run faster if clocked from an external clock source ... maybe?

    The PPPP = %1111 glitch is a real problem that's always been there. To fix it, I'll need to insert 16 series'd inverters between the PLL output and the clock mux (deglitcher) input. That way, the deglitcher captures the current PLL output state BEFORE it sees it change.

    Both RevA and RevB should clock fast with an external XI input (mode %01_10). RevB should be able to go faster due to less self-heating.
  • Cool. Hot but cool. :D


Sign In or Register to comment.