Swp Final Report

A Project Report

On

FPGA IMPLEMENTATION OF MASTER CONTROLLER FOR SINGLE WIRE PROTOCOL

Submitted for partial fulfillment of the requirements for the award of the degree

Of

BACHELOR OF ENGINEERING

IN

ELECTRONICS AND COMMUNICATION ENGINEERING

BY

Ms. AMIREDDY SINDHU (1601-09-735-122)

Ms. TRIVENI GUBBALA (1601-09-735-126)

Mr. RAJEEV PATNAM (1601-09-735-146)

Under the guidance of

Smt. N. ALIVELU MANGA

Professor

Department of ECE

Chaitanya Bharathi Institute of Technology, Hyderabad .

(Affiliated to Osmania University)

.

Department of Electronics and Communication Engineering

Chaitanya Bharathi Institute of Technology, Gandipet, Hyderabad -500 075

I

CERTIFICATE

This is to certify that the project work entitled “SWP BUS PROTOCOL” is a bonafide work

carried out by Ms. Sindhu Amireddy (1601-09-735-122), Ms. Triveni Gubbala (1601-09-735-

126), Mr. Rajeev Reddy Patnam (1601-09-735-146), in partial fulfillment of the requirements

for the award of degree of BACHELOR OF ENGINEERING IN ELECTRONICS AND

COMMUNICATION ENGINEERING by the OSMANIA UNIVERSITY, Hyderabad, under

our guidance and supervision.

The results embodied in this report have not been submitted to any other university or institute

for the award of any degree or diploma.

Internal Guide Head of the Department

Smt. N. Alivelu Manga Prof. Dr. N.V. Koteswara Rao

Associate Professor Professor and Head

Department of ECE Department of ECE

CBIT, Hyderabad. CBIT, Hyderabad.

II

DECLARATION

This is to declare that the work reported in the present project entitled “FPGA

IMPLEMENTATION OF MASTER CONTROLLER FOR SINGLE WIRE PROTOCOL”

is a record of work done by us in the Department of Electronics and Communication

Engineering, Chaitanya Bharathi Institute of Technology, Osmania University. The reports are

based on the project work done entirely by us and not copied from any other source.

Ms. AMIREDDY SINDHU (1601-09-735-122)

Ms. TRIVENI GUBBALA (1601-09-735-126)

Mr. RAJEEV PATNAM (1601-09-735-146)

III

ACKNOWLEDGEMENT

I would like to express my sincere gratitude and indebtedness to my project supervisor

SMT. N. ALIVELU MANGA for her valuable suggestions and interest throughout the course

of this project.

I place on record and warmly acknowledge the continued encouragement, invaluable

supervision, timely suggestions and inspired guidance offered by our professor,

Prof. Mr. K. SUDERSHAN REDDY.

I am also thankful to Head of the department PROF. DR. N.V. KOTESWARA RAO for

providing excellent infrastructure and a nice atmosphere for completing this project successfully.

I convey my heartfelt thanks to the lab staff for allowing me to use the required equipment

whenever needed.

I would like to express our special gratitude and thanks to VEDIC INSTITUTE OF VLSI

organization persons for giving us such attention and time.

Finally, I would like to take this opportunity to thank my family for their support through the

work. I sincerely acknowledge and thank all those who gave directly or indirectly their support in

completion of this work.

(Name of the student)

IV

LIST OF FIGURES

Figure 2.1 SWP data transmission 0

Figure 2.2 CLF-UICC physical link 0

Figure 2.3 Voltage definition for the signal S1 0

Figure 2.4 Definition of the Current level for S2 on SWIO 0

Figure 2.5 Bit coding of S1 0

Figure 2.6 S2 timing

Figure 2.7 Data Link Layer overview 0

Figure 2.8 Frame structure sent by Master 0

Figure 2.9 Frame structure sent by Slave 0

Figure 2.10 Zero-bit stuffed sequence 0

Figure 2.11 LLC Control field coding 0

Figure 2.12 LPDU Structure of the 3 defined LLC Layers 0

Figure 2.13 ACT LPDU Structure 0

Figure 2.14 End points 0

Figure 2.15 RSET frame payload 0

Figure 2.16 One way data flow with RR frames acknowledgement

Figure 3.1 Block Diagram

Figure 4.1 IDLE State

V

Figure 4.2 ACTSYNC State

Figure 4.3 ACTPOWER State

Figure 4.4 ACTREADY State

Figure 4.5 Link RSET State

Figure 4.6 Link UA State

Figure 4.7 Data in FIFO

Figure 4.8 Information Frames

Figure 4.9 Receive Ready Frame 3

Figure 4.10 Receive Ready Frame 6

Figure 4.11 CRC Output

Figure 4.12 Software Implementation of CRC Module

Figure 4.13 Block Diagram of CRC

Figure 4.14 S1 Output

Figure 4.15 FIFO Write

Figure 4.16 FIFO Read

Figure 4.17 RTL Schematic

Figure 4.18 HDL Synthesis

Figure 4.19 Advanced HDL Synthesis Report

Figure 4.20 Final Report

Figure 4.21 Device Utilization Summaries

LIST OF TABLES

Table 2.1 Electrical characteristics of SWIO for S2 under

normal operating conditions 0

Table 2.2 The meaning of ACT_CTRL and ACT_DATA 0

Table 2.3 SHDLC control field coding 0

Table 2.4 Type coding of the S-frames 0

Table 2.5 Modifier coding of the U-Frames 0

VI

ABSTRACT

The Single Wire Protocol is intended as a direct interface between a mobile phone's SIM card

(UICC) and the mobile phone's contactless front-end (CLF). The first devices implementing this

communication protocol, mainly in its draft versions, are already in production. The SWP uses a

single wire for full-duplex communication between one master and one slave device. While

master-to-slave data transfers take place in the voltage domain, slave-to-master data transfers

take place in the current domain.

A steadily increasing number of mobile phones are equipped with Near Field Communication

(NFC) technology. With this progress a central question arises: Who should have control over

the secure element? With current applications the secure element is an integrated part of the

