K some VERY VERY preliminary verifiable measurements. (verifiable from my side).

Iv'e had code for some time that takes about 1ms to do ONE round (no laughing at the back there), which would make it about a 1kh/s.
This is actual code on an FPGA,  yes it has not been optimized yet and yes it is a SINGLE core.

I had not done any work on it, purely because I was working on a 'crypto job' for someone else.... then there was the work on getting  the Bitcoin FPGA code operating at a higher level, currently thats clocking about 350MH/s on a xilinx, with bitcoins at a stupid level, and the fact that BFL & TOM both shafted me on deliveries of ASIC kit it is about priorities.(beer money)

Since I recently took a slagging down on IRC about what some called  'stock images' that I : "had modified so they could not be google searched" , there were requests for a special 'proof' message which I have included specifically for the IRC doubters.



This is not a  'get rich quick scheme' but rather a pure research task, possibly the first images of  an FPGA product running litecoin.
Crypto currencies are of interest to me, but I really will be surprised if people can break into high double figures with a single core on an FPGA.

Sorry , you seem to have a very short memory....... or are you saying that it was not you that had the PM from me......

 :'(Seriously some noobie statements  in this discussion.

1. FPGA  is NOT , I repeat NOT a single product from a single manufacturer and as such there are NO hard and fast rules on what you can and cannot do with  BRAMs or memory generation, even the Xilinx product range has a different 'flavour' across product lines.

So statements such as "you don't know what you are talking about" only show you up for the noob you are, if you were THAT WELL researched you would know this.

Talking about 'RAM' as a single entity is also a misnomer ,because generally there are multiple ways to 'construct' RAM, which is after all just a flipflop.

If you are "lucky" the FPGA may have BRAM blocks where the internal resources and routing are all optimized for you, and you just 'hook it up'
If you are not one of gods chosen people then you have to construct the 'RAM' from normal logic, with all the shitty routing and interconnection that infers.

2. Memory access speeds have little to do with it, ultimately it comes down to internal logic chains..., no matter how FAST your memory is,
if your shittly VHDL/verilog is so badly written it takes 20ns to execute a clocked routine, then you may as well just be using paper& pen as a scratch pad, ultimately it bottlenecks somewhere.
Xilinx allows their internal BRAM to be operated 'upto' 600Mhz on some of the V5/V6, but unless you can get the rest of your relevant logic upto that speed , it does not really matter how fast it is.

As regards Scrypt, I had actually contacted some members who claim to be interested in Technical co-op, but it came to naught....
People are only interested if they think you have an edge.

I have my own Scrypt code for Xilinx FPGA and a pluggable rack system, that takes 10 boards, I had to mux them as 8+2 hot spares.(yep sometimes they drop in & out of service randomly)

Its a nice size, about 70cm*20*35cm, which allows for cooling & to slide PCBS along to get the JTAG into each board, with per board highspeed 17CFM MAGLEV fans (none of those shitty fans with the oilpool and stupid split washer under a label)
Only oversight is WTF do I put the PSU's.....(I'd banked on an ATX actually being able to supply the 3V3 supply, but they all lie about the capability)

Unfortunately...
Performance is shite...... insofar as comparison to high-end CPU or GPUs.
Who knows if I can get an improvement but it is going to be very hard to beat the GPU thrughput Vrs cost.

Sorry but it can and does.
There is no correct Measurement of delay UNTIL the device is thrugh the place and route stage, sometimes "map" can come close, but I've had bitcoin designs that give  closure timings for over 300MHZ, but then after final P&R  they hit stupidly low figures

I.E 87Mhz....... or 87MH/s

which is just embarrassing..... for a V5 or V6,(HOT TIP coming up...)

The  absolutely F***** stupid thing is that changing a single DCM_BASE or DCM_ADV parameter can  trash your results....
The unit is supposed to be totally self contained clock multiplier(which it is...) but what they don't tell you is that when you configure it, the configuration pins are either grounded or taken high and depending on the combination you choose, it can screw up the routing resources to such an extent you loose massive throughput.

CLKFX_DIVIDE => 10,
CLKFX_MULTIPLY =>12,

does not give you the same routing and performance as
CLKFX_DIVIDE => 5,
CLKFX_MULTIPLY =>6,

Even though the final CLKFX frequency that feeds your logic is the same!!!!!

The way I tackled it was to find the BEST routing configuration frequency for the DCM then to externally CHANGE the crystal to match the internal clocking rate I wanted, which defeats the purpose of the DCM......
The other solution would be to register the DCM_ADV then dynamically reconfigure during running.

Problem is that XST ALWAYS reports shit hot timings for the simulation, but once the design is mapped into the actual device, then the  timings go to pot because of the way the interconnects work.(some of the XST tools just look at the 'pure logic' chains for timing).

Also as regards splitting the clocks.. it is a bad idea and there is no need for it....(in this design), becasue once you have more than one clock you have to deal with crossing clock domains and then you have to deal with shitty situations of clock lag and jitter over multiple clock sources.
As regards heat.. the hotter it runs the shorter it lives, Xilinx starts to shutdown at just over 85deg. die temp.(its designed into the die)

