Topic: Project Evil Genius – Custom SHA2-256 Circuits on a FPGA - page 2. (Read 12351 times)

My live code for my DE0-Nano board is actually using a 0.5MBit scratchpad (the EP4CE22 chip only has 600kBit ram), so I have to interpolate the missing half of the scratchpad (basically one extra pass through the salsa-mix for half the addresses). I can't really see how I can parallelise this as each ram read address depends on the results of the prior salsa-mix (scrypt was explicitly designed to be awkward to parallelise). From some reading I've seen that a larger scratchpad eg 8MBit can speed up the scrypt, which I don't quite understand yet, so once I've read up some more on it then perhaps some tricks will be apparent (yeah, I just wanted to get something running quickly so I coded a direct analog of the cgminer CPU scrypt.c code, rather than doing my research first  )

The pipelining of the salsa-mix is definitely an issue, but its tricky due to the dependency of the scratchpad reads on addresses generated from the prior salsa. Adding extra register stages allows a faster clock, but needs extra clock cycles to complete, completely cancelling out any gain (and there is no gain from the pipelining itself due to the address dependancy). Once I understand the algorithm better, perhaps I can come up with a solution (I'll need to take a look at the CUDA code to see what's done on the GPUs).

Thanks for the kind words, and good luck.

hi

on wich fpga you ll use as basis ?

maybe it ll be interesting to make an asic from your fpga vhdl if it gives better hashing power so we ll be able to get a more powerful asic

keep us posted

OMG he's been outed as a Capitalist!  Someone kill him before he gets away!   

Improving on stuff and making a profit from his efforts!  This cannot be endured...

 

Guys you do realise he is trying to improve FPGA efficiency, and patent the results? This is a hell of a long way from open source.

your work is appreciated, im going to run mine until it costs more in power than its worth just to contribute to the network.

I'm running the core at 25MHz (it didn't seem worth pipelining the salsa mix, given that scrypt is essentially a serial algorithm, so I've implemented it as one huge combinatorial tree), and clocking the on-chip ram at the same speed (just to keep it simple). Using the on-chip ram makes the ram interface very simple as its just a 1024bit wide data path. External RAM (as would be needed for to get any sort of performance from the fpga) is going to be more complicated and would need to run faster, which might make pipelining the salsa worthwhile. Bear in mind that I'm a complete amateur with FPGA/logic design, so don't expect anything sophisticated 

Anyway you can take a look at my code here https://github.com/kramble/FPGA-Litecoin-Miner any suggestions would be welcome. I created a thread to discuss it earlier today in the altcoins section https://bitcointalksearch.org/topic/ann-open-source-fpga-litecoin-miner-260598

That's awesome kudos to you. Would it be possible to load it on github so others can also try to use  your scrypt miner?

Jasinlee has a project running at http://ltcfpga.com/ which seems fairly advanced (but NOT opensource)

I'm currently working on an opensource implementation (just for the LOLs), using the on-chip FPGA ram (it needs 1Mbit per hasher core). I've got the simulation running fine using a register array for ram. Unfortunately I'm only estimating around 1khash/sec performance per hasher core. The next step is to port it to my DE0-Nano board (it can only fit half the scratchpad, so its going to interpolate which is even slower). I'll post it on my github once its in a presentable state.

Okay got it. Sometimes the synthesis software can also do logic optimization, which could reduce the size of hardware, though it's very rarely succesful in substantiial reduction of hand optimized designs.

May I ask did you obtain the size reduction on a HDL module or was it something else?

Watching, good luck with this. 

Only if you were here a year ago, now this is a bit late if not obsolete very soon. I'm hoping the best and I'm very interested to see how well you manage to do with this project.

I'd also be very interested in a git, and I'd certainly throw a tip your direction.

If this does work you should be able to get twice the engines into one FPGA. There is money in this as there are plenty of FPGAs out there and I'm sure ppl would love to double thier hash rate!!

Great, keep going!

Memory is problem. He will

Is there a compiled bitstream compatible with ztex out there?

FPGAMINER

Getting SL3 unlock to FPGA miners would give them new life. I do not have much of them but they will be more universal if someone keeps them running SL3.

Also I am not rich, but willing to support job with some BTCs.

It's a lot of fun down there!  It's a shame the Spartan 6 architecture is so limited.  I suggest you take a look at the 7-series FPGAs, like the Kintex or Artix.  The architecture is nicer, and performance is much higher.  For example, I was able to implement a miner using the DSP48E1s on a Kintex.

Also, have you looked at bitfury's code?  He has the most performant code for Spartan-6 LX150 chips, and I would be shocked if anyone beat his record (in MH/s) on that chip.  It's optimized down at the slice level and manually placed.  https://bitcointalk.org/index.php?topic=228677.msg2417706#msg2417706

Unfortunately, or fortunately (depending on how you look at it), FPGA's will never beat ASICs in terms of performance per dollar, or performance per Watt.  So FPGA mining is a curiosity and plan-B sort of thing now.

I coded up a quick SL3 cracker about a year ago.  It either ran on my Spartan 6 devkit, or the X6500, I can't recall.  I could probably dump the code to github if people are interested.  I didn't optimize it particularly well, just got it working.