upc eetac_1

Project P6 on finite state machines (FSM)

16-key matrix keypad encoder

1. Specifications (or understanding the problem)

In the first stage of project designing, customers and company staff meet together to discuss which are the features of the product or project under design. We do it in class investing all the necessary time to fully understand how does the system work. 

Part #1


Fig 1. Symbol (Visio)of the Matrix_encoder_16key to be designed using a FSM architecture.

Some theory on how a matrix keyboard operates. In this Proteus simulation there is a 16-key matrix keyboard component. 200 Hz CLK may be a convenient frequency for scanning keys (MM74C922 using a  COSC = 330 nF). 

keyboard freq
Fig 2. Adaptation of the MM74C922 and how the scanning frequency can be fixed.

Part #2  [To be solved in P8]

The idea is to add communication signals to be able to connect this keyboard controller (slave peripheral) to a master device or a microcomputer, like the data available (invitation) and the enable output (response or data acknowledged) in Fig 2. Note in Fig. 3 that the CLK frequency for scanning keys (MCLK) may be very different to the system CLK (SCLK) running in the computer.


Fig 3. Symbol for the proposed device with handshake capabilities for buffering and synchronising the matrix encoder to the system CLK (SCLK).

Learning materials:

- Tutorial: designing a push button digital low-pass filter and synchroniser.

- Design of a binary synchronous counter of a few number of states (FSM strategy, state enumeration). [Reorganising the former Unit 2.3].

- Tutorial: on the design of a LED bicycle torch.


2. Planning

Devising a strategy to solve the problem. This is the engineer's job and the most difficult task. Generally, many teams intervene planning top-down strategies to conceive how the modules can be interconnected and assembled.

Part #1

Since you know only about flip-flops, start this project running a tutorial like the LED bicycle torch referenced above to see a FSM in action. It'll be the theory to copy and adapt. Examine similar projects from previous semesters. Or instead, study how a binary or BCD counter works.

Plan ideas

Fig 3. Architecture of the 16-key matrix keyboard encoder FSM and some other planning ideas (click to zoom).


Part #2 [To be solved in P8]

Here we have to infer a circuit like the one in Fig.4 to be able to register the code of the key pressed until the computer can read it, thus establishing a kind of handshaking between computer and peripheral (the matrix keyboard) using signals like data available and data acknowledged. Full discussion, state diagram and example of timing diagram. 

Fig 4. Proposed enhancements to allow communication (handshaking) with a master computer. Even of we assume that the SCLK is used for both, the peripheral and the master device, DA may be set for more than a SCLK to be sure that the master device can read the registered data, and perhaps D_Ack also may be larger than a single SCLK.

3. Development

Carrying out the plan, which usually is the job of an engineer or a technician.

Part #1

Here we have to write the previous schematics and truth tables in a single VHDL source file like this one and synthesise a circuit from it using an EDA tool, for instance, ispLEVER Classic and Synplify Pro Lattice Edition.

In our project, the RTL view (or the technology view in a lower level), must show the main details of the FSM. Print and comment the schematic indicating the main components CC1, CC2 and the state register. 

This is an example of state diagram as drawn by Synplify Pro Lattice edition that can be inspected in the RTL view. And this is the default encoding (onehot), which means that 8 DFF are required. Below in Fig. 5 is the technology view of the circuit being synthesised, which give you an idea of the design complexity and resources (instances) used. Count and check the number of registers DFF. 

tech view

Fig 5. Example of a technology view (click to zoom).


Part #2 [To be solved in P8]


4. Testing

Examining test results, engineers must look back to see whether the device comply with the specifications; and forward to see which modifications may achieve better performance. Engineers must be able to organise test procedures to verify that the system works as expected before the next prototyping stage in the laboratory.

Part #1

  1. Perform a functional simulation to verify that the device operates like expected in the initial timing diagram sketch.  This is an example vht file that can be used directly to obtain the results in Fig. 6 or even better, modify it to test other inputs

Test Example

Fig 6. Functional simulation.
  1. Perform a gate level simulation to measure the tCO parameter for a given technology, for instance the ispMACH4128V CPLD, in a convenient CLK rising edge transition. Which is the maximum processing speed of this circuit? A question equivalent to asking how fast can be scanning and encoding the keypad (in case of not having parasitic effects and key bouncing problems)?


