PCI and interrupts...confusion

Hello, So, I am in the process of working on a new project where we will be using PCI Mezzanine Cards (think normal PCI cards from your PC, except in a smaller form factor) for a small, expandable, embedded system. This system will be running stand-alone (no CompactPCI or other backplane scheme). Just a Processor PMC card running the show, as well as a few add-on PMC cards on a stand-alone carrier card.

I have come up to speed on PCI in general and feel that I understand how the bus is enumerated, how transactions take place, etc. The one thing I don't get yet are the interrupts (Note: I come from the embedded world, so I understand interrupts in the general sense, but not how they apply to PCI).

In all the timing diagrams shown for PCI, you never see any indication of the interrup lines being used (INTA-INTD are available on the PCI bus). The typical (watered-down) transaction goes like this:

0) PCI initiator device asserts its request line 1) PCI system arbiter asserts the initators grant line indicating that it can use the bus 2) PCI initiator puts a 32-bit address onto the bus 3) PCI target device (that has the 32-bit address as part of its memory space) indicates that it is being targetted by asserting the "device select" line 4) PCI initiator starts clocking 32-bits of data on to the data bus 5) PCI initiator asserts the "stop" line synchronous with the last 32-bit data element

...and the transaction is basically complete. At this point, the PCI interface hardware at the PCI target end would now have buffered up the bytes that were sent by the PCI initiator, and the PCI target hardware would then signal to the CPU at the target end that data has been received over PCI, and some device driver would then suck the data up into software-land for processing.

But how does INTA fit into this whole thing? You typically see the INTA line of an non-monarch PCI device (the one that doesn't enumerate the bus and is an interrupt generator) hooked up to one of the INTA through INTD lines on the monarch PCI device (the one that does enumerate the bus and is an interrupt receiver) to allow a direct interrupt from non-monarch to monarch. Does the initiator device not need to generate interrupts at all in the above scenario? This is my leading argument, since I have read that interrupts aren't even required. Is the idea here that a PCI initiator can use interrupts (INTA) to signal to a PCI target if it needs to do some sort of expediated transaction? If so, then does the INTA line get asserted prior to the transaction? This doesn't really make any sense to me, because the CPU shouldn't be interrupted and have to wait while the transaction completes.

I'd appreciate any insight here...thanks for reading!

Regards, John

Reply to
john.orlando
Loading thread data ...

Sounds like you a doing a processor PMC design that supports "Monarch" mode. That in itself makes it confusing. I'd suggest that you step away from your particular design and understand how PCI interrupts work in a standard PC environment. Once you do this, then you can tackle the complexity of Monarch with a basic understanding of how interrupts are supposed to work.

Think of PCI interrupts as wire-or signals. They are open-drain (actively driven low, pulled up by resistors), and level asserted (asserted low and held low until the interrupt condition in the device is cleared).

PCI interrupts are routed to "the cpu" (of course generally via an interrupt controller). They are asserted by the device and serviced by a device driver running on the cpu. Note that I did not use the term "initiator" as that is a missuse of the "intiator" (it applies to bus master devices, not interrupts).

Once you firm up on this level of understanding then make sure you understand the "interrupt swizzle" rules for PCI. Again, start with the PC, then look at the Monarch specific requirements.

There were some differences between interrupt swizzling as implemented by the PC industry vs. PICMG specifications. I don't know enough about Monarch to tell which rules apply. But isn't Monarch a standard for a processor module implemented as a PMC for a CompactPCI Card (which is a PICMG standard)?

Hope this helps. There is an e-mail reflector specific to PCI that is helpful. I think it is run by the DiniGroup these days.

TC

Reply to
TC

We are indeed doing a design with a Processor PMC card as the main "processing" card in the system. Its essentially a small, high-capability, stand-alone embedded system. One of the PMC modules in this system needs to enumerate the bus and act as an interrupt receiver...that is the Processor PMC module.

Ok...so it sounds like you are saying that the PCI transaction itself will get the data from the initiator to the target across the PCI bus, but won't necessarily indicate to the target's CPU (in my case, the monarch) that data has been received. I suppose the target's CPU could somehow be polling on its end to determine if data has been received over the PCI bus, but, of course, interrupts make more sense. I guess in my head, I was thinking that the hardware implementing the PCI interface on the target's end would take care of interrupting the CPU to indicate to it that data has been received. But it sounds like this isn't the case...sounds like the initiator needs to signal to the target that a transaction has been completed, and that data has been transferred.

Our system will maximally have one PrPMC card and up to 3 additional PMC cards all on the same local carrier card. Thus, no PCI-PCI bridges are needed, and my understanding is this is where the whole "interrupt swizzling" comes into play. I could be wrong here though...just some quick googling to figure out what you were referncing.

So...is the above correct? Any of it???

Thanks for the help TC!

John

Reply to
john.orlando

I'm going to guess that you have a CPU running a device driver that is controller some sort of IO device. What you want to understand is how the IO device interrupts the CPU to notify the device driver that an IO operation is complete (i.e. "the data has been received"). If this is the case then I think that some of your confusion is due to a misunderstanding of PCI terminilogy.

Let me try to clarify a few things.

PCI transactions invole a bus master (initiator) and a slave (target). Typical PCI transactions are reads or writes. So the initiator will either read from or write to the target device (at a specifed address). Read or write data will of course flow across the PCI bus. The initator knows explicitly (due to PCI transaction protocol) that the data has succesfully been moved.

Note that when a device driver running on the CPU reads from or writes to the IO device that the CPU is the initiator (master) and the IO device is the target (slave) of the bus transaction. Conversely, if the device has a DMA engine that can read from or write to the CPU's memory then the IO device is the iniator (master) and the memory (processor chipset) is the targer (slave).

So, in the case where a device driver running on the CPU has set up the IO device to complete some IO operation (i.e. read a block from a disk) and wants the IO device to assert an interrupt to notify it that the IO operation is complete, then the PCI interrupt signals come into play.

So there is one additional detail of interrupts that I wasn't clear about. The PCI interrupt signals are "side-band" signals. That is, they are an additional set of wires that are not used during PCI bus transations (i.e. reads and writes). In your case, an assertion of a PCI interrupt will result in your processor being interrupted. Typically, a low level interrupt service routine with determine which device, or devices (if there are mutliple devices that share an interrupt wire) *may* be interrupting and call a device specific interrupt service routine (i.e. the interrupt service routine provided by the device driver).

This device specific interrupt service routine will determine if the device is actually interrupting or not. Typically, this involves reading status from the device. If the device is requesting then the device driver will service the interrupt. In the case of multiple devices sharing an interrupt wire then multiple device drivers may get called due to a single interrupt wire assertion (one or more devices may be requesting service).

You also added in your reply....

You are correct that interrupt swizling TYPICALLY involves PCI-to-PCI bridges. But this is also an area of confusion. Even in the absence of a PCI-to-PCI Bridge you need to be aware of the realtionship between the interrupt pin on device and the INTA#, INTB#, INTC#, and INTD# interrupt signals normally defined as part of a PCI bus. There is a realionship between the IDSEL used to select a device for configuration and the binding of the devices interrupt pin to one of the four interrupt signlals. HOWEVER, if you are doing some implementation specific interrupt routing because the interrupts are entirely implemented on your board then you can make implmentation specific choices about interrupt routing and need not worry about interrupt swizzling.

Hope this helps. You really do need to get the spec and read the relevant sections if you haven't already.

TC

Reply to
TC

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.