In-line device turnaround time

[ericthegeek]

> What is the maximum time of t between the falling
> edge on the command port and transmitting on the
> responder port?

Section 4.2.2 permits each inline device to delay the data by 88uS.

> If it's a non-discovery packet with a break, the device
> must shorten the break by no more than 22 μs, so that's
> an upper limit on this time.

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.

> 1. All devices should ignore preamble bytes of
> 0xff as well as 0xfe. This would allow the
> first 8 μs low period of the discovery response
> to be shortened by an arbitrary amount.

It is good practice for a controller to ignore corrupt preamble bytes (as you propose). 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.

I worked on an inline device that accidentally corrupted the first byte of a discovery response. It confused many controllers.

[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.