RE: Question about the initialization of configuration registers

["O'Shea, David J" <david.j.oshea@intel.com>]

John,

If that is what he intended, then I agree.

Actually, when I read it more carefully, I think we both
misinterpret exactly what he intended to do, but your assertion is closer.


When I read it more closely, and interpret "application-side 
(not PCI-side)", I realize he means that he will have some code 
run on his own private bus which will program his componenent through the
backside interface (whatever it might be).   This would be
legal, but has to be done by Trhfa after RST# deassertion.
i.e. His private bus code must have configured his PCI bus
side components DID, VID, SSDID, SSVID's by Trhfa, or 2^25 clocks.
Which is ~ 1 second at 33Mhz, or .5s at 66Mhz.    So if his private
inteface & firmware is relatively quick (not all that quick to beat
1second),
then he can proceed with his plan.

I believe I misinterpreted his use of "application-side" to mean
the PCI opROM application side, but I don't think that was what
he intended after closer reading.  His use of "boot-ROM program"
program threw me off.   His intended "external" boot-ROM private
bus program, or your (John's) in-the-hardware-built-in-state-machine
have the same rules to live by, namely that the values have got to
be ready by Trhfa (2^25 clocks).

So, I stand corrected.  And whomever you were at there (I have lost
the original mail, and left your name out of the quote for some reason),
You can do what you want, as long as you meet Trhfa (See section 4.3.2
of the PCI 2.2 spec).

-David O'Shea

-----Original Message-----
From: John Bloomfield [mailto:john@datacube.com]
Sent: Monday, October 02, 2000 12:47 PM
To: O'Shea, David J
Subject: RE: Question about the initialization of configuration
registers


Just curious, but when I read the question, it seemed to me
that it could be interpreted in the following way:  His chip
would go out and read some locations in the boot-ROM, without
requiring the BIOS to run. In other words a state machine in
his chip would, after reset, go read the boot-ROM to get the
subsystem vendor ID and subsystem ID and load them into the
cofig registers in his chip.

This approach seems to me no different than having a physically
different eeprom, here the separation is done in the address
space of the boot-ROM. Am I missing something? Why wouldn't this
work?

--John--


John Bloomfield
VP Hardware Engineering
Datacube Inc. 300 Rosewood Drive Danvers, MA 01923
Voice: 978-777-4200 Email: john@datacube.com

-----Original Message-----
From: O'Shea, David J [mailto:david.j.oshea@intel.com]
Sent: Monday, October 02, 2000 2:09 PM
To: pci-sig@znyx.com
Subject: RE: Question about the initialization of configuration
registers




> I have some questions. I'm going to design a PCI master/target device chip
according to PCI Spec. rev. 2.2. Because this chip can be used in many PCI
application cards, I think subsystem vendor ID and subsystem ID must be
changeable by system vendors and these IDs will be used to identify the
system card in PC Windows system. Therefore, many chips use an EEPROM to put
them in it. But I'd like to implement a PCI device without an EEPROM. Using
the boot-ROM program in the application side(not PCI side), we can assign
the initial values of these configuration registers whenever system reset
(PCI bus reset) is released.
>
> 1) Any problem in this method?

Yes.  This is explicitly forbidden design practice.  The ID registers
must have valid (correct) contents in them exclusive of an option ROM
running.  They have to be valid shortly after RESET# deasserts.  Your
device is expected to issue RETRY responses until the ID is set.

The boot-ROM is not guaranteed to run in many situations.
Most common, and of most interest to you, would be when a system
is restoring from a lower-power state, say S3 and your device is
coming back from an off state.   (As if all the PCI devices and its
associated
PCI bus was powered down).    The BIOS will not run the option ROM
again.   The opROm's handy work is still preserved in memory in terms of
system state, and there isn't supposed to be any "device state"
that is dependent on an option ROM running.  (i.e. your ID setting
idea here).   (i.e., the system keep memory on standby voltage.  It is
good.  You device went off, then on again.  The system will reassign
the old BAR values that it saved before device power-down.  Your option
ROM will not be run on power-up....)

This is a no-no.   It is a no no that everyone is tempted to do, to save
the cost of an serial EEPROM....     The only devices allowed to cheat and
actually do what you propose are devices used on the motherboard.   Its
still
illegal, but the system BIOS always does get to run on an ACPI power-state
change, so it can always restore the values as you suggest.   But add-in
cards
don't get this luxury, nor do PCI devices used on such adapter boards.

-David O'Shea