Topic: 100BTC bounty for bitstream that fries ztex boards (Read 3054 times)

Good idea to make this a bounty.

Besides, a ztex 1.15x board costs less than 100 BTC. Why would you try it on a 1.15y (quad)?

Bounty is for bitstream. If you make one, send it to him. He will load it to his ztex board and see if it will fry. If yes you will be richer by 100 BTC.

Surprised it took this long for someone to say this.

The problem with this bounty is you would have to fry a ztex board which costs more than 100 btc lol.

Improper use (insufficient cooling) is not covered. A 12W bitstream at a case temperature of 30°C is as save as a 8W bitstream at 40°C (CGS484 package).

enable the internal terminal resistor, and set them to 25 ohm

Would it not be possible to void the warranty running non approved bitstreams?

@Elden  Should a clarification be added that the damagaing bitstream be able to hash?

My concerns are not about "board damage due to excess power use". I'm concerned about the reliability over the warranty period of 2 years. Please read the posting https://bitcointalksearch.org/topic/m.954712 for details.

Personally, I don't think this will work.

On the other hand, I don't want people pouring a ton of effort into an attempt to claim the bounty using this sort of thing -- circuits like this do not appear in anything remotely resembling a bitcoin miner, so the solution wouldn't actually contribute any useful knowledge to the question at hand (whether or not a bitcoin miner drawing 8A of current can damage the FPGA).  The reason I posted the bounty was to encourage people to devote their efforts to answering this question and -- if it is not claimed after an extended period of time -- to have evidence that these fears are strictly theoretical.  A huge mass of 800mhz-toggle combinational loops does not contribute to this one way or the other.

Since the bounty has only been open for 18 hours, I feel only slightly guilty about changing the terms.  I would not do this if it had been open for, say, a week.

How about good old ring oscillators? I think ISE will not allow combinatorial loops, but they can be created later with fpgaeditor. Even a DSP slice can be turned into a parallel bank of negators by configuring it to do: Out := -1 * In - 1 (or some such). Anyone here with an access to a fast oscilloscope tried that trick on a small scale?

Ah, you have a good point about the PLLs.  The format of the PLL dynamic configuration register is undocumented, and there might be a way to damage it with invalid bits.  I will add a clarification.



Fair enough.  I don't actually think this will work -- the fill layers do a great job of spreading heat a few thousand lambda in each direction.  At this point I'm not sure it would be fair for me to add a condition prohibiting this to the bounty, but I'll mention it.

I dont think anyone is allowed to claim the bounty if they simply do something like Frig with the temp sensors and/or failsafes built into the device

Ztex's concern is reliability.  There are many packaging related rel failures that scale with an exponent of the power consumption in the chip.  Inter-metallic regions are depleted of material through mass transport, dielectric materials break down, conductors develop whiskers which eventually create shorts.  Pushing the package to the edge of it's power and thermal envelope will reduce the functional life of the device.  How serious the impact of the bitstream will be would depend on what Xilinix's reliability targets were when they qualified the package, and how much margin they had in the design.  It could be irrelevant relative to the useful life of a mining system, or it could be that these forums fill with the wailing of miners with dead boards 6 months from now.

 

Yep. It would just drop off bitstream :-) But... Xilinx says that certain "bad" PLL configurations are not safe, as well as possibly associated DCM_CLKGEN... So actually you may wish to concentrate on damaging of clock-generation resources, not the logic fabric.

ALSO - there could be special approach - to overclock only smaller parts of logics - say take some small area of chip and run it @ 800 Mhz say by producing clock for that part of logic fabric inside the fabric by XORin two slower global clocks :-) Then with such small damage unrolled designs will never work there... And possibly bitstream would not even load properly.

That is precisely my point.

If one and only purpose is to fry a chip then take your bitstream and just clock the chip with let's say 250 MHz. There are some PLL's in Spartans6? Propably DC/DC converter will shut down from overcurrent protection, but spikes of votage that are generated when shutting down may cause damage to the chip.

What generates the most heat?
From what I remember from school, the changing from 0 -> 1 -> 0 costs energy and thus generates heat.
If you make a design that just uses all the flipflops and changes from 0 -> 1 each clock and 1 -> 0 the next clock and then clock it as high as you can, will that make the most heat?

Reserved for clarification of bounty terms.

Clarification: you may not use the PLL dynamic reconfiguration port.  It is undocumented, so there is a remote chance that Xilinx missed some sort of safety-related check there.  None of my bitstreams use PLL dynamic reconfiguration.

Clarification: if your scheme to claim the bounty involves toggle rates in excess of 420mhz (which is twice the fastest toggle rate of anything in my designs), please check here first.  It probably wouldn't be fair of me to deny someone the bounty for a solution that involved ultra-fast toggle rates, but it wouldn't settle the question of whether or not power draw can damage the chip.  So if you manage to do this (and I don't think it's possible, but I'm less certain), we might end up in a situation where I pay the bounty but don't "admit defeat" Edit, 9-Jun-2012: since the bounty has only been open for 18 hours, I'm going to simply rule out any toggle rates above 420mhz (which is obscenely high to begin with); it would be a waste of money and time if somebody poured a ton of effort into a solution based on this… I'd have to post a new bounty and, most importantly, it wouldn't contribute anything of interest to the question of whether or not 8A of current can damage a well-cooled chip running anything remotely resembling a bitcoin miner.  If you have invested substantial amounts of effort in this approach during the last 18 hours since the bounty was announced, contact me and we will work something out.  I still don't think this will work; I'm changing the criteria only because (a) it's only been 18 hours and (b) a solution based on absurd toggle-rates does not contribute anything useful to the question at hand, which was the whole reason I posted the bounty.

I'm posting this because I don't think it's possible -- not because I actually want a chip-frying bitstream.

There have been some (IMHO unwarranted) concerns about board damage due to excess power use.  My opinion is that the 8A power regulator on the board will drop out long before that becomes an issue.

Here's where the bounty originally came from:

  https://bitcointalksearch.org/topic/m.950585

As I wrote there,


I'll leave it running as long as you like, but if you expect it to take more than a day or two let me know since I'll have to find a location where it won't be disturbed.

Abnormal I/O pin use is prohibited, since bitcoin miners don't use I/Os anyways (except a very few) and it probably is possible to fry an FPGA by doing dumb things with the I/O pins.  But this is not relevant to the original discussion about power-consumption-related damage.  Also, your design has to pass Xilinx DRC which checks for things like multiple drivers on a node (the tools won't let you create such things, but it is rumored to be possible by directly manipulating the post-bitgen bitstream).

Lastly, since reading the source code and building bitstreams takes a nontrivial amount of time, I reserve the right to ask for a 10BTC review fee if the person claiming the bounty is not generally acknowledged on the forum as a serious FPGA designer.  Submissions coming from ztex, artforz, rph, bitfury, etc would obviously not be subject to this fee.