Topic: The performance claims and prices are unrealistic (Read 5311 times)

I see no point in continuing this discussion. I tried to reason with you but you avoided to answer all the technical arguments I spent time writing down in this post explaining that ASICs are very plausible. Besides, it is now proven that you were wrong. As widely reported today, "it happened": jgarzik, a core bitcoin developer, has received the first ASIC unit, and is mining with it as we speak. So, please stop trolling the forums.

Please specify what "few months" means in real numbers. I don't think you will get 4.5GH/s for $150 price tag at 1000MH/J as the Jalapeno is specced here:
https://en.bitcoin.it/wiki/Mining_hardware_comparison

Don't get me wrong, I don't want to be the "doom cryer" or a pessimist, I would LOVE to see ASIC products to be available for bitcoin. I just don't think it will happen. By ASIC i mean true asic, not FPGA conversion.

Which is why BFL is selling ASICs (for an instant profit) instead of mining with them for months to recoup their investment. Congratulation for logically deducing that BFL's business actually makes financial sense, therefore is realistic!

PS: will you promise me that you will write an apology, once I receive my ASICs from BFL in the next few months, proving that you were wrong?  

Damn, people here know their sh*t!  A bit of FUD/BS here and there, but some good debates!
If only the NSA agent on this forum would post, and bring us a few years into the future...

A few thoughts:

* OP's post title could be applied to ANY technology industry: cars, phones, etc. - IT'S CALLED MARKETING.
* I doubt anyone here is particularly concerned with export restrictions - this is bitcoin, not a Corporation X board meeting!

No need to, I think what he meant to say is GTFO.

There has been dozens and dozens of people who did extensive cost analysis already, Thank you anyway.

Even if it took 2 year to pay for your said ASIC R&D, remind yourself bitcoin isn't going to stay in the XX$ range forever and some people will want do it even at a lost to secure the network.

Hold on a sec, I promise i will reply. Just give me a few moments to google what a clock buffer is/does.

You know......

With so many f*** Crypto/Hash and ASIC experts in this thread... by now the planet should be flooded with bit-coin producing ASICS

Please just  go buy an FPGA development board and build a demo engine ... or at the very least go do some research.
At the end of it.....you may even be able to have a decent conversation about clock buffers.........

Yes i do, but by the time you add in the cost of electricity, occasional down time, the designers profit margin etc, you are talking close to 6mo to pay for your ASIC chip.

You know that 1110 hours is only a month and a half, correct?

Users will buy hardware to make money. Would you buy $1000 chip if it did no good for you? The network capacity is relevant, because the only way a chip maker will comit to designing and making a chip is if they can sell enough of them to justify the R&D cost.

Do some math:
network btc is 150 btc/hr, which is $2700/hr. Your fraction of this would be based on your hash ratio to network total. Let's make the most favorable assumption that ASIC will drive all GPUs and FPGAs off the grid, so 100% of network hash rate is coming from ASIC. If total N asic units are made, the R&D cost per chip is X/N. Lets say that X is $1million, so R&D cost per chip is 1,000,000/N. When you buy 1 chip you get 1/N network capacity and so you are getting $2700/N/hr. Which means just to pay for R&D cost you will have to run your ASIC 370HR with FREE electricity. In reality ASIC will not have 100% of network hashrate, your electricity is not free and your actual cost will be at least 3x the RND cost since you need to pay for hardware itself. Which basically boils down to 370*3/F =1110/F Hours. F is the hashrate fraction of ASIC devices to the rest of the network. So in the most ideal case it will take you say 1110 hours of hashing with free electricity to pay for your ASIC chip.

That chip doing 73 Mhash/J was more than merely designed, it was built! Go look at the die pictures!

Nice try. I can design a nuclear reactor in couple days, i really can; but it does not mean I can build one for less than $5 billion and faster than 5-10 years.

No. The SHA-256 part of the ASIC that I pointed to was designed in weeks, not 2-3 years. It is open source and just a few hundred lines of VHDL: https://cryptography.gmu.edu/athena/index.php?id=source_codes

Also, yes, BFL can, and probably did, spend about $1M developing their ASIC so far. They have received more than $1M of preorders (proven), plus additional venture capital (according to them). They can definitely foot the bill.

