Follow

Been re-reading the PCI specs again, and it seems I was mistaken about PCI needing specialized bus transceivers. Looks like normal 3.3V CMOS logic can drive the bus.

The reason why it's able to run at 33MHz at all is because the spec requires that a bus never exceed 10ns of propagation delay. In other words, instead of allowing a 20" long backplane and requiring screwy logic like BTL, it says, "Nope; limit the length of the bus to 4" and use normal logic."

So how would I get a full-sized backplane? Naively, you cannot (at least, at 33MHz). You'd need to either drop the clock rate to something like 12MHz or you'd need to use multiple, independently running PCI segments and bridge them with active logic. This latter approach is what most full-sized backplanes end up doing.

I should point out that while the multiple-bridged-segments approach increases latency, it doesn't impact throughput. Since PCI is built to handle burst transfers (e.g., cache line fills and spills), this doesn't normally cause any issues.

The more I think about it, the more it seems to make sense to build the around a COTS PCI passive backplane. I see vendors which offer them for around $40 or less for 4-slot boards.

Hmmm...! 🤔

@vertigo Is this about a PCI bridge (like the chipset) or PCI device (like a card?), can you sugget projects with CPU-PCI interface? have a lot of projects for PCI that were abandoned...

@gassahara

Is this about a PCI bridge . . . or PCI device

Yes. From the bus electribal spec's point of view, both a bridge and a device are the same.

can you suggest projects . . .

I'd give this project a shot. The author's English is difficult, and it lacks schematics; but, the page gives enough details to at least get IN and OUT instructions working with a device.

elm-chan.org/works/pci/report_
(found via hackaday website)

@vertigo Thank you very much!, very kind...
elm-chan.org/works/pci/report_ too is from the point of view of the device (board interface with the CPU).
We abandoned such projects for lack of sustainability of the solutions (bridges would be more scarce through time), would love a comeback because, as this project shows is a friendlier interface for tinkerers, is this achievable in FPGA?, or do you recommend the same thing for PCI-e, that one seemed daunting to me, willing to change my mind though =)

@gassahara PCI-e definitely requires at least an FPGA, and a fast one at that. Lattice FPGAs that open source tools currently target might have some difficulty keeping up with the PCIe signalling speeds and voltages. You'd probably want to use a Xilinx or Altera FPGA for PCIe.

Regular PCI and PCI-X should be very easily supported in any FPGA that open source tools can target, provided you have enough I/O pins available. (Regular PCI takes ~ 50 pins, and PCI-X will take about 100 or so).

@vertigo
"..and a fast one at that" That's what I thought, thank you.
"Regular PCI and PCI-X should be..." Thank for the the reply and the recommendation, excellent observation, time to get back on it =)
Thank you for pointing me back to this ideas, excellent reference, a great reflection of what managed micro-blogging (and conscious bloggers like yourself) can achieve!

Sign in to participate in the conversation
hackers.town

A bunch of technomancers in the fediverse. Keep it fairly clean please. This arcology is for all who wash up upon it's digital shore.