Metadata & timestamps
Posted: Sun May 10, 2015 1:05 am
Good Evening,
I am trying to get my head around these metadata timestamps for the purpose of building an application in which transmission timing must be tightly synchronised with receive timing.
I see that unlike the USRP/UHD, there is no mechanism to set the timestamp. However, there is a method to read the timestamp, bladerf_get_timestamp(..), which could be useful for me, if I could understand how it worked.
Looking at the "real" implementation of this function, i.e. in usb_get_timestamp, there appears to be a lack of documentation around the specifics of how this really works.
I am hoping some of the FPGA gurus can help me out with these questions I have:
1. Why are there two independent counters for RX and TX?
This seems counter intuitive for the purpose of scheduling. How can I safely establish the relationship between the two counters without timing uncertainty? I can see no way of doing this. I get that the bladerf can run independent sample rates in either direction, so part of the reason for this makes sense, but I still need to establish the relationship when both counters are running.
2. Is the read atomic when the counter is running?
The read in usb_get_timestamp appears to issue two commands to the FPGA to read 32-bit halves of the 64-bit value. When the counter is running, will this result in possible tearing if the MSbs wrap around, or does the FPGA implement a state machine to guarantee an atomic read?
3. Under what circumstances are the counters actually running? The moment I do a bladerf_enable_module()? If this is the case how can I establish RX-TX timing relationship?
4. When am I allowed to read the timestamp? In what states?
I am trying to get my head around these metadata timestamps for the purpose of building an application in which transmission timing must be tightly synchronised with receive timing.
I see that unlike the USRP/UHD, there is no mechanism to set the timestamp. However, there is a method to read the timestamp, bladerf_get_timestamp(..), which could be useful for me, if I could understand how it worked.
Looking at the "real" implementation of this function, i.e. in usb_get_timestamp, there appears to be a lack of documentation around the specifics of how this really works.
I am hoping some of the FPGA gurus can help me out with these questions I have:
1. Why are there two independent counters for RX and TX?
This seems counter intuitive for the purpose of scheduling. How can I safely establish the relationship between the two counters without timing uncertainty? I can see no way of doing this. I get that the bladerf can run independent sample rates in either direction, so part of the reason for this makes sense, but I still need to establish the relationship when both counters are running.
2. Is the read atomic when the counter is running?
The read in usb_get_timestamp appears to issue two commands to the FPGA to read 32-bit halves of the 64-bit value. When the counter is running, will this result in possible tearing if the MSbs wrap around, or does the FPGA implement a state machine to guarantee an atomic read?
3. Under what circumstances are the counters actually running? The moment I do a bladerf_enable_module()? If this is the case how can I establish RX-TX timing relationship?
4. When am I allowed to read the timestamp? In what states?