[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Non-burst accesses
Thanks for all the replies on this issue.
I implemented a disconnect, however I noticed that the core I'm using does a
disconnect without data on writes and a disconnect with data on reads (the
core allows only one method to signal a disconnect from the back end). As
far as I can tell this is OK however please comment if you see any issues
From: Kevin Brace [mailto:firstname.lastname@example.org]
Sent: Sunday, October 20, 2002 12:05 PM
Subject: Re: Non-burst accesses
I personally will never assume that all I/O cycles will be a single
However, the specification (Rev. 2.2) isn't too clear about it.
So, the safest way to deal with the problem is to signal Disconnect with
Data (STOP# asserted simultaneously when TRDY# is being asserted.) when
dealing with all I/O cycles.
There is no side effect to signaling Disconnect with Data even when the I/O
cycle was a single transfer.
If the transaction indeed happened to be a burst I/O cycle, after signaling
Disconnect with Data, you will then transition the target state machine to a
Although the treatment of a burst I/O cycle isn't too clear in the
specification, it does say that a burst configuration cycle is allowed.
In fact, I heard that Intel 430FX chipset (Released back in 1995) can
initiate a burst configuration cycle.
Again, if your PCI IP core isn't capable of handling a burst configuration
cycle, signal Disconnect with Data when receiving/sending data.
Other than that, you should be aware of the following caveats when
developing a PCI IP core.
* All PCI devices must be able to handle Fast Back-to-Back cycles to
"itself" regardless of the state of Command Register's Fast Back-to-Back
* The target state machine must have a "Bus Busy" state to ignore a
transaction not intended for itself (It must not remain within an "Idle"
state during the transaction for someone else.).
* Some chipsets (i.e., SiS chipsets) do insert wait states during the first
data phase (Initiator remaining at FRAME# = 'L' and IRDY# = 'H' for multiple
cycles after the address phase.). PCI Rev. 2.2 specification 3.5.2 Master
Data Latency says this is legal. You may want to make sure your PCI device
works correctly under such condition.
Kevin Brace (In general, don't respond to me directly, and respond within
the mailing list.)
>From: "Alex Horvath" <email@example.com>
>Subject: Non-burst accesses
>Date: Fri, 18 Oct 2002 16:23:33 -0700
>I'm designing an interface to a PCI target core and I have several 32 bit
>registers that I have mapped in the I/O space. These registers can only be
>written/read via single accesses (no burst).
>While simulating my PCI environment I was unable to generate a single word
>read. Although this seems to be a limitation of the simulator master model,
>I am wondering if it is possible to guarantee that a master will never
>attempt to burst from an I/O location. This would imply that accesses to a
>particular I/O location would always be master terminated after the first
>In general is it necessary to provide a method for target disconnect on
>registers which cannot be accessed as part of a burst?
Broadband? Dial-up? Get reliable MSN Internet Access.