cellular phone. This leaves control to the phone manufacturers. For telephony, the counterpart to

the secure element is the subscriber identity module (SIM). The SIM is part of the universal

integrated circuit card (UICC). This card is already present in the cellular phone. Therefore, it

would be reasonable to also use the UICC as the secure element for NFC and, thus, shift the

control to the mobile network operators (MNOs). To implement the UICC as the secure element

for NFC, a direct interface to the mobile phone's contactless front-end (CLF) is necessary. It has

been agreed that the newly developed Single Wire Protocol (SWP) should be used for this

communication.

The SWP is divided into three layers:

(1) The physical transmission layer (PHY) specifies the bit coding and the SWP interface's state

management.

(2) The medium access control layer (MAC) defines the bit order, the framing, the bit stuffing

and an error detection mechanism.

(3) The logical link control layer (LLC) defines the format of data packets and several protocols

for data exchange.

We in our project are trying to implement Single Wire Protocol using HDL and FPGA.

VII

TABLE OF CONTENTS

PAGE NOS.

Certificate (college) .......................................................................................................... I

Certificate (company) ...................................................................................................... II

Declaration…………………............................................................................................ III

Acknowledgements........................................................................................................... IV

List of Figures ................................................................................................................... V

List of Table....................................................................................................................... VI

Abstract.............................................................................................................................. VII

CHAPTER 1

INTRODUCTION

1.1 Motivation 01

1.2 Aim of the Project 02

1.3 Layout of the thesis 02

CHAPTER 2

SWP BUS SPECIFICATION, PRINCIPLE, ARCHITECTURE AND CHARACTERISTICS

2.1 Definitions, Symbols, Abbreviations and coding connections 0

2.1.1 Definitions 0

2.1.2 Symbols 0

2.1.3 Abbreviations 0

2.1.4 Conventions 0

2.2 Principle of SWP 0

VIII

2.3 System architecture 0

2.4 Electrical characteristics 0

2.4.1 Operating conditions 0

2.4.2 Signal S1 0

2.4.3 Signal S2 0

2.5 Physical transmission layer 0

2.5.1 S1 bit Coding and sampling time 0

2.5.2 S2 Switching management 0

2.6 Data link layer 0

2.7 Medium Access Control (MAC ) layer 0

2.7.1 Bit order 0

2.7.2 Structure 0

2.7.3 Bit stuffing 0

2.7.4 Error detection 0

2.8 Supported LLC Layer 0

2.9 Act LLC definition 0

2.10 SHDLC LLC definition 0

2.10.1. End points 0

2.10.2 SHDLC frame types 0

2.10.3 Control field 0

2.10.4 I-Frames coding

2.10.5 S-Frames coding

2.10.6 U-Frames coding

2.10.6.1 RSET frame payload

2.10.6.2 UA frame payload

2.10.6.3 Variables

IX

2.10.6.4 Initial Reset state

2.10.6.5 Data Flow

CHAPTER 3

SWP MASTER CONTROLLER 0

3.1 Block diagram 0

3.2 Description 0

3.2.1 CPU Interface 0

3.2.2 Asynchronous FIFO 0

3.2.3 SWP Interface 0

3.3 Flow charts 0

3.3.1 Activation Interface 0

3.3.2 Link Establishment 0

3.3.3 Information transfer 0

CHAPTER 4

SIMULATION AND SYNTHESIS RESULTS

4.1 IDLE state

4.2 ACT SYNC state

4.3 ACT POWER state

4.4 ACT READY state

4.5 LINK RSET state

4.6 LINK UA state

4.7 INFORMATION state

4.8 CRC module

4.9 S1 Output

X

4.10 ASYNC FIFO

4.10.1 WRITE

4.10.2 READ

4.11 SYNTHESIS Results

CHAPTER 5

CONCLUSIONS & FUTURE SCOPE

BIBLIOGRAPHY

APPENDICES

APPENDIX I- IMPLEMENTING VHDL DESIGNS USING XILINX ISE AND FPGA

XI

CHAPTER 1

INTRODUCTION

XII

1.1 INTRODUCTION

The Single Wire Protocol is intended as a direct interface between a mobile phone's SIM card

(UICC) and the mobile phone's contactless front-end (CLF). The first devices implementing

this communication protocol, mainly in its draft versions, are already in production. The

SWP uses a single wire for full-duplex communication between one master and one slave

device. While master-to-slave data transfers take place in the voltage domain, slave-to-master

data transfers take place in the current domain.

It is a contact based protocol which is used for contactless communication. C6 pin of UICC

is connected to CLF for SWP support. It is a bit oriented full duplex protocol i.e at the same

time transmission as well as reception is possible. CLF acts as a master and UICC as a slave.

CLF provides the UICC with energy, a transmission clock, data and signal for bus

management. The data to be transmitted are represented by the binary states of voltage and

current on the single wire.

A UICC has eight contacts. Only one of these contacts is unused with previous

specifications. As a result, the SWP is required to use only this contact (SWIO) to be

backward compatible to existing standards and applications.

1.2 AIM

The aims of this project are to develop a CLF Master Controller based on the SWP bus protocol

and send information from CLF to UICC. Physical transmission layer, Data Link layer which

consists of MAC and LLC layers are to be successfully established. This is done using VHDL

and implemented on FPGA.

1

1.3 OBJECTIVES OF THE PROJECT

1. To design a CRC module to generate a 16 bit CRC-CCITT (0XFFFF) code for the given

payload.

2. To design an asynchronous FIFO module which performs read and write operations on

different clocks.

3. To design and implement the Physical transmission layer, Data Link layer which consists

of MAC and LLC layer.

4. To integrate all the above modules and form a fully functional CLF Master controller for

SWP protocol which can successful activate the master and slave, establish a link

between them and to send the required data from master to slave.

5. To simulate, synthesize and dump the code on to an FPGA and verify the hardware

compatibility of the code.

1.3 LITERATURE SURVEY

ETSI has published ETSI TS 102 613 V7.3.0 (2008-09). This Technical Specification (TS) has

