Forum Discussion

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

Cyclone III FPGA set to I/O mode

Hello all,

well i am a bit new to Cyclone III FPGA,

so, the problem i am having is a bit strange. i have made VHDL IP-core, which worked fine previously on my MAX-II CPLD, but now i wanted to run the same IP-Core on my Cyclone III, but i am getting unexpected outputs to some of the IO pins, the real core works fine, but i get unknown or unexpected results over other pins (even if i set all unused pins to tristate in Quartus II). so now i think it would be that my fpga is not configured in Only IO mode or so, and this is the reason i get additional results, so can any one help me in this regard??? or tell me that how can i configure my fpga to only for IO mode.

looking forward for support

13 Replies

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

    It's not clear to me, what you mean with "(only) I/O mode". There are a few dual-purpose pins, that have a dedicated function e.g. for FPGA configuration. If you assign I/O functions to these pins, that are nor compatible with the selected pin configuration, the project won't compile. But you can check the configuration of each pin in the Quartus pinout file.

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

    well on my fpga their are different banks, and now for example i am using a pin 69, has description (IO, PLL1_CLKOUTp) -- or --- pin 39 (IO,VREFB2N0) --- now does this mean that this pin is configured in IO or xxx mode???

    i mean do we have to specify any option to set the pin to IO mode?

    P.S. i am using a cyclone iii EP3C16Q240C
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    --- Quote Start ---

    i mean do we have to specify any option to set the pin to IO mode?

    --- Quote End ---

    No. Just make the right assignments in the pin-assignment window. (assignments > pins).

    Make sure you see the pin list (view > all pins list) and you'll get pin name, direction, location, I/O standard and so on.

    There you can set the proper values. If your settings are not consistent within a bank, you'll get an error.

    Good luck, Ton
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Thanks a-lot for the reply,

    yes i do check these options to pin assignments and they were as you suggested.

    well now i have a strange outcome, but before that let me explain the real scenario i am having, in my design, the Cyclone iii is connected to the x86-platform, a SDRam and to ARM7, and for now i my IPCore is just communicating between x86 and ARM7, and nothing is configured for the SDRAM.

    Now the strange thing is when i program my IPCore on fpga (with option, all unused pins set to tristate), all systems get hanged (x86 and ARM7). BUT when i explicitly give a VCC (1-logic) in quarts-II to the pin-outs of the FPGA (attached to SDRAM) every thing go to normal and my core starts to work, no system hang nothing what so ever... i couldn't understand this behaviour, i just want to make sure, is it some problem with fpga configuration or something else, that i have to force a vcc to unused pins to get my desire output !!!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Well, this is realy difficult to understand without knowledge of the design.

    Are you telling that there are no connections inside the FPGA between the IPcore and the SDRAM pin-outs?

    And that making the SDRAM pin-outs tristate or one has impact on the IPcore?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    yes, inside FPGA i haven't implemented anything for SDRAM, so yet there are only physical connection to SDRAM but nothing related to the core has been developed yet. and as i mention, that i explicitly give a logic-1 to these pins(physically connected to SDRAM) and then all work fine then.

    i mean when there is no logic designed for SDRAM then why it is interfering with the core which is running separately form SDRAM, so the only thing i can think of could be some wrong configuration of FPGA or what???
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    I've never seen or heard of a wrong configuration. Or it configures, or not.

    You could implement an independent counter on some unused pins and check if that one keeps running in both situations. If it is, you may assume that there's nothing wrong with the configuration.

    I'm afraid I can't help you any further.

    Success, Ton
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Setting pins connected to other chips to tristate isn't a good idea, because the pins float to an unknown value, vcc or gnd is even worse, because you have to assure, that no pin is driving out, possibly damaging a FPGA pin by a high short circuit current. You should select either tristate with weak pull-up or hold-circuit for unconfigured pins.

    As said, there's no simple explanation for the observed behaviour. It may be the case, that a floating tri-state pin enabled the connected device in an unexpected way and caused switching noise affecting other parts of the circuit. Also a high current consumption can overload the power supply in this situation.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    --- Quote Start ---

    Setting pins connected to other chips to tristate isn't a good idea, because the pins float to an unknown value, vcc or gnd is even worse, because you have to assure, that no pin is driving out, possibly damaging a FPGA pin by a high short circuit current. You should select either tristate with weak pull-up or hold-circuit for unconfigured pins.

    As said, there's no simple explanation for the observed behaviour. It may be the case, that a floating tri-state pin enabled the connected device in an unexpected way and caused switching noise affecting other parts of the circuit. Also a high current consumption can overload the power supply in this situation.

    --- Quote End ---

    okay, then i will try flashing again without the vcc and tri-state, and set to the option as you suggested, and will update with the results.

    thanks for the support
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    --- Quote Start ---

    Setting pins connected to other chips to tristate isn't a good idea, because the pins float to an unknown value, vcc or gnd is even worse, because you have to assure, that no pin is driving out, possibly damaging a FPGA pin by a high short circuit current. You should select either tristate with weak pull-up or hold-circuit for unconfigured pins.

    As said, there's no simple explanation for the observed behaviour. It may be the case, that a floating tri-state pin enabled the connected device in an unexpected way and caused switching noise affecting other parts of the circuit. Also a high current consumption can overload the power supply in this situation.

    --- Quote End ---

    It Worked :), thanks a-lot for the help.

    as for your interest, i had following findings

    well the output results were the same when set to "tri-state with weak pull-up" (i.e. everything still not working),

    but every thing get normal when i changed it to "as input tristate with bus hold circuit" now the core is working as it should !!!

    thanks,

    regards.