Unused CPLD Pins

[Altera_Forum]

I have two CPLDs on my PCB that connect to a common SPI bus. In order to keep things simple I'm trying to talk to only one of the chips at first but I'm having some trouble with the voltages which lead me to think that there is some sort of bus contention on the SPI bus. Here's a schematic: 

 http://i.imgur.com/FHZkb.png   The issue is that the MISO_Driver pin only goes upto 2.5V. The pin then goes to a 22 Ohm resistor and then a non-inverting logic buffer. There is a 0.9V drop on the resistor and hence the buffer only sees 1.6V or so. Which leads me to believe that there's a 40mA draw from the CPLD - this has surely damaged the chip! Fortunately, I have a few spares.  Now, the MISO_Receiver pin is unused and my Quartus is setting unused pins to "as outputs driving ground". With my limited experience with CPLDs, my best guess is that this is causing bus contention. Am I correct?  I know that MISO_SD is not causing problems because I don't have a SD Card connected to that pin at all. As there's no card, that point is definitely at Hi-Z.  Do I need to set unused pins to "Inputs with weak pull-ups" in order to solve this issue? (I would just try it but I just came home from work and won't get the chance till tomorrow).

[Altera_Forum]

The problem can't be clearly understood from your schematic snippet, there's e.g. no 22 ohm resistor, so it's unclear which pin you're exactly talking about.  

But input with weak pull-up is the better setting for unused pins, particular if there's a small chance that they may be ever driven by external signals.

[Altera_Forum]

Oh, I'm so sorry. Long day at work! Yes, there's no 22 Ohm resistor. The schematic is slightly out-dated. I AM using 22 Ohm resistors in place of 100. Considering that, do you think it's bus contention? 

 What does "output driving ground" really mean? Does it imply that the pin is LOW?  Secondly, when I choose "tri-stated but with weak pull up", are the pull-ups internal to the chip or am I supposed to connect them?

[Altera_Forum]

--- Quote Start ---  Oh, I'm so sorry. Long day at work! Yes, there's no 22 Ohm resistor. The schematic is slightly out-dated. I AM using 22 Ohm resistors in place of 100. Considering that, do you think it's bus contention?  --- Quote End ---  Now you will understand the beauty of having a resistor in your signal path ... remove it, and toggle the source signal, it should be 3.3V logic levels. Probe the destination signal, what voltage is it? Wire things back together, using a larger resistor to protect your circuit, and continue debugging.  Look at the package diagram for the CPLD. Is your bad signal on a pin next to a power rail? Perhaps you have a short between the destination signal and a power pin next to it.  Keep in mind that debugging is the fun part, its where you really learn how things work.  Cheers, Dave

[Altera_Forum]

Hi Dave, 

 Will remove the resistor and check those. However, considering the short between that and Vcc - no such thing. I checked that multiple times.  What thoughts do you have regarding the bus-contention I spoke of? MISO_Receiver is unused and so set to "output as driving ground" - I am guessing this means it's set to LOW. If that's the case, then surely two signals are trying to driving Pin 1 of the Buffer and this is causing problems. Perhaps this is why the pin is never gets to 3.3V because the other pin isn't Hi-Z.  Would appreciate your thoughts on this.

[Altera_Forum]

--- Quote Start ---   What thoughts do you have regarding the bus-contention I spoke of? MISO_Receiver is unused and so set to "output as driving ground" - I am guessing this means it's set to LOW. If that's the case, then surely two signals are trying to driving Pin 1 of the Buffer and this is causing problems. Perhaps this is why the pin is never gets to 3.3V because the other pin isn't Hi-Z.  Would appreciate your thoughts on this.  --- Quote End ---  You definitely do not want to have that setting. It should be set to "As input".  My Tcl synthesis scripts always have this setting:  # Tri-state unused pins# set_global_assignment -name RESERVE_ALL_UNUSED_PINS_WEAK_PULLUP "AS INPUT TRI-STATED" set_global_assignment -name RESERVE_ALL_UNUSED_PINS_WEAK_PULLUP "AS INPUT TRI-STATED WITH WEAK PULL-UP" and I uncomment the line I want.  If you're using a new CPLD, then the default setting should be as input. Did you change it?  Cheers, Dave

