This message is from the T13 list server.

> ... I haven't yet seen a bridge sample
> appear here that passes a simple-minded
> test of random terminations within a transfer
> (with our Pio history, we speak of this as "arbitrary DRQ")

Maybe this is what is disturbing me most deeply.

I readily enough make fun of the powerful people who buy our stuff, run some legacy 
test badly ported to new protocol, and then tell us our stuff is broken because the 
port of their test is broken.

The silliest example I quote most often was the customer who tried to tell us ERR 
should be a little more sticky: once we had reported an ERR, we were supposed to 
report the immediately following command had an ERR too.

Maybe now I'm on the other side.

Back with Pio, we could build a custom test device ask to move data arbitrarily, and 
if a bridge couldn't handle it, my answer was "talk to the hand" i.e. fix it and call 
me when you're done.

My own people backed me up here, because the task of precisely characterising exactly 
what pattern of bursts came out of the all the legacy devices that matter to us was 
always a lot huger than the cost of fixing the bridge to handle anything we could 
throw at it.

I can swallow the idea that to test Sw/Mw/UDma this way you have to round up all byte 
counts to an even number.  These protocols flatly can't distinguish N from N - 1 when 
N is positive and even.  Such is life.

But it bothers me deeply that a test host is supposed to tolerate receiving 1 or 2 
extra clocks in the terminating pause, and is supposed to tolerate a device not 
noticing if it was sent 1 or 2 extra clocks in the terminating pause.

I guess I was more concerned when the traffic here was suggesting that I was wrong to 
think this was unavoidable.  I'd really hate to learn to ignore these apparent 
indications of trouble and then learn that some competitor had figured out how to 
distinguish false trouble from real trouble.

If this is unavoidably the way life is for anybody who uses UDma to move streams of 
blocks of data, then at least we're all playing on a level field.

Maybe over time more and more of us will learn to never clock garbage past the 
terminating pause.

Pat LaVarre


Subscribe/Unsubscribe instructions can be found at www.t13.org.

Reply via email to