What's the best use of my time/energy? (FPGA/Control Tech)

[DeathAndTaxes]

First thing I thought of was this



That is before you get into the competitive pressures.  For example BFL makes larger boards.  They actually benefit from high per board cost.  While they could support low cost universal standard it would actually hurt their competitive posistion.  A rig box saving $6 on a $30,000 monster is a rounding error doesn't do much good but dropping a $3 usb controller, $2 usb cable and $2 usb hub (per port) from ztek $200 board (in bulk) is a significant cost savings.

From a capitalist standpoint BFL would be incentivized to not participate or participant in an attempt to slow down the standard and create disruptions.

I wasn't thinking that big.  I was just wondering why no FPGA builder used serial.  I mean it is serial.  There aren't many protocols which are simpler. 

[P_Shep]

Code:

| Dev address 32bit | length 8 bit | Data 8 * length | crc 16 bit |

Done

[rjk]

Code:

| Dev address 32bit | length 8 bit | Data 8 * length | crc 16 bit |

Done

lol. I was thinking of including the features mentioned in the other posts. A standardized firmware delivery would be useful, so that all devices could remain connected to the same bus. A standard way to distribute work to each device, and then pick it up when finished would also be necessary.

First thing I thought of was this

http://imgs.xkcd.com/comics/standards.png

That is before you get into the competitive pressures.  For example BFL makes larger boards.  They actually benefit from high per board cost.  While they could support low cost universal standard it would actually hurt their competitive posistion.  A rig box saving $6 on a $30,000 monster is a rounding error doesn't do much good but dropping a $3 usb controller, $2 usb cable and $2 usb hub (per port) from ztek $200 board (in bulk) is a significant cost savings.

From a capitalist standpoint BFL would be incentivized to not participate or participant in an attempt to slow down the standard and create disruptions.

I wasn't thinking that big.  I was just wondering why no FPGA builder used serial.  I mean it is serial.  There aren't many protocols which are simpler. 

Yeh I know, <sigh, another standard>, but what the hell. It'd be nice to hear from some of the FPGA makers and see if there are stumbling blocks that haven't been considered.

[P_Shep]

Just been idly thinking a bit more.

Getting device addresses:
1. Host sends address 0 (broadcast address), command 'Hello', it's address as the payload.
2. Each device waits a random time between 0-0.5 seconds, checks the bus, and if clear, sends a hello back to the host.
 - Host logs the address of each device that responds.
3. After 1 second of inactivity on the bus, host sends a 'shut up' command back to each device that responded.
 - This command stops a device from responding to 'hello' until it's reset.
4. Host repeats 1-3 until the hello command gets no response.
 - This is to cater for any collisions that occurred earlier.

Obtaining a unique address for each device is a bit tricky. You can get devices with unique embedded serial numbers, such as Dallas' 1-wire ICs. Adds a bit more complexity and cost to the device though. And 32-bits may be too short, 1-wire addresses are 64bits IIRC.

After this it's a matter of defining the commands and data payloads.
Communications could be multi-master, each device, when returning a result would check the bus, then send then result if clear. No ack back would mean a collision - wait a random time, then resend. Give up after 3 attempts.

[DeathAndTaxes]

No need to reinvent the wheel serial (RS-232) already has hardware collision detection and RTS/CTS handshake implemented.

[P_Shep]

No need to reinvent the wheel serial (RS-232) already has hardware collision detection and RTS/CTS handshake implemented.

Requires extra lines. RS485 is just two lines. And I'm fairly sure RTS/CTS only works on point-to-point systems, not mutli-drop.

[P_Shep]

Further thinking:

The system would operate asynchronously. Each device works independently, requesting work from, and submitting work to, the host. I don't think there'd be any advantage the host doing the polling, or using any kind of token scheme. This may lead to delays between polls where the device is not working. Not long delays, but delays nonetheless. An asynchronous system would cause collisions to occur (and more often with more devices on the line) but with proper delay times this could be minimised.

When requesting/sending work, a device would:
1. Listen for activity
2. If clear, send.
3. If not clear, wait a random time from 10-100ms, go to 1.

When responding to a message, all devices would respond immediately. The min 10ms delay above would prevent collisions on response messages. No delay would mean they would be the most likely hit.

Devices could be hot-plugable too. Every few seconds the host could broadcast the hello message. Already initialised devices wouldn't respond (since they were given the 'shut up' command), the new device(s) would send their hellos.

[nedbert9]

@wondermine

Improving a system is important, but with limited resources work expended should be scrutinized.

Using pricing for non-volume board/components pricing.  MO is that the minority will be purchasing in quantities sufficient to make conclusions using low per unit cost.

IMO, enhancements ranked by value (Having no digital design background I cannot speak to difficulty):

Increase revenue
1.  Efficiency increase in FPGA logic performance.  Consider eldentyrell's work on 1.5 stages on LX150.  An anticipated 50% increase in MH/s.
(IIRC, eldentyrell stated that an enhancement targeted at lesser model FPGA's, e.g. Spartan6-100, isn't possible due to inadequate gate array dimensions.)

Reduce expenses / improve reliability
2.  IMO, and correct me if this is not an issue, having a single board with 1+ FPGA's and components introduces a risk of total loss due to failure of either cheap component or FPGA.
This leads me to believe that 1xFPGA daughterboard design is a prudent one.  In case of FPGA failure, replace daughterboard.  In case of component failure, replace the mainboard where cost is a fraction of total.
This assumes, probably rightly so, that repair would not be cost effective.

3.  Here's where it gets tricky.  So, moving from USB to RS232/RS485 would equate to about a 4% cost savings per board using very low cost board estimates at volume qty.
Seems we are trying really hard to eek out a few percent of savings or nearing 1% of savings in standard retail pricing.  I'm not saying 4% is good to leave on the table.  I'm saying is it worth the time to develop while only considering material cost savings.
As for convenience introduced by eliminating USB.  Maybe that's worth it.  It has a value, but hard to quantify savings.

I'm not even sure that W efficiency can be improved upon much further without easily outstripping effort.  Even a 50% improvement in W efficiency results in a tiny amount of monthly OpEx at US natl avg kWh. 
Makes me wonder just how non lucrative BTC mining would have to be for a 50% improvement in W efficiency to be a considerable factor.

As for Ethernet and HTTP server functionality.  My question is whether you are providing a solution to a real need to majority of miners.  IMO, in most cases, no. 
I'm just looking at this from an effort expended vs. value proposition.  As I see it most miners do not have a compelling need to run in a headless configuration.