I have an FPGA (Xilinx Spartan 6) for which I want to stress test the power supply in "steps" (e.g. the FPGA runs in loops of 1 seconds: full steam for 900 ms, halted for 100 ms) to check that the voltage drops at the power source are acceptable.
What would be my best strategy to test the FPGA "full steam"? Ideally I would have to write little Verilog code and I could programmatically control the FPGA usage (from 0% to 100%) from an external microprocessor.
What you describe in your question is not stress-testing the FPGA, it's stress-testing the power supply.
It sounds like what you want to know is, if you were to fully utilize your FPGA resources, would your power supply still be able to provide in-spec power.
Use the power estimator tool for your FPGA to determine the maximum draw for your device, given your clock frequency, I/O assignments, etc. The main thing is, when it asks how many registers and logic elements you're using, use a number that's 2x or so what's in your actual design, or 75 - 80% of what's physically available in the chip.
Choose power resistors to provide an equivalent load. Hook them up to the various supplies (VCC_core, VCC_io, etc).
Put the whole circuit into a thermal chamber at the maximum operating temperature you want it to run at. This is the part that will be hardest if you are not working in a well-equipped lab. If you're doing this for hobby work, put it on the dashboard of your car on a hot summer day. Run test leads out from the VCC nodes and ground to outside the chamber.
Run the circuit for some reasonable time to allow it to warm up.
Measure the fully loaded and temperature-stressed Vcc's.
As other answers have said, cycling the load like you propose is not especially important.
I'm not an expert in FPGAs (as you will obviously see), but these could be some (probably naïve) ideas:
1) Try to cause voltage toggling in as many CMOS structures as you can, inside the FPGA, and at the fastest possible rate. Options for that:
1.1) Create as many inverters as possible in your FPGA (hopefully, the software won't do optimizations), connect them in cascade, and drive all of them with an external clock running at the highest tolerable frequency.
1.2) If, by just synthesizing inverters, you can't make use of all existing general-purpose fabric logic, try to see, by examining the details on how it implemented, how you could cause toggling in as many of them as possible.
1.3) If the FPGA has RAM, devote a small part of the previous logic to cause flippings in all RAM bits, at the highest possible rate.
1.4) If the FPGA has dedicated DSP structures, put them also to stress.
All this, synched by the external clock.
To make all that gradually controllable, from 0% to 100%, vary the frequency of that external clock. Or devote a small portion of the fabric logic to have there a divide-by-N counter, so that it is the output from that counter, what drives everything I talked about.
(I'm assuming here that you have an application programmed in your FPGA. Testing for maximum FPGA usage probably will stress the power supply more, but it would be pointless if you never would use the FPGA to the max in real life.)
"I could programmatically control the FPGA usage (from 0% to 100%) from an external microprocessor"
Then do that! Set it to 100% if you want a stress test. No mercy! I wouldn't use the 100ms pauses: your power supply will have a harder time at 100% duty cycle than when it can take a breath every now and then.
Load all FPGA outputs to the maximum allowed.
If you can activate some part of the FPGA which is out of reach of the microcontroller, do it. A high frequency square wave may cause more activity than a static level.
edit
If you can stuff the FPGA with whatever you like I'd also fill it with inverters that all see the maximum clock frequency, like Telaclavo, but with a difference. The way he daisy chains them they will all switch one after an other, thus spreading the switching power in time. That's what you do if you want to be nice to the power supply.
I would make a tree where the first inverter drives, say, 100 others. Each of those 100 drives another 100. And again. At the third level there will be 1000 000 (or the number of gates the FPGA has) switching simultaneously.
Preferably the number of 100 should be higher than the fan-out of a gate (if the synthesizer allows that). This will slow down switching and increase switching power.
I think you should consider dividing your tests into 2 parts: FPGA stress testing and PSU stress testing.
If you want to see if the FPGA doesn't overheat (or if you do want to see it overheat).. sure put a program in it that runs as high frequency as possible with all logic cells required. Use all DSP blocks etc, and it will consume a lot of power..
If you want to know the load transient behaviour of your PSU , I don't think you should really be using a FPGA itself for that. What if the 1.2Vcore overshoots to 2V briefly everytime you do a load transient and kills the FPGA it after 10 attempts?
I'd say hook up a heavy load to your SMPS without FPGA and turn it on/off very rapidly. Just use a toggle switch and single-shot on the oscilloscope. A SMPS doesn't like load variances. If the load current drops rapdily, the output current will instead go into the output capacitor. If the output cap is very quickly charged with the load current, you're going to see some very high spikes. Same is true if you put a load on it; the SMPS takes time to ramp up to the particular current, so the output capacitor is discharging instead. If the voltage spikes are too large, increase the output capacitance. This will make the supply take longer to boot up etc. but will be able to withstand these high load changes better.
Otherwise you may want a SMPS with higher frequency and lower inductance so it responds quicker.
Also remember, that FPGA itself is not the only one power eater. E.g. DDR3 RAM combination of 16GB can eat a burst of >5A in some cases.
