Cyclone IV unused input in 3.3V bank tied to +1.2V

[Altera_Forum]

We're using the Cyclone IV EP4CE15 device in a 256-pin package. This package allows migration to the next larger device (EP4CE22), but the larger device has more VCCINT and GND pins. This requires tying a total of 12 pins that are I/O pins on the EP4CE15 to either GND or VCCINT (+1.2V). All of our I/O banks are +3.3V. I'm currently setting unused pins on the EP4CE15 to "tri-state input with weak pull-up", and the device loads and runs fine. But having 3.3V inputs tied to +1.2V has me a little concerned since 1.2V is right in the middle of the invalid zone for 3.3V logic. Will these pins draw any excess current and/or create any extra noise on the device? Is there a better way to leave them post-config than "tri-state input with weak pullup"? 

 Thanks, Bob

[Altera_Forum]

VCCINT are power pins (Not I/O) and must be connected to 1.2V. You can leave unused I/O pins floating as you are doing for EP4CE15. Refer to Cyclone IV Device family pin Connection Guidelines.

[Altera_Forum]

--- Quote Start ---  VCCINT are power pins (Not I/O) and must be connected to 1.2V. You can leave unused I/O pins floating as you are doing for EP4CE15. Refer to Cyclone IV Device family pin Connection Guidelines.  --- Quote End ---    Thanks for the response, Danish, but I don't think you understood my question. Supporting migration between devices does in fact require tying 6 normal I/O pins on the EP4CE15 to +1.2V, because those pins become VCCINT pins on the larger EP4CE22 device. (Another 6 normal I/O pins become GND on the larger device and must be tied to GND on the board.)  My concern is what happens when the EP4CE15 is installed. The 3.3V pins that are tied to +1.2V will become tri-stated inputs with weak internal pullups after configuration, but the +1.2V will overcome the weak pullup so the input to the buffer will be +1.2V. With a normal 3.3V input buffer 1.2V is right in the middle of the transition zone where both the high and low transistors of the totem pole input are conducting, which would draw excessive current. The only way to prevent that would be to isolate the input buffer from the pin, but I don't think there is a switch in the Cyclone IV IOB that can do that.  Can anyone from Altera explain exactly how this works?

[Altera_Forum]

When I have been in this situation with a BGA device, I tie the 6 I/O pins to VCCINT through resistors. This requires that you "borrow" a via from an I/O pad next to the via that needs to be tied to VCCINT, and that you use an 0402 resistor to short the vias together. This placement is really no different than the placement for the decoupling capacitors. 

 Its a little easier to show what I mean with a photo ... scroll down to the photo in Post#9  http://www.alteraforum.com/forum/showthread.php?t=44695  Click on the photo to enlarge it. The blue 0402 components are resistors, while the brown components are decoupling caps.  Faced with a situation where I needed to optionally tie 6 I/O pads to VCCINT, I would give up 12 I/O pads, and "steal" 6 of the BGA breakout vias to tie them to VCCINT (the trace on the top-side of the board to the BGA ball pad would be cut). The PCB assembly BOM would then include the 6 VCCINT shorting resistors if I loaded the BGA device that needed those VCCINT pins.  If you're not quite sure what I am talking about, you can download the PCB design files (Allegro) and take a look at them (there is a free viewer). I don't recall if this specific design needed the VCCINT migration option, but this method would meet your needs.  Cheers, Dave

[Altera_Forum]

