RST# Timing ECN

["Scott Eichman" <seichman@simpact.com>]

I just finished reviewing the ECN for the RST# timing change. It appears
pretty good until I hit the second paragraph on page 3.  (emphasis is mine)

"All other devices must be prepared to respond as a target not more than the
Trhfa after the deassertion of RST#.  It is *** RECOMMENDED *** that the
system wait at least Trhfa following the deassertion of RST# to a device,
before the first access to that device, unless the device is in the path
between the CPU and the boot ROM, or the ***SYSTEM KNOWS THAT THE DEVICE IS
READY SOONER.****"

1) The SIG is implementing an ECN because there is a problem. Why weaken the
ECN from the get-go? We all know what happens to ** RECOMMENDATIONS **.
Let's make it a hard requirement

2) How would a system know that a device is ready sooner?


It appears to me that "generic" PCI interface device implementations with
soft configurations are not addressed in the discussions of what happens at
RST# time.

We use the AMCC S5933 device which has a default configuration that enables
the device to be fully functional after RST#. It allows us to initialize
some of the default registers to customize the interface to our specific
implementation on the add-in board side. This is done with a serial ROM and
allows us to update AMCC's default VID,DID, MAX LAT, GNT, Base Registers,
etc.  with our configuration.  

We have seen the "problem" of fast system configuration reads.  The AMCC
device is ready to respond to the reads, and does so. It just does it before
the serial ROMs "soft" configuration is completed. The result is that the
AMCC defaults are in the system configuration tables and our driver can't
find "us" because it is looking for our VID and DID values.

It's not a matter of the device not being ready to respond. The device IS
ready, it CAN respond to configuration reads. WE JUST NEED THE SYSTEM TO
WAIT AWHILE SO THAT WE CAN GET OUR SOFT CONFIGURATION COMPLETE.

Barring a better explanation of how "a system knows that a device is ready
sooner", the only way to guarantee proper configuration reads is to REQUIRE,
not RECCOMMEND, that systems wait the specified Trhfa time period before
configuration reads.
 
Perhaps someone from the working group on this ECN can explain the intent of
the "system knows" terminology. If interpreted to mean that the system
simply tries configuration reads until it completes a "valid" transfer, then
I would object to the ECN.  The AMCC will complete a configuration cycle and
return valid data, it's just not my data.


What would I like to see?  

Change the paragraph above to read:

"All other devices must be prepared to respond as a target not more than the
Trhfa after the deassertion of RST#.  The system must wait at least Trhfa
following the deassertion of RST# to a device, before the first access to
that device, unless the device is in the path between the CPU and the boot ROM."

OR:

Give a fuller explanation of how "a system knows" that a "device is ready
sooner".


Sorry that this message is not very concise, but I wanted to throw this out
to the group quickly because of the short time frame for ECN discussion. If
I have missed something in my reading of the ECN, please let me know.




Scott Eichman                      ___    __ __   ___  ___  ___ _/_
Director, Hardware Engineering    /__  / /  /  / /  / ___/ /    /
Simpact, Inc.                    ___/ / /  /  / /__/ /__/ /__  /_
9210 Sky Park Court                            /
San Diego, CA 92123  
Phone: (619)565-1865 x1122    Email: seichman@simpact.com
FAX:   (619)560-4112          URL:   http://www.simpact.com