1. The Need for a Smart Card Reader device

1.1 Half Duplex mode of communication

1.2 RS232 Voltage levels

A major problem encountered when using a long cable for serial communications is that the signal is subjected to electro-magnetic interference while propagating down the cable. This can cause a change in the voltage level that is being transmitted along the cable. Moreover, the level of interference (noise) increases with an increase in the length of the cable.

If one assumes that all voltages in the range 0v to 2.5v represent the binary value 0 and all voltages in the range 2.6v to 5v represent the binary value 1, then it only takes interference resulting in a change in voltage of 2.5v to cause an error in transmission. To address this problem, the RS232 standard transmits a binary 0 as a voltage in the range 3v to 12v, and a binary 1 as a voltage in the range -3v to -12v. Typically, devices adhering to RS232 transmit at 10v and -10v for the two binary values. Consequently, in order for an error to occur, the effects of interference would have to change the signal by 13v to change the binary value being transmitted. This is a significant improvement over the 2.5v change needed when using the 0v to 5v range.

The smart card serial port is designed to be connected directly to the controlling logic of some other device via a contact pad on the card. Since the signal is only propagated over a very short distance, the effect of external electromagnetic interference is negligible. For this reason, smart cards are able to simplify the transmission of binary values via the serial port by keeping these values in the 0v to 5v range - the same range used by the internal circuitry of the card.

Unfortunately, these different approaches to propagating the serial data make smart cards incompatible with the RS232 standard used by PC's. It is the smart card reader device's task to translate voltage levels from one protocol to the corresponding voltage levels of the other protocol. 

1.3 Error Detection and Correction in the T=0 protocol

When the receiver of a T=0 transmission detects a parity error, it is required to force the voltage level on the transmission line to the binary 0 state half way through the transmission of the first stop bit. Since the stop bit is usually the binary value 1, the transmitting device can detect that the receiver has signaled a parity error and can retransmit the previous byte in an attempt to correct the error.

The hardware implementing the RS232 serial communications protocol is not able to transmit binary values at a resolution of half a bit period (the time it takes to transmit a bit). It is therefore not possible for hardware implementing the RS232 protocol to signal errors in the way required by the smart card T=0 protocol. The smart card reader device is responsible for signaling errors in the T=0 communication protocol. 

1.4 Signals required by Smart Cards: Clock, Reset and Power

An alternative approach is to use the parallel port of the PC to interface with the smart card. This is a far more viable approach, as the parallel port has enough pins with the ability to send the signals required by the smart card. A concern here is the power consumption of a smart card, which can be as high as 100mA. This is far in excess of the typical 20mA limit that can be drawn through a single pin of the parallel port. A solution to this problem is to connect 5 pins together in parallel and keep them in the logical high state (5v) to provide the smart card with power.

Although it is more viable than a direct connection to the RS232 port, connecting the smart card directly to the parallel port has its drawbacks. Most significant amongst these is the need for accurate timing of signals to the smart card. In particular, the clock signal must initially have a frequency of 3.58Mhz. It is possible to produce accurately enough timed signals through software control of the pins of the parallel port (this has been done by MS-DOS based programs). However, the driver controlling the clock signal must have complete control of the CPU and parallel port at all times in order to maintain such accurate timing. This makes the parallel port approach to interfacing with the smart card unsuitable for multi-tasking operating systems such as Microsoft Windows NT and UNIX.

A final consideration in concluding that a reader device is more suitable than a direct connection to the parallel port is the type of applications where smart cards are used. A typical use for smart cards is for access control. This could require that the connector that connects the PC's parallel cable with the smart card is quite some distance away from the PC. For example, the connector could be situated next to a door, while the PC could be behind the door, several meters from the connector. Since the parallel port is only designed to communicate over short distances, the length of a parallel cable cannot exceed approximately 3 meters before errors occur due to electromagnetic interference with the signal on the cable. In contrast, a serial cable can transmit data reliably on cables 30m long. 

2. Microprocessor-based Smart Card Readers

A natural design choice for such a device is one based on a microprocessor. Initial designs for this project's reader where based on the 8051 microprocessor (originally manufactured by Intel). A high-level language, called PLM, and 8051 assembly language were considered for programming the microprocessor. Initial work in PLM revealed that this language did not offer the required precise control over the timing of signal changes. If 8051 assembly language had been used, it would have been necessary to take into account the number of clock cycles required for each instruction to execute. However, this approach is very time consuming and tedious. It makes it virtually impossible to produce a clock signal for the smart card with the microprocessor. 

