It appears that the ‘bit’ argument in okUsbFrontPanel_ActivateTriggerIn() specifies a bit number, not a bit mask. This means I can only set one bit at a time. (It might have been better to make that argument an int so that I could set any or all of the trigger bits).
Since it appears there is no UpdateTriggerIn function, does ActivateTriggerIn happen immediately, and hence is it not possible to set multiple bits in a TriggerIn?
You are correct – ActivateTriggerIn happens immediately. Therefore, it is not possible to activate multiple triggers at the same time – within the software.
The same can be accomplished, however, by connecting your hardware appropriately.
I recently discovered this behavior about the TriggerIn myself. It was not obvious to me and tripped me up a while as I troubleshot my application. Is there any reason not to allow multiple bits in the Trigger to be set at the same time? I can think of applications where this would be very useful and off hand I’m not seeing any disadvantages.
Is there anything in the design that precludes this change to the Trigger functionality? If OK isn’t interested in changing this behavior, but it is possible, would it be possible to get access to the source to make the change ourselves?
Thanks,
Todd
Can you please describe a use case?
Absolutely, two cases:
I may be interested in sometimes triggering multiple events concurrently. For example, I could have data pattern generators tied to each bit of the TriggerIn Register. Sometimes I want to trigger them in an asynchronous fashion and can do this by sending a TriggerIn with only a single bit. In other instances I might want to ensure that my patterns are generated in sync and could trigger the by settings multiple bits high with one TriggerIn command.
In a second case I might want to trigger an event that has a variable parameter to it. For instance, with the afore mentioned pattern generators I could pass the parameter (perhaps a seed to an LFSR) at the same time as the “start” command, by writing the parameter in the TriggerIn command. This would preclude the ability to write a value of 0; but in the case of an LFSR a seed of 0 isn’t generally useful. And I could do an offset if I could get away with 65534 values, but needed 0 to be one of them.
For both of these cases I could write the configuration parameter (or which generators to run) in a WireIn and then send a TriggerIn to copy the WireIn and start the requested event. Which is my current work around.
Thanks for the interest,
Todd
Your “work around” is the more reliable implementation for this.
Activating two (or more) triggers through FrontPanel would imply two signals crossing a clock boundary. Because of the non-deterministic routing within an FPGA, this cannot be done reliably without a lot of additional logic. Without careful handling, there is a risk that the two crossings would not be synchronized.
It is much more efficient and reliable to cross the clock boundary once and use logic on the “other side” to distribute that signal, as necessary.
For your case, it’s better to set up the transaction with wires, then trigger it with a single trigger.
Thanks for the feedback. I can see how having the bits set to individual clock domains would be beneficial. However, for my proposed examples the bits would be in the same domain and that wouldn’t be an issue.
Hm. I’m not sure we’re on the same page here.
Consider the scenario where the you have no clock domain crossing. The host interface is CLKh. The other logic is CLKh. This is the reductive case where no synchronization logic is required.
Now consider domain crossing to from CLKh to CLK1 and CLK2. CLK1 and CLK2 are asynchronous to each other. Since they’re mutually asynchronous, there’s no way to guarantee any synchronous arrival of a pulse to both of them. So this isn’t a case worth considering here and it is not the case mentioned above.
So we’re back to the case considered: CLKh is crossing to CLK1. If you want to synchronize two different triggers, you necessarily have two different paths. h0 (host bit 0) and h1 (host bit 1) cross through synchronization logic paths p0 and p1 to generate trigger bits in CLK1 t0 and t1.
I think what you’re looking for is t0 and t1 to occur in the same clock cycle of CLK1. However, since p0 and p1 are different, you can’t guarantee this. At some narrow slice of the timing, if p0 differs from p1 in as little as femtoseconds, the synchronization can land t0 and t1 in different clock cycles of CLK1.
The only way to assure that t0 and t1 are in exactly the same clock cycle is if you have a single crossing path (p0) and generate t1 from t0 in CLK1’s domain.