been produced by ETSI Technical Committee Smart Card Platform (SCP).

This document defines a communication interface between the UICC and a contactless frontend

(CLF) in the terminal. This interface allows the card emulation mode independent of the power

state of the terminal as well as the reader mode when the terminal is battery powered.It also

ensures interoperability between a UICC and the CLF in the terminal Independently of the

respective manufacturer, card issuer or operator. Any internal technical realization of either the

UICC or the CLF is only specified where these are reflected over the interface.

The document specifies the Single Wire Protocol (SWP). SWP is the interface between the

UICC and the CLF. The document defines the various layers in SWP.

Layer1: Physical layer

Layer 2: Data link layer

This layer can be split into two sub-layers:

1. The Medium Access Control (MAC)

2

2. The Logical Link Control layer

Three different Logical Link Control layers are defined in the present document.

- The concepts of VHDL were studied from Circuit Design with VHDL by V. A. PEDRONI. It is

a very straight forward book which quickly covers the basics and goes into the design oriented

concepts. Specifically chapter 2(Code structure), chapter 5(Concurrent code), chapter

6(Sequential code) were very informative and helped us to a great extent in understanding the

concepts and implementing them in our project.

1.4 ORGANIZATION OF THE THESIS

Chapter 1 of this project introduces Single Wire Protocol.

Chapter 2 explains SWP Specifications, its principle, basic architecture and

characteristics.

Chapter 3 deals with the block diagram of CLF Master Controller, its architecture and

individual blocks design. The state machines are discussed by flow charts.

Chapter 4 is a brief account of VHDL LANGUAGE.

Chapter 5 explains implementation of VHDL designs using Xilinx ISE and synthesis.

Chapter 6 discusses the simulation output waveforms followed by synthesis of design.

Chapter 7 looks into the future scope and concludes the report.

References are mentioned in the end.

3

CHAPTER 2

SWP BUS SPECIFICATIONS,

PRINCIPLE, ARCHITECTURE AND

CHARACTERISTICS

4

2.1 DEFINITIONS, SYMBOLS, ABBREVIATIONS AND CODING COVENTIONS

2.1.1 Definitions

Contactless frontend: circuitry in the terminal which:

handles the analogue part of the contactless communication;

handles communication protocol layers of the contactless transmission link;

Exchanges data with the UICC.

Full duplex: Simultaneous bidirectional data flow

Half duplex: Sequential bidirectional data flow

Master: entity which provides the S1 signal

Reader mode: mode where the UICC act as a contactless reader through the CLF

State H: high electrical level of a signal (voltage or current)

State L: low electrical level of a signal (voltage or current)

S1: signal from the master to a slave

S2: signal from the slave to the master

Slave: entity which is connected to the master and provides the S2 signal

2.1.2 Symbols

For the purposes of the present document, the following symbols apply:

Gnd Ground

T Bit duration

TH1 Duration of the state H for coding a logical 1 of S1

TH0 Duration of the state H for coding a logical 0 of S1

Vcc Supply Voltage

VIH Input Voltage (high)

VIL Input Voltage (low)

5

VOH Output Voltage (high)

VOL Output Voltage (low)

2.1.3 Abbreviations

For the purposes of the present document, the following abbreviations apply:

ACT ACTivation protocol

CLF ContactLess Frontend

CLK CLocK

CLT ContactLess Tunnelling

CRC Cyclic Redundancy check

EOF End Of Frame

HDLC High level Data Link Control

I/O Input/Output

ISO International Organization for Standardization

LLC Logical Link Control

LPDU Link Protocol Data Unit

LSB Least Significant Bit

MAC Medium Access Control

MSB Most Significant Bit

REJ Reject

RF Radio Frequency

RFU Reserved for Future Use

RNR Receive Not Ready

RR Receive Ready

RST ReSeT

SREJ Selective Reject

SHDLC Simplified High Level Data Link Control

SOF Start Of Frame

SWIO Single Wire protocol Input/Output

SWP Single Wire Protocol

6

2.2 PRINCIPLE OF THE SINGLE WIRE PROTOCOL

The SWP interface is a bit oriented point-to-point communication protocol between a UICC and

a contactless frontend (CLF) as shown in figure 2.1.

The CLF is the master and the UICC is the slave.

Fig. 2.1 SWP data transmission

The principle of the Single Wire Protocol is based on the transmission of digital information

in full duplex mode:

The signal S1 is transmitted by a digital modulation (L or H) in the voltage domain.

The signal S2 is transmitted by a digital modulation (L or H) in the current domain.

When the master sends S1 as state H then the slave may either draw a current (state H) or

not (state L) and thus transmit S2. With pulse width modulation bit coding of S1, it is possible to

transmit a transmission clock, as well as data in full duplex mode. S2 is meaningful only when

S1 is in state H.

7

2.3 SYSTEM ARCHITECTURE

Fig 2.2 CLF-UICC physical link

Figure 2.2 represents the physical link between the CLF and the UICC. The contact C6 of the

UICC is connected to the CLF for the transmission of S1 and S2.

8

2.4 ELECTRICAL CHARACTERISTICS

2.4.1 Operating conditions

The voltage levels for the CLF (Master) and the UICC (Slave) signal S1 are illustrated in figure

3.3.

Fig 2.3 Voltage definitions for the signal S1

VIH and VIL refer to the receiving device signal level (Slave). VOH and VOL refer to the

sending device signal level (Master). All voltages are referenced to Gnd.

The SWP interface uses a second signal S2 which is the current from the master to the slave and

allows data to be sent back from the slave to the master. S2 values are defined when S1 is state

H.

9

Fig 2.4 Definitions of the current level for S2 on SWIO

2.4.2 Signal S1

S1 is a signal in the voltage domain to transmit data from the CLF to the UICC on SWIO

(contact C6). S1 shares the same electrical contact as S2

2.4.3 Signal S2

S2 is a signal in the current domain to transmit data from the UICC to the master. S2 shares the

same electrical contact as S1 (contact C6). S2 is considered as in state H when the current drawn

