Bring back timeouts

[henryhallam]

In commit 99f0bc with the introduction of the async API, the timeout parameter was removed from the synchronous flWriteChannel and flReadChannel functions.

The justification was that in the event of a timeout, recovery is impossible because synchronization has been lost with the FPGA. That's true, but when the application has some kind of out-of-band control (e.g. power on/off or a master reset/reconfigure line to the FPGA), the ability to detect and recover from faults[1] is useful even when the recovery is rather inelegant.

I can put together a pull request to bring timeouts back but would appreciate input on how you'd prefer it to be done - just add the argument back to flWriteChannel? A new flWriteChannelTimeout function?

[1] The fault might be completely unrelated to FPGALink but could still result in CommFPGA getting stuck.

[makestuff]

Would it work if we had the early termination of reads working? So for example if the FPGA has no data to return for N contiguous cycles, it terminates the host read early, and the host gets fewer bytes than it asked for (rather like POSIX read()). The N could be set with a generic on commfpga* at synthesis time (or perhaps even set by the host at runtime). This is something I've been meaning to do for a while, to elegantly handle scenarios where you want to read data efficiently whilst there is data to be read, and terminate cleanly when there isn't.

That won't help for write timeouts though - so far as I'm aware USB has no mechanism for doing early termination of writes.

Chris

[henryhallam]

Unfortunately at least in our case, faults can cause write timeouts just as often as read timeouts. They can totally knock out the FPGA configuration. Pretty rare, but it happens.

[makestuff]

OK, let me have a think about it. It has been a while since I looked at that code.