One of References for Digital Signal Processing

8/3/2019 One of References for Digital Signal Processing

1/87


2/87

UNIVERSITY OF SOUTHAMPTON

Digital Data Transmission

by

Team C

Josh Bowman, Daniel Easton, AndrewJordan, Nicholas Reynolds, James Snowdon,

Daniel Spencer

Technical Report

Faculty of Engineering and Applied Science

Department of Electronics and Computer Science

May 4, 2007
http://www.soton.ac.uk/http://www.engineering.soton.ac.uk/http://www.ecs.soton.ac.uk/http://www.ecs.soton.ac.uk/http://www.engineering.soton.ac.uk/http://www.soton.ac.uk/


3/87

UNIVERSITY OF SOUTHAMPTON

ABSTRACT

FACULTY OF ENGINEERING AND APPLIED SCIENCE

DEPARTMENT OF ELECTRONICS AND COMPUTER SCIENCE

by Team CJosh Bowman, Daniel Easton, Andrew Jordan, Nicholas Reynolds, James Snowdon,

Daniel Spencer

The D4 design exercise involves the design, construction and test of a serial data trans-

mission system. This report covers both the design process and the final system in

detail. It is the conclusion to the design proposal submitted at the start of the project

and the goals in this are used to assess the final design. The report includes detail of

subsystems including a VHDL data source and sink implemented using Altera FPGAdevelopment boards. The design features transmission over an infrared optical channel,

a matched noise source and a robust digital clock recovery system. The contributions

of team members are outlined in individual reports. The project was highly successful

with almost all design goals completed and a full and working system demonstrated.
http://www.soton.ac.uk/http://www.engineering.soton.ac.uk/http://www.ecs.soton.ac.uk/http://www.ecs.soton.ac.uk/http://www.engineering.soton.ac.uk/http://www.soton.ac.uk/


4/87

Contents

1 Team Report 1

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Design philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Data source overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Channel Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.6 IR Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.7 IR Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.8 Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.9 Sink overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.10 Sink controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.11 Clock recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.12 USB debugging interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.13 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.14 System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.15 Performance and conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.16 Final costing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Individual I Josh Bowman 19

2.1 Overview and individual contribution . . . . . . . . . . . . . . . . . . . . 19

2.2 Management and resource allocation . . . . . . . . . . . . . . . . . . . . . 19

2.3 Clock recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4 C# test vector generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.5 VHDL Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.6 Clock recovery VHDL design . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.7 Weighted Sum ( WSUM.vhd ) . . . . . . . . . . . . . . . . . . . . . . . . . 242.8 Phase comparator (phasecomparator.vhd ) . . . . . . . . . . . . . . . . . . 25

2.9 Bit controller ( (bit)controller.vhd ) . . . . . . . . . . . . . . . . . . . . . 25

2.10 USB Interface controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.11 Simulation and testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.12 Laboratory Work and results . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Individual II Andrew Jordan 28

3.1 Design approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Serial to parallel converter . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Decoders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

ii


5/87

CONTENTS iii

3.5 Putting it all together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.6 Data Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.7 Build and Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Individual III Nicholas Reynolds 35

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3 Filter Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4 Testing of the LPFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5 Line Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.6 Clock Stabilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.7 Infrared Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.8 Eye Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Individual IV Daniel Spencer 44

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2 Low pass filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.3 Mixer circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.4 Differential line driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.5 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.6 Infra red channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.7 Amplifier Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Individual V Daniel Easton 55

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.2 Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.3 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.4 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.5 Encoders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.6 Serialiser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.7 General Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.8 Programming the FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7 Individual VI James Snowdon 64

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.2 Initial Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.3 Producing the circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.5 Further implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Bibliography 71

Appendicies 73

A Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73


6/87

CONTENTS iv

B Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73


7/87

List of Figures

1.1 Block diagram of entire system . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Data source overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Channel implementation block diagram . . . . . . . . . . . . . . . . . . . 4

1.4 IR modulation circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5 IR receiver circuit block diagram . . . . . . . . . . . . . . . . . . . . . . . 5

1.6 IR received signal to digital conversion . . . . . . . . . . . . . . . . . . . . 61.7 Block diagram of the noise generator . . . . . . . . . . . . . . . . . . . . . 7

1.8 Output waveform of the noise generator . . . . . . . . . . . . . . . . . . . 8

1.9 Block diagram of the data sink . . . . . . . . . . . . . . . . . . . . . . . . 8

1.10 Block diagram of the data sink controller . . . . . . . . . . . . . . . . . . 9

1.11 Manchester decoding on four bits . . . . . . . . . . . . . . . . . . . . . . . 9

1.12 RS232 encoding on four bits of data . . . . . . . . . . . . . . . . . . . . . 9

1.13 Block diagram of clock recovery . . . . . . . . . . . . . . . . . . . . . . . . 10

1.14 State machine for USB controller . . . . . . . . . . . . . . . . . . . . . . . 11

1.15 Differential Line Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.16 Received infrared signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.17 Received IR signal compared to filtered & amplified signal . . . . . . . . . 13

1.18 Saturated received signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.19 Eye diagram with stabilised clock . . . . . . . . . . . . . . . . . . . . . . . 14

1.20 Eye diagram with increased noise . . . . . . . . . . . . . . . . . . . . . . . 15

1.21 Photograph showing data source circuit . . . . . . . . . . . . . . . . . . . 16

1.22 Photograph showing line receiver . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 Expected data patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2 Bit period averages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3 Difference function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4 Functional diagram of weighted average unit . . . . . . . . . . . . . . . . . 242.5 Phase comparator state machine . . . . . . . . . . . . . . . . . . . . . . . 25

2.6 Controller decision flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.7 Example of clock recovery simulation . . . . . . . . . . . . . . . . . . . . . 27

2.8 USB simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1 The controller state machine . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 A screenshot showing the received message and a couple of errors . . . . . 34

4.1 Receiver block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Passive Low Pass Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 LPF simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

v


8/87

LIST OF FIGURES vi

4.4 Results of built LPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5 Line receiver circuit diagram . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.6 Waveforms for PLL using phase comparator . . . . . . . . . . . . . . . . . 39

4.7 Logic diagram of PLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.8 PLL waves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.9 Eye diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1 A simplified Sallen & Key 2nd order low pass filter stage . . . . . . . . . . 45

5.2 Block diagram showing a Butterworth filter . . . . . . . . . . . . . . . . . 45

5.3 Fourth order low pass filter . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.4 Simulation Bode plot for a Sallen & Key 2nd order filter . . . . . . . . . . 46

5.5 Simulation Bode plot for a Sallen & Key 2nd order filter . . . . . . . . . . 46

5.6 Bode Plot for the simulation of the Butterworth filter . . . . . . . . . . . 46

5.7 A unity gain summing amplifier using a standard op-amp . . . . . . . . . 47

5.8 Signal mixer circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.9 Simulation of mixer circuit . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.10 Simulation of mixer circuit . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.11 Audio bridge amplifier circuit . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.12 Simulated output from the differential line driver circuit . . . . . . . . . . 50