Fig 7. Gate level simulations and the timing analyser tool can be used to measure the maximum speed of the system CLK.

Here, we take advantage of the easiness  in using the design automation tools being able to compare circuit realisations. Therefore, which circuit is faster, the one using onehot or the one using a sequential-binary encoding?, and thus, as you can imagine there is a trade-off here: which uses more resources? Such answer can be deduced inspecting the timing analyser results.

Part #2  [To be solved in P8]

Similarly, you can develop a test for the matrix_encoder_16key_registered.



5. Report

By now, you know very well how to report your project and what has a mark assigned. Therefore, try to self-assess your project using the rubric discussed in class.

It's interesting to look back and annotate remarkable questions that were raised while working on the projects (thanks to students deep engagement and discussion), that in the end can be used to generate a higher quality device:

 - Why the system gets stuck when the matrix CLK frequency is too high?
- What can be done to prevent the hanging of the system and how it can recover automatically to a known state?
- Which is the advantage of using deboucing filters in each column?
- What can be done to design a system with all the outputs fully synchronised?
- What can be done to read/sample the columns on the rising edge of the CLK, so that they are going to be kept freezed until the next rising edge?


6. Prototyping

Use training boards and perform laboratory measurements to verify how the circuit works.

It is interesting, in order to see how the circuit works, to use some extra LED to visualise signals and data, which implies building a top schematic containing for instance a HEX_7SEG_DECODER to represent the 16 hexadecimal symbols. This is the top schematic to be implemented in the HWDLC4128V board (schematic) populated with a ispMACH4128V CPLD from Lattice Semiconductor. And this is the RTL view interpreted by Synplify Pro synthesiser tool.

Symbol TOP

Fig 8. The top schematic symbol that includes some extra ports for debugging purposes generated by the ispLEVER Classic. This is the complete zipped project where you can examine the top VHDL file.

Once the development board has been chosen, we have to assign PLD pins to inputs and outputs. This task is conveniently done using the spreadsheet "Constrain Editor", as represented in Fig. 9.

pin assignments

Fig 9. Using the Constrain Editor for pin assignments available through the ispLEVER Classic project navigator.  

So that the final configuration file *.JED can be downloaded into the chip. This task is performed as shown in Fig. 10, the programmer tool, like the ispVM System from Lattice Semiconductor.


Fig 10. This is the ispVM System tool to be used for chip programing. The development board is connected to the computer using a simple USB interface and the tool scans the hardware to detect which is the chip populating the board. Clicking GO the PLD is programmed in a few seconds.

For sPLD or CPLD technologies, the programming of the macrocells is permanent and only can be erased reprogramming he chip another time with the same or a different configuration.

For FPGA technologies, the programming of the LUT (look-up tables) is volatile, and the RAM is erased once unplugged from the power supply. Thus, usually boards contain a supportive EEPROM memory to save the FPGA configuration rewriting the RAM every time the board is powered.  


Finally, we can experiment with the prototype represented in Fig. 11 in order to see whether all the specifications has been met, as shown in this recording. Many times the real circuit, as it was in the simulations, does not fully work, and so, a design loop (Visio) must be started again to modify schematics, rewrite VHDL code and synthesise and program again.


Fig 11. This is a picture of the scanning keyboard running on a Lattice ispMACH4128V CPLD target chip (click to zoom).


Other similar projects on sequential circuits

- A previous project on a matrix encoder that can be used to study this one.

- A similar project on the design of a traffic light controller.



Other materials of interest

- General ideas on FSM. (AMD, 1993).

- An application note on how to design safe FSM, the concept to prevent that a machine "hangs" being unable to get back to a valid state.

- At this stage it is recommended to read books in digital electronics to see how the stuff  in sequential systems is explained and which are the differences with respect the methodologies in CSD.

- Here you are a commercial chip from SILEGO, a company specialised in "asynchronous" state machines (ASM) architectures  which is very similar to the system we are dealing with.  Naturally, we can implement the functionality of the chip in our PIC or Atmel microcontroller in the project P12 as an example of microcontroller application. 


Fig 12. Block diagram of the SILEGO GreenPAK chip that performs the I2C interface between a keypad and a microcontroller.