Re: Control signal driving question

["Kevin Brace" <kevinbraceusenet@hotmail.com>]

>From: wen-king@myri.com
>To: pci-sig@znyx.com
>Subject: Control signal driving question
>Date: Thu, 5 Sep 2002 12:11:25 -0700 (PDT)
>
>I have a question about the timing of output enables for the pads
>connected to the control signals of the PCI bus.  In a bus cycle
>where my PCI component has control of over a control signal, say
>the STOP_ signal during a cycle when my component is the target,
>do I have to keep the pad enabled the whole time?
>
>That is,
>
>1) If I will never assert STOP_, do I have to bother with its
>    output enable at all?
>


        In my opinion, all target devices must drive STOP#, and here is why.
While you might think Configuration cycles are always a single transfer 
because the figures in various publications (PCI specification, PCI Hardware 
& Software, and PCI System Architecture.) that show a Configuration Cycle 
are most of the time a single transfer, but I heard that Intel 430FX chipset 
(Triton chipset) does initiate a burst Configuration cycle.
Indeed what 430FX chipset does is legal because PCI Specification Revision 
2.2  3.2.2.3.4. does say that a burst Configuration cycle is allowed, and 
linear burst increment of the address is assumed. (Note: 430FX was released 
back in 1995. I believe it was PCI 2.0 compliant.)
So, if your target device's Configuration Register block is not capable of 
handling a burst Configuration Cycle, your target device must always end the 
transaction by signaling Disconnect with data. (Assert STOP# simultaneously 
when the target asserts TRDY#.)
Since making your device's Configuration register block capable of handling 
a burst Configuration cycle is probably not worth the effort considering 
that Configuration cycles don't usually impact the performance that much, 
the simplest way to deal with it will be to signal Disconnect with data.
I won't also assume that a burst I/O cycle can never happen, so when dealing 
with I/O cycles, you should also make sure that the target signals 
Disconnect with data.




>2) If I do assert STOP_, do I have to actively drive a 1 onto
>    the bus line prior to the time I start to assert STOP_?
>


        No, you can simultaneously assert STOP# (STOP# = L) and drive STOP# 
at the same time.
In fact, initiators always assert FRAME# and start driving FRAME# when 
initiating a transfer.




>3) If I do assert FRAME_ (STOP_ is a bad example in this case),
>    do I have to keep driving 1 onto that bus line after I have
>    driven it to 1 for one clock cycle?
>


        The PCI Specification Rev. 2.2  3.2.4. says that FRAME# uses an idle 
cycle as its turnaround cycle.
However, in reality, you will turn off the driving of FRAME# on the clock 
cycle when you detect,

(Internal_FRAME# = 1 ) & [(TRDY# = 0) | (STOP# = 0)]

or,

(Internal_FRAME# = 1 ) & (DEVSEL#_Timer = 4) & (DEVSEL# = 1)

or,

(Internal_FRAME# = 1 ) & (DEVSEL#_Timeout_Already_Detected = 1)



         I personally think, your FRAME#'s OE control logic will be cleaner 
if you stop driving it when one of the above conditions are met, rather than 
stop driving it one clock cycle after FRAME# is deasserted.



>I am trying to simplify my logic, and all my EE background tells me
>it is OK to turn off the output enable when a control signal is
>in the '1' state, as there are pull up resistors to keep it from
>drifting when nobody is driving.
>


        True, the on-board weak pull up resistor will keep the FRAME# high 
as long as FRAME# was tri-stated when FRAME# was high, but since the PCI 
specification says you should use an idle cycle as its turnaround cycle, you 
should be obeying the specification.



>The spec doesn't seems to say explicitly if it is OK or not, although
>the appendix B state machine seems to imply the output enables are to
>be asserted for the whole time.
>
>
>							- Wen


        Again, because a burst Configuration cycle can occur, you should 
always drive STOP#, and signal Disconnect with data if the Configuration 
register block is not capable of handling a burst Configuration cycle.
        Speaking of simplifying your design, you should be aware that "all" 
PCI devices are expected to be able to handle back-to-back transactions to 
itself regardless of the state of Command Register's Fast Back-to-Back 
Enable bit. (Configuration register 04H bit 9)
I don't believe there are too many PCI devices out there that actually 
perform back-to-back transactions, but according to their datasheets, VIA 
Apollo VP2 chipset, VIA Apollo MVP3 chipset, and AMD-640 chipset are capable 
of initiating back-to-back transactions.
Other newer VIA chipsets might be capable of initiating back-to-back 
transactions, too.



Kevin Brace (In general, don't respond to me directly, and respond within 
the mailing list.)

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com