2.1 Inability of Microprocessor-based Readers to produce a Constant Clock Signal

<CLK = 1>
instruction #1
instruction #2
instruction #3
<CLK=0>
instruction #4
instruction #5
<CLK=1>
...

Note that the intervals between manipulations of the CLK signal are equal in time (i.e. clock cycles of the microprocessor executing the code), but not necessarily in the number of instructions, since some instructions take more clock cycles to execute than others do. Another consideration is that, since most instructions take more than a single clock cycle to complete, it may be impossible to manipulate the clock at the correct time (instructions are atomic and cannot be interrupted). It would then be necessary to insert unnecessary 'dummy' instructions into the program to correct the timing, resulting in inefficient and difficult-to-understand code.

The task of adding up clock cycles and inserting clock manipulations for code structured as in the example above is feasible, but would be time consuming and tedious. However, the example above is unrealistically simple. Consider the following example:

<CLK = 0>
instruction #1
if (X = 0) then
   instruction #2
   instruction #3
else
   instruction #4
   instruction #5
end if
instruction #6
instruction #7
...

The path of execution depends on the value of X. Since the value of X is only known at run-time, the programmer must ensure that for any value of X, the path of execution taken by the program always results in clock manipulations occurring at the correct time. This may still be achievable if, for all values of X, the code executed takes the same number of clock cycles to complete. However, if the different execution paths possible require differing numbers of clock cycles to complete, it is not possible to insert clock manipulations in a suitable position following the execution of such a conditional branch.

It is still possible for the program to record which path it has taken to arrive at the currently executing instruction, and to use this information to time a clock manipulation correctly. The complications resulting from this solution would make programming an extremely difficult, if not impossible, task. For all intents and purposes, it is not possible to produce a clock signal with a microprocessor that is simultaneously running another program.

A solution to this problem is to not clock the smart card with the microprocessor, but rather to include a separate crystal oscillator in the interface device. This is the approach taken by most commercial smart card interface manufacturers, including Schlumberger, whose Reflex 60 interface device was used as a reference in this project. However, this solution limits the flexibility of the smart card interface device and results in less-than-optimal transfer rates between the smart card and the interface device. The reason for this is explained in the following section. 

2.2 Limitations imposed by the use of a crystal oscillator

FI	0000	0001	0010	0011	0100	0101	0110	0111
F	Internal clock	372	558	744	1116	1488	1860	RFU
f max (MHz)	-	5	6	8	12	16	20	-

FI	1000	1001	1010	1011	1100	1101	1110	1111
F	RFU	512	768	1024	1536	2048	RFU	RFU
f max (MHz)	-	5	7.5	10	15	20	-	-

Table 7.1: Values of the upper nibble of the TA1 byte of the ATR [13].

DI	0000	0001	0010	0011	0100	0101	0110	0111
D	RFU	1	2	4	8	16	32	RFU

DI	1000	1001	1010	1011	1100	1101	1110	1111
D	12	20	1/2	1/4	1/8	1/16	1/32	1/64

Values of the lower nibble of the TA1 byte of the ATR [13].

Table 7.2:

Since microprocessor-based interface devices clock the card with a dedicated crystal oscillator, they are unable to alter the frequency at which the smart card is clocked. For example, the following values for FI and DI returned in the ATR are valid possibilities according to the ISO 7816 specifications (see tables 7.1 and 7.2 above): FI = 0110 and DI = 0001

This indicates that the card divides the frequency it is clocked at by 1860 to reach a bit rate for serial communications. Since a microprocessor-based reader can only provide the card with a fixed frequency, and this frequency must lie between 1MHz and 5MHz, the maximum serial speed attainable between the microprocessor-based interface device and a card with this ATR is:

(5 000 000 ¸ 1 860) = 2 688 bps Short serial links, such as those connecting a smart card to the interface device, are typically able to operate reliably with speeds up to 115 200 bps. The serial interface in the example above is therefore running at: 

(2 688 ¸ 115 200) = 2.3% of its potential speed. It is clear from the above discussion that for many of the valid values for the TA1 character of the ATR, a reader design with a crystal oscillator would be unable to optimise the speed of data communication between the reader and the card. An alternative to using a crystal oscillator is to produce a clock signal using a CPLD. The following section explores this alternative. 