Thanks for sharing that solution, Dave. In my situation I'm the FPGA consultant and was not involved in the board design. I was not even aware that Cyclone IV migration required this odd conversion of I/O pins to VCCINT and GND pins until there was a problem bringing up the board due to the selected state for unused pins after configuration. After looking into this I was thinking the way to do this would be to create a separate voltage rail for the 6 migration pins that need to be tied to +1.2V on the larger device. Then have option resistors so that when the smaller device is installed that rail is tied to +3.3V (or left floating), and when the larger device is installed it's tied to +1.2V. But I think I like your approach better. 

 What I would really like to hear from Altera is what the downside is (if any) of just tying those 6 unused I/O pins to +1.2V as they advise. Any extra I/O current drawn on those pins when the smaller device is installed? Any potential for extra input switching noise? As long as those 6 input buffers with VCCIO at +3.3V are seeing the +1.2V input then there must be something happening in there. Starting to look like I may have to open a support ticket to get an official answer, if even then.  A local FAE said he has never seen or heard of any issues with switching noise or excess current draw in Cyclone IV migration situations. Just looking for something a little more official.  Best, Bob

[Altera_Forum]

Having the 3.3V inputs at 1.2V is probably no worse on an FPGA than with any other device. It is a voltage in the switching region, so chances are you will get random input toggles and higher current on those inputs. 

 If you already have a board with the 3.3V I/O tied to 1.2V, create an instance of SignalTap II and capture a long trace of the input values on those pins using say a 100MHz clock (use a PLL if needed).  Run a few tests where you have some noisy circuits nearby. My favorite is a power drill - press the button and place the chuck near your circuit board - if you've got a really crappy drill, you may even see arcing. Heat guns can also be pretty noisy / RFI generators. If the SignalTap II traces are all static high or low, even in the presence of nasty RFI, then you can indicate that the "error" is not terminal, but that the few tests you've performed are not exhaustive, so you would not recommend a production run of these boards.   I am sure you will do this ... as a "consultant" I would appraise the customer of how it should have been done (the VCCIO resistors trick, or your small power segment -> which probably turns out to be a whole layer due to the location of the pins). The customer can the decide whether to implement a board revision. Before they initiate the board revision, you should recommend they use these boards to check out the rest of the functions. For example, is the power system ok, does it support the transients it will expect? How good is the PLL decoupling? Is the JTAG wired correctly (to VCCA not VCCIO)? Given that one mistake was already made (albeit a tricky one to catch), they may as well check for other issues.  Cheers, Dave

[Altera_Forum]

Using SignalTap to snoop those pins is a great idea. And I love the power drill trick. Sounds like you've been doing this stuff for a while, Dave. Thanks for the ideas! 

 Best, Bob

[Altera_Forum]

--- Quote Start ---  Using SignalTap to snoop those pins is a great idea. And I love the power drill trick.    --- Quote End ---   It was a matter of the nearest RFI "test equipment" on hand ... :)    --- Quote Start ---   Sounds like you've been doing this stuff for a while, Dave. Thanks for the ideas!   --- Quote End ---   I have had the "pleasure" of solving my own mistakes for a while :)  Solving problems is actually the fun part of engineering. If everything just worked, then clearly you're not doing anything challenging! I'm sure "consulting" has its fair share of problem solving :)  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  It was a matter of the nearest RFI "test equipment" on hand ... :)  --- Quote End ---   Environmental chambers are great rfi generators too :D

[Altera_Forum]

I'm all in for running tests to see how these pins behave on our board, but the migration methodology comes from Altera so I'm still puzzled why there's no official information flowing from them. Has this situation never been characterized? I seriously doubt that. C'mon, Altera, cough up the goods!!

[Altera_Forum]

--- Quote Start ---  I'm all in for running tests to see how these pins behave on our board, but the migration methodology comes from Altera so I'm still puzzled why there's no official information flowing from them. Has this situation never been characterized? I seriously doubt that. C'mon, Altera, cough up the goods!!  --- Quote End ---    I do recall having to do this analysis in the past ... but I don't recall seeing a warning in the Altera docs. I think I simply found the issue while trying to create a common package for a Cyclone IV device.  Did you try filing a Service Request with Altera? If not, submit one, and post the results back here.  Cheers, Dave

[Altera_Forum]

I opened a SR last Friday but have heard nothing yet. I'll post the results if/when I hear back, and will also post any test results if/when I get to that.