Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

Unused CPLD Pins

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

23 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    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.

    --- Quote End ---

    The recommendation was more to start using components, rather than writing things inline. A synchronizer is a useful component. You can add generics to indicate how many stages of DFFs to use and whether to power-on high or low.

    When you start using components in your source, it also becomes easier to read, since you start to see the 'big-picture' rather than a huge number of VHDL signal names that have slight variations. Eg. The input spi_clk becomes spi_clk_sync once synchronized.

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Oh I do apologize for missing the point! Yes, when you mentioned I need to sync. CS as well I realized it's better to have a component I can reuse. Thanks again!

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    The nice thing about writing components is that you can also write a testbench for each component ... hint hint ...

    Cheers,

    Dave