[Altera_Forum]

--- Quote Start ---   If you're using a new CPLD, then the default setting should be as input. Did you change it?  Cheers, Dave  --- Quote End ---    I did not change it, actually. Until recently, I didn't even know how to change it. In the compilation log I always noticed that Qaurtus was warning me that all unused pins were set to as outputs driving ground. Does this mean that they are basically an output set to low?

[Altera_Forum]

--- Quote Start ---  I did not change it, actually.   --- Quote End ---  Which device are you using?  The setting is under:  Assignments->Device, Device and Pin Options button, Unused Pins  (which can be a tab or selection menu depending on Quartus version).    --- Quote Start ---   Does this mean that they are basically an output set to low?  --- Quote End ---  Yep.   Its a stupid default, which has been changed to a sane value for newer devices.  This is why I always define a top-level entity with every signal pin defined. Then the unused pins really are unused and the unused pin setting is of no consequence.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  Which device are you using?  The setting is under:  Assignments->Device, Device and Pin Options button, Unused Pins  (which can be a tab or selection menu depending on Quartus version).   --- Quote End ---    Yep. Just changed it and the warning disappeared. The devices are Max V 5M240ZT100.    --- Quote Start ---   Yep.   Its a stupid default, which has been changed to a sane value for newer devices.  This is why I always define a top-level entity with every signal pin defined. Then the unused pins really are unused and the unused pin setting is of no consequence.  Cheers, Dave  --- Quote End ---    I don't know why it was set to the older default then. I'm 100% sure I did not change this setting and always remember seeing the warning in the compilation log.

[Altera_Forum]

--- Quote Start ---   I don't know why it was set to the older default then. I'm 100% sure I did not change this setting and always remember seeing the warning in the compilation log.  --- Quote End ---    Stupidity is hard to eradicate from software :)  What version of Quartus are you using? It must be fairly new to support this device. Create a new project, select that device, and then look at the setting. It sounds like the default will be the stupid value. Repeat for a Cyclone IV device and you'll see that the default is the sane value.  Cheers, Dave

[Altera_Forum]

Indeed! If I change the device to a Cyclone the default is the same one. If I change it to Max V, it's set to "as outputs driving ground".

[Altera_Forum]

Thanks for confirming that. 

 Cheers, Dave

[Altera_Forum]

I have a further question. Suppose one solders a brand new chip onto the PCB. What state would it's pins be in? I am, of course, asking before the chip is programmed at all. 

 I ask because one of the chip's pins are connected to pull up resistors. If the default state is an output then powering up a brand new chip might cause some I/O damage - but if that is the case, how is one supposed to program it?

[Altera_Forum]

--- Quote Start ---  I have a further question. Suppose one solders a brand new chip onto the PCB. What state would it's pins be in?   --- Quote End ---    You'll have to read the MAX V handbook.  They should be tri-stated, since their function has not been defined.    --- Quote Start ---   I ask because one of the chip's pins are connected to pull up resistors. If the default state is an output then powering up a brand new chip might cause some I/O damage - but if that is the case, how is one supposed to program it?  --- Quote End ---    Your pull-up will define the power-on state with a blank device.  You can also program the devices prior to assembly. There are TQFP and BGA sockets available.  For small numbers of boards, its easier just to use the JTAG to program the boards.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  You'll have to read the MAX V handbook.  They should be tri-stated, since their function has not been defined.    Your pull-up will define the power-on state with a blank device.  You can also program the devices prior to assembly. There are TQFP and BGA sockets available.  For small numbers of boards, its easier just to use the JTAG to program the boards.  Cheers, Dave  --- Quote End ---    Searching for the word "unprogrammed" in the databook lead me to this:    --- Quote Start ---   The programmable pull-up resistor is active during power-up, in-system programming (ISP), and if the device is unprogrammed  --- Quote End ---    So since the pull-up resistor is active it means the device must be tri-stated.  I'm a bit confused by what you mean by    --- Quote Start ---  Your pull-up will define the power-on state with a blank device.  --- Quote End ---    How would my pull up resistors define the default state of the device?