5.13 Simple bias circuit for infra red receiver diode . . . . . . . . . . . . . . . . 51

5.14 Scan from logbook of wave form . . . . . . . . . . . . . . . . . . . . . . . 51

5.15 Fourth order high pass filter . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.16 Bode plot for simulation of 4th order high pass filter . . . . . . . . . . . . 52

5.17 Circuit diagram of gain stage . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.18 Simulation of simple gain stage for the infra red receiver . . . . . . . . . . 53

5.19 Gain stage, gain of 50 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.1 Block diagram of data source . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2 Controller ASM chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.3 Simulated Waveform of the Data Source . . . . . . . . . . . . . . . . . . . 62

7.1 IEEE standard symbol for a random signal generator implemented as ashift register. Figure reprinted from [1] . . . . . . . . . . . . . . . . . . . . 65

7.2 Diagram illustrating simple digital to analogue converter . . . . . . . . . . 65

7.3 Illustrating the repeating nature of the random signal . . . . . . . . . . . 66

7.4 Waveform of output from random signal generator when simulated in

Modelsim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.5 Waveform of output from clock divider when simulated in Modelsim . . . 66

7.6 The completed noise generator circuit . . . . . . . . . . . . . . . . . . . . 68

7.7 Output wave from the noise generator system . . . . . . . . . . . . . . . . 69

7.8 Pspice circuit model of random signal generator . . . . . . . . . . . . . . . 70

A1 Full circuit diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77


9/87

List of Tables

1.1 USB message format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 The sequence of bytes sent to the USB module for each received byte . . . 31

4.1 PLL component values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

A1 Clock recovery coefficients . . . . . . . . . . . . . . . . . . . . . . . . . . . 73A2 VHDL files showing dependencies . . . . . . . . . . . . . . . . . . . . . . . 74

vii


10/87

Listings

3.1 Part of the VHDL testbench to simulate serial data . . . . . . . . . . . . . 29

6.1 Memory Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.2 Controller Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.3 Encoder Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.4 Serialiser Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.1 topentity.sdc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.2 source.sdc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

viii


11/87

Chapter 1

Team Report

1.1 Introduction

The D4 design exercise involves the design and test of a serial data transmission system.

A serial transmission system is one in which the data is transmitted over a single data

line without a separate clock signal. The clock must then be recovered at the receiver

and this is the primary difference between a serial and parallel system. Serial systems

commonly operate at higher bitrates than an individual data line of a parallel system

and thus transmission line effects are more significant. The data may also be expected

to cover greater distances and be subject to noise and therefore the error rejection and

recovery of a serial system are also important.

1.2 Design philosophy

The D4 design exercise is undertaken using a top-down method with subsystems allo-

cated to individual team members. This is reflected in the report which covers subsys-

tems in increasing detail. An individual report by each team member covers their own

contribution. The full task allocation is described in the project proposal, which also

outlines goals for the project.

The design philosophy of a modular system allows for the test of individual units before

integration. This was important to the design and for this reason FPGA devices were

selected for both the source and the sink. The VHDL entities for these may be fully

tested before use and even included in a simulation of the full system in the digital

domain. Testing of the channel involved meeting a specification suitable for interfacing

with the digital stages.

1


12/87

Chapter 1 Team Report 2

1.3 System overview

Figure 1.1: Block diagram of entire system

The most general view of the system may be seen in Figure 1.1, which provides an

overview of the functional modules. The source and sink as shown in this diagram are

implemented in VHDL on FPGA devices. The channel was upgraded to infrared during

the design and this was used for the final testing. The separate blocks and interfaces

are now examined in detail.

1.4 Data source overview

The requirements for the Data Source are to read data bytes from memory, encode them

so that errors can be checked and/or corrected after transmission, and then produce a

serial output with each bit of the encoded data being sent in a clock cycle. Extensions

include options for the user to either repeatedly send the data or to send it once with

the press of a button. As mentioned in the system overview, this is implemented using

VHDL and then downloaded on to an FPGA.

The data source is based on a hierarchy of functional units as represented in the block

diagram of Figure 1.2. The memory block contains the message data and is implemented

as ROM with address and data lines. This memory is read by the controller whichmanages timing of the data sends.


13/87


Figure 1.2: Data source overview

The data is then encoded by either Manchester encoding or RS232 encoding implemented

as flexible encoder blocks. Manchester encoding involves XORing the data with a clocksignal which in effect involves converting all 0s into 01 and all 1s into 10, and RS232

appends a start bit, a stop bit and a parity bit to the data byte, which are 1, 0 and even

parity respectively. In the end RS232 encoding which had been demonstrated with a

wired connection was abandoned as this is not a DC balanced scheme and therefore not

suitable for the high pass IR receiver.

The serialiser takes in the parallel encoded data and outputs this one bit at a time. It

also sends a signal to the controller informing it of how long to wait before sending the

next byte. There is a higher level entity which connects all the units together. The

higher entity models the multiplexer, sending one set of encoded data to the serialiser

depending on what the user requests, and it also informs the controller and serialiser of

when to send a synchronous pulse.

1.5 Channel Design

The channel design for the system included the hardware to take the serial data from

the data source, drive it on to a channel, receive the data and process it ready for the

data recovery and sink. This is summarised in Figure 1.3.

There were two versions for the channel implementation. The first was using a differential

line, with a 100 impedance wire. This was driven using a series of op amps to create

a differential line driver and also a mixer for the noise. The receiver was a dual line

receiver chip with two low pass filters.

In our final implementation we used an infrared channel. The emitter used was a forward

biased IR LED driven at up to 3Vp-p for short pulses. The one advantage of using IR

was that we didnt need any summing circuit for the noise. The noise generator drove a

second emitter and the receiver picked up both signals. The received signal was processed


14/87


Figure 1.3: Channel implementation block diagram

ready to be digitalised and then sent off to recover the data and clock.

The channel was created to run at a frequency of 10kHz to start with. Once the whole

system was working and tested, this was increased to 100kHz. The only change required

to the design when increasing the frequency was to the filter component values.

1.6 IR Modulation

The data signal which was being transferred across an infrared channel needed to be

processed from the FPGA before it could be transmitted by the IR emitter. The signal

from the FPGA would be a 5Vp-p square wave, but the emitter operated at 0-3Vp-p.

The line driver for our original differential line would have needed a DC offset to operate


15/87


the emitter. It was calculated that an inverting amplifier with a gain of 0.5 would suffice

[2].

Figure 1.4: IR modulation circuit

This circuit would drive a 2.5Vp-p square wave across the diode which is emitted at a

wavelength of around 880nm as a cosine wave.

1.7 IR Receiver

Using an infrared channel requires a lot of signal processing at the receiver before it can

be processed by the digital data sink. Figure 1.5 gives an overview of what is required.

Figure 1.5: IR receiver circuit block diagram

The IR receiver detects the signal from the line emitter and noise emitter. To remove

the DC offset and low frequency noise due to variations in ambient lighting, the output

needed processing through a high pass filter. The cut-off frequency needed to be no

