Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring back timeouts #24

Open
henryhallam opened this issue Jun 11, 2014 · 3 comments
Open

Bring back timeouts #24

henryhallam opened this issue Jun 11, 2014 · 3 comments

Comments

@henryhallam
Copy link

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
Copy link
Owner

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 comm_fpga_* 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
Copy link
Author

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
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants