To: Dave Curtis , Richard Schwartz 301 286 4714 From: Dorothy Gordon Subject: Re: time stamp generator is faulty X-Mozilla-Status: 9011 At 07:14 PM 2/3/00 -0800, Dave Curtis wrote: > OK, I can believe that the packet may be started when the last event of >the previous packet is filled, rather than when the first event of the new >packet is ready (Dorothy, is that right?). This would mean that you would >get a time stamp event at the start of a packet if there is more than 1ms >between those two events. In any case, you should be able to figure out >the time. Each packet timestamp is initiated by the "first" event of that packet. There may be some delay, however, from the actual event to when it gets stuffed into the packet. This delay has increased somewhat since we slowed down the IDPU bus. If the DIB that creates the event is "last" in line and has to wait for the other 8 DIBs to be serviced, the delay could add up to about 5us. For the timestamp events: if the time period for timestamp generation is exceeded (>1ms), when the BCF receives an event it inserts a timestamp event right before the event itself is forwarded to the PFF. Again, there is some pipeline delay in handling it, but the timestamping itself (which is done in the PFF) should occur within a few microseconds at most. Let me know if this is not the case and I'll look into it. > Yes there was a late 2-bit shift in the time stamp bit selection in order >to provide overlap in the bits to avoid any possible confusion when an >event is generated just before a clock roll-over, and the time stamp is >generated just after (the time stamp event may be generated a few >microseconds after the real event that causes it). The 2-bit shift was implemented about a year ago. It's not really mentioned in detail in my specification, but may be in the Telemetry Formats document if it was updated (my copy - Version D - predates the change). The timestamp (for timestamp events) is: SECONDS[14:0] and SUBSECONDS[19:8] Dorothy