higher than 10kHz because with RS232 encoding you can get a byte of 0s and a higher

cut off frequency would remove the data. The next stage was to amplify the signal to

above 2Vp-p, in order that the line receiver circuit can convert the wave to a 5V digital

signal.

An op-amp circuit was used since the infrared receiver circuit had very high output

impedance so the gain stage used must be impedance matched, so no signal power is

lost.


16/87


A low pass filter was used to remove the high frequency noise added to the channel

by the noise generator as well as background noise. The design consisted of an active

4th order low pass filter, consisting of two Sallen and Key filters, combined to give a

Butterworth Filter with cut off frequency 100kHz. By removing almost all the noise,

the digital signal should produce an accurate reconstruction of the sent data.

The signal needs to be converted to 5Vp-p digital level so it could be processed by the

FPGA receiver, which is done by the SN75107A. This chip is a dual line receiver and can

take differential inputs, which allowed us to use this receiver for our differential channel

as well as the infrared channel. For the infrared channel, one of the inputs was grounded

and the other input received the IR signal. The chip then ramps up the signal voltage

to Vcc or gnd depending on the signal level.

Figure 1.6: IR received signal to digital conversion


17/87


1.8 Noise

The noise generator brought together digital and analogue electronics to work with the

basic system and the advanced system. The generated noise was added to the line

driver using a summing circuit for the differential line channel. The circuit then had

to be adapted to work with the IR channel by using a second IR emitting diode and

reducing the 5Vp-p signal using a potential divider.

Figure 1.7: Block diagram of the noise generator

The noise generator consisted of two shift registers, one eleven bits in length and the

other seven bits. The last two bits of the shift registers under went EXOR operations

and were then inverted. This value was then fed back into the first bit of its respective

shift register. This was the implementation of a pseudo random signal generator, which

is based upon a design featured in a former ELEC2014 examination [1]. To produce a

signal with varying magnitude the two bits from each of these shift generators were put

into a simple digital to analogue converter making sure to weight each bit accordingly,

however exact weighting was not necessary for the noise generator.

A frequency generator was used to clock the noise generator so it was possible to vary

the frequency of the noise. This was useful at it allowed the noise generator to work

with the 10kHz system and 100kHz system. The noise used was set to be at least five

times the data rate.

1.9 Sink overview

The data sink for the system shown in Figure 1.9 was implemented on a single Altera

FPGA. Its structure consists of a hierarchy of functional units described using VHDL.


18/87


Figure 1.8: Output waveform of the noise generator

Each of the blocks shown in Figure 1.9 represent a sub unit which is explained in thefollowing sections. These blocks are linked by the highest entity TopEntity.vhd and

TopEntity test.vhd included on the CD. Pin assignments are described using an sdc file

(Listing 7.1).

Figure 1.9: Block diagram of the data sink

1.10 Sink controller

The data sink block diagram is shown in Figure 1.10. The serial data from the data

source is first converted to a parallel word which is 16 bits wide. This allows the whole

packet to be available for the decoders to operate on every time a new packet has been

received. The decoders were designed to be modular so that any number of decoders

could be written and used with few changes to the rest of the subsystem.

The Manchester decoder accepts a 16 bit word as an input and produces an 8 bit

decoded data byte as the output. Decoding is performed by looking at groups of two

bits and a received 01 is translated to a 0 when decoded, and a 10 is translated to a 1, as

demonstrated in Figure 1.11. The number of valid symbols is only half the symbol set

size so if an invalid symbol is received then an error is detected. The number of errorsproduced is summed and provided as an output.


19/87


Figure 1.10: Block diagram of the data sink controller

Figure 1.11: Manchester decoding on four bits

RS232 encoding does not encode the data byte as such, instead the data byte is paddedwith a start bit, stop bit and parity bit as shown in Figure 1.12. An even parity scheme

was used for the parity bit. The decoder stripped the start and stop bits off and then

calculated the parity of the received byte. This was then checked and any disparity

detected generated an error count output. In the final system, although both were

implemented, Manchester encoding was used instead of RS232, because a guarenteed

number of transitions was required for use with the optical channel.

A controller was required to produce valid output data which was only available after

the entire packet had been sent. The controller also waited until a special preamble

packet had been detected by the decoders, which indicated the start of the message.

Finally, the controller counted the number of received bytes and went back to waiting

for the preamble packet after the number of bytes received was greater than the message

length, which was represented by the first byte in the message.

Figure 1.12: RS232 encoding on four bits of data


20/87


The output of the data sink was interfaced with a USB module, so the controller also

generated a signal to the USB logic to tell it when a valid byte was ready on the output

and should be sent to the PC.

1.11 Clock recovery

Figure 1.13: Block diagram of clock recovery

Clock recovery in the sink takes the form of a digital phase locked loop, shown in Figure

1.13. To reduce errors first a weighted average of the previous bits is calculated in order

to minimise the effect of expected noise patterns. The peak differences in this function

are then used to find transitions in the data and the timing of these is used to find the

phase difference between the data and a reference clock. A controller unit acts on the

phase difference to correct the phase of the reference clock. The blocks from diagramin Figure 1.13 represent entities in the VHDL produced. The code implementation and

test benches are included on the CD and the design process is described in detail in

the individual report for Josh Bowman. Files WSUM.vhd, FractionalClock.vhd,

PhaseComparator.vhd and (bit)Controller.vhd. The coefficients used are listed in

Table A1.


21/87


1.12 USB debugging interface

Interfaces with USB module as per main block diagram 1.9. The USB module used is

a USB245M [3]. The USB controller implemented operates in transmit mode only and

therefore only data and transmit signals are required. Transmit is asserted, active high,

for a send and data is written into the USB send 245Ms buffer on the falling edge. To

ensure the data hold time is not violated the controller must hold the data lines for at

least 10ns [3].

Figure 1.14: State machine for USB controller

The USB controller VHDL operates as a simple state machine as shown in Figure 1.14.

This is triggered on new data and registers this data before entering the send sequence

for the message described in Table 3.1. The number of bits since the previous message

is counted and an overflow of this counter also triggers the send sequence. The VHDL

implementation of state machine and its test bench may be found on the CD (USB-

control.vhd, USBcontrol test.vhd). The test bench covers both the sending of a defined

message and timeout operation.

Standard Message Upper 4 bits Lower 4 bits

1 0xDD

2 Correction count Decoder Bit Errors

3 0x0 Comparison Bit Errors

4 Received Byte

5 Bits since last message >> 4

Alternative Message

1 0xDE

2 Bits since last message >> 4

Table 1.1: USB message format


22/87


1.13 Testing

A modular approach to testing was taken, so the smaller subunits were tested individu-

ally before testing the system as a whole. During the preparation week as much of the

design was simulated as possible using ModelSim. The whole system was simulated in

ModelSim by joining the data source serial output to the data sink input and running

a full simulation using a common data clock. This was very beneficial as it allowed

problems to be recognised easily and fixed so that when the system was tested for the

first time in the lab it worked as per the simulation.

To test the channel a square wave of 5Vp-p from a signal generator was input to the

