I think this may be a step in the right direction

[erinmars]

http://www.cast-inc.com/ip-cores/encryption/sha-256/ I know what I think about it, what does everyone else think about it?

[brocktice]

Requires far fewer gates than other solutions I've seen.

[erinmars]

Its pretty quick too, its the infrastructure between the chips that would be a pain. I think using an fpga as the router in between the chips would be the way to go (Some of the cheaper fpga chips have 800+ pins). Then you would have alot of options in terms of connecting the node to bitcoin (usb/ethernet/etc) for there are already preconfigured fpga modules ready to go for those types of interconnects. I personally like the idea of ethernet. Teach the fpga how to pull work from bitcoin over ethernet, all you would need is a router/switch/hub.

[BitCointransfers]

Looks good, an already optimized SHA256 ASIC, so how much does this fucking thing cost.. and would like to hear ArtForz's comments on this one...

[kjj]

Looks good, an already optimized SHA256 ASIC, so how much does this fucking thing cost.. and would like to hear ArtForz's comments on this one...

Sadly, it is unlikely to be optimized for the way we use SHA256.  Most commercial implementations assume you want to push a big stream through them and keep a running hash.  We want to hash a tiny block twice, then start over with a slightly different tiny block.

[brocktice]

Looks good, an already optimized SHA256 ASIC, so how much does this fucking thing cost.. and would like to hear ArtForz's comments on this one...

There's probably a reason he's doing something different. I've yet to ask him about an FPGA/ASIC solution and have him not already know about it and why it's not going to work well.

[melco]

Looks good, an already optimized SHA256 ASIC, so how much does this fucking thing cost.. and would like to hear ArtForz's comments on this one...

Sadly, it is unlikely to be optimized for the way we use SHA256.  Most commercial implementations assume you want to push a big stream through them and keep a running hash.  We want to hash a tiny block twice, then start over with a slightly different tiny block.

Sorry for n00b question, but can we put two of them in line?

[MoonShadow]

Sent them an email just to judge whether they are aware of Bitcoin or not.

[MoonShadow]

Looks good, an already optimized SHA256 ASIC, so how much does this fucking thing cost.. and would like to hear ArtForz's comments on this one...

Sadly, it is unlikely to be optimized for the way we use SHA256.  Most commercial implementations assume you want to push a big stream through them and keep a running hash.  We want to hash a tiny block twice, then start over with a slightly different tiny block.

Sorry for n00b question, but can we put two of them in line?

Should be able to, but I can already see the disadvantage to ArtForz's own version.  This core uses 66 cycles to complete a hash, while ArtForz's is claimed to be a pipelined asic producing a hash on every cycle.  This is probably something intended to be a cheap co-processor in an ecommerce server, off-loading some calcs from the CPU in order to avoid bogging down the main website.

[Bitbird]

I'm considering set up a HPC mining rig start-up project. The rig will use floating point co-processor for FPGAs which could create compute blocks with 4096 processors (8 TFLOPs) in each unit.

[kjj]

I'm considering set up a HPC mining rig start-up project. The rig will use floating point co-processor for FPGAs which could create compute blocks with 4096 processors (8 TFLOPs) in each unit.

You'd better research this a bit more.

[Bitbird]

Hi kjj,
Do you suggest floating point co-processor would be no helped for Bitcoin mining?

(might open a subject for this question latter)

[befuddled]

Do you suggest floating point co-processor would be no helped for Bitcoin mining?

Yes. Or at least I do.

[enmaku]

Hi kjj,
Do you suggest floating point co-processor would be no helped for Bitcoin mining?

(might open a subject for this question latter)

Bitcoin mining is mostly integer math. This is also the reason it's so laughable that BitcoinWatch uses some unknown algorithm to estimate the network speed in Teraflops.

[JoelKatz]

Sorry for n00b question, but can we put two of them in line?

They're optimized for performing hashes on large amounts of data, not for performing large amounts of hashes.

[PulsedMedia]

Was just looking about this ASIC, i see it has been mentioned here, but this seems to be the only thread?
Didn't anyone look in detail?

Afterall, it's a function of costs, if these chips are low powered and cheap, why can't you chain them?

Looking at these two:
http://ipcores.com/sha_ip_core.htm
http://www.cast-inc.com/ip-cores/encryption/sha-256/index.html

I guess single chip achieves atleast 4.24Mhash/s? That's quite weak, but if a single chip costs less than 1.7$ and consumes less than 0.2W it could be viable vs. current FPGA solutions. Hell, even at at 1W per chip it would achieve a nice ratio.
It has so few gates it can't consume much!

[kjj]

Because all of the commercial SHA chips are designed for an operation that doesn't apply to bitcoin mining.

Bitcoin mining is done by hashing huge numbers of distinct two-block inputs.  SHA chips are designed to do small numbers of many-block inputs.

Think of the difference between a billion files of 1000 bytes each, and a thousand files of a billion bytes each.

[Dexter770221]

Those are IP cores that may be implemented into FPGA or ASIC.
Little math.
SIngle core = 640 slices in Spartan6 = 36 cores in LX150. One core = one pass of two needed in mining, so you get only 18 full cores. Each one running at 115MHz and proceed one hash in 132 cycles (115/132=0.87 hash/cycle). With 18 core that gives you 18*0.87=16 MH/s. Compare to 210 from ztex. I say it's a giant leap backwards!