cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
dspulator
Observer
Observer
16,532 Views
Registered: ‎09-19-2011

Output IOSTANDARD = LVCMOS18 but Vcco = 3.3

Jump to solution

I'm an FPGA newbie who has inherited a Spartan 6 design.  I have found where some output pins were spec'd with IOSTANDARD = LVCMOS18 but the actual Vcco of the bank they're in is connected to 3.3 V.  These signals power up inactive occasionally.  Could this be due to the improper logic level spec?  What happens when you use the wrong IOSTANDARD logic level for output pins like this?

 

Thanks,

Gerrit

0 Kudos
1 Solution

Accepted Solutions
avrumw
Expert
Expert
21,627 Views
Registered: ‎01-23-2009

Gerrit,

 

They really don't work that way - the output drivers are pure CMOS output stages - there are no comparators or anything.

 

However, if you want to rule this out, this can be easily fixed in FPGA editor - just load in the NCD files, change the I/O standard for the IOB in question, write out a new NCD file and run bitgen (or I think you can generate a bitfile directly from FPGA editor).

 

But, I am sure that it won't make any difference.

 

Avrum

View solution in original post

0 Kudos
8 Replies
avrumw
Expert
Expert
16,527 Views
Registered: ‎01-23-2009

The LVCMOS standards are all "rail-to-rail" standards with conventional input stages (i.e. non-referenced, non-differential).

 

The output stages pull to VCCO when driving a 1 and to GND when driving a zero. Since your VCCO is 3.3V, these will behave "like" an LVCMOS33 standard, regardless of the fact that they are configured as an LVCMOS18. The only (potential) difference is the drive strength, which may be different in an LVCMOS33 configured pin vs. an LVCMOS18 configured pin (in a VCCO=3.3V banks).

 

Similarly, the input will transition based on VCCO - below some percentage of VCCO it will be recognized as a zero, and above some percentage it will be recognized as a one (and in between it will be unknown). The actual transition point may be subtly different between an LVCMOS18 configured I/O and an LVCMOS33 configured I/O in a 3.3V bank, but not by much (if at all).

 

However, the I/O will definitely function in a very similar manner to an LVCMOS33 configured I/O. Whatever condition you are seeing is almost certainly not caused by this misconfiguration.

 

The only other question is what is connected to the other side of this I/O. If the FPGA pin is an output, can the receiver tolerate a 3.3V input? If it is expecting 1.8V, this can create abnormal currents (the receiver's protection diode will conduct as you get a few hundred milli-volts above the VCCO of the receiver). If the FPGA is an input, the transmitting device may not put out a voltage high enough to be recognized as a one by the FPGA.

 

Avrum

 

Avrum

dspulator
Observer
Observer
16,522 Views
Registered: ‎09-19-2011

Thanks for the quick reply, Avrum.  These are outputs only.  They are driving 3.3 V logic, so the hardware levels are correct.  Output drive strength and slew are fine, too -- these are relatively slow signals.  

 

I wondered if it was possible that internal logic levels are set based on IOSTANDARD but then applied to logic or comparators based on the output bank voltage.  If internal logic switches to 1.8 V because of IOSTANDARD and is applied to, say, comparators with a threshold at 1/2 * 3.3 V, I could have a problem.

 

Gerrit

0 Kudos
avrumw
Expert
Expert
21,628 Views
Registered: ‎01-23-2009

Gerrit,

 

They really don't work that way - the output drivers are pure CMOS output stages - there are no comparators or anything.

 

However, if you want to rule this out, this can be easily fixed in FPGA editor - just load in the NCD files, change the I/O standard for the IOB in question, write out a new NCD file and run bitgen (or I think you can generate a bitfile directly from FPGA editor).

 

But, I am sure that it won't make any difference.

 

Avrum

View solution in original post

0 Kudos
dspulator
Observer
Observer
16,513 Views
Registered: ‎09-19-2011
I've already fixed the IOSTANDARDs using PlanAhead and generated a new .bit file which will be tested on Monday. Thanks for your help!

Gerrit
0 Kudos
dspulator
Observer
Observer
16,488 Views
Registered: ‎09-19-2011

Testing today indicates that a 1.8 V IOSTANDARD voltage spec on output signals does in fact cause them to sometimes fail if they are operated with Vcco = 3.3 V.  Three systems which exhibited the problem no longer do with the proper IOSTANDARD spec.

 

My guess is that internal thresholds or levels are set based on IOSTANDARD, and if they don't match the thresholds set by the actual Vcco there can be a problem.  This is a pretty fuzzy explanation, but I don't know the output buffer structure in the FPGA.

 

Gerrit

0 Kudos
dspulator
Observer
Observer
16,464 Views
Registered: ‎09-19-2011

Sorry, this was wrong -- the systems have started showing failures again.

0 Kudos
mcgett
Xilinx Employee
Xilinx Employee
16,459 Views
Registered: ‎01-03-2008

Looking back over the thread you never said which part you are using.  Can you please let us know which part/package you are using?

 

You are saying that failures are occuring.  Is this with a correct set IOSTANDARD of LVCMOS33 and VCCO of 3.3V?  or some other combination?

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
dspulator
Observer
Observer
16,456 Views
Registered: ‎09-19-2011

I did say it was Spartan 6.  I'm using the XC6SLX16 specifically.  And yes, the latest is that errors are occurring with LVCMOS33 and VCCO of 3.3V.  But this is not the problem, I now know.

 

I just learned that a clock derived from my DCM CLKFX does not start properly when this problem occurs, so the IOSTANDARD vs Vcco discrepancy isn't the problem.  I am working on implementing the DCM resetting scheme from UG382 pg 83 now.

 

Thanks,

Gerrit

 

0 Kudos