line driver and the output from the line receiver chip (SN75107A) was displayed on an

oscilloscope. If the channel system produced a clean 5Vp-p output then we knew it

should be sufficient to use to connect the data source and sink.

As mentioned in the design stage, we first made a differential line driver and receiver

over a 100 wire. Once the subsections had been tested we connected the line driver

to the line receiver. Two signal generators were used to produce a 10kHz 5Vp-p square

wave to represent the data and a 50kHz 1Vp-p sinusoidal wave to represent the noise.

Figure 1.15 shows the inputs into the dual line receiver, which were produced by the

line driver, and the output digital signal.

Figure 1.15: Differential Line Test

This shows the differential channel between the driver and receiver was functioning

correctly.

The same method of testing was used for the infrared channel. The frequency generatorwas connected to the IR emitter driver. The received signal was filtered and amplified


23/87


to produce Figure 1.16 (running at 100kHz). Some low frequency noise on the signal

can be seen, but this did not affect the digital signal recovered.

Figure 1.16: Received infrared signal after processing and recovered digital signal

The received signal after processing was very clean. This allowed us to recover an

accurate digital signal. The comparsion between the received signal and the filtered

can be seen in Figure 1.17. This shows that the low pass filter and amplifier worked

correctly.

Figure 1.17: Received IR signal compared to filtered & amplified signal

The low frequency noise, seen in Figure 1.16, is not due to poor high pass filter design.

After testing the channel at 10kHz, we updated it to run at 100kHz. While testing the

10kHz system with no input, it was found that there was still a signal being produced at

the output. The receiver circuit naturally oscillated at about 40kHz. It is thought this

is due to the large number of op amps with feedback. This effect wasnt really noticeable

on the 10kHz system, but as can be seen from Figures 1.16 and 1.17, it affects the input

to the line receiver (SN75107A) by around 1Vp-p at 100kHz. Although it turns out thatthis natural oscillation didnt affect the digitally recovered signal, showing how robust


24/87


the SN75107A is (see Figure 1.16).

The other significant discovery during testing of our design was that the output impedance

of the low pass filter was considerably higher than the input to the line receiver chip.

This caused a loss of signal from the output of the chip. Once the output impedance ofthe filter was reduced, the system worked as expected. The system worked at a distance

of 1m, and gave a robust signal across a range of distances. Due to wiring of the supply

rails and lack of space we couldnt try for larger distances. At distances less than 10cm,

the signal became saturated removing the 50% duty cycle.

Figure 1.18: Saturated received signal

The eye diagram was created by repeatedly sampling the received data before it was

digitalised. The oscilloscope was then triggered off the stabilised clock. The eye diagram

gives us an overall view of the performance of the system.

Figure 1.19: Eye diagram with stabilised clock

The eye diagram has a reasonably open eye, which means the signal to noise ratio at

the sampling point is good. The time variation and amount of distortion is acceptable.

To give a comparison of how the eye diagram varies with conditions, the transmission


25/87


Figure 1.20: Eye diagram with increased noise

distance was increased from 1m to 1.2m. This reduced the intensity of the received

signal. You can clearly see the eye diagram is showing a lot poorer signal to noise ratio

and an increase in distortion.

1.14 System Testing

The synthesis tool (Synplify) presented some problems initially when synthesising the

VHDL data source and data sink. This was discovered to be due to a problem with thehierachy of entities and their order in the listing. Another problem with the synthesis

was updating the pin constraints, which required a new place and route to be generated

each time the constraints file was changed. In particular there was a problem with

specifying inputs/outputs and obtaining the onboard USB clock.

A fault with one of the FPGA development boards meant that the global reset button

was no longer functional. Simple test hardware was downloaded onto the FPGA to

connect the global reset to an FPGA output which confirmed it was not operational,

and so a different push button was defined for the reset input. It was also discovered

that the FPGA had a relatively low impedance input and so this was misleading when

checking that inputs were not being driven before connecting them.

The initial choice of preamble caused problems with data sink. In cases where the normal

message preamble was missed due to noise, the preamble may be incorrectly recognised

in the message data. The false start caused by this lead to a parasitic state with repeated

message data. This was fixed by changing the preamble code to one that would never

occur as any part of the serial data.

When the bit rate was increased from 10kHz to 100kHz it was found that the PC software

was running too slowly to cope with the higher speed. This was fixed by rewriting the


26/87


way the software communicated with the USB device to make it much more efficient.

Figure 1.21: Photograph showing data source circuit

Figure 1.22: Photograph showing line receiver

1.15 Performance and conclusion

The conclusion for this report draws on the design completion form and the original

design proposals by which success is measured. The original goals as outlined in the

proposal were achieved and demonstrated as recorded on the design completion form

with this report.


27/87


The project proposal outlined several levels of progress of which all were completed.

The basic specification was to achieve a functioning source and sink unit and this was

demonstrated on the first day of the laboratory week as recorded on the design com-

pletion form. Whilst only at 3 bps at this stage the design demonstrated many of the

features of the full system. These included line encoding selection, pulse shaping, chan-

nel implementation and a noise source. Two different line coding schemes were used as

specified in the proposal. The decision was made to attempt the full system by Friday

with both the IR channel and the USB system status link. This required the construc-

tion of new transmit and receive circuits suitable for infra red transmission. The system

was demonstrated early on Friday at 10kBps and later redesigned to reach the higher

speed of 100kbps. The final demonstration featured a full working system operating

at 100kbps. Bit errors which occurred infrequently without the presence of noise were

visible using the windows software tool. Clock recovery operated correctly and the result

of its operation may be seen in eye diagram in Figure 1.20. Parts were then returned to

stores as recorded.

The performance of the system meets the goals outlined in the proposal and therefore

the project is considered successful. The failings and improvements for this design

must be noted. Larger message block sizes and a greater number of encoders were not

implemented during the project due to time constraints. These changes only impact

modular VHDL and would represent a natural extension to the design. Improved line

speeds may be possible however the eye diagram indicates that the design may have

limited at as little as twice the bitrate demonstrated. The limitation at this pointbecomes slew rate of the amplifiers used, primarily the op-amp driving the LED. Further

improvements to the channel would include filtering and gain in order to increase the

maximum range of the transmission.

1.16 Final costing

Parts cost unchanged 150

Labour cost:

Design preparation 144 hours

Time during laboratory week 220 hours

Report time 150 hours

Total 514 hours at 52 per hour labour cost.

Total cost:

26900

Original estimate13240


28/87


This figure suggests that while successful the project cost is twice over the original

estimate. Much of this difference results from the inclusion of time in the laboratory

only in the original estimate. The project report also added to the time.


29/87

Chapter 2

Individual I Josh Bowman

2.1 Overview and individual contribution

The D4 design exercise proved highly successful with a full system demonstrated. My

individual contribution to this project took the form of actions as group leader and

design of subsystems. I was responsible for the design and VHDL coding of the clock

and data recovery systems and also the FPGA end USB controller. The top entity for

the data sink was produced in collaboration with Andrew Jordan. The design process is

