Add hard and soft reset support to riffa onidriver

[aacuevas]

Required for:
open-ephys/onix-common-hdl#26
open-ephys/onix-pcie-host-hdl#13

[jonnew]

I've now tested this on

• Headstage-64 alone
• NPX 1.0f alone
• Headstage-64 and NPX 1.0f together
• Headstage-64 and NPX 1.0e (passthrough) together

all these seem to work with incident.

[aacuevas]

Regarding versioning:
After much thought, I believe libonidriver_riffa should not be 2.0.0 but 1.1.0
The reason being, this onidriver seems to work well with older firmware, so it does not really break compatibility. And the software API does not change. However, it introduces a new "feature" (i.e.: hardware behavior) that is required by the new firmware (the firmware does break compatibility with older drivers, so it is a major update)

For the same reasons, clroni should increase to 6.2.0

@jonnew what do you think? Versioning is a bit of a headache in this case, but I believe the rule is "if it breaks compatibility in any direction (up or downstream) then it's a major, if it retains compatibility in both directions but adds something in any, minor, if it's just a fix, patch"

[jonnew]

I came here to follow up with exactly this question: does this work with old firmware? Since it does, the major version should not increment.

So, I agree with the proposed changes. The only thing I want to make sure i understand is the "direction, up stream, downstream", wording. I don't think we need to think about this at all assuming it refers to a "spatial" dimension in some sense. We just need to think about two things:

1. The public interface which is very nicely defined for all of our components
2. If that public interface works with the exterior components that the last version of the interface did work with.

If the answer to 2. is no, then major increase.

So, in this case

1. HDL: major increment
2. Driver translator: minor increment
3. liboni: No increment
4. clroni: minor increment

[aacuevas]

Well, what I meant here is, there are two public interfaces in the driver translator or in libONI: The software API and the hardware communication. So, in a sense, there are two interfaces, if any of these broke (e.g. this translator did not work with older gateware) then it would be a major update regardless of the other.

In this case, we should do some stress-test to be sure that, indeed, the driver translator does work with current gateware. If it indeed does, it would be exactly the case you wrote (so the driver translator should be 1.2.0 instead of the 2.0.0 I wrote. should not be an issue since this is not published yet)

[jonnew]

Ah, yes. TBH, i was starting to think along those lines even when writing this. However, I think both points are correct: the hardware and and software interfaces both form the greater public interface. If any part of that public interface is does not work with whatever was was previously "plugged in" to it, the its a major change.

But I do understand the wording now.

I think it might be worth making a set of tests on Monday's meeting to ensure that we are testing all the recent changes properly.