add details about RTIO PHY #26

New Issue

sb10q · 2022-01-14T10:19:48+08:00

sb10q commented

2022-01-14 10:19:48 +08:00

Feedback from Joe Britton:

Documentation that M-Labs is best situated to supply relates to the
added functionality afforded to Sinara hardware modules by the
underlying ARTIQ PHYs. A focus on documenting the PHYs would be a real
boon to end users. Example elements that would be helpful for BNC-TTL
include...
- ttl_serdes_generic.py... Output, InOut
- triggering on rising/falling edges are configurable
- how deglitching is implemented and user expectations for performance
- timestamp resolution (RTIO clock vs RTIO/8)
- consider just two rising edges at t0 and t1; I want to timestamp
them; what is the minimum tmin=t1-t0?
- consider a train of rising edges at ti
    - how many timestamps at tmin can I acquire before there's an RTIO overflow?
    - this reveals relationship between SED and RTIO FIFO parameters
and data transfer speeds
    - while aspects of SED and RTIO can be configured, much of value
can be communicated by explicitly calling out the default values and
their implications
    - what is tmin assuming I want to continuously timestamp edges for all time?
- edge_counter.py is an example of higher level capability built into
the PHY and exposed in ARTIQ
    - similar questions about tmin
- mention that some details depend on FPGA type (Kasli vs KC705 vs
Ultrasscale) but that you're going to discuss Kasli 1.0 and Kasli 2.0

Feedback from Joe Britton: ``` Documentation that M-Labs is best situated to supply relates to the added functionality afforded to Sinara hardware modules by the underlying ARTIQ PHYs. A focus on documenting the PHYs would be a real boon to end users. Example elements that would be helpful for BNC-TTL include... - ttl_serdes_generic.py... Output, InOut - triggering on rising/falling edges are configurable - how deglitching is implemented and user expectations for performance - timestamp resolution (RTIO clock vs RTIO/8) - consider just two rising edges at t0 and t1; I want to timestamp them; what is the minimum tmin=t1-t0? - consider a train of rising edges at ti - how many timestamps at tmin can I acquire before there's an RTIO overflow? - this reveals relationship between SED and RTIO FIFO parameters and data transfer speeds - while aspects of SED and RTIO can be configured, much of value can be communicated by explicitly calling out the default values and their implications - what is tmin assuming I want to continuously timestamp edges for all time? - edge_counter.py is an example of higher level capability built into the PHY and exposed in ARTIQ - similar questions about tmin - mention that some details depend on FPGA type (Kasli vs KC705 vs Ultrasscale) but that you're going to discuss Kasli 1.0 and Kasli 2.0 ```

occheung referenced this issue from a commit

2022-07-26 18:26:58 +08:00

2118-2128: add t_min info from #26

occheung commented

2022-07-28 12:21:01 +08:00

3a6ed63 added minimum time separation for registering 2 adjacent gated edges.
The default size of input event FIFO is also addressed.
The number of timestamps that can be acquired before trigger overflow really depends on the way that the application code is written. If there is a large time gap between the first timestamp_mu() call and receiving the 65th edge, then RTIO overflow is going to be triggered right away.

440b3ef finds the t_min for continuous sampling, which reflects the required time for running timestamp_mu().

The EdgeCounter just has a counter in gateware to add up the counts, instead of having it as a variable in the kernel, it should not impact timestamp_mu() from TTLInOut and the input timestamp reported from the RTIO input events.

3a6ed63 added minimum time separation for registering 2 adjacent gated edges. The default size of input event FIFO is also addressed. The number of timestamps that can be acquired before trigger overflow really depends on the way that the application code is written. If there is a large time gap between the first `timestamp_mu()` call and receiving the 65th edge, then RTIO overflow is going to be triggered right away. 440b3ef finds the `t_min` for continuous sampling, which reflects the required time for running `timestamp_mu()`. The `EdgeCounter` just has a counter in gateware to add up the counts, instead of having it as a variable in the kernel, it should not impact timestamp_mu() from `TTLInOut` and the input timestamp reported from the RTIO input events.

Sign in to join this conversation.

No Label

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: sinara-hw/datasheets#26