outlined subsequently with a full listing of files produced available, initials jjb in Table

A2

2.2 Management and resource allocation

As team leader it is important to comment on management of the project. The basis

for work allocation during the D4 exercise is specified in the documentation provided by

ECS. Tasks are grouped together and allocated to individual group members. The team

leader must ensure that the sub-units of a system will interact correctly. This was done

early on in the project with block diagram outlines covering the responsibility of each

member, see proposal [4]. These areas were selected with participation from the group

in order to suit preferences for analogue or digital work. The project was managed on

ugforge, Group 295 [5]. This held recent simulations, prospective circuits, code and the

updated block diagrams to ensure compatibility.

The group project was highly successful with nearly all design goals accomplished. This

performance was shown with the demonstration of a full working system and is recorded

subsequently. Despite this success lessons should be learned from the projects fail-

ings. For example partitioning of work is not necessarily the most efficient method of

19


30/87

Chapter 2 Individual I Josh Bowman 20

allocation. Some parts invariably take longer to complete whilst the IR channel was im-

plemented early due to slack time. There is also much benefit from two people working

on VHDL and C code as demonstrated during debugging including higher rates of fault

finding. The need for strict VHDL conventions was also apparent, some group members

felt the need to use entirely active low logic. These changes were implemented during

the laboratory week.

2.3 Clock recovery

Clock recovery is required in serial data receiver circuits in order to determine the timing

of individual bits in the data transmission. In the case of digital clock recovery this

commonly takes the form of a clock generated based on transitions in the data. These

may be found using the method of over-sampling, digital sampling of the data at a rate

higher than the expected bit rate [6]. A clock recovery system must also tolerate noise

in the data stream. This may take the form of timing jitter, a variation in bit period, or

amplitude noise. Amplitude noise in a sampled digital signal may only have the effect

of complementing the data.

In order to design a clock recovery system some understanding of the expected sampled

signal is required. The recovery of the clock is not a fixed function and different meth-

ods will match better to different expected data patterns. The nature of any system

expecting noise becomes probabilistic. The system must consider minimising bit errorsand signal loss in presence of noise. A second measure is the minimum noise power that

can cause an error.

Due to the inability to spend time in the lab before the exercise the theoretical work is

based on a series of assumptions.

1. The received signal does not have square edges. Being either slew rate or bandwidth

limited ( triangular or cosine ). Higher frequency but lower amplitude noise is more

likely to complement a bit at the point of transition.

2. the data rate is low in relation to the speed of the device. Higher noise rejectionthrough oversampling and processing are the priority.

3. The noise is of a higher frequency and complements the data for less than a bit period

[6].

4. Loss or slipping of the clock is the worst case, losing all subsequent data.

Excel simulations for both sawtooth and cosine waves in the presence of noise are pre-

sented. The noise is of the form of a random value per sample between thresholds.

The bitstreams found in Figures 2.1(e) and 2.1(f) are then used as examples of expected

data as noise levels are varied. From these graphs it is clear any simplistic recoveryscheme will fail as transitions do not indicate bit boundaries. The probability of a sample


31/87


(a) Sine wave (b) Saw-tooth wave

(c) Sine wave with noise (d) Saw-tooth wave with noise

(e) Digitised sine signal (f ) Digitised saw-tooth signal

Figure 2.1: Expected data patterns


32/87


being in error is a function of its relative position in the bit period. To account for this

each bit over the sample is given a weight and added together in what is subsequently

referred to as the weighted sum. This weighted sum is compared to a threshold value to

determine the bit. In order to find edges in this function the difference between weighted

sums spaced apart by one sample period is taken. This will produce a maximum at the

midpoint of the data sample. This is shown in Figure 2.3.

(a) Uniform average (b) Weighted average

Figure 2.2: Bit period averages

Figure 2.3: Difference function

When the difference function is above a certain level, shown as Th1 on the Figure 2.3,

a peak has been observed. Smaller peaks in the presence of noise may be ignored. The

timing of this peak can be compared with a reference clock in order to determine phase

error. There is a case where two identical bits are stronger than one and the weighted

sum will peak towards the centre of the two bits. The phase differences from this shift

will be symmetric and on average produce no resultant effect.

In order to implement a full PLL system the phase differences found are used to correct

the phase or frequency of a reference clock. Digital systems add some complexity asthe frequency of local clocks may not easily be altered by non integer quantities. This


33/87


results in high levels of jitter.

Given that the run length of the data will be known in advance and assuming both

clocks are stable there is little need to match frequency. Instead phase alone will be

corrected, reducing the complexity of the design. The maximum difference in clockspeeds is determined by the size of the standard operating phase correction relative to

the oversampling rate. Where this clock difference accumulates over the maximum run

length of samples the following formula gives the maximum difference in frequencies.

max ferror =relative correction

maximum run length(2.1)

To validate the assumption of clock stability the target is considered.

The Altera FPGA board uses 14.318Mhz reference clock [7]. RS232 encoding has a

maximum run length of 10.

A phase correction of less than 103 of a full bit period is required to match a change

in the least significant figure of the reference clock frequency.

2.4 C# test vector generation

Clock recovery is not a fully deterministic system due to the presence of random noise onthe sampled data. In evaluating the function of such a module the method of exhaustive

testing was selected. A C# software program was produced to create the expected

oversampled bit patterns for a noisy raised cosine type data. The software has features

to vary the noise ratio, run lengths and oversample rate of the generated data. The

output files created contain 1 million test vectors at the oversampled rate as standard.

The software is in the form of a GUI application for a windows environment therefore

just the active functions alongside a table of external variables are included on the CD

as testvectorgeneratorcode.txt and testvectorguireferences.txt.

2.5 VHDL Design

The following conventions are used in VHDL created for the project. All signals are

active high and where the complement is used externally this is handled in the top

most entity. Unless exceptional each file has its own test bench with the test suffix.

The older naming convention is used where words are concatenate with underscored

feature action.


34/87


2.6 Clock recovery VHDL design

The VHDL entities and corresponding files created are outlined in the body of the group

project and can be seen in the block diagram shown in Figure 1.13. The justification for

this method of clock recovery is also described previously. The structure of the entities

is now described in detail.

2.7 Weighted Sum ( WSUM.vhd )

Figure 2.4: Functional diagram of weighted average unit

This entity is outlined in figure 2.4. It implements a shift register for incoming data.

The weighted sum of the previous bits is calculated and stored in a second shift register.

The difference between the weighted sum and that one bit period previously is calculated

and output along with the value from the previous cycle.

Fractional Clock is a controllable clock using fractional counts and phase corrections.

These were not used in the final design where integer adjustments were suitable.


35/87


2.8 Phase comparator (phasecomparator.vhd )

Figure 2.5: Phase comparator state machine

The phase comparator records the time since the last difference peak or rising clock edge

and analyses this using the state machine in Figure 2.5. This phase difference value is

output along with a separate signal to indicate when this is valid.

2.9 Bit controller ( (bit)controller.vhd )

The bitcontroller entity contoller.vhd is the highest level entity in the clock recovery

