Block Erupter: Dedicated Mining ASIC Project (Open for Discussion)

[novusordo]

I came in late, is the project still going forward despite all the GLBSE hoo ha?

Check the ASICMINER thread. Everything is still going, friedcat is just waiting for Nefario to send the list of shareholders.

[1714238089]

1714238089

[1714238089]

1714238089

[makomk]

All code with ASIC should be using USB direct not serial-USB
And having the serial-USB can cause problems on windows (and usually means a manual driver fix)

I've been screwing around with this for the last few weeks on an MMQ-FPGA converting it from serial-USB to USB
only to find all the windows problems were driver related - not my code.
Lucky I've had access in IRC to the guy who does libusb, to help me sort it out

Heh. There is exactly one prior FPGA mining setup I know of that speaks native USB - my toy 25 MH/s miner which isn't actually running at the moment. (Implements USB 1.1 on the FPGA itself using a cheap USB transceiver chip. Never caught on with anyone else for various reasons.)

Edit: Also, there's actually a 5th optimization you can do that's very worthwhile in FPGAs - you can push part of the computation of T1 into the previous pipeline stage/clock cycle to the rest of the SHA-256 round, which doesn't affect the amount of logic but does shorten the length of the critical path and increase your maximum clock. I think there are a few tricks with the W computations too...

[kano]

All code with ASIC should be using USB direct not serial-USB
And having the serial-USB can cause problems on windows (and usually means a manual driver fix)

I've been screwing around with this for the last few weeks on an MMQ-FPGA converting it from serial-USB to USB
only to find all the windows problems were driver related - not my code.
Lucky I've had access in IRC to the guy who does libusb, to help me sort it out

Heh. There is exactly one prior FPGA mining setup I know of that speaks native USB - my toy 25 MH/s miner which isn't actually running at the moment. (Implements USB 1.1 on the FPGA itself using a cheap USB transceiver chip. Never caught on with anyone else for various reasons.)

OT but yeah this is all the crap that Luke-Jr keeps going on about claiming cgminer is a fork of his miner - coz he wrote the first FPGA Serial-USB driver in cgminer ... that has been recoded in almost every possible place that matters since then ...
... and he started the whole problem I'm removing ...

Code done already for the ModMinerQuad - as my first step in the lead up to ASIC - so I could do something while waiting - should be in cgminer RSN

Interesting however, that from a hardware point of view, USB itself may end up being the bottleneck in processing in the not too distant future.

So ... who's planning a better hardware interface

[memvola]

So ... who's planning a better hardware interface

I had always imagined that if ASIC boards were produced at one point, we would connect them to PCI express x1 slots.

[DiabloD3]

So ... who's planning a better hardware interface

I had always imagined that if ASIC boards were produced at one point, we would connect them to PCI express x1 slots.

No point in using a more expensive controller for the ASIC plus have more limited room and power availability.

Easier to just build large scale 2 or 4U boxes dedicated to the task.

[Unacceptable]

All code with ASIC should be using USB direct not serial-USB
And having the serial-USB can cause problems on windows (and usually means a manual driver fix)

I've been screwing around with this for the last few weeks on an MMQ-FPGA converting it from serial-USB to USB
only to find all the windows problems were driver related - not my code.
Lucky I've had access in IRC to the guy who does libusb, to help me sort it out

Heh. There is exactly one prior FPGA mining setup I know of that speaks native USB - my toy 25 MH/s miner which isn't actually running at the moment. (Implements USB 1.1 on the FPGA itself using a cheap USB transceiver chip. Never caught on with anyone else for various reasons.)

OT but yeah this is all the crap that Luke-Jr keeps going on about claiming cgminer is a fork of his miner - coz he wrote the first FPGA Serial-USB driver in cgminer ... that has been recoded in almost every possible place that matters since then ...
... and he started the whole problem I'm removing ...

Code done already for the ModMinerQuad - as my first step in the lead up to ASIC - so I could do something while waiting - should be in cgminer RSN

Interesting however, that from a hardware point of view, USB itself may end up being the bottleneck in processing in the not too distant future.

So ... who's planning a better hardware interface

If we're just going to transfer data & not draw any power,how about SATA.It's very fast & most mobo's have several extra & a card can installed to add more  

I know as of now its only for hardrives,but can a perephrial device work on SATA 

[DiabloD3]

All code with ASIC should be using USB direct not serial-USB
And having the serial-USB can cause problems on windows (and usually means a manual driver fix)

I've been screwing around with this for the last few weeks on an MMQ-FPGA converting it from serial-USB to USB
only to find all the windows problems were driver related - not my code.
Lucky I've had access in IRC to the guy who does libusb, to help me sort it out

Heh. There is exactly one prior FPGA mining setup I know of that speaks native USB - my toy 25 MH/s miner which isn't actually running at the moment. (Implements USB 1.1 on the FPGA itself using a cheap USB transceiver chip. Never caught on with anyone else for various reasons.)

