...
i will add a temperature sensor on the next design, but IMHO, it's useless.
because it can't be installed inside the FPGA package, and the temperature read out is just a board temp. the response time is not quick enough for protection purpose.
board interconnect can be done now, only need a bitsteam modify. this feature is still under development.
The temperature sensor would not be for the sake of a microsecond shut down - but more for noting a trend to reduce the work to help reduce the temperature.
I don't run my GPU cards near the limits - I set them below those limits to promote a longer life
There is, however, a rather simple need for it: if the fan should fail, you would see a temperature rise and possibly have the software notice this and reduce the amount of work or even stop it from processing.
It may not be fast enough - but I guess only experimentation would tell?
Different subject ...
Actually one thing I've not asked or found written anywhere yet: is it possible to upload a new bitsteam using USB?
Or do you need the extra developer hardware to do that?
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?
...
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 really hate to butt into this thread, but I wanted to point out that
the new X6500 has all of these features you're asking about.
The temp sensors are
definitely useful, if only to see exactly the effect of different cooling arrangements or clock frequency. Of course, it takes some time to respond, but typically less than a minute. ngzhang, what exactly makes you think that isn't fast enough? I'm planning to do a fan failure test this weekend, and see how well the temp sensor responds. Maybe even take a heatsink off entirely and see what happens. I get the sense that it's going to be hard to actually kill an FPGA, even trying my hardest. We'll see, though!
We have new firmware that allows you to set the clock to any frequency you like, in 2 MHz increments. Unfortunately, we're still fighting with Xilinx ISE to get it to meet timing at frequencies higher than around 190 MHz. Still, the ability to automatically adjust the clock to whatever frequency best suits your setup is really fun to play around with. MPBM will also automatically reduce the clock if either the invalid nonce rate or the temperature sensors exceed some threshold. You can set these thresholds yourself (and I'd guess that you'd prefer setting those thresholds a little lower than some people).
Finally, you can upload the bitstream over USB, without any special hardware. The software will do this for you automatically whenever you power up the board the first time.
Sorry again for the thread hijack!!
hummm. it's fine. so i have chance to do a deeper analyses.
the core problem is the on board temperature sensor can not measure the FPGA's core temperature (Tj). due to the bad plastic package, it's impossible to accurate measurement it (from the outside).
we already find a way to sample this parameter (Tj) by a special method in a few nanoseconds, and adjust the frequency continuously by the TJ, not 2MHz step or some other value.
a tip for you is: we all using ZTEX's verilog code, this full pipe-lined architecture is pretty fast, but the power consumption is also high. i find that even icarus us a 6 layers PCB with 4 planes plus heatsink and fan, it's really hard to control the Tj under 105C when the frequency over 200MHz, far above. under this situation, generate invalid shares is not a big problem, but the "Electron Drift" effect will kill the chip in a few months. that's why i have a 200Mhz bitsteam months ago, but our volume products still using the 190MHz one. even though icarus is a no warranty product as yours.
about the config interface, you know icarus is a common use development board. i must follow some established rules in this field. but our next product will also add a MCU friendly config port.