3. Complex Programmable Logic Devices (CPLDs)

A CPLD is a chip that is programmed to perform specific functions. This 'programming' takes the form of making actual physical connections between the pins of the chip and arrays of logic gates inside the chip. This is in contrast to a microprocessor, which is a general-purpose computational device with an instruction set. CPLDs and microprocessors are not entirely different. In fact, a CPLD can be configured to be a microprocessor (if it has sufficient resources).

A naive, but useful way of appreciating the difference is to consider the CPLD to be a device executing any of its 'instructions' in a single clock cycle. A microprocessor instruction typically takes several clock cycles to execute. Since every function on a CPLD takes a single clock cycle to execute, manipulating timing-sensitive signals is greatly simplified. In addition, several programming languages, which are designed specifically for writing timing-critical code, are available for programming CPLDs. The language chosen for programming the CPLD in this project was VHDL. 

3.1 Very high speed integrated circuit Hardware Description Language (VHDL)

VHDL was developed in 1980 as part of the Very High Speed Integrated Circuits (VHSIC) program, run by the US government [14]. It has since been accepted as a standard (IEEE 1076) by the Institute for Electrical and Electronic Engineers [15].

VHDL offers a number of features that are desirable during the design process [16]:

• It allows the structure of a design to be described (i.e. what its constituent sub-designs are and how these are interconnected).
• It allows the functional logic of a design to be described using high-level programming constructs (such as if... then... else... statements).
• It allows designs to be simulated before being implemented as hardware, thereby reducing the need for expensive and time-consuming hardware prototyping.

Although VHDL offers many high-level features familiar to programmers, it requires a different way of thinking to that which most programmers are accustomed to. The reason for this is that the code is going to be compiled into connections between logic gates, rather than into instructions to a general-purpose microprocessor.

To appreciate the different approach required, consider the following programming task: An 8-bit data value is stored in a register, called R. Assume that each bit of the register can be referenced as if the register were a one-dimensional array of 8 storage locations. For example, to access the 3rd value, one would reference R(3). Typically, in serial communications, one has to assign the value of each of the 8 bits (0 or 1) to the serial line, one at a time.

A natural approach to this problem is to implement the following loop:

for (bit = 1; bit <=8; bit = bit + 1) {
   line = R(bit);
} Although VHDL does have a for loop, it would not be suitable for this use because the bits should each be assigned to the serial line for a certain period of time. In VHDL, the for loop executes all its iterations instantaneously, which would make it unsuitable. 

Instead, a case statement is used, within a process structure. The process is executed every time there is a change in one of the signals listed in the brackets following the process definition. For example:

process(CLK)
begin
   <instructions>
end process;

This pseudo-code executes <instructions> every time there is a change in the CLK signal.

The case statement is functionally similar to that found in C and other popular languages. As the VHDL syntax can be rather cryptic, this example will use C syntax.

case (bit) {<>   1: line = R(1); bit++; break;
  2: line = R(2); bit++; break;
  3: line = R(3); bit++; break;
  4: line = R(4); bit++; break;
  5: line = R(5); bit++; break;
  6: line = R(6); bit++; break;
  7: line = R(7); bit++; break;
  8: line = R(8);
}

This case statement would be enclosed in the process above, causing it to be executed every time there is a change in the CLK signal. By controlling the rate of change of the clock signal, one could control the amount of time each bit spends on the serial line.

Note that every time the clock signal changes, a different element of the register R is put onto the serial line. Now, consider an alternative approach to the same problem:

process(CLK)
begin
   R = '1' & R(8 downto 2);
end process;
line = R(1);

This pseudocode illustrates the solving of the problem by shifting each value in the register R one place to the right (i.e. towards element 1) and then transmitting the value in R(1) on the serial line. Assuming all 8 bits of the register contained the value '0', the values of the register would change as follows:

00000000 ® 10000000 ® 11000000 ®... ® 11111111

This is not an intuitive way of approaching this problem when programming for a microprocessor, as it involves 8 memory shifts every time the CLK signal changes. However, the key to the success of this method is that exactly the same operation is applied to the register every time the CLK signal changes. This is in contrast to the method using a case statement, where a separate operation was executed every time the CLK signal changed, depending on the current bit being sent.