OT but yeah this is all the crap that Luke-Jr keeps going on about claiming cgminer is a fork of his miner - coz he wrote the first FPGA Serial-USB driver in cgminer ... that has been recoded in almost every possible place that matters since then ...
... and he started the whole problem I'm removing ...

Code done already for the ModMinerQuad - as my first step in the lead up to ASIC - so I could do something while waiting - should be in cgminer RSN

Interesting however, that from a hardware point of view, USB itself may end up being the bottleneck in processing in the not too distant future.

So ... who's planning a better hardware interface

If we're just going to transfer data & not draw any power,how about SATA.It's very fast & most mobo's have several extra & a card can installed to add more 

Are you retarded, or just trolling?

[LazyOtto]

Are you retarded, or just trolling?

Are you doing an Inaba imitation?

He put out an idea. It might not be a good one.

Tell him the downsides of the idea rather than just be insulting.

[Unacceptable]

All code with ASIC should be using USB direct not serial-USB
And having the serial-USB can cause problems on windows (and usually means a manual driver fix)

I've been screwing around with this for the last few weeks on an MMQ-FPGA converting it from serial-USB to USB
only to find all the windows problems were driver related - not my code.
Lucky I've had access in IRC to the guy who does libusb, to help me sort it out

Heh. There is exactly one prior FPGA mining setup I know of that speaks native USB - my toy 25 MH/s miner which isn't actually running at the moment. (Implements USB 1.1 on the FPGA itself using a cheap USB transceiver chip. Never caught on with anyone else for various reasons.)

OT but yeah this is all the crap that Luke-Jr keeps going on about claiming cgminer is a fork of his miner - coz he wrote the first FPGA Serial-USB driver in cgminer ... that has been recoded in almost every possible place that matters since then ...
... and he started the whole problem I'm removing ...

Code done already for the ModMinerQuad - as my first step in the lead up to ASIC - so I could do something while waiting - should be in cgminer RSN

Interesting however, that from a hardware point of view, USB itself may end up being the bottleneck in processing in the not too distant future.

So ... who's planning a better hardware interface

If we're just going to transfer data & not draw any power,how about SATA.It's very fast & most mobo's have several extra & a card can installed to add more  

Are you retarded, or just trolling?

I guess I'm retarded...........just a thought  

Why wouldn't it work  

[meowmeowbrowncow]

All code with ASIC should be using USB direct not serial-USB
And having the serial-USB can cause problems on windows (and usually means a manual driver fix)

I've been screwing around with this for the last few weeks on an MMQ-FPGA converting it from serial-USB to USB
only to find all the windows problems were driver related - not my code.
Lucky I've had access in IRC to the guy who does libusb, to help me sort it out

Heh. There is exactly one prior FPGA mining setup I know of that speaks native USB - my toy 25 MH/s miner which isn't actually running at the moment. (Implements USB 1.1 on the FPGA itself using a cheap USB transceiver chip. Never caught on with anyone else for various reasons.)

OT but yeah this is all the crap that Luke-Jr keeps going on about claiming cgminer is a fork of his miner - coz he wrote the first FPGA Serial-USB driver in cgminer ... that has been recoded in almost every possible place that matters since then ...
... and he started the whole problem I'm removing ...

Code done already for the ModMinerQuad - as my first step in the lead up to ASIC - so I could do something while waiting - should be in cgminer RSN

Interesting however, that from a hardware point of view, USB itself may end up being the bottleneck in processing in the not too distant future.

So ... who's planning a better hardware interface

If we're just going to transfer data & not draw any power,how about SATA.It's very fast & most mobo's have several extra & a card can installed to add more  

Are you retarded, or just trolling?

I guess I'm retarded...........just a thought  

Why wouldn't it work  

You are not retarded.  D3 is being a little harsh. 

SATA phy would work, but a serial protocol is needed that does not incur contention present with a large number of bus nodes.  SATA data link is not appropriate since it's a ptp link.

A cascade/daisy chain linkage of sata phy ala the mini rig sc is a good example.  Still need a protocol.

[Jutarul]

When it comes to connections, something which supports broadcasts may be good. You can feed data in one burst and collect only those data blocks (results) which are interesting - this can be done on a p2p basis. Broadcasts can also be emulated in node based system where the p2p connections are distributed as a tree. However, that requires the nodes to have an understanding of the global layout.

I'd like to review an expert opinion on ethernet vs. USB interface. Any good links?

[DiabloD3]

When it comes to connections, something which supports broadcasts may be good. You can feed data in one burst and collect only those data blocks (results) which are interesting - this can be done on a p2p basis. Broadcasts can also be emulated in node based system where the p2p connections are distributed as a tree. However, that requires the nodes to have an understanding of the global layout.

I'd like to review an expert opinion on ethernet vs. USB interface. Any good links?

With Ethernet, the miners would just be emulating the miner interface itself (ie, directly connect to bitcoind).

[Jutarul]