on SWIO is between IH min and IH max and is considered in state L when the current drawn on

SWIO is between IL min and IL max.

Table 2.1 Electrical characteristics of SWIO for S2 under normal operating conditions

10

2.5 PHYSICAL TRANSMISSION LAYER

2.5.1 S1 Bit coding and sampling time (Self-synchronizing code)

The bit coding of S1 is illustrated in figure 2.5.

Fig 2.5 Bit-coding of S1

The nominal duration of the state H for a logical 1 is 0.75 x T, the nominal duration of the state

H for a logical 0 is 0,25 x T.

All bits shall be transmitted consecutively. A bit is defined as having two rising edges. These

rising edges constitute the beginning and end of the bit period.

11

2.5.2 S2 switching management

S2 is valid only when S1 is in state H. Figure 2.6 illustrates the timing of S2 related to S1.

Fig 2.6 S2 timing

2.6 DATA LINK LAYER

Overview

The Data Link layer manages LPDUs (Link Protocol Data Units) as illustrated in figure below.

This layer can be divided into two sub-layers:

• MAC layer is in charge of framing.

• LLC layer is in charge of error management and flow control.

Fig 2.7 Data link layer overview

12

2.7 Medium Access Control (MAC) layer

2.7.1 Bit order

The bit order of the SWP communication channel is MSB first.

2.7.2 Structure

Figure 2.8 illustrates the format of a frame sent from the master to the slave.

Fig 2.8 Frame structure sent by master

The SOF flag has the value '7E' and the EOF flag has the value '7F'.

Illustrates the format of a frame sent from the slave to the master.

Fig 2.9 Frame structure sent by slave

The payload size is limited to 30 bytes. The CRC field is 16 bits long.

13

2.7.3 Bit Stuffing:

In order to unambiguously detect the SOF and EOF flags, zero bit stuffing shall be employed

by the transmitting entity when sending the payload and the CRC on SWP. After five

consecutive bits with the logical value 1, a bit with the logical value 0 is inserted. If the last five

bits of the CRC contain the logical value 1, then no bit with the logical value 0 will be added.

The receiver shall recognize the stuffed bits and discard them.

Fig 2.10 Zero bit stuffed sequence

2.7.4 Error detection

The detection of errors in a frame is based on the standard CRC-16 CITT. The CRC

polynomial is: X16+X12+ X5+1.

Its initial value is 0xFFFF.

The CRC is computed on the bits between SOF and EOF both excluded.

14

2.8 Supported LLC layers

Three Logical Link Control (LLC) layers using the previously defined MAC layer are

SHDLC: This is the generic LLC used during most of the contactless transactions.

SHDLC . Support of this LLC in mandatory in the CLF and the UICC.

CLT: This LLC is used for some proprietary protocol handling. CLT mode is defined in

clause 11 CLT LLC definition. Support of this LLC is optional in the CLF and optional

(application dependant) in the UICC.

ACT: This LLC consist of frames used during interface activation. Support of this LLC is

mandatory in the CLF and the UICC.

Fig 2.11 LLC Control field coding

The control field is the first byte of the SWP frame payload.

15

The LPDUs payload shall be structured according to figure 2.12

Fig 2.12 LPDU structure of the 3 defined LLC layers

16

2.9 ACT LLC definition

The ACT LPDU shall be structured according to figure 2.13

Fig 2.13 ACT LPDU structure

Coding of ACT TYPE:

Meaning of FR in a frame when received by the UICC:

o FR = 1: The UICC shall repeat the last sent ACT frame.

o FR = 0: The UICC shall not repeat the last ACT frame.

Meaning of FR in a frame when received by the CLF:

o The CLF shall ignore the FR bit.

A frame sent from the UICC to the CLF shall have the FR bit set to 0.

Meaning of INF in a frame when received by the CLF:

o INF = 1: Last byte of ACT payload contains the ACT_INFORMATION field.

o INF = 0: ACT_INFORMATION field not available.

Meaning of INF in a frame when received by the UICC:

o The UICC shall ignore the INF bit.

A frame sent from the CLF to the UICC shall have the INF bit set to 0.

The meaning of ACT_CTRL and ACT_DATA is given in table 2.2

17

Table 2.2 The meaning of ACT_CTRL and ACT_DATA

2.10 SHDLC LLC definition

The SWP SHDLC layer is responsible for the error-free transmission of data between network

nodes.

The SHDLC layer shall ensure that data passed up to the next layer has been received exactly

as transmitted (i.e. error free, without loss and in the correct order). Also, the SHDLC layer

manages the flow control, which ensures that data is transmitted only as fast as the receiver may

receive it.

SHDLC ensures a minimum of overhead in order to manage flow control, error detection and

recovery. If data is flowing in both directions (full duplex), the data frames themselves carry all

the information required to ensure data integrity.

The concept of a sliding window is used to send multiple frames before receiving confirmation

that the first frame has been received correctly. This means that data may continue to flow in

situations where there may be long "turnaround" time lags without stopping to wait for an

acknowledgement.

18

2.10.1 Endpoints

SHDLC communication occurs between two endpoints. Those endpoints are identified as the

CLF and the UICC. There is no priority of traffic.

Fig 2.14 End points

2.10.2 SHDLC frame types

SHDLC uses several types in order to transfer data and to manage or supervise the

communication channel between the two endpoints (ends of the communication channel):

I-Frames (Information frames): Carry upper-layer information and some control

information. I-frame functions include sequencing, flow control, and error detection and

recovery. I-frames carry send and receive sequence numbers.

S-Frames (Supervisory Frames): Carry control information. S-frame functions include

requesting and suspending transmissions, reporting on status, and acknowledging the

receipt of I-frames. S-frames carry only receive sequence numbers.

U-Frames (Unnumbered Frames): Carry control information. U-frame functions

include link setup and disconnection, as well as error reporting. U-frames carry no

sequence numbers.

19

2.10.3 Control Field

The SHDLC control field has the structure described in table 2.3, including the first bits of the

payload.

Table 2.3 SHDLC Control field coding

where:

N(S): Number of the information frame