I've taken the XUPV5 to over 350MH/s,  but it has required a very special power supply design and special PCB (which smells like cooked hairy crab when it's running full pelt)+6 17CFM fans...(those are special 'maglev' designs, not like the shitty stuff with the oil and the shitty washer holding the spindle in the housing)

BUT It's a bitch, yesterday it worked fine but today it was heavy rain and It's getting bad shares, but dropping it back 20MH/s fixed it until the rain became heavier...

it is purely a research project as both Tom & BFL have screwed me on my ASIC deliveries.

Finally as regards to the 'main delay' being in communication... actually it is unlikely, rather it is in some FPGA designs that don't allow block interruption when the block changes.
 I suspect this becasue  of the FIFO's and the increased USART timings(230400) I designed in to deal with other 'idle time'

Plus there are a number of shortcuts (nope not the well documented SHA256 ones) even saving a few tens of ms per round all adds up....

So the plan is to solve the problem with your own get rich quick scheme......
at the current rate of $160USD per bitcoin@ 7%

Sorry 1500%, even if you took my advice you would have made  70% on your money in 5 days!!!!

K...
Iv'e just taken a look at both sets of java code.
The reason it is not performing as well as C++ is the creation of objects,  creating objects in java is SLOW.

The trick is to instigate the objects you need at the start then REUSE the objects already created.
Also on the threading use a pool.

Failure to follow these two simple cases is why 90% of all java programs run slowly, because the bytecode is spending its time continually re-creating object it has just disposed of.
Once memory gets squeezed, then the GC continually kicks in.


OK I graphed it, you can clearly see the problem




You can see the 'Heap' thrashing about as objects are created and destroyed

Lets just say as usual Hardcore is wide of the mark!!!!!!

If you actually check the link given.... you will see that one V5 is a 110T the other is a 50T

"Xilinx Virtex-5 XC5VLX110T XC5VLX50T"

You can get a double hashing core into the XC5VLX110T.
I have just finished research which gets the hashing rate upto 370MH/s per chip at a little over 10W per chip.(why?, because i'm bored)

As for the XC5VLX50T good luck with getting any decent hash rate out of that!!!!, because you would have to go with a nested core and not an unrolled one.

So actually if you buy that board, we can see from here:
http://tpbitcalc.appspot.com/

That at 200Mh/s which is a public bit file, you would need about 85 days to recover the cost, and since  Avalon and BFL(most probably)
will have dumped a shit load of ASICS in the next 3 months, it is unlikely you would see any decent return.


I myself have indeed been buying up FPGA's at stupid prices, but that is for a project on litecoin, but first I will mine bitcoin to recover the cost of the XC5VLX110T's.

Another idiot wanting a 'freebee' go do some CPU mining.

Simple host your kit in Hong Kong... the tax is 0% on bitcoins

Yep.. it will continue in the short term , until the media settles down.
Then there will be a massive sell off.

Depends
if the EU are going to continue to do stupid things like steal 80% of peoples money.
if yes then crypto currencies will become BIG, but at the same time governments will do their best to limit them.

previously Bitcoin was a gimmick used by people wanting to buy drugs, but if the stupidity continues then people will invest, purely because there is nothing else, I mean 900% increase since September 2012

Good luck to them........

People will only buy if they can get ROI and if you are selling a unit at 1.5k but the ROI is 4 years , then it's really going to dent their sale figures.

more likely they will do what josh is doing... set up a mining company

And yet an even better solution would be to take your wad of Sweaty cash over to mtgox and buy some bit coins.

In the last 5 months the price is up nearly 800%.......

That is slightly incorrect.......

You should state FPGA's bit-mining kit  from the major suppliers in not currently cost effective, the actual FPGA's can be had very cheaply on Ebay. and are cost effective when incorporated into a home brew system...

I'm doing research.

I have an FPGA XUPV5-LX110T that seems to be pushing about 400MH/s, that is double the current record.

Current consumption is about 3A at 3V3  which is about 10w , but even so it still blew out a component bottom right.

and half way up the right a solder blob to patch the  inductor that blew out....

The current seems  too low for the hash rate, but chipscope seems to confirm it....


I just finished debugging the "hacked" board today.. and yes I know there is no 'coin' in using an FPGA to mine, but I have my eye on litecoin.....



Yellow glue & bluetack is great for sticking  development hacks on a PCB

Basically it is a  'scheme'

Someone who wants to 'hold' hardware but does not want to put up the cash, gets a load of people to buy 'shares' in the mining throughput of the hardware, whilst they charge a % for electricity and hosting.


The shares *may* pay a % return.

Problem with many of these schemes is that they are setup without proper legal protection so if it goes tits up, or the person runs off with the hardware, then there is little you can do.

You pay's your money and you's takes your chances........

Yep  I've been lurking for quite some time, but I have a couple of new projects on, that require contact with some bitcoin members.