I am interested in trying my hand at creating yet another FPGA cluster hasher, with each cluster connected via a single USB connection to the host (rather than 1 per FPGA).
I've looked at the Cairnsmore 1, Ztex, and Icarus drivers; each one has hard-coded some of the idiosyncrasies of those particular devices. I'm wondering if there is something like a generic CGminer driver skeleton I could fill in / develop against.
Is there a simple block of code that easily links with CGminer, passes up the relevant info from the device chain (estimated duration of one hash-cycle iteration, number of hashes completed per cycle) to the main miner program on initialization, downloads base header data and range to be hashed against from the miner to the device with each getwork or stratum fetch, receives proof of work from the device to send to the mining pool, and sends an interrupt to the device when assigned work becomes invalid?
Given the proliferation of mining devices, there's almost a need for a "miner driver" specification just like the old "packet driver" specification back in the days of Win32s enabling Win3.11 to connect to the internet, so that the people creating the new mining devices would be responsible for driver creation, rather than the mining stack software creators.
Thanks,
-Tom
Pointless.
As soon as someone comes out with the next design of hardware, suddenly the whole thing would be thrown out the window and have to start again.
At the moment we advance the drivers as we see they need them and incorporate changes and improvements where we see needed.
If something is going to 'break' the 'interface', we simply change the 'interface'.
If an improvement is found inside that interface we can simply change that.
It's the same everywhere in cgminer.
When a new pool protocol comes up, we then add support if we consider it viable or it is sponsored well enough and popular enough.
If the protocol used for the old GetWork (and the same for the crappy GBT) was defined as 'The must use Interface' some of the gains of Stratum would not exist.
Stratum is a completely different connection to Getwork
In fact it has quite clearly already happened with ASIC.
Earlier last year I had reservations about using serial-USB and the restrictions and loss of information from the underlying USB.
So at the end of last year I wrote a new interface using USB direct (libusb) and we've both improved on that since then.
It wasn't even a year ago I was having arguments with people about USB even being able to support ASIC speed devices.
Although there is still room to grow, it hasn't been a simple case of knowing there's a mile of headroom so it doesn't matter, it has indeed been a case of tuning the way everything works to make the ASIC miners work at maximum speed.
Locking things down to old ideas, or adding extra layers in the mining process to simplify it, is exactly what are are not trying to do.
Performance is what matters, but of course that's not absolute, it's simply getting the device to perform optimally (and not being restricted by some interface that someone decided is how it should be)
Things change in bitcoin pretty quickly actually ...
