PCI Bus layout for "on board" design.

PCI bus.

embedded board.

PCI signals,

be on the

the 60-100

didn't

PCI should not be terminated! The nodes on the bus shouldn't be too far away from the bus itself. (Read the PCI specs). I guess if you pretend you are routing each device as if it where on a PCI card (in other words: maximum and minimum length of traces in respect to the bus) you'll be fine.

that bus ?

busses ...

Don't share any PCI signal with other busses.

Ok, thanks.

that bus ?

busses ...

Well, I didn't design the CPU I'm using ... Mostly the AD[31:0] is shared ( other lines are not ).

Sylvaint

Could you elaborate on the shared pin thing? That doesn't sound right at all. And 20 inches sounds a tad long, but I imagine it will work OK. Maybe you should take (or "have," if you are British) a look at the PCI spec.

Your basic topology seems right.

What are you doing for a clock? You should probably route separate clocks to each device, and match lengths on the clock traces.

I don't remember, but I think that PCI requires pullups on some or all lines. Don't forget them if applicable. I am assuming this is 32-bit, 33 MHz PCI?

--Mac

Well yes that doesnt sound right but ... The CPU I use shares the AD[31:0] line between the PCI and other busses (like it's local bus where the flash is). The other control signals ( for PCI : pci_clk, irdy, ... or for local bus CE, WE, .... ) are separate.

In the datasheet they claim the drivers for AD[31:0] is of type PCI_33 but when I look at the IBIS model, it seems to drive the line a bit high compared to what a "true" pci driver should do. But in the simulation, that looks the same more or less ( doesn't look pretty IMHO, 800mv over/undershoot ??? for a simple point to point line at 33 Mhz)

The other "devices" I have on that bus are : Some flash and a level switcher 3.3v/5v for a ATA bus. When theses other bus are accessed, the cpu keeps frame# deasserted so the other pci device don't care what happens and refuses any req#.

Well, 20inch was a little pessimistic ... It should be more like between 10 and 15 inch (from pad to pad)

I have read the specs but it's not always very clear to me. I'll try to reread them more closely.

That's a start ;)

I was thinking to route clock as any other trace, just a litte further away than the others. My PCI host just have one PCI clk output.

Yes, control lines requires pullups, other lines stability is assured by bus parking.

Yes I didn't mention it but it's that in 3.3v signalling ;)

Sylvain

Ah, OK. I guess that is OK, then, as long as the arbiter won't grant the bus to anybody. We just have to hope that the CPU doesn't starve the devices out. But if this is a real CPU that other people are using successfully, then we have to assume it works reasonably well.

Hmmm. How many devices do you have? In all the PCI designs I have seen, each device gets a separate copies of the PCI clock. This includes designs such as yours where all the devices are "on-board."

Also, the loading the devices put on the clock is constrained by the PCI specification, so it seems like the specification considers the clock to be critical. So, if you have more than two devices on the clock, then I think you need to buffer it to be safe. You have to use a buffer with a PLL in it. (Or a separate PLL with a buffer in the loop) These are sometimes called zero delay buffers or ZDB's.

Here is one chip that might suit your application, depending on how many devices you have:

The cy2305, a "zero delay buffer" from cypress semiconductor.

Digikey stocks it. The digikey part number is: 428-1347-ND

Good luck!

--Mac

I have at least 4 pci devices so I'll use a zero delay buffer as you suggested then.

Many Thanks,

Sylvain