Topic: What's the best use of my time/energy? (FPGA/Control Tech) (Read 2482 times)

@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.

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.

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.

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

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.

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.


Yeh I know, , 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.

Done

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. 

I like it! Anyone want to start drafting a spec?

The Unicorn protocol? Standards are great to dream about, but getting all the devs to do work together is going to be hard

Minebus

OK great, sounds like a good interface even though it is older than dinosaurs, now all we need is a standard protocol that can be used for sending and receiving work units (and their results), firmware updates, and so forth.

Imagine this: If it were adopted by hardware makers, you could be able to buy a ztex one day, an x6500 tomorrow, and be able to add a Rig Box next month when your paycheck comes in. Plug them all into the same bus, run one instance of cgminer, and as if by magic the devices get programmed with the latest firmware and start hashing away.

What should it be called?

No it is a bus, daisy chaining isn't a problem it is routinely done in embedded system and industrial boards.  

The advantage of plane boring serial is that most computers already have a serial port and even machines like Pi and embedded micro controllers have UART which is serial you can use any connector you like (standardized or customized).

Serial literally can be this simple:
Plug one end of cable into host (Pi/ AMR board, low power PC, embedded system, etc).
Plug other end into first FPGA.
Take second cable connect first FPGA to second
...
take 255th cable and connect 254th FPGA to 255th.

Power up and run "cgminer" (once it supports serial devices).

No fees, open spec, very simple protocol, and can use lots of different physical layers including cheap & robust RJ-45 terminated cat5.  For the rare system which doesn't have a serial port (most MB do even if they leave it off the back panel) a single $10 USB to serial adapter could connect hundred FPGA to a host.

1-wire buses have quite a complicated protocol, RS485 is the same at RS232, just electrically different.

1wire was my example, and it doesn't really get any simpler. 1 ground/shield, and 1 signal. No special connectors needed. Daisy-chain to your heart's content. Maximum run length of 300 meters have been tested on a single twisted pair, and speeds should be acceptable for the minimal data traffic that mining uses.

Any networks that rely on token buses should be avoided, what happens if a device goes offline taking the token with it? and other similar hassles.

Another interesting option would be I²C, but devices need licensing fees to get addresses assigned to them.

For serial, isn't that also a star topology? If it can easily be daisy-chained, then yeah that could work. RS485 was another one I considered, but I don't remember why I came to the conclusion that it was insufficient.

Well that is beyond my knowledge but I have seen industrial A/D and relay boards which allow 128 or even 256 boards to be chained.

RS485 would be more appropriate; allows for muti-drop systems and uses differential signals.

Be a good idea though. Save $20 per 4-8 devices. Not sure how many devices you could practically dasy-chain though. the lead one will have quite a current load on it!

How about serial?  Never understood why FPGA boards don't just connect over serial.  It is easy to daisy chain and you can use just about any physical wiring including the ultra cheap RJ-45.



Something like:

You save a usb controller on each board, no need for hubs, and can use dirt cheap cat5 cable (even crimping your own if you want).  Would also make it much easier to form large clusters.  Using a MOLEX in/out power connector you could chain up the power also.

QFT

1. create a description of what the marketplace wants
2. model the description over time, BTC-time, i.e. what happens to the model when reward is halved, etc.
3. decide what pieces to use
4. don't get diverted into developing new buses or protocols, make do with what's here now

I am only learning about hardware, and FPGA technology, specifically. It seems to me that the best approach would be to allow a system to be expanded as it is affordable.

Have you seen schmartboards? Maybe purists scoff at that? I may misunderstand schmartboards but would it be possible to buy FPGAs and add them using schmartboard in a sort of expand-as-money-becomes-available scenario?

Maybe there is a modeler out there already? For example I have no idea how much bandwidth is required of a miner. How many FPGAs can share a 10Mbit connection.

Just throwing out thoughts/ideas.