When synthesising VHDL code for execution in CPLDs, code which behaves exactly the same for every change in the clocking signal is, generally speaking, more efficient than code which behaves differently. The reason for this becomes apparent one attempts to construct the two approaches using logic gates. There is no need for the circuit to determine which of the 8 possible bits it is transmitting when the second approach is used. The bit in R(0) is simply transmitted on the serial line.

Resources on CPLDs are generally fairly limited, requiring a great deal of care to be taken to minimise resource usage when coding. Every construct must be thought of in terms of the resulting synthesis in CPLD hardware, often resulting in counter-intuitive coding styles. After compilation, it is possible to simulate the compiled VHDL code. This feature is of great value, as it allows values of different signals throughout the circuit, and at any time during the simulation, to be displayed as a waveform. Unfortunately, simulation can be very time-consuming, resulting in it often being necessary to simulate each component of a large system separately. 

3.2 Compilation of VHDL code

Most high-level languages are compiled into machine instructions to a microprocessor. VHDL differs from these languages in that it is compiled into a series of Boolean equations that are then used to connect arrays of logic gates together in a Programmable Logic Device (PLD). For example, consider the following snippet of VHDL code which implements a 2 bit counter.

-- Context Clauses
  -- Library Clause
  library ieee;

  -- Use Clause
  use ieee.std_logic_1164.all;

-- Library Units
  -- Package Declaration (optional)
  -- Package Body (optional) entity counter is port (
--inputs
  Clk : in std_logic; --20MHz
--outputs
  Finished : out std_logic --9600bps
);
end counter;

-- Entity Declaration
 

-- Architecture Body
architecture counter_arch of counter is
  signal count : integer range 0 to 3;
begin -- architecture   process
  begin -- process
     wait until Clk'event and Clk = '1'; -- rising edge
     count <= count + 1;
  end process;
  finished <= '1' when count = 3 else
     '0';

 end counter_arch;

Compilation of this source results in the following series of Boolean equations, which are applied every time the Clk signal changes from '0' to '1'. Values on the right of the = sign are the previous values of the signals. count0 indicates the least significant bit of count, while count indicates the most significant bit. '!' indicates negation.

  count0 = !count0
  count1 = count0 xor count1
  finished = !count0 and count1 

4. Evaluation of the Suitability of CPLDs for Use in Smart Card Readers

This section explores some problems that may arise when using a CPLD to control a smart card reader. Many of the observations discussed resulted from the issues encountered while designing the smart card reader for this project.

The heart of the reader is an Altera MAX7000 series CPLD clocked at 20MHz. The actual frequency at which the CPLD is clocked need not be 20MHz - in fact, certain other frequencies may have resulted in fewer complications. However, the value of 20MHz is suitable for use in the discussion that follows, and was tested using a prototype circuit board with a 20MHz crystal oscillator.

In order to create a clock signal for timing serial transmissions, one must implement an integer counter in the CPLD. The counter is incremented every time the 20MHz clock signal clocks the CPLD. When the counter reaches a specific value, an output signal is produced and the counter is reset to zero. Essentially, such a circuit creates a regular pulse on the output signal, the frequency of which is the frequency of the signal clocking the counter (20MHz in this case) divided by the maximum value of the counter + 1.

For example, suppose one aims to produce a pulse suitable for timing serial transmissions at 9600 bps from a 20MHz clock signal.