[Altera_Forum]

Ok, so the handbook indicates that the CPLD internal weak pull-ups are active in the unprogrammed state. 

 The signals connected to the CPLD pins will have a weak high applied to them. If an external device drives the signal on the CPLD, then it will over-ride the weak pull-up. If an external device is driven by the CPLD, then it will have a weak high applied, eg., an active low signal will be deasserted.  If you have a device signal that you would like a low on during power-on, then you need an external pull-down resistor on the signal, eg., 300-Ohms to ground. For example, the resetN signal on a controller that is controlled by the CPLD. If the CPLD is not programmed, then the external device will be held in reset.  I hope that is a little clearer.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---   The signals connected to the CPLD pins will have a weak high applied to them. If an external device drives the signal on the CPLD, then it will over-ride the weak pull-up.  --- Quote End ---    Thank you. And just to be sure - when an external signal overrides this weak pull up it will not damage the CPLD as the pins will be in tri-state?

[Altera_Forum]

--- Quote Start ---  Thank you. And just to be sure - when an external signal overrides this weak pull up it will not damage the CPLD as the pins will be in tri-state?  --- Quote End ---    That is correct.  Cheers, Dave

[Altera_Forum]

Just to update you, Dave. The problem was indeed that the unused pins were set to "as outputs driving ground". When I changed it to "tristate inputs with weak pull up" the voltage went back to 3.3V. 

 I have the data transferring now and I've also modified the code to use the 8 MHz global clock instead of relying on SCK, as it was before in my old design.  begin sync1: process(CLK) variable resync: std_logic_vector(1 to 3); begin if rising_edge(CLK) then rise <= resync(2) and not resync(3); fall <= resync(3) and not resync(2); resync := SCK & resync(1 to 2); end if; end process; process (CLK,nCS) begin if (nCS='1') then tmp <= PI; elsif rising_edge(CLK) then if(fall = '1') then tmp <= tmp(PI'high -1 downto PI'low) & '0'; end if; end if; end process; SO <= tmp(PI'high) when nCS = '0' else 'Z';  Sorry about the non-indentation. The forum seems to be messing up my tabs.

[Altera_Forum]

--- Quote Start ---  Just to update you, Dave. The problem was indeed that the unused pins were set to "as outputs driving ground". When I changed it to "tristate inputs with weak pull up" the voltage went back to 3.3V.   --- Quote End ---  Great!    --- Quote Start ---   I have the data transferring now and I've also modified the code to use the 8 MHz global clock instead of relying on SCK, as it was before in my old design.   --- Quote End ---  If I was going to resynchronize an SPI clock to a local clock, I would instead write the code as:  1) SPI SCK goes through a dual DFF synchronizer. SPI select also needs to be synchronized. MISO and MOSI do not.  2) Generate a pulse on the rising or falling edges (or both since you want to read on rising and shift out on falling). The edge detector can be built by delaying the synchronizer output by one clock, and then using the delayed and non-delays signals (I'll let you figure it out).  3) Your SPI controller FSM can then be clocked at 8MHz, with inputs spi_sel, spi_sck_rising and spi_sck_falling to indicate edges.  You can then use those controls to determine whether your command shift register is shifted (on rising-edges), or your response is shifted (on falling-edges).  Write a testbench to generate the SPI input waveforms and you'll start to see what I mean.  Cheers, Dave

[Altera_Forum]

When I look at the RTL schematic it seems that I do have two flip-flips (actually three) through which SCK is going. See below: 

 http://i.imgur.com/qWKkW.png   Do I gain anything from explicitly writing this with d-flip flops (like you did in your ByteBlaster code) instead of a vector? I must be missing something important.