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 

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;


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.

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.

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).


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!

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

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.

Check out the whitelist request topic.  Explain the situation, they may take pity! https://bitcointalk.org/index.php?topic=15911.0

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).



I think the problem is caused by the following code in sha256_pipeline.vhd;
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.

Ignore that.  Just hit 4 hours.

Whitelist request.

I've been browsing the forums for a month or two, mainly reading up on the processing side of things.  I didn't realise there was a 4-hour restriction or I'd have joined sooner.

I'm fairly new to using bitcoins, but do have an understanding of the underlying protocol and hashing algorithm.

I'm currently experimenting with a home brew FPGA system.  I wish to participate in this thread; https://bitcointalk.org/index.php?topic=9047.0  (Official Open Source FPGA Bitcoin Miner)


Thanks

I wish I'd known about the 4 hour restriction last month when I started browsing the forums!  I only found out when I had something interesting to post.

Thanks!

Merry Christmas... slowly learning how this works:  188FCZTf1Tc91nj3cTfPThvVKe6dFrNX7h