(20 000 000 ( DIVISOR) = 9 600
DIVISOR = (20 000 000 ( 9 600)
= 2 083.3333 The fact that this DIVISOR is not an integer poses a problem, because most VHDL synthesis packages do not support floating-point numbers. Even if these packages did support floating point values, the resources required to implement floating-point values and manipulations in the CPLD would be extremely large. One therefore has to choose the closest integer DIVISOR to 2083.3333, namely 2083. 

(20 000 000 ( 2 083) = 9 601.5362

The percentage error for this transmission rate is:

(9 601.5362 - 9 600) ( 9 600 = 1.5362 ( 9 600
= 0.00016% The question now is: Is this percentage error small enough not to cause a bit to be incorrectly read by a receiver that is expecting a transmission at 9600 bps? To answer this question, one must firstly appreciate the way in which serial data is transmitted. 

4.1 Serial Data Transmission

Serial data is typically sent a byte (8 bits) at a time. Since there is only a single line (wire) over which to transmit the data, the line must be allocated the value of each bit for a set period of time. The time that each bit's value is on the serial line is known as an elementary time unit (etu).

Consider the receiver of such a transmission. How would the receiver know when the transmitter is sending data? There are only two states the serial line can be in: 0v (binary 0) or 5v (binary 1). One cannot decide that one of these is going to be the 'idle' level, indicating that no data is being transmitted, as both possible values are valid data values. An answer to this problem is to append a start bit to the front of the transmission. This bit must have the opposite logical level to the idle level. In the RS232 protocol and the smart card serial protocol, the idle level is binary 1, and the start bit is binary 0.

Equipped with this protocol, a transmitter could send a start bit followed by any number of data bits in an uninterrupted stream. After transmission, the line would have to be put back into the idle state so that a receiver could detect a start bit for another transmission. A problem arising now is that of how a receiver is supposed to know when a data transmission has ended and the idle state has begun. After all, the idle state could be interpreted as a long stream of binary 1 bits if it did not realise that transmission had ended and the idle state had begun.

For this reason, data is always packaged into bytes (8 bits). A receiver knows that, should it read a start bit, it should read in the next 8 bits, and then wait for a start bit to occur again before reading the next byte. In this way, the idle state cannot be mistaken for a data byte, because it is not preceded by a start bit.

At this point, one can again consider whether or not the 0.00016% error in the timing of a serial transmission will result in any errors in reception. To allow more the maximum tolerance of errors, serial data receivers always sample data bits on the serial line in the middle of the transmission of that bit (or, more accurately, where it perceives the middle to be according to it's bit-rate timing). It would therefore require a total difference in timing of 50% of an etu between the transmitter and the receiver to cause a bit to be incorrectly read.

(50 ( 0.00016) = 312 500

It would therefore take the transmission of 312 500 consecutive bits before the error has accumulated to the extent where it causes the incorrect bit to be read. It is quite conceivable (even likely) that this number of bits would be exceeded in a typical serial transmission.

The method used to counteract this problem is to send the serial line back into the idle state between each byte transmitted. This is achieved by appending a stop bit to the end of each byte transmitted. This stop bit is the same logic level as the idle state (binary 1) and effectively puts the line in its idle state for one etu. When the line is idle, it is sampled at a much higher rate than the normal bit rate at which data is sampled. Every time it is sampled at this high rate, the receiver is trying to detect the beginning of a start bit. When it detects this start bit, it has effectively resynchronised its timing for the current byte being transmitted. This protocol, with the inclusion of a parity bit, is illustrated in Figure 7.1.

Figure 7.1: RS-232 serial data-byte timing waveform.

The transmission of each byte involves the transmission of a total of 10 bits: a start bit, 8 data bits and a stop bit. As before, it would take a cumulative error of 50% to result in a bit being incorrectly read. Thus, any error less than (50% ( 10) = 5% per bit will not result in a bit being incorrectly read in the current byte transmission. Since the reader resynchronises on each byte's start bit, the error never accumulates further than 10 bits.

Thus it can be concluded that the 0.00016% error one has to accept when using a 20MHz clock is well within the 5% tolerance for serial communications at 9600 bps.

A more serious problem is the clocking of the smart card itself. The card divides the frequency it is clocked at by 372 to arrive at the bit rate for its serial transmissions. A bit rate of 9 600 bps is desirable, so the calculation determining the frequency at which the card should be clocked is:

f ( 372 = 9600 f = 9600 * 372 = 3 571 200 Hz

A question that now arises is, using a 20MHz clock, what is the closest to 3 571 200 Hz that one can arrive at by dividing by an integer?

(20 000 000 ( DIVISOR) = 3 571 200 DIVISOR = (20 000 000 ( 3 571 200) = 5.6

This is closest to the integer 6. If one were to divide the 20MHz clock signal by 6 and use this resulting signal to clock the smart card, would the resulting bit rate be close enough to 9600 bps, so as not to result in an error?

(20 000 000 ( 6) = 3 333 333.3 Hz (3 333 333.3 ( 372) = 8 960.57 bps (9 600 - 8 960.57) ( 9600 = 6.66%

Since this is greater than 5% per bit, an error will result during the reading of a byte.

Fortunately, VHDL allows a process to execute at half clock cycles (by being able to respond to both the signal changing from 0 to 1 and from 1 to 0). It is therefore possible to use the value of 5.5 to divide the 20 MHz clock. The resulting error percentage per bit would be:

(20 000 000 ( 5.5) = 3 636 363.6 Hz (3 636 363.3 ( 372) = 9 775.17 bps (9 775.17 - 9 600) ( 9 600 = 1.8%

An error of 1.8% is well within the tolerance level of 5%.

In conclusion, it can be seen that a 20MHz oscillator can be used to clock the CPLD. An oscillator producing a signal which is an integer multiple of 9 600 would have simplified the timing of other aspects of the design. However, the 20MHz oscillator was considered due to its inclusion in the prototype circuit board used in this project for testing. 

4.2 CPLD output voltage levels

The Altera MAX7000 series CPLD used in this project outputs voltages suitable for interpretation as logic values, but not suitable for driving other devices. In particular, the voltage outputted to indicate a 'true' logic level (binary 1) is typically about 3.8v [17]. This is within the 2.5 to 5v range typically interpreted as binary 1, but does not conform to the input specifications of many other devices, including smart cards. Smart cards require the input voltage level representing binary 1 to be in the range 4v to 5v in accordance with the ISO 7816 specifications.

In order to rectify this problem, the signals outputted by the CPLD are fed into other Integrated Circuits (IC's), which interpret these signals as logical levels and output the suitable voltage levels corresponding to the input being received from the CPLD.

In the case of the RS232 serial transmission line from the CPLD to the PC, this IC is known as a MAX232. The purpose of this IC is to convert a binary 1 outputted by the CPLD to a voltage in the range -3v to -12v and a binary 0 outputted by the CPLD as a voltage in the range 3v to 12v. The reason for this conversion is to convert the signal to one more suitable for transmission down long serial cables (as explained in section 7.1.2).

In the case of the half-duplex serial link from the CPLD to the smart card, a simple buffer chip is used. This IC simply takes a binary input value and outputs the same value if the IC is enabled. Although the binary value of the output is the same as the input, it outputs 5v to indicate a binary 1, thereby correcting the problem of the CPLD outputting voltage levels not suitable as input to the smart card.

The buffer takes care of another problem: the limited amount of current that can be drawn through a pin of the CPLD. This limit is approximately 20mA, while a smart card can draw up to 100mA through its Vcc contact. In addition, the output voltage of the CPLD drops off sharply as more current is drawn through the output pin. It is therefore clear that an output pin of the CPLD is not suitable for providing a power supply (Vcc) to the smart card. It is, however, necessary for the CPLD to have control over the turning on and off of the power supply to the smart card, as the order in which signals are applied to the contacts of the smart card are strictly defined in the ISO 7816 specifications. Fortunately, the output pins of the buffer IC are able to provide the power source needed by the card, and can also be controlled by the CPLD. 

5. Other Components of the Smart Card Reader

5.1 Smart Card Connector

The smart card connector is the physical device into which the smart card is inserted in order to allow the reader to communicate with it. It usually takes the form of a plastic slot with several metal pins that touch the smart card contacts to form the electrical connection between the reader and the smart card. There are two main approaches to bringing the pins into contact with the smart card contacts:

• Fixed-position spring-loaded pins
• Landing-type pin mechanism
. These pins are forced aside as the card is inserted, and drag along the surface of the card until they are correctly positioned over the contacts. This design has the disadvantage of causing wear on the card surface and contacts, but has the advantage of being cheap, simple and durable. . In this design, the pins are only brought into contact with the smart card contacts once the card is in position in the slot. This design reduces wear on the card, but is mechanically more complex and more prone to failures than the fixed-position spring-loaded pin design. A landing-type pin mechanism was chosen for this project.

Smart card connectors also feature a switch that is activated when a card is in its correct position in the connector mechanism. This switch indicates the controlling hardware (CPLD in this case) that it is safe to activate the contacts of the smart card. If the card were not properly in position, the pins could be incorrectly aligned and connect to the wrong contacts on the card. This could result in the card being damaged.

5.2 LED

The reader designed as part of this project also included a Light Emitting Diode (LED) under the control of the CPLD. This was included to aid in debugging the program being implemented in the CPLD. Since there is no video display and keyboard input to the CPLD, the LED is particularly useful for providing the programmer with feedback. Once the RS232 connection with the PC was established, this was another way of providing feedback to the programmer. 

---