[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: PCI Politics (was RE: why Target cannot change its mind)

> > > I would love to hear an
> > > example of something put into the PCI spec. (or some other
> major industry
> > > spec. I guess) that was put there for the purpose of making
> it difficult
> > > for small companies to compete.
> >
> >PCI is a prime example.  It was specifically designed to require
> an ASIC to
> >interface to.  ASICs cost tens to hundreds of thousands of
> dollars to make,
> >and as such, prohibit small companies from doing them.
> >
> >I wrote, what I believe was, the first PCI implementation in an
> FPGA, which,
> >at the time, was quite a feat...since the FPGAs, without all sorts of
> >tricks, were not very PCI compliant.
> >
> >Obviously, FPGAs, being much more compliant, and with cores, now
> level the
> >playing field to some degree.
> The idea that PCI was made ASIC-centric to keep little companies
> out of the game is a novel, to say the least, idea.

It's a fact that it was 'made ASIC-centric', and certainly as a byproduct,
it is a fact that it keeps little companies out of the game...until FPGAs
were able to sufficiently handle it.


> Do you have any idea of how to get the signaling of PCI
> at 33MHz (make it easy -- ignore 66MHz) to work without the
> ASIC-based drivers we all use?

I have every idea how to get the signaling of PCI at 33MHz.  It is not the
PCI signaling that makes it difficult to be done outside of an ASIC.  It is
some of the cycle to cycle timing.  Initially designing PCI without certain
cycle to cycle timing constraints (basically too much logic between cycles)
would have made a negligible impact on performance.

> The days of just slapping
> some CMOS gates on a connector and whomping up a new
> peripheral board are long gone, my friend.  Where have you
> been?

Where have I been?  Designing (over 50) PCI interfaces since its inception.