[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Is is possible to receive a cheep SubVendorID?
I have been around since the start of the SIG, but my
memory is pretty hazy about the original member companies.
I could hazard a guess that it involved the 'usual
suspects' -- Intel, Microsoft, Compaq, etc. I seem
to even recall that the original SIG offices were
housed (and maybe still are) at Intel (or maybe that
was the I2OSIG). Essentially, the original companies
donated far more than the $2500 membership fee in terms
of employee time, travel, and other expenses, to get
this whole thing off the ground. It was really
quite a herculean effort, and not unlike herding
cats, to get all those players to agree to something
and to stick with it.
Yes, I would agree that the SIG has tried hard to
protect the integrity of the specification and
also any advance information about draft changes,
restricting it to their member companies. At
least once the changes are adopted, they specifications
are available at a reasonable cost to those that
want it. They also do not try to restrict anyone
from implementing PCI boards and interfaces, if
they wish, member or not (granted, Vendor ID
issue is a sticky point).
This is in stark contrast to the way I2O was run.
Even released specifications were given only under
an NDA and a license grant, making it all but
impossible to write I2O code for GPL'ed software,
like the Linux kernel (yes, I know that GPL exceptions
are granted for closed-source loadable module drivers,
but this runs counter to the idea of sharing
infrastructure-related code amongst developers,
so they can get on with doing applications).
After much pressure from the free software community
(and I believe, when the I2OSIG realized that their
effort was about to 'die on the vine'), the I2O
specification was open-sourced, so to speak. So far,
the reaction has been pretty ho-hum. My impression is
that they missed the early adopters, by insisting on
restrictively licensing the I2O technology, making
it illegal to implement it if you hadn't joined the
I wouldn't go so far as to accuse these 'secret'
consortiums of conspiring to keep all the small
players out. Instead, they are conspiring to
keep just about *everybody* out. 8-)
Companies are required to answer to their
stockholders. They are particularly concerned
about competitors. By definition, if you aren't
a signatory to a consortium that they belong to,
you are by definition a competitor (and sometimes,
even if you are! 8-). Fortunes have been won
and lost on such industry relationships. Witness
the RAMBUS debacle that has been unfolding in
In essence no one can keep you from using whatever
ID you want in your designs, but you may be
denying yourself some amount of market share,
once it becomes known that your board won't play
in some systems, because of an ID conflict that
may crop up in the future.
I certainly don't mean to mislead students. Maybe
someone else that knows more about the current state
of the PLD art can rescue me, but I've listened to
horror stories on the list about timing problems
(in particular) when using programmable logic. The
clock specification, in particular, is usually a
killer item. You must be able to go from DC to 33
MHz, and back again, on a per-cycle basis. No
PLL can deal with that, and all the so-called
'zero-delay' clock drivers fail to follow
such severe clock frequency changes. Being
'almost compatible' is simply not good enough.
I don't blame folks for wanting to avoid the typically
high charges associated with the major commercial
vendors of FPGA hardware/software. I find it
amazing that the design software costs so much,
but I suppose that it is a far cry from the old
days of ABEL.
As far as what can be done with CPLD's I'm waiting
to hear from someone that has actually implemented
a completely PCI-specification (electrical, logical,
and timing) compliant interface in these things.
If you have, and you are willing to share all that
you have learned, then I'm sure a lot of folks
would be interested in hearing about it.
From: Dimiter Popoff [mailto:email@example.com]
Sent: Thursday, October 26, 2000 6:03 PM
Subject: Re: Is is possible to receive a cheep SubVendorID?
>When the PCI SIG was just starting out, such
>membership fees helped to fund the startup
>activities of the organization for working sessions,
>etc., to get the initial specs out and organize
you seem to be familiar with that period of history. Could
you tell us which companies were involved then and how
much money did they gather from membership fees?
>...For certain, there are many companies
>whose membership is not current, but the SIG has
>declined to drop and/or re-assign their Vendor ID.
>To do so would create mayhem of the worst sort,
>with conflicting ID's, etc.
Sounds more and more like a protective mechanism to me... Those who
had to get the ID got it and did not even bother to pay again.
>The other benefits that accrue to member
>companies is access to draft specifications,
>the ability to participate in the standards process,
>and voting rights.
Oh please don't mix them all together.
I do not claim voting rights - I do not even claim participation
in the process of standardisation, though the latter would not
hurt (see how the earlier mentioned examples like t10 and t13
work) - but I certainly would like to have access to the draft
Keeping them secret just means that those who control PCI need
the one or two years of secret work to be able to produce something
which the others out there won't be able to 'comply' with
within several months.
>After a hue and cry, particularly
>from the academic community, this policy was
A look the numbers at the stock exchange related to those who
control PCI - and matching them to the level of the technology
they have - will make you believe they changed their policy
not because they wanted to do so.
>Perhaps it is time for some SIG members to float
>the idea that there should be a one-time low-cost
>Vendor ID registration, say, $250 or so, to simply
>defray the costs of administering the database...
No deal :-). My proposal is still valid: use that 0xFA3C
and have a free subvendor ID and device ID,
I'll personally maintain this for free.
>Note that if a bunch of folks got together
>and pooled their money to buy a Vendor ID, they
>could then hand out up to 65K Device ID's, as they
Yeah, now try to sell them $FA3C.
>On the subject of someone inventing their own
>PCI interface circuitry, I would assert that
>that is a more difficult proposition than one
>may think. ....
Now, Dave, misleading students is certainly not ethical.
It is _not_ hard at all for a skilled guy to program a PCI
inerface into a silicon which can contain it.
>In all of these situations, I would expect the vendor of
>the IP to also offer a Device ID registration service, to
>relive the developer of the burden of registering their
>own Vendor ID.
What if I _don't_want_ to buy their IP? It has cost me more than
a week of work already to decode what Xilinx would not tell me
about their silicon; do you expect me to want to become dependent
on their _code_?! Being dependent on silicon they (or anyone of
the kind) just took over is about enough for me.
>On the other hand, FPGA development software/
>hardware is so expensive, that $2500 is just lost
>in the noise.
Not really. For example, I program my CPLDs using my own
software which runs under DPS; and then I can pretty much do
what I want to my boards using the JTAG tools I have written
(which, as one may guess, use the same DPS objects which the
logic compiler has produced). I spent 3 months on implementing
this which is not cheap; but I guess it did pay off the first
month of its employment because of the benefits one has if
one has access to any level of the design; and, btw, getting
familiar with an alien product won't be much shorter that 3 months.
>There is also far too much logic to build one in a reasonable
>amount of space without resorting to FPGA's or custom or gate
You will be astonished how much you can fit i b, 1000 Sofia, Bulgaria
Email: firstname.lastname@example.org, email@example.com
Phone: 00359/2992/3340, 00359/2/9805997, Fax: 00359/2/9540384