Architecture rtl of work.ps2_keyboard

This is a state-machine driven serial-to-parallel and parallel-to-serial interface to the ps2 style keyboard interface. The details of the operation of the keyboard interface were obtained from the following website:

http://www.beyondlogic.org/keyboard/keybrd.htm

Some aspects of the keyboard interface are not implemented (e.g, parity checking for the receive side, and recognition of the various commands which the keyboard sends out, such as "power on selt test passed," "Error" and "Resend.") However, if the user wishes to recognize these reply messages, the scan code output can always be used to extend functionality as desired.

Note that the "Extended" (0xE0) and "Released" (0xF0) codes are recognized. The rx interface provides separate indicator flags for these two conditions with every valid character scan code which it provides. The shift keys are also trapped by the interface, in order to provide correct uppercase ASCII characters at the ascii output, although the scan codes for the shift keys are still provided at the scan code output. So, the left/right ALT keys can be differentiated by the presence of the rx_entended signal, while the left/right shift keys are differentiable by the different scan codes received.

The interface to the ps2 keyboard uses ps2_clk clock rates of 30-40 kHz, dependent upon the keyboard itself. The rate at which the state machine runs should be at least twice the rate of the ps2_clk, so that the states can accurately follow the clock signal itself. Four times oversampling is better. Say 200kHz at least. The upper limit for clocking the state machine will undoubtedly be determined by delays in the logic which decodes the scan codes into ASCII equivalents. The maximum speed will be most likely many megahertz, depending upon target technology. In order to run the state machine extremely fast, synchronizing flip-flops have been added to the ps2_clk and ps2_data inputs of the state machine. This avoids poor performance related to slow transitions of the inputs.

Because this is a bi-directional interface, while reading from the keyboard the ps2_clk and ps2_data lines are used as inputs. While writing to the keyboard, however (which may be done at any time. If writing interrupts a read from the keyboard, the keyboard will buffer up its data, and send it later) both the ps2_clk and ps2_data lines are occasionally pulled low, and pullup resistors are used to bring the lines high again, by setting the drivers to high impedance state.

The tx interface, for writing to the keyboard, does not provide any special pre-processing. It simply transmits the 8-bit command value to the keyboard.

Pullups MUST BE USED on the ps2_clk and ps2_data lines for this design, whether they be internal to an FPGA I/O pad, or externally placed. If internal pullups are used, they may be fairly weak, causing bounces due to crosstalk, etc. There is a "debounce timer" implemented in order to eliminate erroneous state transitions which would occur based on bounce.

Parameters are provided in order to configure and appropriately size the counter of a 60 microsecond timer used in the transmitter, depending on the clock frequency used. The 60 microsecond period is guaranteed to be more than one period of the ps2_clk_s signal.

Also, a smaller 5 microsecond timer has been included for "debounce". This is used because, with internal pullups on the ps2_clk and ps2_data lines, there is some bouncing around which occurs

A parameter TRAP_SHIFT_KEYS allows the user to eliminate shift keypresses from producing scan codes (along with their "undefined" ASCII equivalents) at the output of the interface. If TRAP_SHIFT_KEYS is non-zero, the shift key status will only be reported by rx_shift_on. No ascii or scan codes will be reported for the shift keys. This is useful for those who wish to use the ASCII data stream, and who don't want to have to "filter out" the shift key codes.