I've attached an updated infographic to illustrate the improvements. It seems so much easier now in retrospect than it did before. Thanks again!
Looks good.
If your PCB is not super-high-density, you could look at SOT23-5 packages, which allow you to layout for more options for low-voltage regulators
NCP115ASN330T2G
NCP163ASN330T1G Lower noise than NCP115
TPS7A2033PDBVR Similar noise.
LDLN030G33R Similar noise to NCP163, but adds PowerGood signal to SOT23-5 pin 4
NCP164ASN330T1G adds PGood to NCP163
If your PCB is high density, this is DFN6 2x2
NCP187AMT330TAG 1.2A PGood
We had a chance to run some more simulations, so I thought a little more about the test program that tries to maximize power consumption.
I had eight cogs executing from register memory at 180MHz. I made their loops in hub memory, instead, which forces frequent FIFO reloads. The simulation showed a worst-case power consumption of:
2.4 Watts
That measurement was taken at fastest process corner, highest voltage (1.98V) and lowest temperature (-40C). I don't think a customer will ever see more than 2 Watts consumed by the core. So, the original estimation of about 2 Watts is probably accurate.
I'm presuming this is specifically for the 180Mhz clock speed. At 1.9V this ends up being about 1.2A.
Just some data points for consideration, if my math is accurate:
If the current draw scales linearly with core clock, that means it *might* be possible to hit 2.3A at 320Mhz @1.9V with the above test.
At a core voltage of 1.8, this goes down slightly to about 2.15A.
On the Eval Board, I measured roughly 1.75 V and 1.97 A at 360 MHz. It was a bit of a moving target with the rapidly rising temperature it generated though. Needless to say it can't sustain that without substantial cooling.
My test case exercised the fifo at full tilt bursting random data to 32 pins, so a little more than hubexec would do. I thought I'd disabled the pin drives as well but I'm not seeing that in the code. Duh, of course, DIR is low by default.
program3
waitx #500
wrfast #0, #0
rep @.rend, ##(64*1024/4) '64 kB random hubRAM data
getrnd pa
wflong pa
.rend
mov pa, #1
xoro32 pa 'revA (D = $42a01290 S = $50ad0021), revB (D = $84908405 S = $62690201)
mov pa, 0-0
cmp pa, ##$50ad0021 wz
rdfast ##(64*1024/64), #0 '64 kB block rollover
if_z xinit ##(%0011_0000_1000_0001<<16) | $ffff, #0 'revA silicon, full sysclock/1 continuous FIFO reading
if_nz xinit ##(%1011_0000_1000_0001<<16) | $ffff, #0 'revB silicon, full sysclock/1 continuous FIFO reading
program2
'Continuously loop, filling every cordic pipeline slot with random data
dirh #56
rep #4, #0 'loop forever burning the cordic
getrnd pa
qmul pb, pa
add pb, pa
mul pb, pa
PS: The lowered 1.75 V is due to the inline current meter I used - plugged into the provided 1v8 jumper on the Eval Board.
EDIT: Oops, in my rush I missed that "program3" falls through to "program2". So, as well as the streamer exercising the fifo and hubRAM, program2 also pushes lots of multiplies into the cordic. Have now updated the listing above with correct program.
Huh, GETRND is a relatively high power instruction. If I replace the ADD and MUL in program2 with a couple of extra GETRND's then that lifts the current needed, for program3, to 2 Amps at 360 MHz. Must be a gating thing. The bus needed to distribute the global random bits will have to cover some distance.
Comments
If your PCB is not super-high-density, you could look at SOT23-5 packages, which allow you to layout for more options for low-voltage regulators
NCP115ASN330T2G
NCP163ASN330T1G Lower noise than NCP115
TPS7A2033PDBVR Similar noise.
LDLN030G33R Similar noise to NCP163, but adds PowerGood signal to SOT23-5 pin 4
NCP164ASN330T1G adds PGood to NCP163
If your PCB is high density, this is DFN6 2x2
NCP187AMT330TAG 1.2A PGood
My test case exercised the fifo at full tilt bursting random data to 32 pins, so a little more than hubexec would do. I thought I'd disabled the pin drives as well but I'm not seeing that in the code. Duh, of course, DIR is low by default.
EDIT: Oops, in my rush I missed that "program3" falls through to "program2". So, as well as the streamer exercising the fifo and hubRAM, program2 also pushes lots of multiplies into the cordic. Have now updated the listing above with correct program.
EDIT2: And here's the original discussion - https://forums.parallax.com/discussion/comment/1482622/#Comment_1482622