130MHz test status. (YMMV)
davidsaunders
Posts: 1,559
I am running four P8X32A-D40 Propellers (Dip 40) at 130MHz with a XIN of 8.125MHz and PLL16X, for the purpose of seeing how stable they will run at this speed, in order to improve the likelihood of success I am using a 3.8V supply to the Propellers. This thread is to address the status of this test and any discussion directly related to the test. I must note: YMMV!
The four test Props ran with no sign of trouble for 158 hours, there whas not even any measurable increase in the temputure of the Propellers (at least not by the means I have to measure). This test is concluded as of 9:18 PST today.
The next test is on hold until I get a good working Propeller Loader working on Mac OS 'Classic'. This because I am running Mac OS 8.5.1 (was running Mac OS 9.2.2, changed because Mac OS 8.5.x runs Classizilla [Mozilla for Mac OS 'Classic] better).
The four test Props ran with no sign of trouble for 158 hours, there whas not even any measurable increase in the temputure of the Propellers (at least not by the means I have to measure). This test is concluded as of 9:18 PST today.
The next test is on hold until I get a good working Propeller Loader working on Mac OS 'Classic'. This because I am running Mac OS 8.5.1 (was running Mac OS 9.2.2, changed because Mac OS 8.5.x runs Classizilla [Mozilla for Mac OS 'Classic] better).
Comments
I would expect it to need cooling or at least get warm.
By stable, do you mean able to respond to the proptool, or are you running some computation or I/O?
What would be a reasonable definition of stable in terms of usable functions? Something like "continuously run the demoboard demo application"?
I never upped the clock rate but when I had a Prop on 4.2 Volts it didn't get any warmer than usual, ie not warm at all.
Are you exercising every instruction type and keeping all cogs active (no significant waits) all the time? Also are you measuring/controlling the temperature - it would be interesting to characterise the highest temperature against clock speed to plot your own version of the relevant datasheet graph. You should document the chip datecodes too as these properties are likely to vary from batch to batch.
Another thing to test is switching clock from xtal to internal RC oscillators to check this works at these speeds.
I am not quite doing 'every instruction type'. For this first test (to last 1 week with these 4 Propellers), I am having 6 cogs generating video (at 1600x1200) and two cogs generating the line buffer in hub mem that is used by the other 6, every scan line the cogs used for each are rotated up by one (thus giving a even use across cogs). During the blanking periods all COGS are running some simple math to determine the areas to draw for the next frame. Each cog also changes the state of an LED every second (so that I do not have to keep an extra monitor running, all the time [I do check video before updating the status here]).
The next test will have occasional stopping of 7 cogs with a short delay (thus putting the remaining COG in a wait state) before starting all 7 as quickly as possible, as well as stopping the two cogs not used for the current scan line and rotating forward by 2 COGS each scan line.
Also once all tests have been past for one week each, I will be repeating them at an ambient temp of 38C for one week each and then at an ambient temp of 40C for one week each, then I will have them in conditions where the ambient temp changes once per hour in a sudo random pattern, ranging from 0C to 45C.
Mark_T:
Do you have some suggestions for test #3. I am still thinking on this one as I do wish to be as thorough as possible.
Could you run the regular demoboard demo program, just to compare?
A useful test, when doing this type of hours-on-the-clock run test, is to lower the Vcc until it fails, and record that value.
This then gives a margin indication, that is more useful than 'still going'
One would expect that Vcc point, to change with test (ambient+die) temperature.
Well I think its important to cover every ALU operation as these will each have a potentially different critical path to settle the result.
Certainly test each hub instruction too, and.
Possibly test the self-modifying code ability of the next instruction-but-one as that will be a different timing from other register access.
Test switching from 12MHz internal RC to and from xtal as that's going to possibly provoke clock-jitter.
If there's already chip test code out there grab it all - the first symptom of failure will be in one instruction or class of instruction where the critical path is longest or its most vulnerable to clock skew. More important to test coverage than soak testing - you aren't stressing the chip thermally so I wouldn't expect slow degradation - timing issues are very repeatable at fixed temperature/supply I think.
73 hours and going strong.
No I can not quote the ampers pulled.
Yes I can run some standard demo board programs, though I repeat I do not have any to capture Video.
Thanks David for testing. Will be interesting to see where it all leads. Sure are fast running Props!
The four test Props ran with no sign of trouble for 158 hours, there whas not even any measurable increase in the temputure of the Propellers (at least not by the means I have to measure). This test is concluded as of 9:18 PST today.
The next test is on hold until I get a good working Propeller Loader working on Mac OS 'Classic'. This because I am running Mac OS 8.5.1 (was running Mac OS 9.2.2, changed because Mac OS 8.5.x runs Classizilla [Mozilla for Mac OS 'Classic] better).
No.
My Mother Board blew some capacitors. I have no idea what could have caused it.
I have many that Motherboards from My time working active with PC's.
Them aged simply - Most of Electrolitic capacitors DRY in time of use.
I have often wondered about that, as I have had dozens of the newer Mother Boards develop this problem. The thing that does not make much since to me is that my older systems have not had this trouble. I have a working Amiga 1200, a few working C64s, a good Apple IIGS, a good Atari 1040 Mega STE, etc, none has ever blown a cap.