Voltage requirement for fast-switching overclock
escher
Posts: 138
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!
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
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.
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!
> 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
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!
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.
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.
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.
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.
* 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