...
(though I've almost completed the new internal libraries to use direct USB rather than Serial-USB to help with performance and to hopefully simplify ASIC implementations)
Would you mind if you could PM us for some more details please? We are doing everything we could to make sure we are not the cause of the critical path of the whole project and reduce the whole deploying time. So we will be very glad if we could get any help and idea from you.
I'll post it here
(then we can create a thread if a discussion develops here)
I'm using libusb on linux and libusbx on windows (so a consistent code interface for both - same code for both)
In it's first incarnation it's using Bulk transfer to do everything coz I have it running (already working) on an FPGA ModMinerQuad
Working with no trouble already on Linux - just reworking the device identification code coz it didn't work on windows
The ASIC version may need Interrupt transfers for better performance, but I'll get to that, if needed, after the initial code is fully working with Bulk transfers.
If your MCU developer is well versed with the different USB transfers and their advantages/disadvantages then they will be glad to know that the basic identification code (not finished yet) will allow any Transfer Type - but I've only implemented Bulk so far in data transfer.
The MMQ code runs 4 threads (to 4 devices) over a single MCU - so there's no issues (at least for me) for dealing with multiple threads and multiple endpoints - but I envisage only using a single interface - hopefully with 2 endpoint pairs
FPGA MMQ's poll (and so do BFL FPGAs - but Icarus FPGA doesn't) so the actual MMQ code won't look like how it will with ASIC
(I sincerely hope you do not implement any polling requirement - I'm pretty sure neither BFL or bASIC will - and since Avalon is from the Icarus developer who didn't do that in their first FPGA I'm pretty sure they wont with Avalon)
The expected high level interface is: send work, wait for zero or more nonce replies, after zero or more replies sent, get a completion message back.
If you go beyond that level to handling difficulty or even implementing something like stratum in the MCU, then that will of course be done differently.
If you implement difficulty, I'd have the miner actually request shares at an easier difficulty than required (and have some limit even on that) since the advantage of a short known expected average response time is that you also find out quickly when something has gone wrong.
(device disconnect, USB reset required etc)
Clearly there is a trade off between response time and USB limitations - e.g. if someone has 100 mining devices on a single computer
USB1 has a transaction time of 1ms and USB2 of 0.125ms (but can be faster with different transfers)
So hopefully you will be using at least USB2 (some of the FPGAs are currently USB1)
I'm not much of a USB expert
(I've only been messing around with it for a few weeks) but there would be advantage to having multiple endpoints so that one pair is used for the mining and another pair can be used for the status type protocol.
(e.g. temperature, configuration, etc over a different endpoint pair to mining)
Would obviously make the mining software easier but I'm not sure of the positive or negative effects of that on USB.
As for the MCU firmware itself, I'm 99.9% sure the firmware will be uploadable on all ASIC devices, so I don't expect you'll gain much by hiding the details of that.
Meanwhile if you wish to discuss anything in PM or private IRC then that's fine.
But obviously once the miner code is implemented there won't be many secrets