I need to sample a counter value which is 32 bit wide. However, wire widths are only 16 bits.
The Front Panel manual says somthing about the wires being sampled at the same time and the API strucutre seems to support this approach.
How safe it is to split the two halves of the counter into two Out Wires? Will both of them be sampled at the exact same hi_clock cycle ?
If not, is there any singal available (it_control?) that indicates when the wires are sampled so I can freeze the value during this period?
If not, what is the next best way?
Thanks,
Kam
Hi Kam-
The WireIns are all updated on the same HI_CLK cycle. Likewise, the WireOuts are all sampled on the same HI_CLK cycle. If your logic is providing these signals from a different clock domain, keep in mind that you will be crossing a clock domain. Different timing within the FPGA could cause problems if you don’t consider these effects.
To elaborate a bit, the wires are considered asynchronous, so you’re not really privy to know when the values change. However, to support the wider bit widths as you suggest, we do guarantee that they will all update at the same time (or rather on the same HI_CLK edge).
Thanks. That’s simplified things. I was confused by the statemet in the manual that they are ‘asynchronous’. They are sycnrhonous with the hi_clk edge.
Another note, it would be good to have in the manual a section devoted to the clock subsystem. It will eliminate the guess work since we don’t have access to the board schematics and HDL source code.
Thanks for a great product.
Kam
Hi Kam-
You’re right that they are synchronous (to the HI_CLK). The difference we were trying to draw with the synchronous / asynchronous terminology is the difference between the pipes and triggers (sync) and the wires (async).
Triggers are “synchronous” because they can generate a one-shot on a user-supplied clock. They also reliably cross the clock domain barrier so that exactly one trigger is produced (or detected).
Pipes are “synchronous” because they can convey multiple clocks worth of data, albeit on the HI_CLK domain.
Wires are “asynchronous” because they are more like pushbuttons or switches on a board. They convey data but are not associated with any particular clock as the pipes and triggers are – in the abstract sense. Implementation-wise, however, they do have this association.
I will note this to revisit the documentation and try to clarify this.
Thanks for the clarification.
Wire in/out are a convinient way to read/write multi bit values (counter, states, etc). Having the Wire end points also syncrhonus will simplify the interfacing with the ok USB module.
Otherwise, users may need to implement cross clock interface between thier clock and hi_clock or use a less less efficient workaround (adding a buffered register use the dual USB command model, trigger and then read).
One of the best features of your product is the clean model, elegant design and the ease of interfacing out of the box. Having synchronous wire in/out will take it one step further.
The syncrohonized wire ep (both in and out) can have for example an ep_clock input that connects the user’s clock. If the user does not care of the clock (e.g. when reading buttons, that input can be simply tied to ti_clock).
Thanks,
Kam