Litecoin FPGA!

[Charles999]

Sign me up for 100 units!!

[oatmo]

My cost would be about $800-$850 a unit. With large numbers of units (>15000), it could maybe go to $600. It would probably take 500 units to make up my NRE costs. I can do the FPGA design with a $800 development board and figure out the performance and power. Working full time, I could do the design in about 6 weeks. Since I have a day job, I'll start messing around with it and see how long it takes. I'm pretty confident about providing the perf/$. I'm not at all confident about the power number, because I've spent 20 years doing full custom / ASIC design. I've never don'e FPGAs before, so I don't have a good feel for power consumption. I wouldn't do any system engineering until I proved to myself that it can be done.

I looked at Enterpoint's boards. If one of them had the FPGAs which fall in the sweet spot for scrypt, then they would be great, but none of them do. For them to be cost competitive, they will have to design a new product with a different line of FPGAs on the board. Looking at the product line, that product would fill a different niche for them, so I wouldn't be surprised if they did it anyways.

Oatmo

[marcetin]

Is there some real, open source, project on FPGA scrypt mining?

[WindMaster]

Oh boy..  Here we go again (and again, and again, ad nauseum on a daily basis).  Can't we go one single day without someone armchair-engineering a hypothetical FPGA or ASIC-based scrypt miner based on a back-of-napkin calculation and immediately posting performance numbers and pricing before they've even tried to write an actual real Verilog implementation of scrypt+salsa?

I did some back of the envelop calculations myself, and while I think that scrypt can be done in a FPGA are a 2:1 cost advantage over GPUs, I'm not sure what the power will be, so I'd have to do a prototype on a development board. Not sure I want to spend all that time without knowing that a lot of people would buy it.

I've never don'e FPGAs before

The fastest way to spot someone who doesn't know what they're talking about is when they start claiming they're going to implement an FPGA scrypt miner with a cost/performance ratio exceeding GPU's, with any commercially available FPGA currently on the market (or in the process of coming onto the market).  At least you did admit that you've never done any FPGA work previously though.

Propagation times and clock fanout skew on FPGA's are extremely slow relative to ASIC clock fanout and signal routing, if that's your background.  You can achieve nowhere even close to the clock fanout and signal propagation performance on FPGA's than you may be expecting, if you're coming from an ASIC background.  If you do have an ASIC background, then pretend that you're working on a design and throwing in tens to hundreds of extra buffers or muxes (representing the switching fabric of the FPGA) on every one of your signals between logic elements, and you'll get the general idea of what you'll be dealing with performance-wise when getting info FPGA development.

A back-of-envelope calculation is not valid for making a performance claim and estimated pricing.  Your result is overoptimistic by almost an order of magnitude for any commercially available FPGA, if you're expecting a 2:1 cost/performance edge over, say, a Radeon 6xxx or 7xxx GPU.

There are only so many (known) ways to calculate scrypt+salsa(1024,1,1) between the two ends of the TMTO spectrum.  There isn't going to be something totally revolutionary unless someone devises a cryptographic attack against scrypt that significantly shortcuts the effort needed to calculate an scrypt hash.  And at that point, the same attack would be equally applicable to speeding up GPU scrypt implementations.

[jasinlee]

Oh boy..  Here we go again (and again, and again, ad nauseum on a daily basis).  Can't we go one single day without someone armchair-engineering a hypothetical FPGA or ASIC-based scrypt miner based on a back-of-napkin calculation and immediately posting performance numbers and pricing before they've even tried to write an actual real Verilog implementation of scrypt+salsa?

I did some back of the envelop calculations myself, and while I think that scrypt can be done in a FPGA are a 2:1 cost advantage over GPUs, I'm not sure what the power will be, so I'd have to do a prototype on a development board. Not sure I want to spend all that time without knowing that a lot of people would buy it.

I've never don'e FPGAs before

The fastest way to spot someone who doesn't know what they're talking about is when they start claiming they're going to implement an FPGA scrypt miner with a cost/performance ratio exceeding GPU's, with any commercially available FPGA currently on the market (or in the process of coming onto the market).  At least you did admit that you've never done any FPGA work previously though.

Propagation times and clock fanout skew on FPGA's are extremely slow relative to ASIC clock fanout and signal routing, if that's your background.  You can achieve nowhere even close to the clock fanout and signal propagation performance on FPGA's than you may be expecting, if you're coming from an ASIC background.  If you do have an ASIC background, then pretend that you're working on a design and throwing in tens to hundreds of extra buffers or muxes (representing the switching fabric of the FPGA) on every one of your signals between logic elements, and you'll get the general idea of what you'll be dealing with performance-wise when getting info FPGA development.

