Xilinx CPLD XC9500, pull up or pull down?

[legacy]

so, it's time to finalize an old project that I have in my head, it's a matrix keyboard controller with a classic debounce-circuit



and row-col decoder with works with a keyboard recycled from a laptop.

it works in a similar way to the following



it has more columns and rows lines, and it currently uses pull-up (two SIL packs of 10K each) instead of pulldown.

Once designed the PCB, I was ready to send the file to a service but surfing on internet I found this warning message by Xilinx:

Avoid pull-down resistors. Always use external pull-up resistors if external termination is required. This is because the CPLD, which includes some I/O driving circuits beyond the input and output buffers, may have contention with external pull-down resistors, and, consequently, the I/O will not switch as expected.

and elsewhere they recommend:

Avoid pull-down resistors on pins. All Xilinx CPLDs include additional circuitry on an I/O pin beyond just the I/O buffer. This includes ESD as well as circuits that manage power up behavior. For example:

XC9500 has High-Z during power on
XC9500XL/XV has High-Z during power on, then a keeper latch
XPLA3 has High-Z during power on, then a keeper “half latch”
CoolRunner-II has High-Z during power on, then a keeper latch
Pull-down resistors “fight” the internal pin electronics, which may misbehave due to the external pull-down. For the most predictable behavior, avoid pin pull-down resistors.

Thus, mumble, it seems to me that manufacturers's warning is referred to pull-downs which might conflict with *external* pull-ups.

Which is NOT my case, since the above circuit uses pull-up just to force a stable known state when buttons are opened.

Button Opened -> "0"
Button Closed -> "1"

Pull-up will have the negative logic

Button Opened -> "1"
Button Closed -> "0"

From the point of view of the CPLD logic. It's not tricky to modify the VHDL code, and even the PCB is simple to be modified. I just wonder if I had better modify it or not.

I am 90% sure I don't need to turn it into pulldown, but in my head some doubts about the warning

like:
-1- what would happen if I disregard the manufacturers' warning?
-2- and what if I use an extremely weak pull-down? 

oh, well


edit:
ups, I am using a XC9572XL PC84, the I/O core is powered at 3.3V.

[rstofer]

I'm guessing Rows are output and Cols are input? You have shown pull-ups on the Cols and that should be fine.
There are a lot of references suggesting you not use pull-downs, why is there still a question?
I like to put 330 Ohm series resistors (for 5V IOs, 200 Ohm for 3.3V) on all inputs and outputs to protect the pin from short circuits.  They also slow down the rise time and help prevent reflections.
We almost always wind up with switches inverted.  It's just the way of things.

[legacy]

There are a lot of references suggesting you not use pull-downs, why is there still a question?

because I can't see the point. What is the point? Why not?

I like to put 330 Ohm series resistors (for 5V IOs, 200 Ohm for 3.3V) on all inputs and outputs to protect the pin from short circuits

I might add them to the jtag and serial connector. The keyboard doesn't need then. I believe.

They also slow down the rise time and help prevent reflections

The scan frequency is less than 1Khz, thus no reflections.

[legacy]

I'm guessing Rows are output and Cols are input?

Code: [Select]

entity keyboard_controller is
  generic
  (
    clock_frequency   : integer := clock_frequency;
    debounce_frequency: integer := debounce_frequency
  );
  port
  (
    in_clock          : in  std_logic;
    in_reset          : in  std_logic;
    in_matrix         : in  keyboard_matrix_in_t;
    out_matrix        : out keyboard_matrix_out_t;
    out_uart_tx       : out std_logic;
    out_kb_led        : out std_logic
  );
end keyboard keyboard_controller;

From my point of view,  in_matrix(15..1) is the input,  out_matrix(11..1) is the output.
out_kb_led is used to light on the CapsLock.

[legacy]

positive logic, with pull-down

Code: [Select]

  out_matrix  <= matrix_out0 or matrix_out1;
     
  matrix_in0  <= in_matrix and keyboard_matrix_in_mask0; -- common ASCII keys                   
  matrix_in1  <= in_matrix and keyboard_matrix_in_mask1; -- special META keys

negative logic, with pull-up

Code: [Select]

  out_matrix  <= not(matrix_out0 or matrix_out1);
     
  matrix_in0  <= not(in_matrix and keyboard_matrix_in_mask0); -- common ASCII keys                   
  matrix_in1  <= not(in_matrix and keyboard_matrix_in_mask1); -- special META keys

it's just a matter of understanding WHY pull-up!

[legacy]

xapp74: this is the appnote I was talking about. Where my doubts come from.

[rstofer]

I guess I am missing the point.  The app note says don't use pull-downs.  I didn't see where it waffled on that concept.

[legacy]

The app note says don't use pull-downs

They warn, but frankly I see nothing wrong in using pull-downs!
That is the point: why not?

[rstofer]

The app note says don't use pull-downs

They warn, but frankly I see nothing wrong in using pull-downs!
That is the point: why not?

They dance around some reasons but, in the end, the app note is "Best Practices" and I suspect the pull-down approach will work fine but that's a guess.  Personally, I don't like putting a hard voltage on a pin but I can't come up with a reason why I don't mind putting a solid ground on it.  Maybe that's why I like to add the series resistors.

I'm not going to find an app note that says "don't do this" and then turn around and do it.  Now that I have seen a document that says "no pull-downs", I'm happy to play along.  I have enough trouble getting my projects to work without adding potential issues.

And they're not going to tell you what all is involved with the pin and why it's a bad idea.  Like I said, they kind of dance around it but I notice they didn't attach a schematic.

Try it and see how it works out!

[Bruce Abbott]

Reasons to use pull-ups rather than pull-downs:-

1. XC9500 has TTL input logic thresholds (0.8V low and 2.4V high) so pull-ups have higher noise immunity than pull-downs.
 
2. Short to ground won't won't blow the output drivers.

3. XC9500 has internal pull-ups which are active during power up, configuration, in-system programming and test. External pull-downs may put pins into invalid states during these times.

[legacy]

Reasons to use pull-ups rather than pull-downs:-

1. XC9500 has TTL input logic thresholds (0.8V low and 2.4V high) so pull-ups have higher noise immunity than pull-downs.
 
2. Short to ground won't won't blow the output drivers.

3. XC9500 has internal pull-ups which are active during power up, configuration, in-system programming and test. External pull-downs may put pins into invalid states during these times.

Thanks 

Point 3 is what I was afraid it was the problem, but I was not sure at all.

OK, problem solved. Thanks guys 

[Bruce Abbott]

This job would be a piece of cake for any old 8 bit microcontroller. Using a precious XC95108? Waste of a good CPLD.

[legacy]

Next steps:
-1- re-using designed blocks (as well as verification functions and testbenches) for a customer project since he wants the keyboard controller integrated with-in the main big-fpga
-2- re-using the 72/108 CPLDs (as well as the EagleCAD library I made) for a 68020 mini-board where they will still need pull-ups