Cyclone II PS configuration problem

Hi Dave,

Look at this document;

http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf (http://www.ovro.caltech.edu/%7edwh/carma_board/fpga_configuration.pdf)

Page 37 has the timing diagram you are interested in, and the following pages have example scope traces (yes, this is for PCI hardware, but the requirements are the same for PCIe).

You need to take the same measurements inside a working PC and a non-working PC.

The main timing parameter your hardware should meet is; the PCIe IP should be ready for BIOS transactions *before* PCIe RST# deasserts. If you cannot meet that timing, then the board will not be visible at first power-on. If the user hits the reset button (no power cycle) or does a restart, then the board will be visible on the PCIe bus, since it will not have to configure the FPGA in that case.

Cheers,

Dave

Dave,

Thanks for the reply. Perhaps I was not clear, the Cyclone II is not making the PCIe interface for that I have a PLX 8311 PCIe to local bus bridge. The PCIe comes up fine, trouble is Cyclone has not loaded so the local bus logic does not operate.

Hi Dave,

--- Quote Start ---

Thanks for the reply. Perhaps I was not clear, the Cyclone II is not making the PCIe interface for that I have a PLX 8311 PCIe to local bus bridge. The PCIe comes up fine, trouble is Cyclone has not loaded so the local bus logic does not operate.

--- Quote End ---

Can you confirm that the Cyclone II has not been configured, rather than its not working correctly?

For example, consider the situation where your reset logic is wrong (just for example). On the old PCs, PCIe RST# might have been asserted long enough that your FPGA configured, saw RST# asserted, and the registers configured to their reset state. Now on the new PCs, lets say PCIe RST# deasserts faster than your Cyclone configuration time, so now the reset state of the FPGA is determined by the default value of the signals in your design. Perhaps those defaults are not correct, and you never noticed before, because each process was initialized by reset. You can test this theory by running a simulation of the Cyclone design without asserting reset at the start of your simulation.

Of course this theory could be completely wrong. Its just one of those cases of "it used to work, but now it doesn't" :)

Your Cyclone logic should also include reset synchronizers to ensure that reset deasserts synchronous to any clocks in the design. For example, if you have a local bus clock and a separate FPGA clock, then those two clock domains should have independent reset synchronizers.

When faced with this type of issue, I typically create a design with a JTAG master, and poke around to see whats working after reset and what is not.

Cheers,

Dave