A back-of-envelope calculation is not valid for making a performance claim and estimated pricing.  Your result is overoptimistic by almost an order of magnitude for any commercially available FPGA, if you're expecting a 2:1 cost/performance edge over, say, a Radeon 6xxx or 7xxx GPU.

There are only so many (known) ways to calculate scrypt+salsa(1024,1,1) between the two ends of the TMTO spectrum.  There isn't going to be something totally revolutionary unless someone devises a cryptographic attack against scrypt that significantly shortcuts the effort needed to calculate an scrypt hash.  And at that point, the same attack would be equally applicable to speeding up GPU scrypt implementations.

+1

[oatmo]

Oh boy..  Here we go again (and again, and again, ad nauseum on a daily basis).  Can't we go one single day without someone armchair-engineering a hypothetical FPGA or ASIC-based scrypt miner based on a back-of-napkin calculation and immediately posting performance numbers and pricing before they've even tried to write an actual real Verilog implementation of scrypt+salsa?

I did some back of the envelop calculations myself, and while I think that scrypt can be done in a FPGA are a 2:1 cost advantage over GPUs, I'm not sure what the power will be, so I'd have to do a prototype on a development board. Not sure I want to spend all that time without knowing that a lot of people would buy it.

I've never don'e FPGAs before

The fastest way to spot someone who doesn't know what they're talking about is when they start claiming they're going to implement an FPGA scrypt miner with a cost/performance ratio exceeding GPU's, with any commercially available FPGA currently on the market (or in the process of coming onto the market).  At least you did admit that you've never done any FPGA work previously though.

Propagation times and clock fanout skew on FPGA's are extremely slow relative to ASIC clock fanout and signal routing, if that's your background.  You can achieve nowhere even close to the clock fanout and signal propagation performance on FPGA's than you may be expecting, if you're coming from an ASIC background.  If you do have an ASIC background, then pretend that you're working on a design and throwing in tens to hundreds of extra buffers or muxes (representing the switching fabric of the FPGA) on every one of your signals between logic elements, and you'll get the general idea of what you'll be dealing with performance-wise when getting info FPGA development.

A back-of-envelope calculation is not valid for making a performance claim and estimated pricing.  Your result is overoptimistic by almost an order of magnitude for any commercially available FPGA, if you're expecting a 2:1 cost/performance edge over, say, a Radeon 6xxx or 7xxx GPU.

There are only so many (known) ways to calculate scrypt+salsa(1024,1,1) between the two ends of the TMTO spectrum.  There isn't going to be something totally revolutionary unless someone devises a cryptographic attack against scrypt that significantly shortcuts the effort needed to calculate an scrypt hash.  And at that point, the same attack would be equally applicable to speeding up GPU scrypt implementations.

Think what you want. I'm not trying to sell anything, and on lots of things I'm not qualified as an expert. I'm not a FPGA expert, but I've consulted with them (since a lot of my friends work for those companies). I am however a computer architecture and chip design expert, and I've assumed that a FPGA runs 10-20x slower than an ASIC. I was just trying to gage interest, and I think I have a good idea. I know the thousands of caveats that come with the calculation that I did, because I've done 100s of them before, and I know how those designs turned out. Twenty years designing everything in the computer business, and I've made some fantastic things, and totally screwed things up. Luckily I've not made any multi-million dollar mistakes yet, but I've seen plenty of them. I won't ask or pontificate again without some proof for my point of view.

I will add that I did a SHA256 hardware accelerator in an ASIC 10 years ago, so I have done a similar design, and put it into an ASIC.

Oatmo

[anderl]

[digitalindustry]

where do i apply ?!!!


i've seen BitcoinExpress and the other guys work , so i know exactly what to do !

[digitalindustry]

There are only so many (known) ways to calculate scrypt+salsa(1024,1,1) between the two ends of the TMTO spectrum.  There isn't going to be something totally revolutionary unless someone devises a cryptographic attack against scrypt that significantly shortcuts the effort needed to calculate an scrypt hash.  And at that point, the same attack would be equally applicable to speeding up GPU scrypt implementations.

^^^

this is what i think a few people have been working on , i wonder who if any got it ?

[jasinlee]

