Cyclone III stuck at POR?

[Altera_Forum]

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

[Altera_Forum]

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]

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]

--- 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]

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

 Cheers, Dave

[Altera_Forum]

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]

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]

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]

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]

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]

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

[Altera_Forum]

--- Quote Start ---  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.   --- Quote End ---    Are you able to access the device via the JTAG chain?  Cheers, Dave

[Altera_Forum]

No, I can't. 

 If it is held in reset should I be able to access it via JTAG? (I don't know the answer to this and have been searching the handbook for the answer.)

[Altera_Forum]

--- Quote Start ---  No, I can't.  If it is held in reset should I be able to access it via JTAG? (I don't know the answer to this and have been searching the handbook for the answer.)  --- Quote End ---  There isn't a JTAG reset pin, so you should always be able to access the JTAG chain.  Can you try using the JTAG tool from Quartus and toggling TCK, TMS, and reading out the IDCODE. Probe the board with a scope and see if there is appropriate activity on the pins.  For example, if your TDI output from the FPGA back to your USB-Blaster is broken, Quartus will not detect the device, but you should see the TCK/TMS/TDI and TDO pins on the FPGA toggle.  If you cannot get any activity on the TDO pin, then check for shorts. If there isn't one, then that would confirm that the FPGA is not responding to JTAG either.  Cheers, Dave

[Altera_Forum]

That's good to know. I'll try those things. 

 Rick

[Altera_Forum]

Sorry, I have to ask. What is the JTAG tool you are talking about?

[Altera_Forum]

--- Quote Start ---  There isn't a JTAG reset pin, so you should always be able to access the JTAG chain.  --- Quote End ---   At least C III, but I guess other Altera FPGAs too, are actually blocking JTAG access when a reset condition exists, e.g. one of the monitored supply voltages is below it's POR threshold.

[Altera_Forum]

The POR circuit keeps the device in the reset state until the power supply voltage levels have stabilized after device power-up. After device power-up, the device does not release nSTATUS until the required voltages listed in Table 9-4 on page 9-8 are above the POR trip point of the device. 

 For the Cyclone III, voltage that must be powered-up are VCCINT, VCCA, VCCIO (for the banks in which the configuration and JTAG pins reside)  In my application I have the following voltages: VCCINT 1.2 (actual is 1.209) VCCA 2.5 (actual is 2.508) VCCIO 3.3 (actual is 3.255)  So, I believe I have the voltages required.

[Altera_Forum]

Here are what I think are the relevant pages from my schematic.

[Altera_Forum]

--- Quote Start ---  Sorry, I have to ask. What is the JTAG tool you are talking about?  --- Quote End ---    Quartus->Tools->JTAG Chain Debugger

[Altera_Forum]

Downloaded the most recent handbook, in case my copy was too old. 

 VCC specs I saw in the handbook...  VCC must rise monotonically with no plateaus - checked that with a scope. Each individual power supply should reach the recommended operating range within 50 ms - checked that too.