Also, the Avalon team seems to have been able to do it for less than $300-400k (excluding salaries), based on their price quotes from TSMC with poorly obscured prices ( https://bitcointalksearch.org/topic/m.1381782 ). This validates anecdotal evidence of private wealthy individual engineers having designed their own ASIC for personal projects for only a few hundred thousand dollars.

Bottom line, yes Bitcoin ASICs are definitely financially doable by teams with the funding of BFL and Avalon. If you doubt this, I encourage you to bet against the "BFL is real" bet (see link in my signature) - you would make a killing if you are right

Where in the hell are you getting your numbers? I've reread this paragraph a couple times and I still can't piece together your thought process...

1) You don't need $1 million to develop an ASIC...though I suppose it would help.
2) You calculated (poorly) the full output of the network in terms of $$ to somehow justify hardware development. Why would this even matter?
3) I can't even...
No. Just...no.

Look on the bright side: at least get some mashmallows, since we ain't getting ASIC past vaporware phase anyways...

To build a real ASIC it will be $1-$2 million in startup costs. With current bitcoin design 25 coins per 10 min plus transaction fees, call it 30 coins per 10 minutes, 180 coins per hour at the rate of $20 per coin we are talking $3600 per hour for full network capacity. How long you think it would take to make $3million, which is what end user would endup paying for ASIC? We are talking about 1000 hours to pay for hardware development cost alone with free power. And this is assuming that the ASIC will crush all other network capacity, which in reality it will not exceed 75%-90% of. The market is too small, it will simply not be worth the investment.

And with 2-3 years of design, prototyping as well as about $1-$2 million start-up cost you can do it.

Still going. This is fairly amazing. I kind of want to track him down, find out where he supposedly has a job in the engineering field, and alert his superiors that he's vastly unqualified for his job.

Hate that when someone just wastes a whole bunch of people's time.  No idea why I read this whole thread.

You seems to like explaining stuff even if said stuff isn't related in any ways to what you're replying to.

Just stop already,,, you're either off-topic or you're missing 2/3 of what you're trying to explain.

You are wrong. A real-world SHA-256 130nm chip, non-optimized for Bitcoin, has already demonstrated 73 Mhash/J: https://bitcointalksearch.org/topic/best-demonstrated-efficiency-1290-mhashjoule-95762  Merely scaling down this non-optimal design from 130nm to 65nm would multiply the Mash/J efficiency by 4 (because efficiency is linearly proportional to the transistor junction area), making it 292 Mhash/J.

Then it is not hard to imagine that optimizing the chip for Bitcoin (ie. two SHA-256 with no high-speed I/O since the same data block is hashed over and over locally, merely incrementing the nonce) would improve the efficiency by a factor or 2 or 3, therefore making it 584 Mhash/J or 876 Mhash/J.

These numbers are not far from BFL's claims (1000 Mhash/J), making them plausible.

While you have some of the overall concept there, your attention to detail is lacking. 

Hashing and encryption ARE two different things. In fact though, they are both used when you log into your online banking account.
1. Your computer gets the public RSA key of the server and encrypts the AES key with it.
2. Sends the key to the server together with your password, which is encrypted with AES.
3. Server decrypts AES key, using that key decrypts your password, it hashes your password and compares the resulting hash to its stored hash. If two match, you are authenticated.
Server does not actually store your password, just its hash, this way if hacker steals the list of all password hashes, he still cant log in...

I am going to say that you have made the most elegant comeback I have ever read in a long while.

You are a rising star in my book!

Last I checked, hashing and encryption are two different things. They only barely resemble one another on a superficial level.

Sorry, pcm81, but the other camp's marshmallows are lookin' mighty tasty. I may have to head on over there to make sure they're not using any of my barn wood as fuel. That would piss me off.

As a computer engineer (the kind of engineer that actually knows about the topic at hand), I call bullshit on pcm81 having any idea what he's talking about.

Regarding export restrictions, I believe Bitsyncom is a US-based company. As such, it should have no problem manufacturing SHA-256 devices at a subsidiary located in China since China is not on the ban list (Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria). In fact, many companies such as Motorola and Cisco manufacture hardware encryption technologies in China.

I can't say for sure whether Avalon is 100% legit in this matter, but I have been involved in a small busines venture where this setup has been done before and it was no big deal.

Obviously, but the professional training you should have gone through is usually pretty thorough in driving home the idea of not throwing around your qualifications when it's (blatantly) obvious you have no idea what you're talking about.

