the speed adjust feature should build in the bitsteam it self. the FPGA will automatically sample its temperature (with out a independent sensor device, just "it self" ) and rise and down the operation speed continuously.
why need to read the temperature, calculate, then adjust by sending a command from PC?
For large rig with 12-16 boards packaged in the suitable case, it will be better to use two big fans instead of dozen smaller ones. Their rotation speed (and thus consumed power and noise level) may be adjusted by cgminer depending on highest temperature readout of all FPGAs (as cgminer does for GPU).
So please consider FPGA temperature readout in your future design if possible, regardless of sensor type you will use.
Will be very nice if you support SPI in the future bitstream.
I'm going to start developing such carrier board, but we should agree with daisy-chaining protocol details and pinout first.
for a large chain, i support CAN or RS485 for the linkage specification.
As I said, I prefer to have my hardware run a little bit below suggested - and the software would simply reduce the amount of work or stop sending work.
Just like cgminer now does with GPU cards - you can decide on the temperature limit - the GPU cards themselves also have an internal shutdown - but few if anyone lets the cards go that high.
If there is only hardware control and no software control, then ALL boards would have to work exactly the same and have exactly the same limitations - and the hardware control would have to always be correct.
Just like my comments about being able to adjust the MHz of the board, in that case I'd have it err on the side of safety - others may prefer to risk and gain a little more performance.
I want my hardware to last a long time - so I'll prefer to have it run a little lower than some who may prefer to gain that extra performance.
i understand your meaning.
next bitsteam we will set the frequency to let the core temperature below 85C. this can let the device work for ever. this means the frequency will adjust by core temperature but error rate.
the miner may report the frequency and core temperature, but not software adjustable.
because it's hard to realize when neither DCM or PLL enabled. they consumption too much power. we will use another way to adjust frequency.
and next bitsteam will really take some time to release...
I think the ideal solution to reduce core temps would be to look for a heatpipe cooling solution. I'm not sure if there is a small enough heatpipe solution out there, but maybe you can get one custom built? Also some sort of heatsinking on the underside of the board at the fpga core would be ideal. But it's a shame that the lx150 doesn't have a metal heat spreader on it as the way I see it the major limitation to better cooling is the plastic top.
yes, the reality is negative.
"any" attempt to reduce the core temperature by enhance cooling the chip's top is absolute useless. the LX150 FGG484 use a high - thermal resistance plastic package. the core temperature is much higher than the package surface. a heatpipe will not help at all.
there are some solutions now, but we still need to do some measurement.
? 
