Hot-plug/swap and Reset Trhff & Trhfa RE: How to guarantee Trhff for hot-swap

[Lame Brooks-G14738 <brooks.lame@motorola.com>]

	Good question Richard.  Trhff (5clks from RST# hi to first FRAME#)
was not a requirement in PCI 2.1.  I'm not a PCI asic designer, but
revisiting PCI 2.1 section 3.4.2 seems to allude that some PCI state machine
implementations may not be able to reliably track the bus state without some
idle cycle(s) before a FRAME#.  Anybody know more about why this was added
to the 2.2 spec?  BradH?
	Regarding PCI Hot-plug and CompactPCI Hot-swap, the Trhff spec sure
seems to throw a wrench in things.  The hot-plug controller (hardware
connection controller for CPCI) could gate FRAME# to the hot-pluged device
to meet the simple Trhfa requirement.  However, if the real reason for Trhfa
is so the PCI device can sync up with the beginning of a bus transaction,
then simple gating of FRAME# for five clocks won't satisfy that need.  It
seems the only solutions for hot-plug devices is 1) halt all bus activity
while connecting the hot-plugged device, or 2) for hot-plug peripherals, use
only devices that will stay in a holding pattern until a bus idle cycle is
detected and thus don't require Trhff.
	While investigating another hot-swap related issue, I ran into a
needed clarification regarding Trhfa (2^25clks from RST# hi to first config
access-ECN'd into PCI 2.1).  I'll write as it relates to CompactPCI
Hot-swap, but it applies to PCI Hot-plug as well.  In the CompactPCI HS spec
R1.0, section 2.3.1.2 says HEALTHY# indicates a board is suitable to be
released from PCI_RST# (H1 state reached).  Section 2.3.1.3 points out that
boards must not locally come out of Reset until H1 state but that the
backplane PCI_Rst# must also be honored (and therefore, the Trhfa delay
requirement).  ORing HEALTHY# and backplane PCI_RST# for local, on-card Rst#
keeps the card in reset until H1 state is achieved (peripheral is connected
to the bus).  Considering the definition of state H2 in the CPCI HS spec
R1.0, sec 2.2.1, it follows that Trhfa should be the maximum time from state
H1 to state H2.  Further, between H1 and H2, the peripehral should respond
to accesses as described in PCI 2.2, sec 4.3.2 (same as ECN to 2.1) - either
no response, retry, or access accepted and data valid.  
	Comments?
-- BrooksL

> -----Original Message-----
> From: Richard Walter [mailto:rwalter@Brocade.COM]
> Sent: Friday, 30 June, 2000 09:29
> To: 'pci-sig@znyx.com'
> Subject: How to guarantee Trhff for hot-swap
> 
> 
> Folks,
> 
> I'm hoping that someone out there can answer this (potentially) simple
> question.
> 
> How to people guarantee the Trhff requirement in table 4-6, 
> section 4.2.3.2
> in PCI 2.2 when enabling a device during hot insertion?
> 
> Trhff requires that there be a minimum of 5 PCI clocks from 
> the time that
> RESET# is deasserted until the device sees it's first FRAME# 
> going active.
> In a hot-swap environment, a newly inserted card will have it's RESET#
> asserted and then deasserted while potentially other independant PCI
> activity is going on.  How do you guarantee that RESET# won't 
> go away in the
> middle of another transfer, violating the Trhff?
> 
> Thanks
> 
> -Richard Walter
> Hardware Engineer
> Brocade Communications
> rwalter@brocade.com
> Note: I speak for myself, not for Brocade Communications
>