hierarchy. It places two registers in the data line path to avoid invalid states. It also

maps the signals between the lower entities and interprets phase differences to correct

the synthesized clock. The decision tree along with actions is shown in Figure 2.6

2.10 USB Interface controller

The USB module interface is largely described in the body of the report (Section 1.12).

It is based on a single state machine described in Figure 1.14.


36/87


Figure 2.6: Controller decision flow

2.11 Simulation and testing

In order to validate each VHDL file testing is required with suitable testbenches. These

are included for all the VHDL produced by myself. The test benches are of pass or fail

type where possible. For example the simpler entities such as weighted sum, fractional

clock and the USB controller give absolute results. The VHDL passes tests where noassertions report a FAIL.

Due to the random nature of noise a pass or fail type test bench was not suitable

for the full clock recovery system. This system was instead tested exhaustively using

1 million test vectors created for different conditions. The number of recovered bits

in error is counted and this may be used to estimate the performance of the device.

Controller test3.vhd implements this feature reading from files stream.vec and data.vec.

For analysis purposes the test bench also provides a bad bit output which may be

observed. Two conversion functions from other sources are used, available [8].

The final case is of the phase comparator which was tested using waveforms. This module

is not suited to absolute testing due to the flexibility in the value it returns. Negative

where the transition precedes the recovered clock and positive where the opposite is

true.

The simulation process was completed using Modelsim by Mentor Graphics. Extracts

from this simulation are included. The results of absolute tests are of pass or fail form

where as more complicated examples such as clock and data recovery are shown as

waves. The clock recovery function is shown in Figure 2.7. The bad bit signal is raised

for one clock period indicating the test bench has detected a bit incorrectly recovered.


37/87


This error is in response to a noisy data signal as seen in data line. The USB controller

testbench is of pass or fail type however its waveform is included as a typical example

in Figure 2.8.

Figure 2.7: Example of clock recovery simulation

Figure 2.8: USB simulation

2.12 Laboratory Work and results

During the laboratory week further development of the design was undertaken including

the top entity and pin allocation (Listing 7.1) used to link the data sink device. The

clock recovery and USB controller worked correctly and were recorded on the design

completion form. The performance and testing of the full design is found in more detail

in the body of the group report.


38/87

Chapter 3

Individual II Andrew Jordan

I was responsible for developing the data sink subsystem which received encoded data

serially and decoded it using one of a number of decoding schemes. During the de-

coding stage it was able to detect and count any errors in the received data. I also

co-developed software to read from the USB245 FIFO module and show the received

data and associated error counts on a PC.

3.1 Design approach

The data sink was implemented in hardware on an Altera FPGA using VHDL as this

allows for faster operation than a software based approach. A modular approach was

taken so the subsystem was split into functional units which corresponded to different

entities in VHDL, and a block diagram showing how the various entities are related is

shown in Figure 1.10. The advantage with this approach is it allowed the entities to

be tested individually and later connected together and tested as a whole once each

entity was operating reliably. It also made the code easier to read and use as each

entity could be treated as a black box - using it required no knowledge of the actual

implementation, and it also allowed for reuse of entities in multiple instances. Eachentity was designed to be as generic as possible to allow them to be reused in different

instances and configured with minimal changes to the VHDL code.

3.2 Serial to parallel converter

The first component to be designed and tested was the deserialiser. The input was

serial, encoded data from the receiver and the output was an n-bit data vector, where

the size n was determined later by the encoding scheme which had the largest packet

28


39/87

Chapter 3 Individual II Andrew Jordan 29

size, which in this case was Manchester encoding which had a packet size of 16 bits,

since the decoders accepted an input as wide as the packet size.

The deserialiser was implemented as a shift register in VHDL. It was then simulated and

tested with a VHDL testbench. This presented the problem of easily defining the serialdata stream for input to the deserialiser. To solve this I defined the data in a vector and

then used the loop shown in Listing 3.1 in a process to iterate through this and output

it accordingly.

1 constant s e r i al T e s t Da t a : s t d l o g i c v e c t o r ( s e r i a l D at a S i z e 1 downto 0 )

:= 0100011001100011100001111 ;

2 p r oc es s i s

3 begin

4 f o r i i n 0 to s e r i a l D a t a S i z e 1 loop

5 d a t a I n


40/87


3.4 Controller

The controller was required to ensure that valid data was output which meant waiting

for the start of the message and then incrementing a counter so that it could wait until

each new packet of data was ready and the decoders were producing valid data. It

also counted the number of received packets so that it could determine the end of the

message.

The controller was implemented as a VHDL state machine with the ASM chart as in

Figure 3.1.

Figure 3.1: The controller state machine

The counter was implemented as a separate entity to ensure a reliable counter was

produced by the synthesis tool which did not include unwanted latches or multiplexers.

In the preliminary design the controller also took the error count from the decoder as

an input and produced a running total. It was decided later that this was unnecessary

and that the error count from the decoder would be sent straight to a PC which would

create a running total instead.


41/87


The controller also compared the received data with a copy of the original data from

the data source. The data source copy was stored in a ROM block, the design for which

was modified from an example in [9].

3.5 Putting it all together

The separate entities needed to be connected together to form a working subsystem. For

this another entity was created which referenced the deserialiser, decoders and controller

and created signals to connect the various ports of these entities together. The decoding

scheme used could be chosen by the user with input switches and since more than one

decoder existed in the subsystem a multiplexer was required to choose which decoder

was in use and connect those outputs to the controller accordingly.

3.6 Data Display

A method of viewing the received data was required and since the intended data rate

was 100Kbps a PC was chosen as the most appropriate method to display this data

because of the ability to present a large amount of data for review long after it had been

received. An FTDI USB245 module was used to make communication with the system

via the USB easy.

A Windows software program was written in C#.NET to read from the USB module

and present the data. Communication with the USB module in C# was achieved by

using the D2XX driver DLL provided by FTDI and adapted C# sample code [10] to use

the interface driver DLL in C#.

A separate VHDL entity was used to interface to the USB module. When each byte was

received the USB module would clock the data into the USB module as in Table 3.1.

Clock Data In

Start code Data byte Error count [4 MSBs], Correction count [4 LSBs] Comparison error count

Table 3.1: The sequence of bytes sent to the USB module for each received byte

The software checked for the number of bytes present in the USB device continuously

once the Start button was pressed. Because of this a separate thread was required

in order to avoid locking up the UI thread, and to make this easier to handle a .NETBackgroundWorker was used. This presented a problem with cross-threadded operations


42/87


which were unsafe and so to solve this the data was passed back to the UI thread by using

an event handler to perform the UI updates such as adding the data to the ListView.

Initially the program read one byte from the USB module until it found the start code.

Once it had found this it read the next three bytes to get the data byte and variouserror counts. This worked adequately at 10Kbps bit rate but ran too slowly at 100Kbps

bit rate and used up too many resources. It was faster and more efficient to read a

number of bytes in one read operation than read one byte at a time, so the program was

modified by Josh Bowman to wait until there was a significant number of bytes in the

buffer when it then read them all at once and handled them programmatically.

