Re: invalid byte enables

["David O'Shea" <daveo@corollary.com>]

At 04:37 PM 3/27/97 -0800, Eddie Chan wrote:
>Hi all,
>
>I'm trying to find out if it is necessary for a device to report an
>error when it receives an unsupported combination of byte enable
>bits (for example, when a device that can only receive byte accesses
>gets sent a dword with more than one byte enable bit asserted) or if
>it is okay for the device to simply ignore the transaction.  Any help
>would be appreciated.

Well, I would say its sort of the opposite.  You should probably respond
to the transaction, either with sorta-good data & parity, or with TARGET-ABORT.
Trying to ignore the transaction, using DEVSEL# control costs you a 
cycle in performance, and also does not always work in some write-combining
cases.

If you are porting a byte or word device into PCI, then you must do
full address and byte enable decode.   In the case where a where a BE
combination is one that is not logically supported by your less wide
device, the best (IMO) thing would be to drive a known pattern on the
illogical data lines (like 0's, or all 1's).   You are also required
to provide correct parity for the data that you drove (in the next cycle).  
Some people prefer to drive the "logically supported" data lines onto
the "does not make sense" lines as a source of "don't care" data. 
The data driven does not matter except for generating the parity.

A different legal error reporting scheme would be to respond with a
TARGET-ABORT sequence, DEVSEL# deasserted and STOP# asserted.  That
would alert the generator to an error condition.   Usually, target
aborts are picked up by the host bridge and communicated to the end
user via an interrupt signal (in PC's its usually NMI).   This is
good in the sense that an error condition is noted, but bad in that
in most implentations this just kills the machine.

Finally, you could not assert DEVSEL# at all.  This is probably the
worst response from a performance perspective.    This would require
that you delay asserting DEVSEL# for a cycle while you looked at the
byte enables to figure out if you liked them.  You would have to do 
this on every transaction, which would make your device slower.  Also,
this approach will not work if you receive a write combined burst
from a master, with the intial data cycle containing valid BE's, but
later cycles containing illogical BE's.   You will have asserted DEVSEL#
because the first set of BE's looked good.   This leaves you with
the two choices above, either just generate useless data and good parity
and silently ignore the condition by providing this data, or stop the
transaction with TARGET ABORT.

Since this case is really only an issue for the device driver writer,
where the driver is doing an illogical read or write or your device,
its pretty much your choice whether you think TARGET-ABORT is better
or if you think 0's on the other byte lanes with good parity is better.
In a debugged driver, this case should never occur in practice.

I do not think programmers would all agree on what's best.  Some would
like to see that they screwed up by having the machine die when the NMI
hits because of the TARGET-ABORT.   (Some machines are not configured for
NMI on TARGET-ABORT, so they would not get this outward sign).  Some
programmers would prefer to NOT have the machine die, so that they
could figure out where their device driver was making the mistake by using
debuggers, etc.

I think if I was the HW guy, I would use TARGET-ABORT, because I think its
probably easier.   But, since you have to provide valid parity for all
data lines, the BE's, and PAR for a byte or word device anyway, some people
find it easier to use the just-ignore-it technique, and supply the BE
data that makes the most sense (or is easiest) and just return semi-valid,
but illogical data with good parity.

Hope that helps,

David O'Shea
daveo@corollary.com
H8