Forum Discussion

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

EP4CE15 powers on to user IO pins at HIGH and not HIGH-Z

Hello,

I am experiencing some issues with an EP4CE15 at reset (and power on) setting its pins to HIGH (1.7 - 1.8V) instead of HIGH-Z. I very strongly believe that there is no short in the board, even user IO pins that go to vias that ultimately aren't connected to anything but the via also experience this issue. Also, the user IO pins do not go to 0V during JTAG programming, however once an image is loaded the pins do go to their appropriate levels; unused pins apparently go to 0 or HIGH-Z, I can't tell with a multimeter.

The only suspicious thing about my simple design is that the symbol and footprint accommodate both the Cyclone 4 E 15KLE and 115KLE packages. When creating the symbol and respective footprint for this package I used the pin migration wizard in Quartus. The wizard suggested that in order to have a symbol that works with both the 15KLE and 115KLE parts I should designate a pin as a power pin if either or both of the devices use that pin as a power pin. For example, on the EP4CE15 Pin V7 is user IO, however on the EP4CE115 Pin V7 is VCCINT, in this case the Wizard indicated that I should regard Pin V7 as VCCINT. This means that on a board that is populated with an EP4CE15, some user IO pins are tied to VCCINT and GND. In my case I have boards populated with EP4CE15s, so there are a total of 39 user IO pins tied to VCCINT and 40 user IO pins tied to GND.

The exact part number is EP4CE15F23C6N, and it's in an F484 pacakge. Is this designed feasible? Could this be damaging the IO buffers? And mostly importantly could this be responsible for my pins resetting to HIGH-Z? Could there be any other explanation for what is occurring?

Any help, ideas, and suggestions are greatly appreciated.

Thank you

3 Replies

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

    Having I/O pins connected to VCCIO and GND is fine, so long as you never drive those I/Os to a logic level that conflicts with the power rail you have connected it to.

    You'd want to make sure you define the unused pins as inputs. Assignments->Device, Device and Pin Options, Category: Unused Pins, "As Input Tri-stated". There's a setting there for "As Input Tri-stated with weak pull-up". It would also be fine to use.

    Alternatively, you can define all of those pins in your top-level HDL as inputs. That way they are always explicitly defined.

    The Cyclone IV Handbook (CYIV-5V1-1.7) p266 has the section

    --- Quote Start ---

    i/o pins remain tri-stated during power-up

    The output buffers of Cyclone IV devices are turned off during system power up or

    power down. Cyclone IV devices do not drive out until the device is configured and

    working in recommended operating conditions. The I/O pins are tri-stated until the

    device enters user mode.

    --- Quote End ---

    Which is inconsistent with your observations. Try adding a pull-down to a signal and see if it gets pulled down during power-on. Drive it high in the configuration. Monitor the CONF_DONE signal. The signal that you have a pull-down on and drive high in HDL should be low until after CONF_DONE asserts (it should be low until INIT_DONE asserts).

    Cheers,

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

    Ah, thanks for the reassurance and suggestions!

    Adding an external 12Kohm pulldown resistor to any user IO pins makes it hover at around 0.375V which is down from 1.641V; even though VCCIO is at a solid 1.8V. Solving for the unknown resistance in the device yields an internal pull up of 40Kohm. According to Table 1-12 on page 1-11 of the Cyclone 4 handbook that appears to be close to the nominal internal weak pullup resistance value.

    Interestingly enough, if I set the same VCCIO banks to 3.3V, the user IO pins hover at around 3.111V and go down to 1.41V when I add the 12Kohm pulldown. This yields 14.4K for the internal pullup resistance, which is on the low side but still acceptable for R_PU at VCCIO=3.3V.

    It seems almost as if every user IO is being powered by internal weak pull-up resistors. The device does this as soon as it is booted and without any configuration loaded.

    Lastly, there are a few LEDs attached to the C4 that light up very brightly when a configuration that tells them to light up is loaded. However, before the device is configure, the LEDs light up just barely. Every VCCIO is set to 3.3V for the entire duration of the test. This again makes it seem like the internal pullups are powering the device at reset.

    Quick edit: the device and all of its user IO pins seem to work perfectly once the device is configured.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Search the PDF for "pull-up", and you'll see:

    p109: Figure 6-1 - the pull-up has a programmable switch.

    p170: "The user I/O pins and dual-purpose I/O pins have weak pull-up resistors, which are always enabled (after POR) before and during configuration."

    p457: Table 1–12. Internal Weak Pull-Up and Weak Pull-Down Resistor Values for Cyclone IV Devices, RPU = "Value of the I/O pin pull-up resistor

    before and during configuration, as well as user mode if you enable the programmable pull-up resistor option."

    So there is your answer.

    Cheers,

    Dave