3.7 Build and Test

The first thing I attempted in the lab was to get the Altera FPGA development board

operating correctly and reliably. For this a small test device was described in VHDL to

assert an output and show an input on another output. This revealed a problem with

the pin constraints definition with Synplify where I had used the wrong syntax and so

pins were not assigned properly. This was fixed by referring to the format of a working

constraints file from a different Lab. Another problem with the FPGA board was that

the global reset switch did not work because it was probably worn, so a different push

button had to be assigned for the reset.

Once reliable operation of the FPGA was established the code developed during the

preparation week was tested modularly. The deserialiser was tested first using the Digital

Testbed with an external debounced switch to provide the clock and a toggle switch to

control the data input. The output was observed n clock cycles later using the LEDs.

There were no problems with the operation of the deserialiser, so this could now be used

to test a decoder. The RS232 decoder was tested first as it was easier to test with the

Digital Testbed due to the smaller packet size. Data was clocked in serially and the

output from the decoder was observed on the hex display of the testbed. The results of

this were as expected and the input byte was shown on the display. It was not feasibleto test the operation rigorously at this stage because of the impracticality of clocking a

large stream of data in via the Digital Testbed, but nevertheless a reduced amount of

testing still proved very useful.

Testing was made easier once reliable operation of the data source was achieved. The

complete data sink could be tested now since most of it had already been tested as

individual blocks. The data source was first set up to use the 20kHz clock from the

Digital Testbed, and since this was divided as part of the design the actual data clock

was much slower.

Once the source was providing reliable serial data, it was used as an input to the data


43/87


sink and more complete testing was performed. The data clock was slow enough for

the decoded output to be observed on the Digital Testbed. The source was able to

display the correct decoded output byte on the hex display and a whole message was

demonstrated as being sent and received.

The next stage was to produce a more useful output of the data for debugging purposes

and so that a fully operational system could be demonstrated. For this the Windows

software program described in Section 3.6 was produced during the lab week. This was

tested individually by clocking data into the USB245 module with the Digital Testbed

and observing the data in the software program. The software worked as expected and

so could then be used with the data sink. Josh Bowman provided a new VHDL entity

to interface with the USB245 and clock the data structure listed in Table 3.1 into the

device.

With a reliable means to observe the decoded data the system could be run much

faster and so the system was run at 10kHz from this point forward. Valid messages

were received as expected although some problems were observed with some received

messages. This was partly due to a poorly chosen preamble byte in the first instance

which would cause a false reset and loss of the message, so this was changed to one that

could never occur as part of a message. Another problem was with detecting the end

of a message. Originally a stop byte was sent at the end to indicate to the sink when

to stop listening for more data, although this was later decided to be a poor means of

determining the end of a message and instead the message length was sent as the first

byte in the message and the controller was used to count the number of received bytes

and stop receiving based on the known message length.

Once the system was working reliably at 10kHz the rate was increased to 100kHz. This

did not affect the operation of the hardware although changes to the software to cope

with the data did have to be made as described earlier in Section 3.6. A full and working,

reliable system was demonstrated, and the screenshot in Figure 3.2.

3.8 Conclusion

The main problems during the build were due to the equipment such as the defective

FPGA development boards. The design worked well and did not require major changes

because the whole system was tested and simulated during the preparation week. This

aided the production of a fully working system by the end of the build week. All

criteria specified in the original individual design proposal were implemented at some

stage although not all parts formed part of the final working system due to technical

limitations. Specifically, RS232 encoding was tested and shown as working across a wire

but was not used for the IR channel. The total error count was used in simulation but


44/87


Figure 3.2: A screenshot showing the received message and a couple of errors

in the final design the PC performed the running total calculation because the number

of bits required for the count was too large.


45/87

Chapter 4

Individual III Nicholas Reynolds

4.1 Introduction

This report details my contribution to the D4 project. The report describes the design

and build of part of the two channels that were used. We primarily designed and built

a differential line with 100 impedance. The design was then changed and an infrared

channel was used. Both channels worked correctly and we achieved a maximum data

transfer of 10k bytes/s. I also worked on clock recovery, by taking a digitally recovered

clock with jitter and used a phase lock loop to stabilise the signal. This was then used

to produce an eye diagram.

One of my sections of the project was to create the line receiver for the differential

line. This involved taking the data signal with a raised cosine encoding and noise, then

removing the noise and manipulating the signal into a 5Vp-p square wave. This signal

was then transferred to the data and clock recovery section on our second FPGA. The

other part of my work was to recover the clock. Josh Bowman digitally recovered the

clock from the data signal, but this kind of recovery can produce a clock with jitter. We

wanted to produce a stable open eye diagram, so analogue recovery was used to stabilise

the clock.

4.2 Receiver

The receiver circuit can be spilt into 3 blocks. These consist of a filter to remove noise,

the line receiver to produce the square wave and the clock recovery. A block diagram

for this system can be seen in Figure 4.1. To remove the noise I used a passive low

pass filter. The received noise would have a frequency at least 5 times as fast as the

data. As we where firstly going to transfer data at 10kHz the noise would be 50kHz, soI used two low pass filters, with a cut off frequency of 10kHz. This would allow the data

35


46/87

Chapter 4 Individual III Nicholas Reynolds 36

through, but the noise would be reduced to a low enough voltage not to adversely affect

the receiver chip.

The line receiver needed to take around a 4.5Vp-p raised cosine encoded wave (although

it could be less) and turn this into a 5Vp-p square wave. This is just a one chip solutionin the form of a SN75107A line receiver chip. This takes both differential line inputs,

inverts one of them and adds them using basic logic to create a square wave. This signal

can then be processed to recover a clock and be decoded.

Figure 4.1: Receiver block diagram

4.3 Filter Design

I took the approach that keeping my filter simple was the best design philosophy. This

would mean fewer components, less wiring and fewer things to go wrong. For the

differential line I knew what frequency the noise would be so this just required a simple

filter with a cut off frequency of around 10kHz. The only other consideration wasimpedance matching. Our line would have an impedance of 100 to simulate real world


47/87


cable impedance. The incoming signal needed to see an impedance of 50 so that no

power was lost due to an impedance mismatch. After some simple calculations I chose

the resistor to be 33 and the capacitor of 150nF in value.

Figure 4.2: Passive Low Pass Filter

Figure 4.3: LPF simulation

As you can see, the filter lets through the 10kHz data signal but will reduce the voltage

of the noise by around 50

4.4 Testing of the LPFs

Figure 4.4: Results of built LPF

In the first lab session on Monday 23rd I built the low pass filters and tested that they

cut off correctly. As can be seen from the bode plot, it starts to cut off at 10kHz. At

50kHz the signal was reduced significantly. This concluded the testing of the filters.


48/87


4.5 Line Receiver

The line receiver SN75107A is very simple to use and wire. You just need to input both

differential lines through the filters and a square wave is output. This made for a simple

receiver for our system. Just like the basic filters, I took the approach that since there

was one chip to achieve what I required, I should use it. This meant less things to go

wrong and would make debugging more straight forward.