When it comes to connections, something which supports broadcasts may be good. You can feed data in one burst and collect only those data blocks (results) which are interesting - this can be done on a p2p basis. Broadcasts can also be emulated in node based system where the p2p connections are distributed as a tree. However, that requires the nodes to have an understanding of the global layout.

I'd like to review an expert opinion on ethernet vs. USB interface. Any good links?

With Ethernet, the miners would just be emulating the miner interface itself (ie, directly connect to bitcoind).

Does it support UDP? Otherwise the handshake imposed by the TCP connection could be a problem in a scalable design.

[Bogart]

Why does a bitcoin miner need a high bandwidth interface again?

People mine on pools all the time on sub-megabit internet connections.  Why are USB's multiple megabits not fast enough?

Am I missing something here?

[Jutarul]

Why does a bitcoin miner need a high bandwidth interface again?

People mine on pools all the time on sub-megabit internet connections.  Why are USB's multiple megabits not fast enough?

Am I missing something here?

ASICs crunch the numbers much faster. That means that the time to sweep a full nonce range is significantly shorter. Dependent on how much chips feed from a single master, the time to establish a connection can become rate limiting. Thus a communication protocol which avoids unnecessary handshakes and delivers new work to the chips continuously can be beneficial.

In any event, you want your communication protocol to avoid down time for the chips. That means once the chip is thru with some data, the next data should already be loaded and ready. So I guess you want to plug a few chips behind a controller, which handles all the communication and pushes work into a on PBC board memory.

How did the pools do it? Did they add additional servers on demand? How many GH can work off one server?

[Unacceptable]

All code with ASIC should be using USB direct not serial-USB
And having the serial-USB can cause problems on windows (and usually means a manual driver fix)

I've been screwing around with this for the last few weeks on an MMQ-FPGA converting it from serial-USB to USB
only to find all the windows problems were driver related - not my code.
Lucky I've had access in IRC to the guy who does libusb, to help me sort it out

Heh. There is exactly one prior FPGA mining setup I know of that speaks native USB - my toy 25 MH/s miner which isn't actually running at the moment. (Implements USB 1.1 on the FPGA itself using a cheap USB transceiver chip. Never caught on with anyone else for various reasons.)

OT but yeah this is all the crap that Luke-Jr keeps going on about claiming cgminer is a fork of his miner - coz he wrote the first FPGA Serial-USB driver in cgminer ... that has been recoded in almost every possible place that matters since then ...
... and he started the whole problem I'm removing ...

Code done already for the ModMinerQuad - as my first step in the lead up to ASIC - so I could do something while waiting - should be in cgminer RSN

Interesting however, that from a hardware point of view, USB itself may end up being the bottleneck in processing in the not too distant future.

So ... who's planning a better hardware interface

If we're just going to transfer data & not draw any power,how about SATA.It's very fast & most mobo's have several extra & a card can installed to add more  

Are you retarded, or just trolling?

I guess I'm retarded...........just a thought  

Why wouldn't it work  

You are not retarded.  D3 is being a little harsh.  

SATA phy would work, but a serial protocol is needed that does not incur contention present with a large number of bus nodes.  SATA data link is not appropriate since it's a ptp link.

A cascade/daisy chain linkage of sata phy ala the mini rig sc is a good example.  Still need a protocol.

Tank ew berry mcchh 4 esplanin dis ta ma  

[DiabloD3]

When it comes to connections, something which supports broadcasts may be good. You can feed data in one burst and collect only those data blocks (results) which are interesting - this can be done on a p2p basis. Broadcasts can also be emulated in node based system where the p2p connections are distributed as a tree. However, that requires the nodes to have an understanding of the global layout.

I'd like to review an expert opinion on ethernet vs. USB interface. Any good links?

With Ethernet, the miners would just be emulating the miner interface itself (ie, directly connect to bitcoind).

Does it support UDP? Otherwise the handshake imposed by the TCP connection could be a problem in a scalable design.

Bitcoin JSONRPC doesn't do TCP, and UDP isn't recommended for reliability reasons. Existing miners don't have issues with TCP because we keep the connection open over long periods. Plus, even if you don't, each mining box itself (no matter how many chips are on it) would have one controller. Modern machines can handle a million TCP connections concurrently without breaking (usually its the software handling the connections that fails to scale long before any OS's given kernel breaks).

I don't recommend machines implement their own miner though: leave it to the experts like me and ck.

[memvola]

Why does a bitcoin miner need a high bandwidth interface again?

ASICs crunch the numbers much faster. That means that the time to sweep a full nonce range is significantly shorter.

Okay, another dumb question then... Can't you tune the expected response time by picking a lower target?

[DiabloD3]

Why does a bitcoin miner need a high bandwidth interface again?

ASICs crunch the numbers much faster. That means that the time to sweep a full nonce range is significantly shorter.

Okay, another dumb question then... Can't you tune the expected response time by picking a lower target?

No, because ASICs, just like any other miner, will be looking for diff 1 candidates (ie, H == 0).

[DiabloD3]

https://bitcointalk.org/index.php?topic=130795.0