Re: Hands on PCI interface ...
From: TC (noone_at_noplace.com)
Date: 02/05/05
- Next message: R Adsett: "Re: C vs C++ in Embedded Systems?"
- Previous message: Richard H.: "Re: TCP/IP software overhead ?"
- In reply to: Jonathan Kirwan: "Re: Hands on PCI interface ..."
- Next in thread: Nico Coesel: "Re: Hands on PCI interface ..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 05 Feb 2005 04:56:34 GMT
"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message
news:hn280198c28c80j84pegpdt3q2jasjh4jk@4ax.com...
> On Fri, 4 Feb 2005 15:20:35 -0500, Keith Williams <krw@att.bizzzz> wrote:
>
>>In article <ink701dhanogqu5kvljdad31qr36s2fil6@4ax.com>,
>>jkirwan@easystreet.com says...
>>> On Fri, 4 Feb 2005 09:53:19 -0500, Keith Williams <krw@att.bizzzz>
>>> wrote:
>>>
>>> >> The southbridge or PCI-ISA bridge chip can only exist with
>>> >> "side-band" channels
>>> >> to the main chipset.
>>> >
>>> >No side-band channels/signals are needed.
>>>
>>> Why do you say this? It's certainly been true for as long as I've
>>> worked on
>>> these chipsets. That does date back to the P2, but have things changed?
>>> I
>>> doubt it.
>>
>>No sideband signals are in the PCI spec (they wouldn't be
>>"sideband" ;-). Certainly the southbridge and subtractive decoding are
>>covered.
>
> I was involved in chipset testing. One of the prominent examples where
> ISA
> transactions simply cannot be translated to properly formed PCI
> transactions is
> in the case of ISA DMA. There is no correct mapping possible -- the
> timing
> requirements on the ISA side are "hard" and the PCI bus doesn't have the
> needed
> transaction types to fully support ISA-side DMA without the sideband. So
> the
> Intel chipsets all (up to the point where I stopped working with them
> directly,
> anyway) included pins which were simply called "sideband." These pins
> couple
> the southbridge with the main chipset in order to inform it about things
> like
> ISA DMA, which have to be handled through PCI transactions but where the
> timing
> requirements are hard and the chipset needs to support them. This was
> necessary
> as PCI transactions had to be "twisted" a bit to make this work.
>
> This is what I mean by sideband -- these out-of-band communications
> between the
> southbridge and the main chipset for support of things like ISA DMA
> timing.
>
> It was these sideband channels that accounted for about 1/2 of all chipset
> bugs,
> so I know these sidebands exist. Plus, of course, I had to read the data
> sheets
> and understand things like the inbound and outbound queuing, read around
> writes,
> and a host of things regarding testing the chipsets with FPGA boards on
> both
> sides of the southbridge, trying to break it.
>
> Like I said, things may have changed. It's possible that I'd barely
> recognize
> the PCI, today (though I doubt things have changed that much.) But I
> don't yet
> see how ISA DMA timing, for one example, can be maintained exclusively
> through
> standard PCI transactions and without any "extra communication" to the
> chipset.
>
> I'm not saying that a reduced ISA wouldn't work -- it would. But there
> are a
> few bits of non-overlapping semantics between ISA and PCI. And these are
> usually handled by the sideband channel. I can assure you that if Intel
> could
> have gotten rid of it, they would have clawed and screamed to do so. It
> was a
> sink of engineering labor they would have been glad to be rid of.
>
> Jon
The problem is a direct result of ordering rules. PCI (and basically all IO
buses) rely on certain ordering rules. Specific rules that apply in this
case are:
strong write ordering
- posted writes must arrive in order
- reads must flush writes (a read request must push posted writes ahead of
it (towards the target being read), and read completion (i.e. the read data)
must push posted writes ahead of it (toward the requestor of the read data)
deadlock avoidance
- writes must be able to pass requests (for example, read requests)
PCI has a retry mechanism for transactions and ISA does not. Once an ISA
device initiates a transaction there is no mechanism to get the master to
realease the bus until the transaction completes. The master can be held it
wait states, but you can't tell it to retry.
So, take the following scenario...
- the host has a posted write transaction heading towards the ISA bus (i.e.
it is temporarily stored in the chipset because the PCI bus was busy)
- the ISA bus is granted to a bus mastering device and the device intiates a
read of host memory
Without sideband signals, you have a deadlock condition. The read data being
returned the ISA bus master cannot be returned to the ISA bus before the
posted write that were buffered in the chipset. But, the posted write cannot
be delivered to the ISA bus because it is busy (the master is being held in
wait states waiting for the read data to be returned).
The sideband signals are used to make sure that the posted write buffers in
the chipset are flushed (empty) before an ISA bus master is granted the bus.
So, if you are implementing an ISA target device this isn't a problem (you
don't have an ISA bus master device).
These "sideband" signals are not documented in the PCI specifications. They
are chipset implementation specific signals and are private to the
motherboard.
TC
-
- Next message: R Adsett: "Re: C vs C++ in Embedded Systems?"
- Previous message: Richard H.: "Re: TCP/IP software overhead ?"
- In reply to: Jonathan Kirwan: "Re: Hands on PCI interface ..."
- Next in thread: Nico Coesel: "Re: Hands on PCI interface ..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]