N(R): Number of next information frame to receive

TYPE: Type of S-Frame

M: Modifier bits for U-Frame

The size of the sliding window is four frames by default. Frames types may be interleaved. For

example, a U-Frame may be inserted between I-Frames.

2.10.4 I-Frames coding

The functions of the information command and response is to transfer sequentially numbered

frames, each containing an information field, which might be empty, across the data link.

2.10.5 S-Frames coding

Supervisory(S) commands and responses are used to perform numbered supervisory functions

such as acknowledgment, temporary suspension of information transfer, or error recovery.

Frames with the S format control field do not contain an information field.

Supervisory Format commands and responses are as follows:

20

RR: Receive Ready is used by an endpoint to indicate that it is ready to receive an

information frame and/or acknowledge previously received frames.

RNR: Receive Not Ready is used to indicate that an endpoint is not ready to receive any

information frames or acknowledgments.

REJ: Reject is used to request the retransmission of frames.

SREJ: Selective Reject is used by an endpoint to request retransmission of specific

frames. An SREJ shall be transmitted for each erroneous frame; each frame is treated as a

separate error. Only one SREJ shall remain outstanding on the link at any one time.

The type coding is given by the table 2.4

Table 2.4 Type coding of the S-frames

2.10.6 U-Frames coding

The unnumbered format commands and responses are used to extend the number of data link

control functions. The unnumbered format frames (see clause 10.4) have 5 modifier bits which

allow for up to 32 additional commands and responses. Only a subset of the HDLC commands

and responses are used for SHDLC:

RSET: Reset of the data link layer is used to reset the sequence number variables in the

both endpoints.

UA: Unnumbered Acknowledgment is used to acknowledge the receipt and acceptance

of a RSET command.

21

Table 2.5: Modifier coding of the U-frames

2.10.6 .1 RSET frame payload

The RSET frame has 2 optional bytes in order to provide the endpoint window size and

capabilities. The number provided for the endpoint size shall be between 2 to 4 inclusive. In case

this RSET frame is sent in response to a received RSET frame, the endpoint size value shall be

lower than the previously provided value. The second optional byte may be sent after the

window size by the endpoint in order to indicate support of optional endpoint capabilities.

Fig 2.15 RSET frame payload

2.10.6 .2 UA frame payload

The UA frame carries no payload.

2.10.6 .3 Variables

These three variables are modulo 8 and hold sequence numbers.

22

N(S): Sequence number for emission. Used in I Frames. Incremented after emission of

the frame.

N(R): Next sequence number for reception. Used in I and S type frames.

During full duplex data transmission or by emission of a S type frame, all received frames with a

sequence number lower than N(R) are acknowledged.

DN(R): Lowest unacknowledged sequence number.

Acknowledgements are outstanding for frames between DN(R) and N(S).

To know if a frame is in the window, sequence numbers are compared using modulo 8.

The definition used for X <= Y < Z modulo 8 is as follows:

If X <= Z then the equation to calculate is: X <= Y < Z

Otherwise the equation to calculate is: Y >= X or Y < Z

2.10.6 .4 Initial Reset State

The following initial states shall apply in every endpoint after successful link establishment:

N(S) = N(R) = DN(R) = 0.

2.10.6 .5 Data flow

Once the link is established, both endpoints may exchange data.

The CLF sends a stream of data. The UICC has no data to send. The UICC shall acknowledge

frame reception regularly in order to avoid traffic stop. An acknowledge timeout is used in order

to send RR frames to the CLF. The timeout starts at the first received packet after the previous

acknowledgement.

Fig 2.16 One way data flow with RR frames acknowledgement

23

CHAPTER 3

SWP MASTER CONTROLLER

24

3.1 BLOCK DIAGRAM

Fig 3.1 Block Diagram

25

S

W

P

I

N

T

E

R

F

A

C

E

C

P

U

I

N

T

E

R

F

A

C

E

FIFO

7X16 UICCS2

R/W

ADDRESS

DATA

CLK

RESET

CS

CLF

CLK CLOCK

DIN DOUTOU

WT RD

S1

3.2 DESCRIPTION

3.2.1. CPU interface

The CPU interface facilitates the communication between the processor module and the

ASYNC FIFO. The CPU interface makes use of the R/W signal to write the data on to the FIFO.

The data is send through the DATA pin of the CPU interface. The FIFO is selected only if the

Chip Select (CS) is ‘1’ and the MSB of address is ‘1’. The CPU interface only performs the write

operation on the FIFO.

3.2.2 Asynchronous FIFO

The asynchronous FIFO is a 16 bit FIFO having 7 address locations to store the data. The

FIFO has read, write, din, clk, clock as the inputs and dout as the output. As mentioned the FIFO

works on two clocks. That is the reading operation is performed on the low frequency clock

(clock) and the writing operation is performed on the high frequency clock (clk). The FIFO is

written on to by the CPU interface and the FIFO is read by the SWP interface. The din line is

connected to the data line of the CPU interface.

3.2.3 SWP interface

The SWP interface is the part where the majority of the operations take place. This

interface sends and receives the activation, link and information frames, stores the received

frames. This interface does bit stuffing, bit de-stuffing actions on the data being sent and

received respectively. This interface is also responsible for the change of states from one to

another. The SWP interface sends the data to the UICC on the S1 line (voltage domain) and

receives the data from UICC on S2 line (current domain).

26

3.3 FLOWCHARTS

3.3.1 Activation Interface

27

START

S2=0? And reset = 0?

If State = ActSync

If ACTpowerframe is sent correctly

State = ActSync

ACTsyncframe received?

State = Actpower

State = Idle

If State = Actpower

CLF receives actsync frame from UICC.

ACTsyncframe <= s2

CLF sends actpower frame to UICC after stuffing. ACTpowerframe <= s1

State = Actready

If State = Actready

CLF receives actready frame from UICC.

ACTreadyframe<= s2

ACTreadyframe received?

State = Link Establishment

NO

YES

YE

YE

YE

YE

YE

YE

3.3.2. Link establishment state

28

If State= Link Establishment

