I'm very interested in high performance,low cost and ultra low energy hardware for mining.
lulz
Topic: An estimate of fpga performance (Read 51502 times)
lulz
I'm very interested in high performance,low cost and ultra low energy hardware for mining.
The FPGA already meets my needs for low power use and high performance,now all I need is it to be low cost and I can easily get my hands on one.Hope its in UK soon.
The setup has to be easy as well.
If someone can create something that can rival my Radeon HD 6950 (400MHash/s),then I can finally put those noisy GPU and CPU things to rest.
Een if it doesn't rival my card,I can use several FPGAs together to get that performance anyways.
I worked out its less than 13Watts with 6 units (1 each produces 70MHash/s) VS 210Watts for my card.
The FPGA already meets my needs for low power use and high performance,now all I need is it to be low cost and I can easily get my hands on one.Hope its in UK soon.
The setup has to be easy as well.
If someone can create something that can rival my Radeon HD 6950 (400MHash/s),then I can finally put those noisy GPU and CPU things to rest.
Een if it doesn't rival my card,I can use several FPGAs together to get that performance anyways.
I worked out its less than 13Watts with 6 units (1 each produces 70MHash/s) VS 210Watts for my card.
What about evolving the hardware to do the hashing rather than writing it as straight VHDL?
I had a good idea about using hadoop clusters to run the fitness tests for the evolutionary algorithm testing.
I had a good idea about using hadoop clusters to run the fitness tests for the evolutionary algorithm testing.
Could you expand more on this idea? Not all applications are suited for evolutionary approaches, and my guess is that hashing algorithms are definitely not one of them.
For those who have no clue what i am talking about, read the article about the professors that got an fpga to recognize the difference between two tones with way less than 100 gates and no CLK.
http://fsweb.olin.edu/~mchang/research/documents/seminar/evolve2k2/evolve.ppt
http://www.cogs.susx.ac.uk/users/adrianth/ade.html
http://fsweb.olin.edu/~mchang/research/documents/seminar/evolve2k2/evolve.ppt
http://www.cogs.susx.ac.uk/users/adrianth/ade.html
That kind of application is well suited to evolutionary approaches.
Quote
I always had a thought that evolving the circuits would be a way to find really fast ways of "cracking" various hashing algorithms, as well as making really tiny encoders and decoders for various projects.
There's not supposed to be any smooth gradients in a cryptographically secure hash, so I don't see how any evolution-based approach could work for cracking them. What exactly do you have in mind?
single chip 100Mhash/s?
What about evolving the hardware to do the hashing rather than writing it as straight VHDL?
I had a good idea about using hadoop clusters to run the fitness tests for the evolutionary algorithm testing.
For those who have no clue what i am talking about, read the article about the professors that got an fpga to recognize the difference between two tones with way less than 100 gates and no CLK.
http://fsweb.olin.edu/~mchang/research/documents/seminar/evolve2k2/evolve.ppt
http://www.cogs.susx.ac.uk/users/adrianth/ade.html
I always had a thought that evolving the circuits would be a way to find really fast ways of "cracking" various hashing algorithms, as well as making really tiny encoders and decoders for various projects.
Anyhow, i enjoyed this thread.
What about evolving the hardware to do the hashing rather than writing it as straight VHDL?
I had a good idea about using hadoop clusters to run the fitness tests for the evolutionary algorithm testing.
For those who have no clue what i am talking about, read the article about the professors that got an fpga to recognize the difference between two tones with way less than 100 gates and no CLK.
http://fsweb.olin.edu/~mchang/research/documents/seminar/evolve2k2/evolve.ppt
http://www.cogs.susx.ac.uk/users/adrianth/ade.html
I always had a thought that evolving the circuits would be a way to find really fast ways of "cracking" various hashing algorithms, as well as making really tiny encoders and decoders for various projects.
Anyhow, i enjoyed this thread.
You're on the right track - the synthesis of ASIC or FPGA circuitry from Verilog or VHDL code is very very good these days, but there are ways to make things better particularly when you are building an ASIC.
single chip 100Mhash/s?
What about evolving the hardware to do the hashing rather than writing it as straight VHDL?
I had a good idea about using hadoop clusters to run the fitness tests for the evolutionary algorithm testing.
For those who have no clue what i am talking about, read the article about the professors that got an fpga to recognize the difference between two tones with way less than 100 gates and no CLK.
http://fsweb.olin.edu/~mchang/research/documents/seminar/evolve2k2/evolve.ppt
http://www.cogs.susx.ac.uk/users/adrianth/ade.html
I always had a thought that evolving the circuits would be a way to find really fast ways of "cracking" various hashing algorithms, as well as making really tiny encoders and decoders for various projects.
Anyhow, i enjoyed this thread.
What about evolving the hardware to do the hashing rather than writing it as straight VHDL?
I had a good idea about using hadoop clusters to run the fitness tests for the evolutionary algorithm testing.
For those who have no clue what i am talking about, read the article about the professors that got an fpga to recognize the difference between two tones with way less than 100 gates and no CLK.
http://fsweb.olin.edu/~mchang/research/documents/seminar/evolve2k2/evolve.ppt
http://www.cogs.susx.ac.uk/users/adrianth/ade.html
I always had a thought that evolving the circuits would be a way to find really fast ways of "cracking" various hashing algorithms, as well as making really tiny encoders and decoders for various projects.
Anyhow, i enjoyed this thread.
BGAs are definitely solderable with hot blowers - I've done it a few times with maybe 80% success rate. The hard part is creating the balls on a new chip, you need a special solder paste and a thin mesh that allows only a certain amount of paste on each pad (reballing kit). When heated, the paste turns into solder balls. If the balls are readily formed, it's all fun and games.
Anyway, I'd outsource such a job to shops specialized in prototypes or small series, maybe somewhere in China. It will most likely cost less than the whole hardware and man hours otherwise required.
Anyway, I'd outsource such a job to shops specialized in prototypes or small series, maybe somewhere in China. It will most likely cost less than the whole hardware and man hours otherwise required.
Quote
QFP is possible to solder by hand but BGA is not. You will need a special tool and some experience to solder BGA, or pay someone to do it for you.
People have soldered BGA with blow dryers before 
Not that that is the best idea, but just sayin'.Quote
Then again, with the complexity of SHA256, gate propagation problems will probably force us to run the chips slowly enough that heat won't be the limiting factor.
It's not a huge problem, but it's there. The latest design gets 100MH/s (@100MHz) and requires either a lot of air-flow or a heatsink.Quote
you can program the fpga/tiny12/eeprom directly via ISP/JTAG. during development you configure the fpga directly via JTAG from your PC
I only looked at the circuit image you posted, not the rest of it, so excuse me if I missed something obvious, but why is there an ATtiny on there? FPGAs can program themselves from a flash chip unless I'm mistaken.
QFP is possible to solder by hand but BGA is not. You will need a special tool and some experience to solder BGA, or pay someone to do it for you.
Yup. Someone had suggested doing a minimal connection to avoid having to deal with 4 layer PCBs. It might work, but there are a number of potential problems.
Soldering a BGA, PLCC or QFP and watching it pull itself into perfect alignment is one of the coolest things a guy can do. Totally makes you feel like a wizard, commanding the universe with seemingly nothing but your willpower. On the other hand, when it doesn't work right it'll make you want to murder kittens.
Soldering a BGA, PLCC or QFP and watching it pull itself into perfect alignment is one of the coolest things a guy can do. Totally makes you feel like a wizard, commanding the universe with seemingly nothing but your willpower. On the other hand, when it doesn't work right it'll make you want to murder kittens.
You may run into thermal issues if you leave a bunch of BGA balls unconnected. The chip designers typically assume that the PCB is going to be sinking most of the heat load.
I would have thought that if you are going to attach *any* BGA balls then it is far easier to attach them all, than to leave some unconnected. Unconnected pads on the PCB won't make any difference to the PCB price. While I haven't ever hand-soldered BGAs, having all pads is supposed to make it easier, rather than harder. For example, by pulling the part into proper alignment uniformly as the solder melts and wets the pads.
You may run into thermal issues if you leave a bunch of BGA balls unconnected. The chip designers typically assume that the PCB is going to be sinking most of the heat load.
Then again, with the complexity of SHA256, gate propagation problems will probably force us to run the chips slowly enough that heat won't be the limiting factor.
Then again, with the complexity of SHA256, gate propagation problems will probably force us to run the chips slowly enough that heat won't be the limiting factor.
and thats main reason to stack more-than-one FPGA maxtrix per/board, i guess ? i mean in real-use-applications.
Maybe one could make an el-cheapo pcb since we have no use for all those bga pins.
If we manage to connect powers, jtag and a few i/o lines that would suffice.
If we manage to connect powers, jtag and a few i/o lines that would suffice.
if someone design FPGA-chip-based board, designed for mining, not FPGA-related software development, ie, not "evalution board"[without plenty of redundant features and w/o ridiculous pricing
stripped to the bone circuit for a fpga board can look like this:
source: http://www.mikrocontroller.net/articles/Low_Cost_FPGA_Konfiguration (all german tho)
long story short:
you can program the fpga/tiny12/eeprom directly via ISP/JTAG. during development you configure the fpga directly via JTAG from your PC.
when you finished development you can write the .bin file to the eeprom and the Tiny12 will take care of programing the fpga when no pc is connected.
this works really fine with Spartan-3. and you don't need to invest in an expensive development board for this purpose. Of course you will additionally need an ethernet core and/or communication lanes between fpgas if you want to gang them together, etc ,etc. the above circuit is as already said just a cheap basic circuit for a fpga board/dev-board that doesn't have non-volatile memory.
if someone design FPGA-chip-based board, designed for mining, not FPGA-related software development, ie, not "evalution board"[without plenty of redundant features and w/o ridiculous pricing] and publish design in open domain for nominal BTC fee, thats would be cool.
ordering/using software-developing-targeted boards/kits for BTC network needs isn't reasonable.
ordering/using software-developing-targeted boards/kits for BTC network needs isn't reasonable.
Area Improvement: <80K LUTs for 80MH/s
I managed to fit one SHA256 round, one hash per clock, into about 30k LUTs + 13k registers on a Cyclone, although I never validated this design because my FPGA only has 17k LUTs. So, if I didn't mess up (which I can't really tell...) this would mean 60k LUTs + some interfacing. I verified the core idea behind this in a non-FPGA simulation, and then implemented the idea in Verilog.
Unfortunately the larger dev boards are a bit too expensive for my taste, so this project is on halt. If anyone is willing to loan one to a complete stranger, I'm all up for it
We could meet first. I live in East of England, pm me if you wish. 
Maybe one could make an el-cheapo pcb since we have no use for all those bga pins.
If we manage to connect powers, jtag and a few i/o lines that would suffice.
Perhaps one could make a two-layer card and just leave pins not being used?
If we manage to connect powers, jtag and a few i/o lines that would suffice.
Perhaps one could make a two-layer card and just leave pins not being used?
Quote
If you are reading this thread, and you didn't understand any of what I said above, please consider a different approach to mining, or get a demo board, or wait until someone has a tested and working design that they are willing to produce and sell.
You think will stop them trying?
Ovens, solder, chips ... what could possible go wrong? It's like a chemistry set for grown-ups this place.
You probably could whip one up over the weekend. At least the design. The PCB fab would take a while. Bad luck on that too, the next 4 layer dorkbotpdx order is going out on Monday. So, some time in August if you like their service. I don't know if sparkfun has a shorter cycle time for 4 layer or not.
If I didn't have to pack this weekend, I could probably bust out a quick and dirty breakout design in FreePCB. They should already have the footprint, and after that it is just a matter of dragging the pins out to the edges and a quick shot at the autorouter. No promises on clock skew or noise at high speeds, but good enough to play with.
Soldering would be rough. I think I could manage it on a stove / hot plate with my SMD rework gun, but most people would be putting a $150+ chip in their oven with way either way too much or way too little solder paste.
If you are reading this thread, and you didn't understand any of what I said above, please consider a different approach to mining, or get a demo board, or wait until someone has a tested and working design that they are willing to produce and sell.
If I didn't have to pack this weekend, I could probably bust out a quick and dirty breakout design in FreePCB. They should already have the footprint, and after that it is just a matter of dragging the pins out to the edges and a quick shot at the autorouter. No promises on clock skew or noise at high speeds, but good enough to play with.
Soldering would be rough. I think I could manage it on a stove / hot plate with my SMD rework gun, but most people would be putting a $150+ chip in their oven with way either way too much or way too little solder paste.
If you are reading this thread, and you didn't understand any of what I said above, please consider a different approach to mining, or get a demo board, or wait until someone has a tested and working design that they are willing to produce and sell.
Yes, but for this application the LX150T is not needed. The T at the end is for a quite fast transceiver which is great when you want to connect to fast periphery.
For this application a Spartan 6 LX150 is right. Preferably multiple ones on one pcb.
However the LX150 is available only in BGA or CSP, which you cannot solder yourself. You'll need an oven for that. And maybe a stencil for the solder paste too if it's not a prototype. Also BGA package means that you need a multilayer pcb.
What I want to say is that it's certainly not impractical, but you'll not going to engineer this on a weekend.
For this application a Spartan 6 LX150 is right. Preferably multiple ones on one pcb.
However the LX150 is available only in BGA or CSP, which you cannot solder yourself. You'll need an oven for that. And maybe a stencil for the solder paste too if it's not a prototype. Also BGA package means that you need a multilayer pcb.
What I want to say is that it's certainly not impractical, but you'll not going to engineer this on a weekend.
Yeah, sorry. I have the bad habit of limiting my searches on Digikey to parts that are actually in stock.
Jump to: