Cyclone III FPGA set to I/O mode

[Altera_Forum]

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

[Altera_Forum]

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]

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]

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

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]

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]

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]

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]

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]

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

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

[Altera_Forum]

--- Quote Start ---  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.  --- Quote End ---    Thanks for sharing this, but it still makes me wonder why. Any idea? Frank?  -- Ton

[Altera_Forum]

--- Quote Start ---  Thanks for sharing this, but it still makes me wonder why. Any idea? Frank?  --- Quote End ---   Unfortunately not. I expected the SDRAM to be deactiveted reliably by weak pull-ups. Theer must be something special with the circuit.  The more interesting question is, if the final design will work. Good luck!  Frank

[Altera_Forum]

Hello Again. 

 well after, looking again and again to my design, i come to few conclusions i want to share.  the problem was actually not resolved by changing the configuration to weak pull up or bus-hold.. at that time it worked accidentally as i also made few changes to design as well.. but still at that time it seemed resolved, and working fine, BUT not as in past few dayz i added some more functionality to the design and the problem was back again, which was very annoying..as all my work was stopped because of this problem...  any how.. the final conclusion is important to be notice.. and which is.. that it turned out that i have some unused or un-assigned ports (debug ports, input and output) in my design (in BDF design file) which didnt give any problem in my Altera CPLD training kit, but here in FPGA that was the problem. .. i removed all those test ports, and recompile the design. so everything started to work as it should ...   now finally i can move on with my work :)...