FPGAs as a PCI (target) controller

I've seen a lot of boards that use FPGAs as a PCI logic core. For example,

formatting link
formatting link
and
formatting link
offer FPGA-devices mounted on a PCI form-factor (with the FPGA-device serving 'double-duty' as the PCI logic interface.)

...

If I need to use an FPGA as a PCI-controller, are there any tricks I should know about? For example, when you 'turn on' a PC, the PCI-reset line is held for some # of cycles, then the PC's BIOS starts scanning the PCI-bus for devices.

After a reset/powerup, will the FPGA configure itself in time?

And what happens if you want to do 'on the fly' FPGA re-configuration? Will that lock-up the PC? (I.e., do the FPGA's I/O-pads go-crazy during the configuration op?)

I apologize for these novice questions. I've been doing a lot of crash-course reading at xilinx.com's website, but perhaps I missed a few appnotes here and there.

Reply to
don
Loading thread data ...

Followup to: By author: don In newsgroup: comp.arch.fpga

Typically not. Instead you need to:

a) generate your own reset *in addition to* the external reset. This can be done with a counter which initializes to 0 and uses the MSB as a negative clock enable; your internal reset is then external RST_n & counter[MSB].

b) follow the predefined protocol for a device which needs to "join the PCI bus late." It basically means don't do anything or respond to anything until you've seen at least one cycle of the bus completely idle (see PCI bus spec for more details.)

Another pitfall (for masters): make sure you implement all the stop conditions correctly. You cannot assume that you can always restart a transfer after a stop; some bridges don't handle crossing certain boundaries so "stop with data" is mandatory.

Most FPGA will tristate the "regular" I/O pads during configuration -- some small number of pads might not (so avoid using those for the PCI bus.) However, your OS might get confused about your device disappearing and reappearing in a resetted state as opposed to how it was configured. It is mostly a matter of how you write your driver -- you should issue the reconfiguration commands, remove the software end of the device from the OS stack, and re-insert it after the device comes back up.

I just did my first FPGA PCI design last year, so this is pretty fresh to me.

-hpa

Reply to
H. Peter Anvin

Hi,

It depends. The amount of time it takes the FPGA to "get ready" depends on how you are configuring the FPGA with its bitstream, and the size of the bitstream. And if that is "in time" depends on what bus interface you are designing.

For example, a 2vp100 configured with slave serial with a CCLK frequency of 1 MHz is going to take a long, long time...

Another example, a 2s50 configured with select map (8-bit parallel) with a CCLK frequency of 50 MHz is going to be fairly quick.

The next question is, "How much time do I have?" The following assumes a system compliant with the PCI 2.3 and/or PCI-X 2.0 specifications.

  • PCI 32-bit design -- about 2^25 bus clock cycles
  • PCI 64-bit design -- about 100 ms
  • Any PCI-X design -- about 100 ms

The reason a 32-bit PCI design has so much more time is that it does not need to be ready to see the busmode/buswidth broadcast which takes place at the rising edge of reset.

No, I have seen some designs on hardware from VCC that do this. However, it requires some context saving -- done by the driver, or done by the hardware, so that when the new configuration is loaded, you are able to "restore" the values in the PCI Configuration Space, such as the Base Address Registers, etc.

Eric

Reply to
Eric Crabill

I'm farrr from an expert, but I built a PCI target in a CPLD a few weeks ago. I thought it was kind of interesting so I wrote it up:

formatting link

That's about $15 worth of parts if you can make it at home.

First you need to google for the "PCI Local Bus Specification" PDF. You will find bootleg copies. The 2.1 I've found is easier to use than 2.2 because it has a working table of contents.

Reset will be low for a long time (for example if you hold down the front panel reset) but it will only be low with a stable CLK for a period defined in the spec.

The biggest pitfall I'm aware of is that many PCI bridge chipsets (and their BIOSes) can and will disable CLK on a slot that does not respond to a configuration cycle at boot. If you can get past that point you can experiment a lot more.

As long as your IO lines are all tristated during reconfiguration and your part comes out of reconfiguration with everything tristated (without needing a PCI RST# which isn't going to be there). I was working with a CPLD so that meant everything was going to default to zeros. As long as my IDLE state was state=0 it worked fine.

If you rely on any config space bits getting set by the BIOS your driver will have to note those and put them back after a reconfiguration. With an FPGA you might be able to modify your bitstream so it comes up with the right settings.

--
Ben Jackson

http://www.ben.com/
Reply to
Ben Jackson

Followup to: By author: snipped-for-privacy@ben.com (Ben Jackson) In newsgroup: comp.arch.fpga

Let me also recommend this book:

formatting link

-hpa

Reply to
H. Peter Anvin

Could I grab the mode/width info with a small amount of external logic? (and pass it to the FPGA when its ready)

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray

Followup to: By author: snipped-for-privacy@suespammers.org (Hal Murray) In newsgroup: comp.arch.fpga

Yes, you'd have to latch REQ64# if you're doing a 64-bit design, and FRAME#, IRDY#, DEVSEL#, STOP# and TRDY# if you're doing a PCI-X design, on the rising edge of RST#.

You'd have to worry about bus loading, though.

Also, all of this apply if you're doing a plugin card. If you know ahead of time what kind of bus you're plugging into, things are a bit different.

-hpa

Reply to
H. Peter Anvin

Hi,

Yes, you can do this. You would need some thing that turns on quick, like a small CPLD? You'd be looking at the RST# line, for certain.

If it's a 64-bit design, you need REQ64#.

If it's a PCI-X design, you need several other signals, detailed in the PCI-X addendum.

I will note that you'll then have two loads on a number of signals, which is a compliance violation.

Eric

Hal Murray wrote:

Reply to
Eric Crabill

Hi,

That is correct, and having two device pins touch one signal is a compliance violation. If you are careful what you do, though, it will work.

Eric

Reply to
Eric Crabill

Sorry for the redundant post. I tried to cancel my first one, after reading the subsequent response but apparently did not succeed! And now, to make matters worse, I've posted this third time...

Eric

Eric Crabill wrote:

Reply to
Eric Crabill

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.