This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Question on Asynchronous PCI bridge PCI2060

I'm migrating a design from a Pericom PI7C8152B to the PCI2060I bridge for an industrial temperature application.  My system uses the bridge so that the secondary side, which runs from a 33-MHz fixed-frequency oscillator, does not slow down the system when plugged into a 66 MHz primary side bus.  The Pericom chip had a somewhat different clocking scheme and I want to be sure I get it right when I do the re-spin.


In the Pericom part, I needed to use a clock distribution buffer to run the clock from my oscillator to each secondary load and the bridge's S_CLK input pin.  It did not have a separate SEC_ASYNC_CLK input like the PCI2060I.  If I understand it correctly, the PCI2060I should be able to take the oscillator signal (3.3V CMOS) and then all I need to do is configure SEC_ASYNC_RATE high, S_ASYNC_SEL high, and I can use the secondary clocks in the typical fashion of a synchronous bridge, i.e. S_CLKOUT9 looped to S_CLK and other S_CLKOUTx pins to secondary loads.

Is this correct?  Are there any other gotcha's that might prevent the use of this bridge with a fixed 33 MHz secondary clock?  And in this mode, does it matter what I do with the S_M66ENA pin?

  • Hello,

    Not exactly, 

    If SEC_ASYNC_SEL is low then the output clocks S_CLKOUTx will be generated from P_CLK.

    If SEC_ASYNC_SEL is high, then you will have to provide a clock signal to SEC_ASYNC_CLK and that clock will generate the S_CLKOUTx outputs.

    Either way you have to connect S_CLKOUT9 to S_CLK for synchronization.

    Regarding the S_M66EN for 33MHz, it depends on the state of terminal CONFIG66, please see Table 3-9 for more information.

    Regards.

  • Thanks for the info.  I should have been more clear when I said "take the oscillator signal" I meant on the SEC_ASYNC_CLK input.


    If I read Table 3-9 correctly, I should pull down the S_M66ENA pin because the secondary side will always run at 33 MHz.  However I just wanted to make sure that this did not somehow force a divide by 2 of the async clock input, since I will be supplying 33 MHz from the oscillator and not 66 MHz as shown in the examples of Table 3-11.  My guess is that I am correct in assuming that only the SEC_ASYNC_RATE pin controls the clock divider, but I wanted to be sure.

    My typical usage would then be:

    SEC_ASYNC_SEL = 1

    SEC_ASYNC_RATE = 1

    SEC_ASYNC_CLK = 33 MHz

    P_CLK = 66 MHz

    CONFIG66 = 1

    P_M66ENA = 1

    S_M66ENA = 0

    Does this make sense?  The primary side should also work when plugged into a 33 MHz bus, and in that case P_M66ENA would be 0.

  • Hello,

    You are correct on all your assumptions.

    Regards.

  • I have one further question.  In the strapping I listed above, when will the secondary clocks start running?  MASK_IN will be tied low.  Do the clocks start up immediately when the input oscillator signal at SEC_ASYNC_CLK is running?  Do they start up only after P_RST# goes high?  The reason I ask is that some of the clock loads will not be PCI-related.  They just use the 33 MHz as a clock source.  So I need to know if I can rely on the 33 MHz being there during system start-up or if I need another clock source until PCI has come out of reset.

  • Hello,

    The clocks will start only after P_RST# has been de-asserted.

    Regards.