Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

Cyclone III stuck at POR?

Hi,

I have problems to get a custom board work, the FPGA seems to be stuck in POR. It's a PCIe card with a EP3C10F256C7N. I attached an excerpt of the schematic to this post.

I have 10 prototype boards, they all show the same problem: nSTATUS is at LOW level and we can't test the boards with JTAG. It's our the second design with a Cyclone III, the first one worked well.

I checked the power supplies, they are well inside the limits. VCCINT is 1.196V, VCCA is 2.497V and VCCIO is 3,282V. I tried to vary VCCA and VCCIO some 0.1V up and down, but without success. VCCIO is sourced directly from the 3.3V of PCIe connector, VCCINT and VCCA are made from this 3.3V with linear regulators. All VCCIO are tied together to the same 3.3V power supply. MSEL[2:0] is set to 010, that should be AS standard POR with 3.3V configuration voltage.

I measured the config and JTAG pins:

nCONFIG: 3.3V

nSTATUS: 0V

CONF_DONE: 0V

nCEO: 0.2V (open?)

DCLK: 3.3V

nCE: 0.9V (?)

nCSO: 3.3V

ASDO: 3.3V

DATA[0]: 3.3V

TDO: 3.3V

TDI: 3.3V

TMS: 3.3V

TCK: 0V

Can nCE or any other config pin hold the device in POR?

The design has migration parts (EP3C5, EP3C16 and EP3C25), therefore I have more VCC and GND pins than required for the EP3C10 connected to the device. I checked all dedicated pins (configuration and power) against a Quartus II 10.1 generated pin list. I compared it with our schematic and with the PCB artwork, but I can't find any mistake. I didn't check all of the I/O connected to the board, but all peripheral devices are powered from 3.3V, so I assume that they're within the I/O limits.

Where is the mistake? What other reason can hold the device in POR?

Regards,

Jürgen

35 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    nCE needs to be low before a device can be configured.

    Try shorting the pin to ground, or figuring out why it is not 0V with the 10K pull-down.

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hello Dave,

    thank you for your reply.

    I shortened nCE to GND, but nSTATUS is still LOW.

    I understand that a faulty nCE can inhibit configuring the device. But can it really hold the device in POR and inhibit JTAG?

    Regards,

    Jürgen
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    I shortened nCE to GND, but nSTATUS is still LOW.

    I understand that a faulty nCE can inhibit configuring the device. But can it really hold the device in POR and inhibit JTAG?

    --- Quote End ---

    I don't know.

    I don't have time right now to look again in detail at your configuration circuit. However, if you wanted to, compare it to this stratix ii design, see p51:

    http://www.ovro.caltech.edu/~dwh/carma_board/gda06rb004_carma_v0.87_dec03.pdf

    Perhaps a difference will stand out to you.

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Also probe your power supplies to make sure they power sequence within the recommended time.

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I think, only nCONFIG=low and a missing supply voltage (from those that are monitored) can hold the device in Reset. You didn't explicitely tell, but I assume that the device also isn't recognized at the JTAG interface?

    P.S.: The FPGA pinning, as shown in the schematic is correct. Using linear voltage regulators powered from 3.3V for 1.2 and 2.5V guarantees a correct power-up sequence.

    I assume, that some optional resistors at the configuration interface aren't populated (e.g. nCONFIG pull-down), otherwise, the above reported measurements won't be plausible. A small detail, that I don't undertand is L3 at the EPCS supply pins without any bypass capacitors.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hello Dave,

    --- Quote Start ---

    Also probe your power supplies to make sure they power sequence within the recommended time.

    --- Quote End ---

    The 1.2V and 2.5V supplies are made from the 3.3V supply by linear regulators. In chapter 10 of the Cyclone III handbook I found this statement:

    --- Quote Start ---

    The Cyclone III device family supports any power-up or

    power down sequence (VCCIO, VCCINT) to simplify system level design.

    --- Quote End ---

    So, power sequencing isn't really a problem, right?

    Regards,

    Jürgen
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hello FvM,

    --- Quote Start ---

    You didn't explicitely tell, but I assume that the device also isn't recognized at the JTAG interface?

    --- Quote End ---

    Right, the device doesn't respond to JTAG commands. This and the LOW nSTATUS pin are the reasons why I assume that the device is stuck in POR.

    --- Quote Start ---

    I assume, that some optional resistors at the configuration interface aren't populated (e.g. nCONFIG pull-down), otherwise, the above reported measurements won't be plausible.

    --- Quote End ---

    The parts marked with "NB" are not populated to the board. But the nCONFIG pull-down is populated, the pin is driven HIGH from outside by a PCIe to local bus bridge. It will pull nCONFIG high as soon it has finished it's initializing sequence that is longer than the FPGA's POR. So, while the FPGA is in POR, nCONFIG will be LOW. Some 100ms later it will be pulled HIGH, and that should start configuration. I did this the same way with a previous design with a Cyclone I. Do you think this should work with the Cyclone II devide, too?

    --- Quote Start ---

    A small detail, that I don't undertand is L3 at the EPCS supply pins without any bypass capacitors.

    --- Quote End ---

    Yes, this is how it's designed. L3 is a small ferrite that should stop EMI. I know it's unusual without a decoupling resistor at the chip's pin, but it was a recommendation from a EMI siminar and it worked well in former designs.

    Regards,

    Jürgen
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I didn't observe similar problems with C III yet, except for a customer, who tried E144 package with floating exposed pad. Regarding unusual "special" configuration circuits, e.g. pulling nCONFIG high, as long as you do't know the exact internal circuit connected to the pins and their operation, I would avoid these. You can place a decoupling diode and revert to the Altera suggested circuit. But you are most likely right, that this isn't the cause of problems.

    I wonder, if the ferrite bead without decoupling capcitor may cause unwanted ripple or even overvoltages on the device side supply node.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hello FvM,

    --- Quote Start ---

    Regarding unusual "special" configuration circuits, e.g. pulling nCONFIG high, as long as you do't know the exact internal circuit connected to the pins and their operation, I would avoid these.

    --- Quote End ---

    Yes, I think that's a good hint. I'll try to simplify the config circuit to be closer to the Altera recommended circuit.

    --- Quote Start ---

    I wonder, if the ferrite bead without decoupling capcitor may cause unwanted ripple or even overvoltages on the device side supply node.

    --- Quote End ---

    The ferrite's resistance is too low to cause such effects. But the ferrite isn't useless, it will kill most of the noise caused by the device. For the EPCS device it's not really needed, beacuse it's only operated during the startup phase and does not cause continous noise. But especially for oscillators the ferrite significant improves EMI compliance. The reason why the decoupling capacitor is placed before the ferrite is that if it's placed directly at the pin, the noise will flow through the capacitor to the ground plane and cause EMI.

    That's how they told me in the EMI seminar, anyway.

    Regards,

    Jürgen
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I'm dealing with the same issue. Cyclone III stuck in POR.

    All rails are present that should be present. Rail timing/sequencing is not an issue per the handbook. It just stays in Reset until all required rails are in the required ranges.

    My nSTATUS line is pulled up with a 10k to 3.3V, but the chip side of the resistor is measuring to be ground.

    I've looked over my design for two days since receiving my new boards. I've checked my pinout in the schematic, checked my pinout in the layout, checked for proper orientation of the chip, checked the part number of the installed chip, checked all voltage rails, etc.

    I can't wait to figure this one out.

    Rick