State = linkrset mode

If LINKrsetframe

is sent correctly

LINKuaframe received?

If State = linkua

State = linkua

CLF sends linkrset frame to UICC after stuffing. LINKrsetframe<= s1

CLF receives linkua frame from UICC.

LINKuaframe <=s2

If State = linkrset

State = information

YE

YE

YE

YE

YE

3.3.3 Information transfer state

29

If State = information

If dn(r) < y <=n(s)

CLF sends I(n(s)) frame on S1 and fetches data from FIFO while bit stuffing.

If n(s) < dn(r) + window

dn(r) = y n(s) = n(s) + 1

If n(s) = 3 or 6

UICC starts sending receive ready frames on S2 to CLF. CLF stores it in receiveready after bit destuffing.

NO

YES

YES

YE

NO

ACTIVATION INTERFACE:

Initially when Reset = 1 state is IDLE. When Reset becomes 0 and S2 become 0 the state

changes to ACTSYNC.

If state changes to ACTSYNC the UICC send the ACTSYNCFRAME on S2 after bit

stuffing it. The CLF receives the frame and stores the frame in the actsyncframe register

after bit de stuffing it. Actsyncframe register = “7E61FFED4FBB7F”.

If the ACTSYNCFRAME is received correctly then the state changes to ACTPOWER

MODE.

In ACTPOWER mode the CLF sends the ACTPOWERFRAME on S1 after stuffing it.

The frame while being sent is also stored in actpowerframe register. Actpowerframe

register after stuffing = “7E620160667F”.

If the ACTPOWERFRAME is sent correctly then the state changes to ACTREADY

MODE.

In ACTREADY mode the UICC sends the ACTREADYFRAME on S2 after stuffing it.

The CLF receives the frame and stores the frame in the actreadyframe register after bit de

stuffing it. Actreadyframe register = “7E608D567F”.

If the ACTREADYFRAME is received correctly then the state changes to LINKRSET

MODE.

LINK ESTABLISHMENT:

In LINKRSET mode the CLF sends the LINKRSETFRAME on S1 after stuffing it. The

frame while being sent is also stored in linkrsetframe register. Linkrsetframe register after

stuffing = ”7E”&”F882003E66”&”11”.

If the LINKRSETFRAME is sent correctly then the state changes to LINKUA MODE.

In LINKUA MODE the UICC sends the LINKUAFRAME on S2 after stuffing it. The

CLF receives the frame and stores the frame in the linkuaframe register after bit de

stuffing it. linkuaframe register = ”7EE67C187F”.

If the LINKUAFRAME is received correctly then the state changes to INFORMATION

MODE.

INFORMATION MODE:

30

If the state is INFORMATION MODE, then if n(s) >= dn(r) + window, then if dn(r) < y

<=n(s), then dn(r) = y.

Else if n(s) < dn(r) + window, then the CLF sends information frames on S1 line to the

UICC after bit stuffing them.

After every frame n(s) is incremented by 1 and the condition is checked again.

After successful reception of three frames the UICC sends confirmation to the CLF.

31

CHAPTER 4

SIMULATION RESULTS AND

SYNTHESIS

32

4.1 IDLE STATE

Fig 4.1 idle state

The above simulation waveform shows that the state is “idle” when reset is high or s2 is high. As

soon as UICC pulls down the s2 line low and reset is low, state changes from “idle” to “actsync”

When reset=’1’ or s2=’1’ (initially)

state = idle

when reset=’0’ and s2=’0’ (initially)

state = actsync

4.2ACTSYNC STATE

33

Fig 4.2 actsync state

CLF receives actsync frame on s2 line which was bit stuffed by UICC. CLF stores it in

actsyncframe[55:0] signal after bit de stuffing.

Before bit de stuffing frame value is ”7E61F7DB53E7”&”011”&”7F”.

After bit de stuffing frame value is ”7E61FFED4FBB7F”.

The above simulation waveform shows that when actsyncframe[55:0] = x”7E61FFED4FBB7F”

is received correctly then state changes from actsync to actpower.

4.3 ACT POWER STATE

34

Fig 4.3 act power state

CLF sends actpower frame on s1 line to UICC with bit stuffing it and stores in

actpowerframe[47:0] signal. Before bit stuffing frame value is x”7E620160667F”

After bit stuffing frame value is x”7E620160667F”.

The above simulation waveform shows that when actpowerframe[47:0] = x”7E620160667F” is

received correctly then state changes from actpower to actready.

4.4 ACTREADY STATE

35

Fig 4.4 act ready state

CLF receives actready frame on s2 line which was bit stuffed by UICC. CLF stores it in

actreadyframe[39:0] signal after bit de stuffing.

Before bit de stuffing frame value is x”7E608D567F”

After bit de stuffing frame value is x”7E608D567F”

The above simulation waveform shows that when actreadyframe[39:0] = x”7E608D567F” is

received correctly then state changes from actready to linkrset.

4.5 LINKRSET STATE

36

Fig 4.5 link rset state

CLF sends linkrset frame on s1 line to UICC with bit stuffing it and stores in linkrsetframe[57:0]

signal. Before bit stuffing frame value is x”7EF904007D9B7F”.

After bit stuffing frame value is x”7E”&”F882003E66”&”11” .

The above simulation waveform shows that when linkrsetframe[57:0] =

x”7E”&”F882003E66”&”11” is received correctly then state changes from linkrset to linkua.

4.6 LINKUA STATE

37

Fig 4.6 link ua state

CLF receives linkua frame on s2 line which was bit stuffed by UICC. CLF stores it in

linkuaframe[39:0] signal after bit destuffing.

Before bit destuffing frame value is x”7EE67C0C”&”0”&”7F”

After bit destuffing frame value is x”7EE67C187F”

The above simulation waveform shows that when linkuaframe[39:0] = x”7EE67C187F” is

received correctly then state changes from linkua to information.

4.7 INFORMATION STATE

38

Fig 4.7 data in FIFO

Data to be sent from CLF to UICC is stored in FIFO. Before activating the devices, data in

