[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Subsystem Vendor ID assignment
- To: Mailing List Recipients <email@example.com>
- Subject: RE: Subsystem Vendor ID assignment
- From: "O'Shea, David J" <firstname.lastname@example.org>
- Date: Thu, 25 Feb 1999 13:18:03 -0800
- Delivered-To: pcisig@teleport.COM
- Resent-Date: Thu, 25 Feb 1999 14:03:41 -0800
- Resent-From: email@example.com
- Resent-Message-ID: <"CuX1V2.0.ZT3.FxRrs"@electra.znyx.com>
- Resent-Sender: firstname.lastname@example.org
The subsystem Vendor ID and Device ID requirement were
initiated by Microsoft. They want complete identification of
boards. In reality, they are unlikely to get what they want,
but that is mostly besides the point.
The idea behind the requirement is that the same exact ASIC
is sometimes used on multiple different boards, but frequently
wired up differently, or surrounded by differing additional logic.
The most common example of this is video boards. For example, there are
a zillion different S3 Video ASIC boards out there, some of them
different from one another.
The idea was that the subsystem ID and Vendor ID's would
distinguish these boards from one another. (Yes MS uses all
of 4 of the IDs for a match. If the subsystem ID's are 0 or FFFF's,
then it gets unhappy (WHQL disqualifier) but matches on just the
Vendor ID and Device ID.
Microsoft intended for the subystem and ID's to be ready to go
as "hardware" functional by the time the OS runs, without
any type of BIOS intervention (this last for various reasons).
The problem with this valid goal is that it requires that the ASIC
have a mechanism to shift in the subsystem ven & dev ID's
from some sort of programmable outside device. There is cost
in the pin, and lots of cost in the programmable device. Not to
mention details about what to do until the data is loaded. Its very
messy for the ASIC guys (and we DON"T LIKE IT! - I think I speak
for many here. Nonetheless, its now in the spec because MS pushed
So, speaking from the point of view of the intention of the requirement.
You are supposed to provide a means for your ASIC to obtain the
subsystem ven & dev ID's from OUTSIDE the ASIC, so that different
manufacturer's using your ASIC on different board assemblies can
select different ID's. I frequently here people talking about using
a small external serial eprom, and shifting the bits in.
The next alternative would be to provide a writeable alias for
an option BIOS to reset the subsystem ven & dev ID's. This
does not meet the intended requirement, as option ROM's are
not guaranteed to run in many of the power-management
startup-states, so expecting that the subsystem ven & dev ID's
will be set through BIOS software is really not getting the job
done. [People building chipset devices, were they control
the system BIOS can cheat here- but ASIC's that will show up
on option boards really can't].
Finally, if you are selling a core that will always be combined
with other RTL and then resynthisized, then you should have
each licensee of your code change the subsystem ven & dev
ID's. You should have them register with the PCI SIG to get
a vendor ID, and have them place that in the subsystem vendor ID
field. The subsystem device ID field then belongs to them once
the the subsystem vendor ID field has their ID in it.
This last point is very, very, very messy at this point, verging
on out-of-control. Currently, the subsystem ID's space administration
has not been enforced with PCI-SIG Vendor ID's. It really needs
to be. If not, then collisions will occur when unregistered ASIC
users pick an ID that conflicts with a register vendor.
The recommendation is that the SUBSYSTEM VENDOR ID should
only contain registered VENDOR ID values. (i.e. subystem assembly
manufacturer's should cough up the $2K it takes to get their own
VENDOR ID. They only need one for the life of ALL of their products).
That ID should be placed in the SUBSYSTEM VENDOR
ID field. This is really the only way that uniqueness can be
guaranteed. We must use the PCI-SIG to maintain a unique list
of VENDOR ID's. This is same list is used for the SUBSYSTEM
If you intend to make the subsystem ven & dev ID's useless by
hard coding them, then you should use your own VENDOR ID
for the subsystem ID, and probably subsystem DEVICE ID = 0001h.
Don't use 0000h, as this is the reserved value, and Microsoft
software might get unhappy about your using 0. The value 0001h
is just as useless if its a constant, but the software won't be able
to tell and will be happy. After all, you want that WHQL certification.
> -----Original Message-----
> From: Keith Jasinski [SMTP:email@example.com]
> Sent: Thursday, February 25, 1999 11:55 AM
> To: Mailing List Recipients
> Subject: FW: Subsystem Vendor ID assignment
> To further elaborate (or exacerbate) the question:
> The recent release of V2.2 of the spec requires the implementation of
> Subsystem Vendor and Device IDs. Why? Is the sole purpose to allow
> multiple uses of the same core (PLX, AMCC, Motorola, Intel, whoever)
> without replacing their Device and Vendor IDs?
> Since the SIG does not assign Subsystem Vendor IDs, just Vendor IDs,
> does anyone who has a Vendor ID also have a Subsystem ID (ie: the same
> When Windows does a device recognition, does it have to match all 4 IDs
> (both vendor and both device) to recognize a device?
> In our case, we are either creating our own core or replaceing the
> device and vendor ID with our own. Since V2.2 requires subsystem vendor
> and device IDs, do I just replicate the vendor and device IDs in the
> subsystem section?
> Thanks in advance,
> Keith F. Jasinski, Jr.
> Extension 245
> Mortara Instrument, Inc. (www.mortara.com)
> 7865 North 86th Street
> Milwaukee, WI 53224
> (414) 354-1600