What is the suitable Voltage level for clock input? Vccio , Vccd_pll ?

Since the clock, switch, and push-buttons are all inputs to the 1.8V powered bank, what you need to confirm is that this will not damage the I/O cell.

The logic levels will still be interpreted correctly, since 0V will be a low, and anything above 1.8V will be a high.

So lets look at the Cyclone IV Handbook:

http://www.altera.com/literature/lit-cyclone-iv.jsp

Look at "I/O Standards" on p117, "Table 6–3. Cyclone IV Devices Supported I/O Standards and Constraints".

Look at "I/O Standard Specifications" on p458, "Table 1–15. Single-Ended I/O Standard Specifications for Cyclone IV Devices"

This table indicates that Vin(max) = 2.25, when VCCIO = 1.8V. Based on this, I would not drive a 2.5V signal onto a 1.8V bank.

Note however that "Table 1–2. Maximum Allowed Overshoot During Transitions over a 10-Year Time Frame for Cyclone IV Devices" on p449 implies that the I/O pins are actually 4.2V tolerant (100% duty cycle), so if you did drive the pin with 2.5V, it should not cause damage.

Personally, I prefer to be conservative and would stay within the logic level limits imposed in Table 1–15. Texas Instruments and Fairchild have lots of dual-supply buffers that make it easy to interface 2.5V or 3.3V signals into a 1.8V FPGA bank.

Cheers,

Dave

I have to agree with Dave's final sentiment. I would not recommend driving signals of 2.5V amplitude into an I/O bank powered at 1.8V. Generally, this would be considered bad practice.

However, Cyclone IV is a very resilient device family. As such is has been designed to withstand voltages on pins prior to the device being powered - hot-plugging. The device may well not have power to a particular I/O bank before active signals are presented to I/O pins in that bank. The handbook does state the device can handle over 4V on I/O pins.

Having said that, I repeat, it is not good practice to over drive I/O pins on any device and I would recommend you condition the signal appropriately for the particular bank that the I/O pin resides in. Over driving the pin will result in the device dumping the excess power through its protection circuitry whenever the input voltage exceeds the voltage of the I/O bank. If you do wish to do this ensure you use a suitably high value in-line resistor (ensuring the signal's source impedance isn't too low) limiting the current the protection circuitry has to handle.

If you don't wish to condition the signal you can always drive it into a different I/O bank whose voltage is better suited - e.g. 2.5V.

Thank you very much for your answer,already I have it clearly, but i have a query, it's a alittle bit out of topic, the FPGA that I using is EP4CE75F23C8, it's the comercial applicaion, but if i decide change to EP4CE75F23I8 (industrial application), change the pins position or only changes thermal characteristics?

Thanks

--- Quote Start ---

Note however that "Table 1–2. Maximum Allowed Overshoot During Transitions over a 10-Year Time Frame for Cyclone IV Devices" on p449 implies that the I/O pins are actually 4.2V tolerant (100% duty cycle), so if you did drive the pin with 2.5V, it should not cause damage.

Personally, I prefer to be conservative and would stay within the logic level limits imposed in Table 1–15. Texas Instruments and Fairchild have lots of dual-supply buffers that make it easy to interface 2.5V or 3.3V signals into a 1.8V FPGA bank.

--- Quote End ---

Instead of maximum ratings and allowed overshoot, we would primary refer to Table 1–3. recommended operating conditions for cyclone iv e devices , which specifies 3.6 V maximum input voltage independent of VCCIO.

It should be also noted that previous FPGA families, e.g. Cyclone II had been advertised with a MultiVolt-I/O feature, allowing e.g. to feed 3.3V input level to a 1.5V bank. It's not completely clear what motivates the Vih,max specifications in table 1-15.

Interestingly, the Cyclone V datasheet releases Vih,max for the 2.5V IO-standard to 3.6V again. Does this involve a hardware change? I guess it's just arbitrary.