proessor is written into FIFO through processor interface. Here FIFO has 7 locations with 16 bit

data in each.

39

Fig 4.8 Information frames

CLF sends information frames on s1 line with bitstuffing and stores in infoframe[6:0][66:0]

signal. The above simulation waveform shows that all 7 frames are sent as inciof variable

increments from 0 to 6.

RECEIVE READY FRAME AFTER 1ST THREE INFORMATION FRAMES FROM

CLF & NOF(S)=3

40

Fig 4.9 receive ready 3 frame

CLF receives ready frames on s2 line from UICC after sending every 3 information frames.

It stores in receiveready[39:0] signal after bit de stuffing.

Before bit de stuffing =x”7EC308DF7F”

After bit de stuffing = x”7EC308DF7F”

The above simulation waveform displays that when CLF is sending the 4rth information frame

(I3) on s1 line, it is receiving receive ready frame from UICC as acknowledgement of 1st three

information frames (I0, I1, I2).

RECEIVE READY FRAME AFTER NEXT THREE INFORMATION FRAMES WHEN

NOF(S) =6

41

Fig 4.10 receive ready frame 6

CLF receives ready frame on s2 line from UICC after sending next 3 information frames.

It stores in receiveready[39:0] signal after bit de stuffing.

Before bit destuffing = x”7EC6587A7F”

After bit destuffing = x”7EC6587A7F”

The above simulation waveform displays that when CLF is sending the 7rth information frame

(I6) on s1 line, it is receiving receive ready frame from UICC as acknowledgement of 1st three

information frames (I3, I4, I5).

4.8 CRC MODULE

42

Whenever digital data is stored or interfaced, data corruption might occur. For serial data the

solution is to attach a parity bit to each sent byte. This simple detection mechanism works if an

odd number of bits in a byte changes, but an even number of false bits in one byte will not be

detected by the parity check. To overcome this problem people have searched for mathematical

sound mechanisms to detect multiple false bits. The CRC calculation or cyclic redundancy

check was the result of this. Nowadays CRC calculations are used in all types of

communications. All packets sent over a network connection are checked with a CRC. Also each

data block on your hard disk has a CRC value attached to it. Modern computer world cannot do

without this CRC calculation. They are powerful, detect many types of errors and are extremely

fast to calculate especially when dedicated hardware chips are used.

CRC-CCITT (0xFFFF)

Fig 4.11 crc output

The above simulation shows that when an input is x”80”, the output obtained is x”7078” after

which enable is pulled low. This result is verified with online calculator of crc for a definite

polynomial.

43

Fig 4.12 Software implementation of crc module

Fig 4.13 Block diagram of crc

44

4.9 S1 OUTPUT

Fig 4.14 s1 output

The above simulation waveform represents the pattern in which CLF codes high or low data. A

logic 1 is represented with 75% of time period high and 25% low. A logic 0 is represented

with25% of time period low and 75% high.

4.10 ASYNC FIFO

6.10 .1 WRITE

45

Fig 4.15 FIFO write

46

6.10.2 READ

Fig 4.16 FIFO read

The above waveform shows FIFO read, write operations. FIFO write involves writing data into

FIFO locations from processor. FIFO read involves fetching data from its locations.

47

4.11 SYNTHESIS RESULTS

RTL SCHEMATIC FOR TOP MODULE

Fig 4.17 RTL SCHEMATIC

48

Fig 4.18 HDL Synthesis Report

49

Fig 4.19 Advanced HDL Synthesis Report

50

Fig 4.20 Final Report

51

Fig 4.21 DEVICE UTILIZATION SUMMARY

52

CHAPTER 5

CONCLUSIONS & FUTURE SCOPE

53

5.1 CONCLUSIONS

The NFC Master Controller (CLF) has been designed for SINGLE WIRE PROTOCOL (SWP),

simulated and synthesized. Physical transmission layer, Data Link layer which consists of MAC

and LLC layers are successfully established. The simulation output has been studied and verified

with the ETSI standards. Synthesis has been done and the synthesis output has been studied.

The code is implemented on board a XILINX, SPARTAN – 3E, 500 E FPGA. 

The output is verified and the code is suitable for hardware implementation.

Therefore we successfully implemented Single Wire Protocol using VHDL and FPGA.

5.2 FUTURE SCOPE

Currently a number of projects to put identity applications on mobile phone are underway.

In particular NFC interface is being used in card emulation mode for integration into existing

infrastructures. Up to now NFC technology is mainly used in payments and tickets for public

transport.

NFC is finding its applications in social networking situations, such as sharing contacts, photos,

videos or files, and entering multiplayer mobile games.

It can be used in smart posters which have a receiver chip in them so people can tap their phones

on them and get a link to more information, download media, etc.

Location and time recording i.e. tapping your phone at any place to record where you were and

at what date and time.

The use of mobile NFC phone as a reader for contactless smartcards can also be envisaged.

There are a number of ongoing projects to develop ways of using mobile phones as terminals for

e-ID application.

BIBILIOGRAPHY54

BOOKS

[1] Michael Roland, Christian Saminger, Josef Langer, “Packet Sniffer for the Physical Layer of

the Single Wire Protocol”.

[2] J. Bhaskar, “A VHDL Primer” Englewood Cliffs, NJ: Prentice Hall, 1995.

[3] Douglas L. Perry, “VHDL: Programming by Example”, Fourth Edition, McGraw-Hill, 2002.

IEEE ARTICLES

[1] Juntunen, A; Luukkainen, S; Tuunainen, V.K, “Deploying NFC Technology for Mobile

Ticketing Services”, 2010.

[2] Husni, E. ; Kuspriyanto, K. ; Basjaruddin, N. ; Purboyo, T. ; Purwantoro, S. ; Ubaya, H,

“Efficient tag-to-tag near field communication (NFC) protocol for secure mobile payment

Instrumentation, 2011.

REPORTS

[1] Smart Cards; UICC - Contactless Front-end (CLF) interface; Part 1: Physical and data link

layer characteristics (Release 7), European Telecommunications Standards Institute Std. ETSI

