RE: what is put in Vendor ID and Device ID?

[Dave New <NewD@esi.com>]

> -----Original Message-----
> From:	Mark Galecki [SMTP:marek@greenspring.com]
> Sent:	Monday, October 19, 1998 5:26 PM
> To:	Mailing List Recipients
> Subject:	what is put in Vendor ID and Device ID?
> 
> Hello,
> 
> suppose I use a PGA (programmable gate array) and program it to be a PCI
> device.  Should I program Vendor ID and Device ID to default (the defaults
> of the manufacturer of the PGA) and put my own ID's in Subsystem Vendor
> and
> Device ID, or should I program Vendor ID and Device ID to my own?
> 
	[Dave New]  In general (if I can be general about anything
	concerning PCI 8-), the "acid test" is whether or not
	the behavior of the device varies from the viewpoint of
	the system.  In addition, Microsoft (bless their pointy
	little heads) have placed extra requirements for logo
	certification.  They insist that a PCI agent *must* implement
	the sub-vendor and sub-device ID's, so that device drivers
	can tell which 'flavor' of a PCI agent they are talking to.

	For example, a video board manufacturer decides to use a
	popular off-the-shelf PCI video chipset, but adds a
	video-in-a-window TV tuner to differentiate his product.
	If the original video chipset implements only the chip
	manufacturer's Vendor and Device ID's (and they are
	permanently 'fixed' in silicon) then a device driver has
	no way to find out that the functions 'behind' the
	chipset are unique (by using PCI-compliant methods).

	By implementing sub-Vendor and sub-Device ID's (and
	allowing the board manufacturer to set them somehow
	during POST, e.g. from EEROM), then if a device driver
	exists for the exact Vendor/Device and sub-Vendor/sub-Device
	ID combination, it can be used to drive the board.
	Otherwise, a more generic driver that matches
	only the Vendor/Device ID's will be used (usually the
	installer is prompted before a generic driver is used).

	This is why Microsoft would like to eliminate the
	generic situations -- they would like to eliminate all
	installer interactions (and possible installation errors)
	by having only fully-qualified adapters and device drivers
	available.  Of course, reality intervenes 8-), and there
	are plenty of generic chipset ID's and device drivers
	still floating around to make it impractical to enforce
	this provision (yet).  Remember also, that the PCI
	specification does not *require* implementation of the
	sub-Vendor/sub-Device ID fields, so a lot of chipset
	and board vendors have had no compelling reason to do so.

> The PCI spec, rev 2.1 implies that Vendor ID and Device ID belong to a PCI
> "device" or "controller", which is a component that confirms to electrical
> reqs of a local PCI bus.  But an empty PGA does not by itself conform to
> anything particular.  I have to program it to conform.  I have to make the
> "PCI function".  So does empty PGA qualify as a device and therefore
> should
> have its ID's present in Vendor and Device ID?  
> 
	[Dave New]  When you say "empty PGA" I believe you mean
	that it has some basic PCI agent functionality, but
	so far, it can be treated as some kind of generic
	conduit to some addon circuitry (if any) on your
	board (or else all the addon functionality is
	to be added to the PGA at later date).  If that is
	the case, then you could take a cue from such vendors
	as AMCC.  Their 5933, for instance, comes with a
	default AMCC-assigned Vendor/Device ID, and is
	used as an interface to addon circuitry contained
	'behind' the 5933.

	As such, a 5933 port driver could use the 5933
	to 'tunnel' addon-specific commands to addon
	circuitry 'behind' the 5933, without needing to
	know about the functionality of the addon circuitry.
	An analogy to this is a SCSI host bus adapater, which
	can be used to 'talk' to a SCSI device on a bus,
	without knowing the contents of the device-specific
	commands that are being passed to the SCSI device.
	Using a layered approach like this, you can
	separate the port level issues from the addon
	circuitry functionality, both in the hardware and
	in the software drivers.

	Once addon circuitry has been added to the board,
	then you may wish to change the Vendor and/or
	the Device ID's, or leave them as is, and implement
	the sub-Vendor/sub-Device ID's (Microsoft would
	prefer the latter, of course 8-).

	The AMCC 5933 allows you to change the Vendor and/or
	Device ID, and if you leave the Vendor ID set to
	AMCC's they have a registration service which
	can assign you a unique Device ID for your particular
	implementation.  This provides a unique Vendor and
	Device ID, but annoys Microsoft (and those of us
	that would like to use a more usable layered
	driver approach), because you can no longer tell
	that there is an AMCC 5933 between you and the addon
	circuitry, unless you put that intelligence in each
	addon-specific device driver, which destroys the
	encapsulation of the port/class device driver layers.

	Unfortunately, the 5933 is one of those devices that
	don't implement the sub-Vendor/sub-Device ID's (the
	fields are present in the EEROM load area, but placing
	non-default values in those fields are not reflected
	into the PCI configuration space 8-( ), so with that
	particular chipset, you are confined to using either
	AMCC-registered Device ID's, or your own (PCI sig
	assigned) Vendor ID and (self-administrated) Device
	ID.

> What about those PGAs which have already pre-implemented a PCI controller
> as a front end?  Are those "devices"?
> 
	[Dave New]  In my opinion (if you can possibly arrange it)
	use the PCI controller 'front end' provided Vendor
	and Device ID's, and then implement the sub-Vendor and
	sub-Device ID fields to indicate the functionality of
	your addon circuitry.  This will make Microsoft (and
	your system software developers) much happier, and
	make it easier in the future to swap 'front end'
	implementations (and write a different port driver
	for the new 'front end') without having to re-write
	your addon circuitry driver(s) (and vice-versa).  This
	provides a lot of flexibility in port (and bus)
	implementation.

> Thank you,
> 
> Mark Galecki
> ----------------------
> SBS GreenSpring
> 181 Constitution Dr.
> Menlo Park, CA 94025
> 650-327-1200
> ----------------------
> my personal web page:
> http://www.rci.rutgers.edu/~galecki/ 
> 
	[Dave New]  Cheers,

	-- DaveN
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=
Dave New, NewD@elcsci.com    | Neutrinos have mass?
ESI Vision Products Division |      I didn't know they were Catholic...
3980 Ranchero Drive          | 
Ann Arbor, MI  48108         |        Opinions expressed are mine.    | PGP
2.6
(734) 332-7010 VOX           | 08 12 9F AF 5B 3E B2 9B  6F DC 66 5A 41 0B AB
29
(734) 332-7077 FAX