The documentation found here:
https://hashfast.com/wp-content/uploads/2013/10/gn_protocol.pdfInformation source:
https://hashfast.com/golden-nonce-interface-protocol-released/Introducing The Global Work Queue.
HashFast aims to make mining easier and more efficient – a necessity when building and using terrahash mining systems. HashFast is also dedicated to supporting the open source community.
Going forward it is clear that the less work the miner has to do to get devices working the better. What the miner apps should be doing is deriving work (from a Stratum server), pushing that work out to devices, and getting back nonces and device status. Managing individual cores in every die/ASIC in a 6 foot rack is just not sensible. Devices themselves should do the grunt work, leaving the mining app to do what it does best.
We had an opportunity to do this – because (a) we had already built advanced mechanisms in our serial protocol that allow work multiplication and dispersal – group and multicast mechanisms, ntime rolling etc., and (b) our USB interface has programming capability. As such, we are able to offer three interface mechanisms:
1. ASIC serial – useful for vendors who wish to make their own boards and interface means to the ASIC
2. USB mapped serial – USB interface but all of the low level serial protocols available, data CRC not required/present
3. USB Global Work Queue – A higher level interface that just involves work flow to the device and nonce flows back to host
The driver for CGminer (to be published on github soon) will use the Global Work Queue.
Today, we are releasing our interface protocol document that describes these three mechanisms, and more.
There are no fundamental protocol changes to use the Global Work Queue protocol. Drivers using the USB interface simply nominate this as the protocol they wish to use, and they direct OP_HASH operations to a virtual ASIC at address 254. (255 is the broadcast address). A simple sequence numbering system tells the driver when it may send work and when to stop. All it gets back is a nonce stream, and if it asks for it, periodic status/monitoring data which will contain a lot of information about voltages, temperatures, fans etc. and that data will wind up in the miner’s API. The driver doesn’t need to know how many cores or chips are out there.
A side effect of using a higher level interface is that the driver becomes straightforward. Instead of thousands of lines of complex low level code, there will be just a few hundred lines of simple high level stuff to deal with.
Needless to say, we are excited to release this 84-page engineering document to the world, and to present it to the open source development community .
Download the document gn_protocol.
https://hashfast.com/wp-content/uploads/2013/10/gn_protocol.pdfCheck back here for more news on the driver header files (coming soon).