TS 102 613, Rev. 7.1.0, February 2008.

[2] Smart Cards;Test specification for the Single Wire Protocol (SWP) interface; Part 1:Terminal

features (Release 7) ETSI TS 102 694-1 V7.0.0, Technical Specification, (2010-04)

[3] Smart Cards; Test specification for the Single Wire Protocol (SWP) interface; Part 2: UICC

features (Release 7), (European Tele communications Standards Institute Std.) ETSI TS 102 694-

2 V7.0.0,Technical Specification,2009-2010.

WWW

[1] Available: http://www.etsi.org

[2] Available: http://www.xilinx.com

APPENDICES

55

Appendix – I

IMPLEMENTING VHDL DESIGNS USING XILINX ISE AND FPGA

A BRIEF TUTORIAL

This tutorial shows how to create, implement, simulate, and synthesize VHDL designs for implementation in FPGA chips using Xilinx ISE 9.2i and ModelSim: Xilinx Edition III v6.2g.

1. Launch Xilinx ISE from either the shortcut on your desktop or from your start menu under Programs Xilinx ISE 9.2i Project Navigator.

2. Start a new project by clicking File New Project….

3. In the resulting window, verify the “Top-Level Source Type” is VHDL. Change the “Project Location” to a suitable directory and give it what ever name you choose, e.g. “lab3”.

56

4. The next window shows the details of the project and the target chip. We will be

synthesizing designs into real chips so it important to match the target chip with the

particular board/chip you will be using. Beginning labs will be done in a Spartan 2E

XC2S200E chip that comes in a PQ208 package with a speed grade of 6 as shown

below.

57

5. Since we are starting a new design the next couple of pop-up windows aren’t

relevant, just click Next and Next and Finish .

6. You should now be in the main Project Navigator window. Select Project New

Source… from the menu.

7. In the resulting pop-up window specify a VHDL Module source and give the file a

name. I tend to just use the same name as the project itself, e.g. Lab 3.Click Next.

58

8. The next pop-up window allows you to specify your inputs and outputs through the

Wizard if you so desire. In this tutorial we will build a 2 x 1 multiplexer so we can

specify the inputs and outputs as shown below. Here, the default entity and

architecture names have also been changed. Once all inputs and outputs are entered

Click next and click Finish.

9. The project will usually open with the design summary tab active in the right hand side of your window. We want to go to the VHDL code so you need to click the *.vhd tab for yourdesign.

10. You can see that the Wizard has used STD_LOGIC as the default type for your

signals and also filled in the basic entity and architecture details for you.

59

11. Now you can fill in the rest of your code for your design. In this case, we can do the

multiplexer as shown below. Make sure to frequently save your code.

12. Once the code is entered we can proceed with a simulation of the design or we can

synthesize the code for implementation and download onto an FPGA.

60

Let us proceed with the simulation first. In the upper left-hand side of the ISE

environment there is a Sources subwindow which has a drop down box as shown

below. Note that the drop down box currently shows “Synthesis/Implementation”.

Change this to “Behavioural Simulation”.

13. Highlight your *.vhd file in the Sources sub window and then expand the “ModelSim

Simulator” selection in the Processes sub window as shown below. Click on

“Simulate

Behavioral Model” to launch the ModelSim simulator.

14. ModelSim should successfully launch and will open several sub windows by default.

For now we just need the “Wave” and “Transcript sub windows, so close the other

61

sub windows and you should see the following:

15. Now let’s look at the flow for actually synthesizing and implementing the design in the FPGA prototyping boards. Close ModelSim and go back to the Xilinx ISE environment. In the Sources sub window change the selection in the dropdown box from “Behavioral Simulation” to “Synthesis/Implementation”.

16. To properly synthesize the design we need to specify which pins on the chip all the inputs and outputs should be assigned to. In general of course we could assign the signals just about any way we want. Since we will be using specific prototype boards, we need to make sure our pins assignments match the switches, buttons, and LEDs so we can test our design. We will be starting with Digi lab 2E boards that are

62

connected to Digi lab DIO2 input/output boards. The I/O board has already been programmed and configured to have the following connections:

17. To assign specific pins, expand the User Constraints selection under the Process subwindow and double-click on Assign Package Pins.

63

18. A new application called Xilinx PACE should be launched.

19. In the Design Object List subwindow you should see a listing of all the input and output signals from our design.

Here is where we can specify which pin locations we want for each signal. Simply

enter the pins numbers from the tables shown in Step 19 above, making sure to use a

capital letter “P” in front of the pin specification. Let’s assign our signals as

Once all pins have been assigned, save your constraints by selecting File Save

from the menu bar and exit Xilinx Pace.

64

20. Back in the Xilinx ISE environment window we can now tell the computer to

synthesize our design. In the Process subwindow double-click on the Synthesize –

XST selection and wait for the process to complete. Then double-click on the

Implement Design selection and wait for the process to complete. Then double-click

on the Generate Programming File selection and wait for the process to complete. If

all goes well, you should have green checks marks for the whole design.

21. There is a lot of information you can obtain through all of the objects listed in the

Processes subwindow, but let us proceed to downloading the design onto the

prototyping board for testing. First make sure the prototyping board is connected to

the PC and has power on. Also make sure the slide switch on the FPGA board by the

parallel port is set to JTAG (as opposed to “Port”). Then select Configure Device

(iMPACT) underneath the Generate Programming File selection. You should the

65

following window

22. Now you need to specify which bitstream file to use to configure the device. For this tutorial we want to select the mux.bit file and click Open.

You will probably get the message below. Just click Yes.

66

You will also get a warning message saying the JTAG clock was updated in the

bitstream file (which is good) so just click OK. There is a way to correct for that in

the original design flow, but Xilinx automatically catches it here so I don’t usually

bother.

23. You should now see the Spartan XC2S200E chip in the main window. Right click on

the chip to prepare for downloading the bitstream file.

Select Program on the resulting window.

67

24. Click OK.

If all goes well you should get the Programming Succeeded message

25. Now just test and verify your design on the actual FPGA board.

68

69