PCI and interrupts...confusion

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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!


Re: PCI and interrupts...confusion
Quoted text here. Click to load it

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

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

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.


Re: PCI and interrupts...confusion
Quoted text here. Click to load it

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.

Quoted text here. Click to load it
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

Quoted text here. Click to load it

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!


Re: PCI and interrupts...confusion

Quoted text here. Click to load it

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

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....

Quoted text here. Click to load it

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.


Site Timeline