hardcore-fs
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 11:02:59 PM |
|
Re the regulators, I checked the datasheet and they are thermally protected (just about everything is these days), so no harm letting them run hot.
This is NOT correct, just because the Regulator is thermally protected DOES NOT mean the voltage it is supplying to the FPGA is in range!!! Not to mention it causes the FPGA to dump extra wattage for NO reason!!!, thereby severely aging the device.
|
BTC:1PCTzvkZUFuUF7DA6aMEVjBUUp35wN5JtF
|
|
|
kramble
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 18, 2012, 12:54:57 AM |
|
Hi HC
No contest there, the regulator is just protecting itself (to some degree anyway, as higher junction temperatures will still degrade the device faster), not its client.
Not so sure about your second comment about the FPGA dumping wattage for no reason. I assume you mean the system as a whole, rather then the device itself. So yes, an efficient switch mode/buck converter is certainly to be preferred over a linear regulator, though in the case of the DE0-Nano, its meant as an educational tool, so I guess efficiency is not its main purpose.
I'm actually pretty amazed at the cost effectiveness of the little beast. In small quantities, at least, the entire board is hardly more expensive than the bare FPGA itself, given any reasonable cost of building something with it. Unfortunately its not much use as a bitcoin miner (I've been running one full time for about a month now, for educational purposes of course, and I'm only up to about 0.1BTC, not much more than the cost of powering it).
I had a look at the more commercial offerings (mostly LX150 based), and to be honest, I've concluded that there really is no money to be made here. So I'm not entirely sure why I'm pottering along with this project, but it's something to keep me busy I suppose. Not really made that much progress beyond my last posting. The Raspberry Pi is doing a sterling job as a host to one (sometimes a pair) of DE0-Nano's running at 12.5 MH/s apiece (the most I can reliably get out of them at the moment). The freezer experiments are still pending (I took your cautions to heart, so I won't risk a Nano on that), but I've built myself a test board with a TQFP which I'm more inclined to push the limits on (fun was had finding a way to get it programmed (I wasn't going to shell out on the overpriced official programmer), so a Nano was co-opted to that purpose, not without much grief getting it debugged, but these are versatile devices and its now the ward of said Nano).
I'm rather running out of steam on this now, so I'll probably look to some other uses for these rather fascinating devices. Many thanks for you help (and Makomk too). Mark.
|
|
|
|
hardcore-fs
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 18, 2012, 10:01:34 AM |
|
The issue is that a $2 regulator "protects" itself but trashes the FPGA in the process.
The FPGA dumps the extra heat because the regulators voltage drifts and even a 0.1v increase in the core FPGA voltage can cause a significant increase in the wattage dumped by the FPGA.
The only way to make money with this, it to find a market that dumps scrap telecom boards. Sometimes they are loaded with FPGA's.
Reasons to continue? , purely for the educational value because by trying things that Don't work it is an excellent insight into the hardware Same reason why I won't get "rich" mining off a XUPV5, but I continue to improve the code.
|
BTC:1PCTzvkZUFuUF7DA6aMEVjBUUp35wN5JtF
|
|
|
kramble
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 18, 2012, 01:22:36 PM |
|
The issue is that a $2 regulator "protects" itself but trashes the FPGA in the process.
The FPGA dumps the extra heat because the regulators voltage drifts and even a 0.1v increase in the core FPGA voltage can cause a significant increase in the wattage dumped by the FPGA.
The only way to make money with this, it to find a market that dumps scrap telecom boards. Sometimes they are loaded with FPGA's.
Reasons to continue? , purely for the educational value because by trying things that Don't work it is an excellent insight into the hardware Same reason why I won't get "rich" mining off a XUPV5, but I continue to improve the code.
Ah, thanks for that. I can see what you mean now. I had assumed that the regulators would simply enter thermal shutdown if they overheat, but you're concerned about the stage before that where the regulators continue to operate, but their output drifts out of spec. Obviously in a professionally designed system this would be taken into account and the heatsinking sized accordingly, but I can see that in "overdriving" the DE0-Nano this can certainly be an issue (the manual claims the PSU is good for 1.5 amps, but they're just quoting the regulator specs there, and from the temperature they get to at the 800mA or so I'm using, I can see why it would not be wise to push it much further). Anyway I've got a fan blowing air over the board so this will help somewhat, and I'm not too concerned about frying a £70 ($110) board. One of the LX150 mining boards would be another matter entirely, but I'm not going there as I just can't see any way that these can make any money (the payback time is way too long, and with ASIC's perhaps, maybe, sometime, coming to the table, its just not worth the risk). I'm with you on the scrap approach as I had considered this myself. The only problem is reworking the BGA packages as this is not really possible without expensive SMD rework gear (and quite a bit of skill). I was able to reflow a 144 pin TQFP package (only a cheap 10k part, so I was not bothered if I trashed it) quite successfully using a DIY approach with an IR lamp (actually a 150W floodlamp) as a heat source, but that is not going to work with BGA's. Anyway you'd really want professional multilayer PCB's to get the power distribution done properly, rather than the sort of things I can knock up in my "workshop". Not to mention sourcing the scrap parts in the first place! So we're back to the educational value, and I've certainly got my money's worth there. Not sure where I'm going with it, but sometimes the journey itself is the destination, and at my stage of life there is no need to justify what I spend my time on! TTFN Mark
|
|
|
|
LateToTheParty
Newbie
Offline
Activity: 11
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 25, 2012, 11:06:39 PM |
|
Hello, I've managed to get access to a Spartan6 150 FPGA board and Xilinx toolset at work at lunch/evenings to play with. The idea is to learn VHDL, which is going OK. I'd really like to have a play with Bitcoin too. I hope there is someone here that can help me with regards to TheSeven's Xilinx VHDL implementation. If not, do you know where can I get help? I've looked back through this topic and have seen something similar, but the response didn't help me. When I synthesise the project, I get the following message for every stage (i.e. If DEPTH = 0, I get it once. If DEPTH=6, I get it 64 times). Xst:3031 - HDL ADVISOR - The RAM <Mram_rounds[0].round_k> will be implemented on LUTs either because you have described an asynchronous read or because of currently unsupported block RAM features. If you have described an asynchronous read, making it synchronous would allow you to take advantage of available block RAM resources, for optimized device usage and improved timings. Please refer to your documentation for coding guidelines. I think the problem is caused by the following code in sha256_pipeline.vhd; rounds: for i in 0 to 2 ** DEPTH - 1 generate signal round_k : std_logic_vector(31 downto 0); signal round_w : std_logic_vector(511 downto 0); signal round_s : std_logic_vector(255 downto 0);
begin round_k <= K(i * 2 ** (6 - DEPTH) + conv_integer(step));
My understanding is that round_k is not set on a clock pulse, and therefore gets treated as asynchronous. The result of this is that a fully unrolled (DEPTH=6) implementation does not fit on the 150 device (I've read it should). What am I doing differently to everyone else? I haven't seen mention of any errors/warnings/info by others that have used the code. In addition, are there any warnings that I should expect to see? (I also get warnings that txdata/txwidth will be optimised away - although I haven't looked at that code in detail yet). The only difference between the download and what I'm running is that I've had to change the DCM (I created a new one using CoreGen as the old one generated errors). Thank you very much for any help.
|
|
|
|
2112
Legendary
Offline
Activity: 2128
Merit: 1073
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 25, 2012, 11:41:39 PM |
|
I've managed to get access to a Spartan6 150 FPGA board and Xilinx toolset at work at lunch/evenings to play with. The idea is to learn VHDL, which is going OK. I'd really like to have a play with Bitcoin too.
I think most of the people worked on the Verilog version, not the VHDL one. I wouldn't be surprised if the VHDL version never implemented correctly on Spartan chips, but maybe on Virtex-es only. Start your play with the versions that have a top-level ISE project file: *.xise. Are you trying to learn VHDL knowing Verilog or from scratch?
|
|
|
|
makomk
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 26, 2012, 12:29:15 AM |
|
Hello,
I've managed to get access to a Spartan6 150 FPGA board and Xilinx toolset at work at lunch/evenings to play with. The idea is to learn VHDL, which is going OK. I'd really like to have a play with Bitcoin too.
I hope there is someone here that can help me with regards to TheSeven's Xilinx VHDL implementation. If not, do you know where can I get help? I'm afraid getting miners running on Spartan-6 is kind of hairy and really requires HDL tailored specifically to that chip. TheSeven's Xilinx VHDL implementation isn't going to be, and ztex's Spartan-6 mining core which everyone uses is in Verilog rather than VHDL.
|
Quad XC6SLX150 Board: 860 MHash/s or so. SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
|
|
|
LateToTheParty
Newbie
Offline
Activity: 11
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 26, 2012, 10:30:47 PM |
|
Ah, ok. Thanks for the info. I'll abandon that challenge for the time being then. I think I will still try to get the Verilog working so I can run it at weekends ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Are you trying to learn VHDL knowing Verilog or from scratch?
VHDL from scratch. I write embedded software (ASM, C, C++) for a living, so the language syntax is easy enough. The bit I'm struggling with at the moment is exactly what makomk has said - tailoring the HDL to the FPGA. I still think in terms of high level code that has the correct behaviour in the simulator, not how best to utilise the available slices, flip flops, block rams etc. With any luck this will come with time. It seems that getting the VHDL working would be an interesting challenge when I start understanding things.
|
|
|
|
2112
Legendary
Offline
Activity: 2128
Merit: 1073
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 27, 2012, 01:08:27 AM |
|
VHDL from scratch. I write embedded software (ASM, C, C++) for a living, so the language syntax is easy enough. The bit I'm struggling with at the moment is exactly what makomk has said - tailoring the HDL to the FPGA. I still think in terms of high level code that has the correct behaviour in the simulator, not how best to utilise the available slices, flip flops, block rams etc. With any luck this will come with time. It seems that getting the VHDL working would be an interesting challenge when I start understanding things.
I sincerely wish you good luck, but this project isn't a good starting assignment for a beginner. The competitive motivation element (bounties, etc.) is already almost gone. What you have now is just a combination of workarounds for the deficiences in the Xilinx toolchain; e.g. the use of 512-bit vectors where 16-element array of 32-bit vectors would produce much cleaner code. This skill has a value now, but Xilinx will eventually fix it in some future release and the skill would start to look cargo-cult-ey. Also, in your past experience, how often have you faced a problem where you could drop half of the valid results and the project would still appear to work and be valuable? I'm not trying to discourage you at all from working on a miner, just set yourself appropriate goals; e.g. use a comm protocol with CRC so you'll know the actual BERT of your transport. You can also restore the competitive element for yourself and make a first Litecoin FPGA hasher. Again: good luck.
|
|
|
|
hardcore-fs
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 27, 2012, 01:11:38 AM |
|
Ah, ok. Thanks for the info. I'll abandon that challenge for the time being then. I think I will still try to get the Verilog working so I can run it at weekends ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Are you trying to learn VHDL knowing Verilog or from scratch?
VHDL from scratch. I write embedded software (ASM, C, C++) for a living, so the language syntax is easy enough. The bit I'm struggling with at the moment is exactly what makomk has said - tailoring the HDL to the FPGA. I still think in terms of high level code that has the correct behaviour in the simulator, not how best to utilise the available slices, flip flops, block rams etc. With any luck this will come with time. It seems that getting the VHDL working would be an interesting challenge when I start understanding things. The issue is not the "syntax" but rather the complete change in the mindset of hardware programming. If you approach hardware programming the same way you approach C programming, then it will be a fail and you will spend you life in a mental hospital wondering WHY it did not work. Certainly when you code something like noverheat <= NOT overheat; reset <= reset_count(reset_count'high); fpga_0_LEDs_8Bit_GPIO_IO_pin(0) <=NOT overheat; From a C perspective you would say WTF it should be: fpga_0_LEDs_8Bit_GPIO_IO_pin(0) <=noverheat ; So that I can save logic....... But then you discover that in VHDL in this situation: 1. you CANNOT guarantee WHICH order the statements are executed in ,even they are in top down format...... 2.That fpga_0_LEDs_8Bit_GPIO_IO_pin(0) <=NOT overheat; may actually get executed before or at the same time as: noverheat <= NOT overheat; it all depends on the FPGA chip being used and the compiler options, so if you have flaky code that just about functions on one chip, changing the chip can make it non functional even when it simulates correctly. Then you have the completely GASH Xilinx tools, written in all their memory leaking java glory........
|
BTC:1PCTzvkZUFuUF7DA6aMEVjBUUp35wN5JtF
|
|
|
LateToTheParty
Newbie
Offline
Activity: 11
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 29, 2012, 09:23:09 PM |
|
I've grabbed the works laptop for the long weekend to see if I can get something to build. They're unlikely to lend me any of their dev/debugging hardware (and no spare licenses for their decent simulation software), but if I can go in armed with a bit file to program in next week it would be a good start. There are a few test headers I can rig up for comms. So, the next question is: will any of the projects run for me out of the box, or at least compile with minimal tweaking? I don't mind it being in Verilog, but I don't like giving up, so want to see one of these boards mining! What project file would you suggest I use as a staring point? I tried the "LX150 makomk....." projects, but they resulted in thousands of warnings (just opened the project and clicked the build button). You can also restore the competitive element for yourself and make a first Litecoin FPGA hasher.
Once I manage to get someone elses bitcoin code running then maybe you're right. Annoyingly there is a decent amount of RAM on this board, it's connected via a relatively slow ARM processor. Thanks!
|
|
|
|
2112
Legendary
Offline
Activity: 2128
Merit: 1073
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 29, 2012, 10:18:11 PM |
|
So, the next question is: will any of the projects run for me out of the box, or at least compile with minimal tweaking? I don't mind it being in Verilog, but I don't like giving up, so want to see one of these boards mining!
What project file would you suggest I use as a staring point? I tried the "LX150 makomk....." projects, but they resulted in thousands of warnings (just opened the project and clicked the build button).
I never had any of the SLX150 boards that were used in those projects. I built some of them with minor changes on VLX240; but I don't recall which ones. This design is very flexible: you can roll the hashers by increasing CONFIG_LOOP_LOG2 parameter until it fits in your Spartan. You shouldn't worry about warnings; there is no way to completely shut them down in ISE even for a perfect design. This project isn't friendly for simulation. The I/O protocol would need to be changed to give beginning and end of the nonce range to search. Otherwise simulating the search through the 2^32 nonce values just takes too much real time.
|
|
|
|
LateToTheParty
Newbie
Offline
Activity: 11
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 30, 2012, 01:59:38 PM |
|
I had anticipated a few warnings/info messages, but 14,000 synthesis messages about trimming FF/Latches made me think I'd done something wrong. Is this as high as you'd expect?
I've been using the LX150_makomk_Test project as a start point. If these warnings are to be expected, I'll replace the ChipScope stuff with something else for comms (one of the other projects uses serial, I'll probably copy that) and go from there.
My comment about simulation was more directed at the use of the testbench code to smoke test the code before I program it. For the time being, I'm hoping there wont be much debugging required for the main algorithm!
Thanks for your help.
|
|
|
|
hardcore-fs
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 12:31:43 AM |
|
I had anticipated a few warnings/info messages, but 14,000 synthesis messages about trimming FF/Latches made me think I'd done something wrong. Is this as high as you'd expect?
I've been using the LX150_makomk_Test project as a start point. If these warnings are to be expected, I'll replace the ChipScope stuff with something else for comms (one of the other projects uses serial, I'll probably copy that) and go from there.
My comment about simulation was more directed at the use of the testbench code to smoke test the code before I program it. For the time being, I'm hoping there wont be much debugging required for the main algorithm!
Thanks for your help.
Don't sweat it....... the "trimming messages" are just the compiler doing its job. As regards running, I hope you realize that again... hardware programming in NOT like C programming, you DO NOT debug on hardware, you debug in the simulator then when it works, you move to the hardware. A simulation can compile in just under 15 seconds an "un-patitioned" "un-blackboxed" SHA256(SHA256(x)) compiled for hardware is going to take several hours,or on a portable maybe a day to compile..... here is a 4 solution set. Next thing you need.... is to find a 'solution" and use that in the test bed code: 00000001f1fc17f04446c70a6946bdfc0c50addb0157839b8226c2af000001a9000000005e8f39668534c41c8a3322239d6c0cfaf41c222ca8cb863929b440d5c48f38e0509057ad1a0513c5 00000001f1fc17f04446c70a6946bdfc0c50addb0157839b8226c2af000001a9000000005e8f39668534c41c8a3322239d6c0cfaf41c222ca8cb863929b440d5c48f38e0509057ad1a0513c5:b733aa28 00000001f1fc17f04446c70a6946bdfc0c50addb0157839b8226c2af000001a9000000005e8f39668534c41c8a3322239d6c0cfaf41c222ca8cb863929b440d5c48f38e0509057ad1a0513c5:1526ba33 00000001f1fc17f04446c70a6946bdfc0c50addb0157839b8226c2af000001a9000000005e8f39668534c41c8a3322239d6c0cfaf41c222ca8cb863929b440d5c48f38e0509057ad1a0513c5:c885e546 00000001f1fc17f04446c70a6946bdfc0c50addb0157839b8226c2af000001a9000000005e8f39668534c41c8a3322239d6c0cfaf41c222ca8cb863929b440d5c48f38e0509057ad1a0513c5:5b9c067f
Basically you load the hash into the test bench and set the nonce just below one of the solution values, then run the simulation. You really do not want to scan the nonce from 0x00000000 to 0xffffffff, because the simulation will take forever to run. Also watch the endian of the values above.
|
BTC:1PCTzvkZUFuUF7DA6aMEVjBUUp35wN5JtF
|
|
|
LateToTheParty
Newbie
Offline
Activity: 11
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 03, 2013, 12:07:27 AM |
|
It's taken much longer than I thought it would, but I can run the testbench in the simulator and it successfully finds the (assumed) correct nonce ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) I've only just learnt that 'midstate' is deprecated, which this code requires. Perhaps I can work towards adding that feature (later, when I work out what this code is doing!). The test hash I used was already in the code; uut.midstate_buf = 256'h228ea4732a3c9ba860c009cda7252b9161a5e75ec8c582a5f106abb3af41f790; uut.data_buf = 512'h000002800000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000002194261a9395e64dbed17115; uut.nonce = 32'h0e33337a - 256; // Minus a little so we can exercise the code a bit
I didn't completely understand your example hashes. Am I correct in thinking you've provided data:nonce pairs, where one is correct? Or are they all correct? Obviously I'll need to calculate the midstate myself if this is the case. Thanks for your help! I finally feel like I'm getting somewhere.
|
|
|
|
hardcore-fs
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 03, 2013, 01:02:03 AM |
|
It's taken much longer than I thought it would, but I can run the testbench in the simulator and it successfully finds the (assumed) correct nonce ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) I've only just learnt that 'midstate' is deprecated, which this code requires. Perhaps I can work towards adding that feature (later, when I work out what this code is doing!). The test hash I used was already in the code; uut.midstate_buf = 256'h228ea4732a3c9ba860c009cda7252b9161a5e75ec8c582a5f106abb3af41f790; uut.data_buf = 512'h000002800000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000002194261a9395e64dbed17115; uut.nonce = 32'h0e33337a - 256; // Minus a little so we can exercise the code a bit
I didn't completely understand your example hashes. Am I correct in thinking you've provided data:nonce pairs, where one is correct? Or are they all correct? Obviously I'll need to calculate the midstate myself if this is the case. Thanks for your help! I finally feel like I'm getting somewhere. They are ALL correct solutions for a single hash, just it makes it easier to test the code, instead of only having one hit point, specifically because you can test your communications algo. to see how it handles multiple nonce hits. Sometimes when running a simulation, it destroys valuable results when you have to restart it to re-hit the 'nonce' on a single nonce solution.
|
BTC:1PCTzvkZUFuUF7DA6aMEVjBUUp35wN5JtF
|
|
|
hackjealousy
Newbie
Offline
Activity: 53
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 03, 2013, 01:54:15 AM |
|
I've only just learnt that 'midstate' is deprecated, which this code requires. Perhaps I can work towards adding that feature (later, when I work out what this code is doing!).
Just to be clear, using the midstate in mining is not deprecated, receiving the midstate from getwork is. You need code running on a host computer that interfaces with your device anyway. This code can just generate the midstate itself. For an example, check out cgminer.c:calc_midstate(). In fact, once you have your bitstream, the easiest thing to do would be to make a driver for cgminer that interfaces with your device. Check out driver-ztex.c and driver-modminer.c in cgminer for for examples.
|
|
|
|
kramble
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 11, 2013, 03:01:29 PM |
|
A (probably) final update on my experiences with the DE0-Nano, in case anyone out there is interested.
Using Makomk's code (from his github rather than the fpgaminer code), plus some modifications of my own to pack 22 of the sha256_digester's onto the EP4CE22, I've got a single core generating a full bitcoin hash every 6 clock cycles. I've been running this at 140MHz for a couple of days now which I reckon is 23.3MH/s (it averages 20 shares per hour which I reckon is about right, though if anyone wants to correct me on this then please feel free to do so). Its drawing 1.35 amps from an external 3.3V PSU, and the onboard regulators get pretty hot (I'm fan cooling the board). Not that I'd recommend this to anyone as its really pushing the envelope on the DE0-Nano board and may well fry it eventually.
This is probably as far as I'm going to go with this as to clock it any faster will need modifications to the power supply (as Makmok has documented on his web site) since the onboard regulators are only rated at 1.5A (and that's pretty optimistic as they need some serious additional cooling to get anywhere near that).
I'm running a pair of these boards on btcguild which claims to be earning me 0.00659245 BTC per day, not a lot I know, and probably barely covering my power costs (two times 4.5 Watts, plus another say 2 Watts for the raspberry pi host, plus whatever the mains PSU's are dissipating in heat), but I may as well have the boards do something vaguely useful while I think of something else to use them for, and its "free" bitcoins anyway (even if I am just converting joules into coins). I wonder what I can spend them on?
Many thanks to all who have contributed to this project, as its kept me well entertained for the last few months (I saw a quote somewhere saying you can lose 3 months of your life to FPGA's, so it seems like an appropriate point to bow out).
Regards Mark
|
|
|
|
Andynerd
Newbie
Offline
Activity: 14
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 27, 2013, 06:23:41 AM |
|
I just wanted to through this idea out there, sorry if this thread is considered dead or not it has been quite a few days. I was kind of curious if it would be possible to implement an FPGA as a sort of hardware wallet that could be interfaced with an Ethernet adapter (say for arduino). Just kind of a thought I guess, some sort of stand alone, networked FPGA system that would hold onto your bitcoins and not rely on the computer (which can be more easily breached). I guess I'm thinking of something like a piggy bank for bit coins.
|
|
|
|
|
|