In-line device turnaround time

[sjackman]

Originally Posted by ericthegeek

An inline device can receive a byte, hold on to it for 88uS, then send it out. It can also shorten the break by 22us. The two are separate, and an inline device could conceivably do both to some degree.

If the inline device uses a switching fabric rather than a store-and-forward implementation, it doesn't have the ability to `hold on to it'. See my response to Gerry above.

Originally Posted by ericthegeek

It is good practice for a controller to ignore corrupt preamble bytes (as you propose).

Could this be proposed as an amendment to the standard? If not a SHALL directive, even a SHOULD directive would be better.

Originally Posted by ericthegeek

But in order for an inline device to comply with the standard it must shorten the preamble byte by a very small amount of time, or by an entire byte. The requirements in your proposal #2 are all included in the document, just not in a single list.

It's this `very small amount of time' that I feel needs clarification. My best reading of the spec indicates that the first bit be shortened by no more than 75 ns (section 4.2.3 Bit Distortion). Do you agree?

Cheers,
Shaun

[Gerry]

Originally Posted by sjackman

It's this `very small amount of time' that I feel needs clarification. My best reading of the spec indicates that the first bit be shortened by no more than 75 ns (section 4.2.3 Bit Distortion). Do you agree?

Cheers,
Shaun

Hi Shaun,

The 75nS is for non-cumlative bit distortion of the data. Alowing a shortning of 75ns for each inline device could result in a total 300nS shortning. That's a 7.5% error in bit timing.

For the specific instance you mentioned: the processor controlling the switch matrix, I would drop the 1st preamble byte. This gives the processor time to set up the routing to get the next byte out on time.