Yes, Plug it in, turn your miner on... and go. Same with all the other FPGA's at the time.

Yes there were better bitstreams coming out to make them go faster, and JTAG was disabled on at least BFL's FPGAs (Not sure on Modminer, Icarus/Carismore.)

1. I said i am an engineer, i never said i was a PE. Even if I was a PE, this is internet forum small talk, this does not qualify as consulting. Nice try, but no cigar.

But did they actually program the FPGA in China? I seriously doubt that.

Isn't the guy(s) behind AvalonASIC the same people that delivered Icarus and Carismore FPGAs?

I'm probably confused with FPGA they we behind BUT... they still designed an FPGA that could hash the SHA-256 encryption algorithm that Bitcoin uses.

That had no issues from shipping out of china...

This thread is comedy gold.

I honestly can't see his guy being serious, he has to be trolling. If he is a P.Eng, he should review his licensing body's guidelines on consulting outside his area of expertise.

Uhh..what?
So if I light my gate arrays on fire, they spontaneously turn into integrated circuits that can only perform one task? Wish I would have known that before! Could have saved a ton of money on preorders...



This.

@pcm81 - You have a better chance of winning the Powerball Lottery (if you're in the United States) four times in a row (at 1 / 175,000,000 chance or so) than finding 1 collision.

In general, number of pads doesn't have to match the number of pins. One could use a power interposer with one ruddy wire to the pin and many thinner wires to the pads.

Maybe they were given a choice: QFN before New Year or TO-220 after New Year. Example custom packaging from the same site:

http://www.psitechnologies.com/products/custom-packages.php

As far as dual I/O: maybe they used some ready-made serial I/O blocks that operate in a dual ring, sort of like FDDI? There are pins named "bypass", which kinda suggests ring topology interconnect.

I consider pcm81 proven wrong in most of his claims.
The question is, uninformed or FUD?
Still, I enjoy the insights given here, as I had little knowledge of all this before Bitcoin.

And I still don't believe in ASIC miners before having definite proof! :-)

/subscribing

Ente

https://bitcointalksearch.org/topic/announcement-avalon-asic-development-status-batch-1-120184


Having extra pads for power kinda makes sense, but I wonder why they have dual I/O lines.

The original post has multiple false premises and therefore makes false conclusions. I'm going to address just the above two.

Bitcoin hasher is a spectacular example where full-custom ASIC implementation will be much better than the FPGA implementation.

SHA-2 is a rather rare digital circuit that is completely self-testable and observable. All the standard JTAG testing logic required in majority of digital circuits can be omitted. In fact vast majority of the internal D-type flip-flops in the hasher core don't even need the reset signal connected. Order of magnitude less power than FPGA will be easy.

Because of self-testability of SHA-2 and repetativeness of brute force hasher the overall design could be done over a couple of lunch breaks by a single engineer familiar with mixed-signal design and with access to the appropriate software tools. In addition to the above the chip is almost completely solipsist: it really doesn't have to obey any well-known interfacing standard, not even with a second copy of itself. It is sufficient to just communicate between the hashing chip and the I/O controller.

The "mixed-signal" is a key point here. Although the Bitcoin doesn't by itself use analog signals; the hashing chip is limited primarily by (1) power dissipation and (2) simultaneous switching noise. Because of the above two limitation mixed-signal experience would be a key to designing a chip that will be both efficient and will work on the first tapeout.

The optimal package for bitcoin hasher would be something like TO-220 with 7 leads:

http://www.psitechnologies.com/products/todo220.php

The I/O would be serial, the leads would be VccI/O ClkI/O RxD TxD VccHash ClkHash and Reset. Ground would be provided by the heatsink screw pad. One could even omit reset lead by doing serial reset: hold RxD high over (say) 100 I/O clocks.

Well, from the choice of packages (all with many more pins) one can surmise that none of the Bitcoin ASIC vendors obtained the advice from the power-analog and mixed-signal designers.

I'm not familiar with the commercial toolchains used in ASIC development; but from my past experience with R&D in digital and mixed signal design I'm positive that the main stumbling block would be the learning curve required to understand and learn the tools required. This is a time-to-market or time-to-mine issue.

pcm81 didn't make any manufacturing yield claims, but other people did. The Bitcoin hasher is so repetitive that if correctly designed, with a trivial set of clock-disable-bits, the overall yield would be nearly 100% useable chips. Only the chips with faults in the I/O or clock circuitry would have to be rejected.

Some other people also made wild claims about testing effort and expense. Well, SHA-2 is essentially self-testing: it either fully works or fails nearly every test. There are no hidden states  or data-conditional decision making in the algorithm. The test plan for the chip would be as trivial as it gets.

The "millions of dollars" price tags for NRE are just flights of fancy. This really is a project that could be done by a single ASIC engineer over a series of lunch breaks provided that he has both access to and experience with the required toolchain.

I know little about import laws of crypto IPs but this is what make sense to me.

Since bitcoin mining ASICs simply cannot be used to encrypt or decrypt anything....
I would then wonder if having an SHA core isolated from interconnects on the chip would cause concern.

The hash comparison is done against a specific hash mask of X difficulty level. Not some fixed hashes and even less a list of hashes.

I'm serious, pcm81. When it comes to this stuff, I'm lost. BTW, the guy I'm cheering for is you, not some other. Currently, I'm in your camp till better tasting marshmallows are provided at the other(s).

Password stretching is a very niche use-case of hash functions— one that is better done with specialized hard to compute functions instead of generic hash functions, only incompetent software uses a plain cryptographic hash—   and it is not an application which is of general interest to the US government and certantly not one of interest for the export restrictions, which — as I have pointed out to you, _specifically_ exempt authentication (what you're talking about).

(I'd link to the actual regulations but they're spread out across four places and their updated and appendices)

Moreover, your example doesn't actually match your bogus claim— searching for a password requires the password to be weak. Finding a random collision would take time proportional to the size of the hash (e.g. on the order of 2^127 invocations of the hash) and you run into problems with their not being enough energy available on earth. The idea that you think that this is a method for general _decryption_ is why people are laughing at you.

Nevermind the fact that at least one of the companies is doing the design _in_ china— sha256 is, after all, a well documented standard (and the export of cryptographic source code _can_ _not_ be restricted, see bernstein v. us).

I think you are pulling our leg...
1. 10,000+ posts
2. you are cheering for a guy with IQ 111 (above 110 is considered above average)
...
 and you say you got no clue...

I feel generous, so i am going to teach you a little something about hashes. When you create a web account for you online banking, the banks server does not actually store your password. The banks server stores SHA-256 (being extremely optimistic) hash of your password. When you log in the web server compares stored hash to the hash of the password you provided. If the two match, you are in. Now imagine that I hacked the webserver and stole the file which has the hash value of your password. I still can't log in and take your money; i need to find a string which will hash to the same value as the hash of your real password, then use that string to log into the banks server and take your money. There are many strings which would match hash value of your password, but the only way i can find one of them is to start hashing all of the possible strings, until i find one whose hash matches the hash of your password. This is why SHA-256 is under export control. Imagine if i had a super computer doing 1PHps, it would take me less time to randomly find a string which matches your passwords hash. So, US gvt restricts export of SHA-256 to Export Licensed companies. It does not mean it can not be exported, it just means company doing the export/import needs export/import license. Sending SHA-256 cores to china for assembly would require export license.

Seriously, to prove I ain't got no clue, I'm rooting for the guy, but seeing I may be on the wrong team.

In reality this is an infinite loop that produces no results.  It is more likely that all of the oxygen in the room you are in is distributed poorly and none of it is near you.

You've managed to link to something unrelated to your comment, try again. And, no— I'm quite sure I haven't broken the law.

This thread delivers!

pcm81, please, please keep posting.  I haven't laughed like this in weeks.  Hand drawn ASIC masks, mythological export restrictions.  Can't wait to hear what you think of next.

Congratulations, you may have broken US law.
See item #10
csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf

If SHA algorithm you used was not for 256 bits, it may not have required license.

Albeit not the most technical guy here, I find this thread informative, even believing pcm81, but I see doubters, and am getting confused. I dearly seek the truth on this issue, and hope a civil dialog continues.

Hilarious!

No, I actually produced fab ready images for a particular process that I had access to a cell library for, I was in fact specific about this in my post. Geesh. You're trying my patience

The link you provided is incorrect— or overly generalized. I have exported products to china commercially which implemented HMAC for authentication. It does not require a license.

You have omitted  step [2a] "Has the sun stopped shining yet?" ... what you are describing does not actually work in practice for the same reason that hashes are practically secure.

Step 1, generate random contents
Step 2, hash it
Step 3, compare to a known hash. If matches and random contents makes sense you done, if does not match loop to step 1.

ASIC just means Application Specific Integrated Circuit. So, a burned FPGA is ASIC. A very bad one, but it is still ASIC. If you want to design a real, clean ASIC then you need to take SHA-256 cores, or design your own, and wire them up manually on a wafer / pcb etc. To do this you would need to have SHA-265 cores in existence at one or more steps in the manufacturing process inside of the country you are outsourcing the manufacturing to. This is where the Export of SHA-256 to China comes into play. If you take an FPGA like spartan and have china make PCB for it and send the whole thing back, you do not need export license. If you decide to send the config file to engineer in china to burn on your FPGA or if you send him SHA-256 cores (physical chips or design schematic) to be assembled in china, you are in violation of export.

EDIT:
By violation of export i meant you are breaking US law assuming you have no export license. It does not mean you cant send it, but you would need to have US government grant you export license (Long and tedious process).

How does that work? Show me how to decrypt a SHA256 hash back to its original contents.

 

What?

This doesn't even make any sense.

Congratulations, you programmed an FPGA. This is not the same as designing a true ASIC implementation.

1. In regards to export license, see the link i provided above. SHA-256 requires export license to China. Let's say i am in outside of US fixing a broken tank. Lets say to fix it i need a light bulb from "the tourch" flashlight which is sold in US. I call my boss in US to have him buy the flashlight, take out the bulb and mail it to me. He has to add the bulb to export license, because i am going to use it to fix a tank. SHA-256 is used to encrypt data, just as it is used to authenticate a user. Export license for SHA256 core will be required, just like the export license would be required for the light bulb in example i gave. US does not allow export of cripo technology to china. You can not legally send SHA-256 cores to be assembled into a product in the Chinese factory. You can send an FPGA to china to be added to pcb and then, when it gets to US u can burn the FPGA into ASIC.

I actually did a standard cell design for a miner last year myself, starting from RTL generated off one of the open source HDL designs.  God knows if it would have actually run at an acceptable clock rate— given that I don't really know what I'm doing... but it wasn't that much work to get _something_.  A miner is insanely repetitive. The hash function is very simple. Thank god for design automation.

This is nonsense. In particular, ITAR regulations very specifically exclude authentication. I am now beginning to wonder if you aren't being purposefully dishonest instead of just confused.

Not so— Go look at what a directly wired 32-bit adder looks like compared to what actually gets implemented in an FPGA (in particular all the power lost to running the sram). FPGAs also waste a lot of power running the long wires in the generic routing mesh and waste a lot of power in additional flip-flops needed to make it time out acceptably.  All of these are avoided in a straighforward fixed design.

(I suppose I should note that the asic makers are claiming power efficiencies which are at the extreme upper envelope relative to their claimed processes of what I thought was possible from my designs, but I don't find this especially shocking as presumably they know what they're doing and I do not)

Here is an example:
http://www.cast-inc.com/ip-cores/encryption/sha-256/index.html

I have heard stuff like this a few times now. Is that true? Would that be why Avalon's stuff is just "disappearing", it's actually illegal for it to enter or leave China?

Correct, but there are 2 problems with this:
1. SHA-256 capable devices require export license, and no export to China is permitted. So you cant use china as the manufacturing site unless you just build FPGAs and then "convert" them to SHA-256 hashing devices in US.
2. The power density will not decrease as dramatically as you think. The complexity of the process will not be less, so the amount of work "gate flipping" that ASIC would need to do will be the same as it is for FPGA, the difference is that the "unused" parts of FPGA will not be sucking up power in ASIC design. I doubt that there is 90% of FPGA being currently powered on and unused in existing FPGA designs, this is what it would have to be to get 10x increase in MHPS/W in ASIC vs FPGA. The SHA single still has the power connector. It offers 10.4MH/J but for ASIC we are talking at 1000MH/J so this would mean that 99% of FPGA in the SHA single is powered on but not used for hashing... I doubt that is the case.

Nobody designs ASICs by hand just like they don't design FPGA by hand.  They use high level libraries and design tools.  Nobody cares where each individual transistor goes just like a programmer doesn't care which exact memory address every single bit of memory goes.  It is abstracted away.  Comparing these chips to either FPGA or GPU is a false comparison.  These are SHA-256 hashes and will be significantly simpler (and smaller) than any general purpose device like a GPU or FPGA.

Ok.  Now say you had major dollars.  Costing major dollars =/= impossible.

No. You buy existing IP cores from another designer (there's loads out there on offer for SHA-256) then simply pipe and kludge them together.

It's one thing to design processor application, and it is completely different task to actually design the processor.  Something like radeon 6970 gpu has 2.6 billion transistors. For FPGAs like startan-6 we are still talking billions of transistors. For someone starting from scratch, can you imagine how long it would take to draw wiring schematic with a billion components? This is what you would have to do to design a brand spanking new custom ASIC. ASIC is Application Specific Integrated Circuit, so either you have to piece it together via FPGA conversion or you have to design this circuit from scratch. This task would be not easier than it was to design FPGA like SPARTAN-6 in the first place. We talking major dollars here.

I'm pretty sure all Asic "vendors" claimed to not use a fpga2asic conversion but instead a full custom design.

e:fb.

[I split this off the Avalon thread— because it's really nothing to do with Avalon specifically.]


None of the 'asic' vendors are claiming that their next generation products will be FPGA based— all of them have previously shipped FPGA products.  What they're claiming to do is produce custom fixed function mining chips on older processes (65nm for BFL, 110nm for Avalon).  Avalon has even posted a fair amount of their contract information with their foundry.

A miner design is substantially simpler than a FPGA or a general purpose microprocessor, and while fabrication has a high NRE the costs are often overstated. It's possible to do a run in the $100k ballpark on e.g. 130nm, or on better process via an MPW service (although usually this involves long delays). Access to state of the art process is another matter, but for these designs the efficiency gains over FPGA even on an older process can be substantial.

As an aside, MHp_s_/J appears to be confusing power and engery units. You likely want MH/J.

Lets do some basic math:
For existing FPGA design the best can be had is 23MHps/J. There is no reason to anticipate an improvement in FPGA power efficiency, yes, there can be marginal reduction of overhead and the FPGA can be scaled up, but it's efficiency will not increase all that much. Based on existing designs we can anticipate 25MH/J for FPGA. There is nothing special abut ASIC, most ASIC vendors just use a custom programmed FPGA; this is called FPGA to ASIC conversion. So at best ASIC will be 50MHps/J; and i am being VERY generous here. Also, designing a product based on FPGA is one thing, designing an FPGA is completely different. It would take millions of dollars to design a new FPGA.
For the boasted hash rates of 1+GHps we are still talking 25-50 W. This is not unreasonable, until you realize that USB cable provides 5V at 0.5A, which is 2.5W. So those FPGA/ASIC designs better show a mollex connector or something... With single USB you will not hash faster than 2.25/25=0.09GH.

Now lets do some more math:
I work as an electrical engineer and salaries range from $50K/y to $180K/y depending on experience and seniority. To get an FPGA/ASIC project of this scale done you will need 2 very good engineers forking full time for a year. So we talking $200K in salary minimum. You are probably talking closer to $300K in salary by the time you add in customer support, web dev etc. The manufacturers advertise "Limited supply" to not scare miners away. From hardware alone i dont think it is at all possible to make jalapenio for $160, but lets approach this issue from the other end. If they make 10,000 units, the company needs to get $30/unit just to cover bare minimum salaries. Which means all the hardware of something like Jalapeno must cost no more than $119. For this much the best FPGA they can get is like Cyclone III, which does not look cool enough to be beefy enough to do a GH/s. At 315MHz and at least 100 clock cycles per hash (by the time you sync all ins and outs you will waste more, i am being generous here)  we are talking at 3.15 MHps per input path.  Due to the number of available gates just under 200,000 i doubt you can do more than 10 (200,000/256/100=7. hashes in parallel. I am assuming 256 routes per hash since they are 256-bit hashes and 100 gates per hash. So with 3.15MHps*10 we have 31MHps.  In Ideal perfect case, for an FPGA like Cyclone III we are talking (200,00/147,000=1.34) more HPS than from $200 spartan-6. With 100MHps on Spartan6 we would at best get 134MHps on something like Cyclone III, this 134MHps is a theoretical and unattainable number.

Conclusion: All of the FPGA promises are bs for the low prices listed. It is simply not possible to buy enough logic gates for this money to get the advertised MHps.
It would take millions of dollars to design a custom fpga and existing fpgas cost more than any of the advertised prices.