RE: non-consistent byte enables

[Norman J Rasmussen <Norman_J_Rasmussen@ccm.jf.intel.com>]

Text item: 

The spec say on page 27 tird paragraph that if the device owns the entire dword 
then it is not required to decode ad[1::0]. It completes the per the byte 
enables if possible.  It may choose to terminate with Target-abort if it desires
because it does not support the requested byte combination.  I think in general 
this is a non-issue since the driver and silicon come together and the driver 
writer understands how the hardware operates.

Note: devices that request space via BARs (base address registers) always owns 
the entire Dword.  Therefore the above statement applies to all devices except 
PC-AT comaptibility device that share bytes within the same Dword which are few!

This section is in the spec for those cases.  When the spec was first developed 
there was some (bad) software that addressed two separate devices with a single 
instruction.  This requirement to target-abort was a means to identify this 
software and get it changed.  

My 2 cents worth for today.
Norm

 From PCI System Architecture, Third Edition, MindShare Inc., Tom Shanley/Don 
Anderson, pp. 151-153:
     
"It is illegal (and makes no sense) for the initiator to assert any byte 
enables of lesser significance than the one indicated by the AD[1:0] 
setting.  If the initiator does assert any of the illegal byte enable 
patterns, the target must terminate the transaction with a target abort ... 
(STOP# asserted, TRDY# and DEVSEL# deasserted) and terminate the transaction 
with no data transferred."
     
Terry Trausch
RadiSys Corp.
terry.trausch@radisys.com
Beaverton, OR
     
 ----------
From: pci-sig-request
To: Mailing List Recipients
Subject: non-consistent byte enables 
Date: Tuesday, November 12, 1996 11:12AM
     
Hi everyone,
     
I'm struggling with the following question:
     
It says in the spec. (PCI spec. 2.1, pg.22, I/O read command) that 
"The byte enables indicate the size of the transfer and must be 
consistent with the byte address."  What happens if they are not?
     
For example, let's say the master requests an I/O read with the 
byte address AD(1:0) = 01.  The Target then claims the access by 
asserting DEVSEL#, but the byte enables are "0111" which would 
correspond to AD(1:0) = 11.  Should the target go ahead and
complete the read in order to provide parity? (pg.29 last paragraph) 
If so, does it matter what data is returned?
     
I'd truly appreciate any insight.
     
Thanks,
Suzie.

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

To: Mailing List Recipients <pci-sig-request@znyx.com>
Resent-Sender: pci-sig-request@znyx.com
Precedence: list
X-Loop: pci-sig@znyx.com
X-Mailing-List: <pci-sig@znyx.com> archive/latest/3916
Resent-Message-Id: <"1fm-i2.0.aR3.6lVYo"@dart>
X-Mailer: Microsoft Mail V3.0
Encoding: 42 TEXT
Message-Id: <3289FC1D@msmail.radisys.com>
Date: Wed, 13 Nov 96 08:47:00 PST
Subject: RE: non-consistent byte enables
From: Terry Trausch <TTrausch@msmail.radisys.com>
Resent-Date: Wed, 13 Nov 96 08:47:00 PST
Received: by znyx.com (5.65/1.35)
     id AA14112; Wed, 13 Nov 96 08:50:33 -0800
Received: from znyx.com by netcomsv.netcom.com with SMTP (8.6.12/SMI-4.1)
     id IAA13665; Wed, 13 Nov 1996 08:50:50 -0800
Received: from netcomsv.netcom.com (uumail2.netcom.com [163.179.3.52]) by ormail
.intel.com (8.8.2/8.7.3) with SMTP id JAA26573; Wed, 13 Nov 1996 09:32:09 -0800
(PST)
Resent-From: pci-sig-request@znyx.com
Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i
ntel.com (8.8.2/8.7.3) with ESMTP id JAA27981; Wed, 13 Nov 1996 09:32:12 -0800 (
PST)
Return-Path: pci-sig-request@znyx.com
àÍ