Figure 4.5: Line receiver circuit diagram. Figure reprinted from [11]

From Figure 4.5, it can be seen that pins 6 and 5 need to held high. The differential

inputs 1A and 1B are then summed together through the inverter, to create a square

wave. 1A and 1B were connected to the differential line channel.

To properly test the chip, a differential input was required, so I waited for the line

driver to be built. Daniel Spencer and I then tested the whole channel together. This

is a major section of the system and testing is detailed in the group report.

4.6 Clock Stabilisation

As the clock would be digitally recovered, it was decided that we would need to stabilise

this clock to remove jitter. This stabilised clock would then be used to produce an open

eye diagram. I decided the best way to do this would be to use a phase locked loop with

a voltage controlled oscillator (VCO). In the D4 specification the CD74HCT7046A was

mentioned as a possible chip to use. The chip includes a VCO with excellent frequency

linearity and a choice of two phase comparators. After reading the data sheet included

with the D4.zip [12]. I decided to use the second comparator, with positive edge-triggered

phase and frequency detection.

The output from the VCO will be the same frequency and in phase with the recovered

clock signal in (SIGin) from the FPGA. When the signals are out of phase, a voltageis produced from the comparator, which is fed back to the input of the VCO. This


49/87


Figure 4.6: Waveforms for PLL using phase comparator. Figure reprinted from [12]

voltage input causes the VCO to change its phase to match the input signal. This is

demonstrated in Figure 4.6. The phase lock loop can be used to remove jitter because

a low pass filter between the comparator output and the VCO input will remove any

sudden changes in phase, therefore removing jitter.

Figure 4.7: Logic diagram of PLL. Figure reprinted from [12]

Figure 4.7 shows the whole of my circuit for clock stabilisation. The lock detector

capacitor sets the frequency range over which the lock detector works. The resistor R1

and capacitor C1 are used to determine the frequency range of the VCO. Resistor R2 is

used to create a frequency offset to stop the VCO frequency dropping to zero. As I was

using comparator 2 this would never happen, so pin 12 was left unconnected. DEMout

was also unused. R3 and C2 determine how quickly the VCO locks on to the signalinput.


50/87


10kHz 100kHz

R1 4.7k 4.7kR2 8 8R3 56k 5.6k

C1 100n 10nC2 1n 1nCld 100n 1n

Table 4.1: PLL component values

All the component values were calculated based on W. M. Austins report [13]. Below is

an example of one of the calculations to calculate R1 and C1:

f0 = 10kHz

fmin = 0Hz

VCC = 5V

V COin range 1 to 4.5V

fosc =V COin

0.54R1C1C1 = 100nF

10k =2.5

0.54 100 109

R1 = 4.63k

For the LPF components you want the time constant to equal the reciprocal of 1.5 to 3

times the frequency [13]. I therefore picked the values of C2 and R3 based on this. The

lock detector capacitor was chosen using the CD74HCT7046A data sheet. At 100kHz

to 1Mhz a value of 1nF and 10pF is advised respectively. Based on these orders of

magnitude, I selected 100nF for our 10kHz system.

In the Lab I built the circuit in Figure 4.7 using components from Table 4.1 for the

10kHz system. To start with the circuit didnt work at all. As soon as the comparator

output was fed back into the VCO input, the VCO stopped oscillating. After a long time

debugging it started working temperamentally. One major mistake i made was i forgot

to connect pin 5 to ground. This is the inhibit for the VCO and when its not grounded,

the VCO wont oscillate. I had built the circuit on the same breadboard as my receiver,

but decided to move the PLL on to another board so the receiver could be wired into

the channel and allow me to carry on working on the PLL. Once the PLL had beenrebuilt on another board it started working as expected. I suspected that my original


51/87


build of the circuit had some lose connections causing the temperamental behaviour of

the circuit. The lock detector output was connected to an LED to form a visual display

for the lock.

Figure 4.8: PLL waves

Figure 4.8 shows what the oscilloscope looked like. The blue wave represents SIGin,

which was a 5Vp-p square produced by the signal generator. The green wave represents

the output from the VCO. The waves are in phase and as you vary the frequency of

SIGin, the output from the VCO varied accordingly. The VCO had a central frequency

of 8.8kHz, which was measured by having no input to SIGin. The range of the frequency

which the VCO could lock on to was 5.3kHz to 21kHz. This gave a good range and would

be sufficient for the 10kHz system.

4.7 Infrared Channel

After the differential channel was working correctly I assisted Daniel Spencer to build

the infrared channel. The original line driver needed to be corrected as it needed to

have a DC offset. This was due to the IR emitter, the SFH 485, working at 0-3V [14].

This type of emitter that was used as it would allow a frequency up to just over 1.5Mhz,

which would satisfy our needs. To add a DC offset we tried using a pull up resistor, but

it had no effect. We came to the conclusion that it was due to the complexity of Daniel

Spencers circuit. I redesigned the line driver to simply be an op amp with a gain of 0.5

to reduce the 5Vp-p square wave from the FPGA to a 2.5Vp-p wave to drive the IR

emitter [2]. This allowed the IR emitter to be forward biased with up to 3Vp-p pulses.

See Figure 1.4 for the circuit diagram of how this was done.

In a reversal of roles, Daniel Spencer designed and built the receiver circuit. Althoughi did not design the IR receiver i assisted in the building and testing of the circuit. The


52/87


line receiver chip was still used, but one of the inputs was grounded, as we were not

using a differential line for the IR channel.

4.8 Eye Diagram

The eye diagram produced was from our system using an infrared channel and running

at 100k bites/s. It is produced by continuously sampling the signal that was input to

the line receiver and the oscilloscope is triggered by the recovered clock.

Figure 4.9: Eye diagram

Figure 4.9 shows two eye diagrams. The first is one that is triggered from the stabilised

clock and the second is triggered using the clock with jitter. It was found that using the

stable clock did not make a larger difference to the eye diagram. The more open first

diagram was mainly due to lining up the emitter and receiver diodes better. You cansee that the clock trigger has the jitter removed in the first graph.

4.9 Conclusion

The clock stabilisation was a good learning exercise for me, although its use in the final

system was limited. The differential line receiver was simple to use and I believe the

simplicity of my designs allowed for a trouble free implementation. Although I only

designed and built a small part of the channel system, I played a big role in getting


53/87


54/87

Chapter 5

Individual IV Daniel Spencer

5.1 Introduction

During the first group meeting, I was allocated the tasks of researching, designing and

building the line driving and encoding circuitry. This was discussed further and split

into three blocks. I was to design an analogue mixer circuit to add noise, from another

circuit in the block, to the line, a differential line driver to drive a 100 ohm impedance

transmission line, and a low pass filter to shape digital pulses into a cosine wave. There

are differential line driver circuits available such as the SN7511OA or uA9636AC, how-

ever these chips have a digital input, so the noise could not be mixed in before this stage,

since the chip would remove the added noise.

5.2 Low pass filter

I first started designing the low pass filter which was to shape digital pulses. I decided

to design an active 4th order low pa

Documents

One of References for Digital Signal Processing