Voltage requirement for fast-switching overclock

escherescher Posts: 138
edited 2020-06-08 - 16:42:55 in Propeller 1
So I've been experiencing very intermittent, seemingly nondeterministic issues with my project. It involves two P1s, both running overclocked @ 104 MHz, communicating in serial with one outputting a VGA signal.

The serial data connecting runs @ 25 MHz (shl_phsb_imm1 = $2CFFFA01 ' shl phsb, #1), and the VGA data is @ 25.175 MHz.

What I've noticed is that when I feed the system the standard 3.3V, I encounter frequent video dropouts and artifacting. Additionally, pressing any buttons (fed serially via 74HC165 @ 5.2 MHz) will trigger dropouts as well, insinuating the additional current draw of the shift registers is exacerbating the apparent undervoltage issues.

But as I gradually increase the voltage to 3.5V+, the issues completely disappear. The system runs perfectly. I am using bypass caps and power/ground cross-connections, and the voltages at the power pins match the power supply output, so no errant voltage drops are occurring anywhere else.

So, is this extra voltage required for system stability to be expected? Is it a result of these switching speeds? I've read elsewhere people getting up to 120 MHz with standard voltages, so I have to wonder if it's a difference in our use cases. Though, I've also read people supplying 4V+ when the datasheet specified 3.6V as the max rated Vin (of course, data sheets err widely on the side of caution). Thank you!

Comments

  • Hold up, wouldn't your serial be 26 MHz with your propellers running at 104 MHz?

    Video dropouts could also be cog PLL-related. Especially if it's just the video that glitches. Just spitballing: I think the cog PLLs are only rated for 4 to 8 MHz NCO input, is your CTRA NCO frequency in that range? And in general, I've found that running the PLL at some clean multiple or fraction of the sysclock is much more stable with regards to WAITVID timing.
  • escherescher Posts: 138
    edited 2020-06-08 - 17:14:50
    Wuerfel_21 wrote: »
    Hold up, wouldn't your serial be 26 MHz with your propellers running at 104 MHz?

    Video dropouts could also be cog PLL-related. Especially if it's just the video that glitches. Just spitballing: I think the cog PLLs are only rated for 4 to 8 MHz NCO input, is your CTRA NCO frequency in that range? And in general, I've found that running the PLL at some clean multiple or fraction of the sysclock is much more stable with regards to WAITVID timing.

    Yep you're right, fat-fingered the 5!

    As for the PLL data rate, I actually wrote a somewhat extensive breakdown of my project's setup here, and I'm perfectly within specs.

    As for running the PLL at divisions of the system clock, it's simply not possible to achieve the VGA spec video frequency.
  • In analog video land, precise pixel clocks are completely irrelevant and essentially an implementation detail of the signal source, especially if it's a fairly small difference (like between 25.175 and 26). LCD monitors auto-calibrate to the incoming clock (until it is too far off for that particular monitor - and that just makes it a bit blurry) and CRT monitors don't care to begin with.

    I guess if overvolting the Propellers works for you, just do that, I guess. I'd say use a separate regulator for them so all the other parts don't get the high voltage.

    Anyways, something completly random and unrelated because I just saw your schematic: Move anything important off GPU pins P0 through P8 (or even better, bus P0 through P7 to an aligned CPU pin group, ideally also P0-P7), then you can do that cool palette lookup trick from the Turbulence demo (which depends on being able to MOVS from INA)
  • Wuerfel_21 wrote: »
    In analog video land, precise pixel clocks are completely irrelevant and essentially an implementation detail of the signal source, especially if it's a fairly small difference (like between 25.175 and 26). LCD monitors auto-calibrate to the incoming clock (until it is too far off for that particular monitor - and that just makes it a bit blurry) and CRT monitors don't care to begin with.

    I guess if overvolting the Propellers works for you, just do that, I guess. I'd say use a separate regulator for them so all the other parts don't get the high voltage.

    Anyways, something completly random and unrelated because I just saw your schematic: Move anything important off GPU pins P0 through P8 (or even better, bus P0 through P7 to an aligned CPU pin group, ideally also P0-P7), then you can do that cool palette lookup trick from the Turbulence demo (which depends on being able to MOVS from INA)

    Interesting, wasn't aware of the video frequency flexibility, thanks! I'll play around with the PLL and see how even divisions works.

    Do you have a link to this turbulence demo? I haven't heard of it. Thanks!
  • > writes propeller video code
    > has never heard of Turbulence
    smh my head

    Original video:


    NTSC version I made:


    Writeup about the inner workings: linusakesson.net/scene/turbulence/source.php
  • Haha thank you! I built my video & rendering system from scratch, since I wanted some very specific features to maximize specific rendering metrics. I'll take a look!
  • escherescher Posts: 138
    edited 2020-06-08 - 18:47:51
    @Wuerfel_21 Ok, so Occam decided to take a nice big bite out of my **** on this one.

    It turns out, I was getting voltage drop from the LVR due to breadboard parasitics combined with too-thin power rail wire gauge.

    I suspected it was the issue before, but when I "fixed" it, I used too-thin wire resulting in several hundred mV drops into the P1s.

    After taking some time to properly wire the power rails, everything is perfect.

    I am however going to keep the 25 MHz change for peace of mind.

    Thanks for the help!
  • 104 MHz on a breadboard is pretty wild to begin with.
  • Wuerfel_21 wrote: »
    104 MHz on a breadboard is pretty wild to begin with.

    The very next thing on my to-do list after I finish the IDE I'm developing for the project is fab a dev board.
  • escherescher Posts: 138
    edited 2020-06-08 - 18:56:09
    @Wuerfel_21 I think the only thing that's saved me so far is my tight layout.

    jrtuMPs.jpg
  • Wuerfel_21Wuerfel_21 Posts: 718
    edited 2020-06-08 - 19:09:55
    Heh, with my Ventilator Computer, I actually went straight into making a PCB, partly because I just like neat and tidy things that I can easily take with me, but mostly because it's a very simple thing. Basically just a Propeller, boot EEPROM, SPI RAM, SD socket and a bunch of chicken scratch. Yet there are only two bugs that I'm aware of, one of which is a bad PS/2 connector footprint, the other that there needs to be an inexplicable extra resistor on the reset circuit, even though I copied it 1:1 from a known good schematic.

    Still need to make a Rev.B and a website for it, but currently busy working on my game. Also need to convert the design from EAGLE to KiCAD and learn how to use that, which puts a bummer on it.
  • Wuerfel_21 wrote: »
    Heh, with my Ventilator Computer, I actually went straight into making a PCB, partly because I just like neat and tidy things that I can easily take with me, but mostly because it's a very simple thing. Basically just a Propeller, boot EEPROM, SPI RAM, SD socket and a bunch of chicken scratch. Yet there are only two bugs that I'm aware of, one of which is a bad PS/2 connector footprint, the other that there needs to be an inexplicable extra resistor on the reset circuit, even though I copied it 1:1 from a known good schematic.

    Still need to make a Rev.B and a website for it, but currently busy working on my game. Also need to convert the design from EAGLE to KiCAD and learn how to use that, which puts a bummer on it.

    Any particular reason for the move from EAGLE to KiCAD?
  • escher wrote: »
    Wuerfel_21 wrote: »
    Heh, with my Ventilator Computer, I actually went straight into making a PCB, partly because I just like neat and tidy things that I can easily take with me, but mostly because it's a very simple thing. Basically just a Propeller, boot EEPROM, SPI RAM, SD socket and a bunch of chicken scratch. Yet there are only two bugs that I'm aware of, one of which is a bad PS/2 connector footprint, the other that there needs to be an inexplicable extra resistor on the reset circuit, even though I copied it 1:1 from a known good schematic.

    Still need to make a Rev.B and a website for it, but currently busy working on my game. Also need to convert the design from EAGLE to KiCAD and learn how to use that, which puts a bummer on it.

    Any particular reason for the move from EAGLE to KiCAD?

    a) I ran into the size limit on the free version of EAGLE. Infact, I actually kinda pushed it, because it only checks whether the center point(?) of a component is in the 10cmx8cm limit. So I managed to push the PCB size to 10cmx9cm or smth (? i don't remember?).
    b) since then (2017), EAGLE was bought by Autodesk and now the paid version is a subscription and I really do not like subscriptions, so even if I kept Rev. B in the free version's limit, I'd tacitly approve of a stupid business model.

    And KiCAD is apparently the good(TM) alternative, I hear. Last I tried it(2016 or 2017? i really don't remember), it was extremely janky, but I hear it's better now.

  • escherescher Posts: 138
    edited 2020-06-08 - 20:31:01
    Wuerfel_21 wrote: »
    escher wrote: »
    Wuerfel_21 wrote: »
    Heh, with my Ventilator Computer, I actually went straight into making a PCB, partly because I just like neat and tidy things that I can easily take with me, but mostly because it's a very simple thing. Basically just a Propeller, boot EEPROM, SPI RAM, SD socket and a bunch of chicken scratch. Yet there are only two bugs that I'm aware of, one of which is a bad PS/2 connector footprint, the other that there needs to be an inexplicable extra resistor on the reset circuit, even though I copied it 1:1 from a known good schematic.

    Still need to make a Rev.B and a website for it, but currently busy working on my game. Also need to convert the design from EAGLE to KiCAD and learn how to use that, which puts a bummer on it.

    Any particular reason for the move from EAGLE to KiCAD?

    a) I ran into the size limit on the free version of EAGLE. Infact, I actually kinda pushed it, because it only checks whether the center point(?) of a component is in the 10cmx8cm limit. So I managed to push the PCB size to 10cmx9cm or smth (? i don't remember?).
    b) since then (2017), EAGLE was bought by Autodesk and now the paid version is a subscription and I really do not like subscriptions, so even if I kept Rev. B in the free version's limit, I'd tacitly approve of a stupid business model.

    And KiCAD is apparently the good(TM) alternative, I hear. Last I tried it(2016 or 2017? i really don't remember), it was extremely janky, but I hear it's better now.

    Ah man last I had heard, EAGLE was free. Guess that was before the Autodesk buyout. Thanks for the heads up, research indicates you're correct that KiCAD is very mature these days.
  • There still is a free version, but the upgrade paths from that are all super expenso.
  • jmgjmg Posts: 14,372
    escher wrote: »
    ...It involves two P1s, both running overclocked @ 104 MHz, communicating in serial with one outputting a VGA signal.
    .. So, is this extra voltage required for system stability to be expected?...
    As mentioned, 104MHz on breadboard is good. Did you try warming things up ?
    You can buy regulators that output above the standard 3v3 levels, so 3.5 or 3.6v could be used to buy a little margin. Or use a x317 series regulator and set your own voltage.


  • jmgjmg Posts: 14,372
    Wuerfel_21 wrote: »
    And KiCAD is apparently the good(TM) alternative, I hear. Last I tried it(2016 or 2017? i really don't remember), it was extremely janky, but I hear it's better now.
    KiCAD improves all the time.
    It can import Eagle boards, and has been able to import PCAD ASCII files for a while, and the latest nightly builds can import Altium pcbdoc files directly, with SCH import in development.



  • Peter JakackiPeter Jakacki Posts: 9,211
    edited 2020-06-09 - 03:56:15
    Plugin breadboards are fine for simple things, although I'd rather use plated-through matrix board with free pads and connect things how I want and as close as I need by soldering Kynar wire point to point. But now, the main thing I wanted to say:

    * To a reasonable degree, keep your regulator as close as possible to the CPU as possible, and don't be afraid to use more than one. If you use LDO regs you can also drop the input voltage to a few hundred millivolts above regulation if you want to run cool, but the ones I use are tiny specks. TO220 packs are for 70's TTL circuits.

    * Please use proper ceramic decoupling caps and cut the leads as short as possible and place them as electrically close as possible to the matching CPU Vss and Vdd. (Those ugly greencaps are also from the 70's but while they were good for audio work, they were never good then, either for this sort of thing, everyone used ceramics).
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,652
    edited 2020-06-09 - 01:53:05
    To Peter's recommendations I would add this: pay particular attention to the input and output cap requirements for whichever regulator you're using. Read and digest every iota of specs in the datasheet until you understand it! This includes not only the capacitance and voltage values but the capacitor types and ESR ranges required for stability. When you source these caps, make sure they conform to the stated specs. And, equally important, remember the realtor's admonition about properties: location, location, location! The regulator caps need to be located as proximal to the regulator as physically possible. This stuff is particularly crucial with LDO regulators. IOW, it's not enough just to have bypass caps near the Prop for good regulation and noise abeyance.

    -Phil
  • Thanks for all of the advice everyone! Circuit design/analysis was always my weakest area, so I'm making an effort to remedy that.
Sign In or Register to comment.