There are only so many (known) ways to calculate scrypt+salsa(1024,1,1) between the two ends of the TMTO spectrum.  There isn't going to be something totally revolutionary unless someone devises a cryptographic attack against scrypt that significantly shortcuts the effort needed to calculate an scrypt hash.  And at that point, the same attack would be equally applicable to speeding up GPU scrypt implementations.

^^^

this is what i think a few people have been working on , i wonder who if any got it ?

That is not what we are working on actually.

[digitalindustry]

There are only so many (known) ways to calculate scrypt+salsa(1024,1,1) between the two ends of the TMTO spectrum.  There isn't going to be something totally revolutionary unless someone devises a cryptographic attack against scrypt that significantly shortcuts the effort needed to calculate an scrypt hash.  And at that point, the same attack would be equally applicable to speeding up GPU scrypt implementations.

^^^

this is what i think a few people have been working on , i wonder who if any got it ?

That is not what we are working on actually.

ok cool , what are you working on ?

[jasinlee]

Increased efficiency against the hashrate:price. I doubt anyone on here is attempting to shortcut sha256/scrypt or other hashing algos. But if someone accomplishes it we will likely see them on the cover of some very nerdy magazines.

[digitalindustry]

Increased efficiency against the hashrate:price.

hows it turning out so far?

[jasinlee]

Increased efficiency against the hashrate:price.

hows it turning out so far?

30% so I think its a good start.

[CoinHoarder]

Increased efficiency against the hashrate:price.

hows it turning out so far?

30% so I think its a good start.

FYI: 30% price to hash rate... I'm still interested. I'll save it in power costs over a year.  

[jasinlee]

Increased efficiency against the hashrate:price.

hows it turning out so far?

30% so I think its a good start.

FYI: 30% price to hash rate... I'm still interested. I'll save it in power costs over a year.  

That is the goal

[subvolatil]

well correct me  if  i am  wrong, but  scrypt algorithm is  designed  to  prevent   such  hardware  from  being  used  by  creating  a   large  memory requirements, greater the speed, greater  the memory  requirements, FPGA's  would  also  require  in addition RAM chips  to  save  to memory, i guess  the  RAM  requirement  would  be  extraordinarily high.

[broken_pixel]

So, how many people would pay $1500 for a 7MH/s scrypt miner, which ran in say 500 watts? The power is just a swag. I'm pretty sure I could outdo a GPU by 2:1, just not sure if I can get it to 10:1.

If you really had something like that working ($1500 for 7MH), I'd buy a few dozen of them off you, after field testing one. I'm sure there would be a good sized line of similar individuals as well.

The big question you should be asking is... at $1500 a pop for 7MH, what would your profit margins be?

It will depend on there TPG, scrypt uses KH/s not MH/s.

7,000KH/s @ 500 watts

Profit         BTC           LTC             USD          Cost    Profit
Per Day    0.2013 BTC   9.6767 LTC    $20.56      $1.44     $19.12

By profit margins I was actually meaning more oatmo's margins for selling the devices (if that's what he did, rather than opensourcing the design from the start). For 7MH, you could sell it at 3K a pop and still have people line up, since you're still readily beating the price:performance of a GPU rig.

You can buy a 5GH/s- 7GH/s BFL Jap for 288.00 and mine BTC, why would someone spend 3K on an FPGA @ 7MH/s. If it mines scrypt then it would be doing KH/s not MH/s. Just saying. . .  .

[jasinlee]

well correct me  if  i am  wrong, but  scrypt algorithm is  designed  to  prevent   such  hardware  from  being  used  by  creating  a   large  memory requirements, greater the speed, greater  the memory  requirements, FPGA's  would  also  require  in addition RAM chips  to  save  to memory, i guess  the  RAM  requirement  would  be  extraordinarily high.

There certainly is a sweet spot we need to achieve before feeling comfortable selling the fpgas. What you are referencing is not the largest hurdle but I cannot go into details.

[digitalindustry]

Increased efficiency against the hashrate:price.

hows it turning out so far?

30% so I think its a good start.

May I politely suggest at this efficiency , you should market and release,  you see I know more than anyone else about the free-market , (see previous add I applied for )  , at this efficiency your proclivity to tend towards natural inequity is low.

Plus in the open market you will then get the jump on the other., your dillema of courses protecting your investment, but unfortunately , I think that's as good as it gets .

By the time you hold , you take exponentially more risk.

I explained all this before , scrypt  lead time to roi is much longer , (unless hacked) .

That's the key parts to all your market equation. ! And it's going to make you :

1. Give up

Or

2. Be more "honest"/equitable because your risk is greater.


So thank you Colin Percival , you genius.