Understanding port inputs Topic is solved

[larry]

If you do two inputs like this, I'm not sure how the second one could return a timestamp smaller than the first one.

Are you sure both ports are clocked off the same clock block?

The timestamp you get is the time at which transfer register was filled.

[DemoniacMilk]

Yes they are driven by the same external clock.
If the timestamp holds the time of when the transfer register was filled, then the resulting timestamps arent too surpising, as the result was always
|uiTimestampSync - uiFirst| < size of port buffer / width of port

[larry]

Actually, you can have a scenario where two timestamped (timestamped meaning "p :> x @ t") inputs on synchronised ports return a second timestamp smaller than the first. It's because those inputs are un-timed (timed meaning "p @ t :> x") and their effect on buffered ports is to shift in any remaining bits to complete a full transfer word and write the word to the transfer register. Depending on how many bits have already been shifted, you get a different timestamp.

For example you might do an untimed input on a buffered port that is in a state where it has already shifted in 3 bits and current port time is T. The port will shift in 5 more bits, write all 8 bits to transfer register and return the transfer register together with T+5 as timestamp. And next time round returned timestamp could be T+1 or T+7.

To make sure your buffered ports start shifting from 0, begin by doing a timed input. You can then keep doing untimed inputs, which will always stay in sync as long as they are executed in time to cope with given data rate.

[DemoniacMilk]

Thank you for the help and information, it is all working well by now.