# FPGA Implementation of IEC-61131-3-Based Hardware Aided Counters for PLC
## 3 FPGA Counters Implementations
### Software-Like Counters
The second important element of the structure is the PV memory. This memory can be modified only by the state of the CR_W. All these functionalities are implemented by means of OP_MUX. AND gates work as the edge detectors for the CU and CD inputs. In order to detect the rising edge of a variable coming from CR_b, two memories for remembering its previous state must be used. Additionally, two comparators are applied that are used to control the reaching of limit values by the counter--MIN and MAX. These values are constant for each data type of the counter value. The MUX_1 multiplexer is used to produce the state of the counter's binary outputs--QU and QD. It is implemented in a combinational way, so it is calculated after every input change. The QU and QD outputs are calculated during reading their state. There is no need to implement the memory, but in opposite to microprocessor-based solutions, it takes no clock cycles to elaborate the QU and QD values. The content of CV and PV

Figure 11: Software-like counters with conditioning. memories, for particular address, are compared for QU and CV memory is compared with zero for QD. However, the idea presented in Figure 12 has the same problem as hardware counter presented in Figure 7--it realizes every instruction like it was an operand executed immediately. This nuance was presented in detail in Section 2. It is necessary to introduce a block that could realize CAL. In such a case, memories form an environment to a call block. The call block (CALL_UNIT) presented in Figure 13 is just a simple combinational process consistent with Listing 5, so it works as a decoder for MUX_1. This CALL_UNIT block takes into account the MIN and MAX values. As can be seen in Figure 13, edge detection this time requires the use of two memory cells CU and CU' (CD and CD'), because the rising edge detection itself occurs during the execution of the CU (CD) operation, but this result is consumed only at the CALL operation. This requires storing not only the state of the previous CR bit, but also information about current CR_b state. Presented in Figure 13 construction requires extra elements--CU', CD', R and LD bit memory and CALL_UNIT. The undeniable advantage of this design is that it remains a single-clock-edge design. Figure 12: The structure of soft-like counters block dedicated for short operators (CAL not required). ### Summary

Presented in Section 3, the solutions are single clock edge units. This means that the machine cycle is executed within one clock cycle. However, it must be stressed that two kinds of units were presented:

* An operator that executes whole counter (Figures 7 and 12 for hardware and software-like counters, respectively),
* Operators that prepare data in memories, but the counter execution shall take place after the CAL instruction (Figures 8 and 13). Furthermore, it must be stressed that the first idea prevents the use of a CAL operand as a separate execution moment, so this unit implements only a subset of the features defined in the standard. The second idea enables us to execute a counter after every single counter operator, e.g., CU CNTx, but the compiler must split the operator into two instructions (store + CAL). The idea with separate CAL (Figure 13) is more flexible, but its drawback is that simple



counters: 2-1024 (address: 1-bit to 10-bit). The versions with CAL are implemented (hardware--Figure 8; software-like--Figure 13). As can be seen in Figure 14 the number of LUTs utilized for hardware counters increases linearly ( 80 LUTs/CNT) with the number of counters. Furthermore, the number of FFs also increases linearly (Table 1; 70 FFs/CNT)--this is a serious disadvantage of this solution. This solution quickly utilizes huge amounts of resources. However, hardware counters do not use LUTRAMs. Software-like counters are completely different after their implementation.