One of References For Digital Signal Processing

UNIVERSITY OF SOUTHAMPTON
Digital Data Transmission
by Team C Josh Bowman, Daniel Easton, Andrew Jordan, Nicholas Reynolds, James Snowdon, Daniel Spencer
Technical Report
Faculty of Engineering and Applied Science Department of Electronics and Computer Science
May 4, 2007
UNIVERSITY OF SOUTHAMPTON ABSTRACT FACULTY OF ENGINEERING AND APPLIED SCIENCE DEPARTMENT OF ELECTRONICS AND COMPUTER SCIENCE
by Team C Josh 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 transmission system. This report covers both the design process and the nal 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 nal design. The report includes detail of subsystems including a VHDL data source and sink implemented using Altera FPGA development 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.
Contents
1 Team Report 1.1 Introduction . . . . . . . . . 1.2 Design philosophy . . . . . 1.3 System overview . . . . . . 1.4 Data source overview . . . . 1.5 Channel Design . . . . . . . 1.6 IR Modulation . . . . . . . 1.7 IR Receiver . . . . . . . . . 1.8 Noise . . . . . . . . . . . . . 1.9 Sink overview . . . . . . . . 1.10 Sink controller . . . . . . . 1.11 Clock recovery . . . . . . . 1.12 USB debugging interface . . 1.13 Testing . . . . . . . . . . . 1.14 System Testing . . . . . . . 1.15 Performance and conclusion 1.16 Final costing . . . . . . . . 1 1 1 2 2 3 4 5 7 7 8 10 11 12 15 16 17 19 19 19 20 23 23 24 24 25 25 25 26 27 28 28 28 29 30
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
2 Individual I Josh Bowman 2.1 Overview and individual contribution . . . 2.2 Management and resource allocation . . . . 2.3 Clock recovery . . . . . . . . . . . . . . . . 2.4 C# test vector generation . . . . . . . . . . 2.5 VHDL Design . . . . . . . . . . . . . . . . . 2.6 Clock recovery VHDL design . . . . . . . . 2.7 Weighted Sum ( WSUM.vhd ) . . . . . . . . 2.8 Phase comparator (phasecomparator.vhd ) . 2.9 Bit controller ( (bit)controller.vhd ) . . . . 2.10 USB Interface controller . . . . . . . . . . . 2.11 Simulation and testing . . . . . . . . . . . . 2.12 Laboratory Work and results . . . . . . . . 3 Individual II Andrew Jordan 3.1 Design approach . . . . . . 3.2 Serial to parallel converter . 3.3 Decoders . . . . . . . . . . . 3.4 Controller . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . . ii
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
CONTENTS 3.5 3.6 3.7 3.8 Putting it all together Data Display . . . . . Build and Test . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii 31 31 32 33 35 35 35 36 37 38 38 41 42 42 44 44 44 47 49 50 50 52 53 55 55 55 56 57 60 60 61 62 64 64 64 67 68 68 69 71
4 Individual III Nicholas 4.1 Introduction . . . . . 4.2 Receiver . . . . . . . 4.3 Filter Design . . . . 4.4 Testing of the LPFs 4.5 Line Receiver . . . . 4.6 Clock Stabilisation . 4.7 Infrared Channel . . 4.8 Eye Diagram . . . . 4.9 Conclusion . . . . .
Reynolds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
5 Individual IV Daniel Spencer 5.1 Introduction . . . . . . . . . . 5.2 Low pass lter . . . . . . . . 5.3 Mixer circuit . . . . . . . . . 5.4 Dierential line driver . . . . 5.5 Testing . . . . . . . . . . . . 5.6 Infra red channel . . . . . . . 5.7 Amplier Stage . . . . . . . . 5.8 Conclusion . . . . . . . . . . 6 Individual V Daniel 6.1 Introduction . . . 6.2 Entities . . . . . 6.3 Memory . . . . . 6.4 Controller . . . . 6.5 Encoders . . . . 6.6 Serialiser . . . . . 6.7 General Code . . 6.8 Programming the Easton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FPGA .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
7 Individual VI James Snowdon 7.1 Introduction . . . . . . . . . . 7.2 Initial Implementation . . . . 7.3 Producing the circuit . . . . . 7.4 Testing . . . . . . . . . . . . 7.5 Further implementation . . . 7.6 Conclusion . . . . . . . . . . Bibliography
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Appendicies 73 A Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
CONTENTS B
iv
Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
List of Figures
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 1.20 1.21 1.22 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3.1 3.2 4.1 4.2 4.3 Block diagram of entire system . . . . . . . . . . . . . . . Data source overview . . . . . . . . . . . . . . . . . . . . . Channel implementation block diagram . . . . . . . . . . IR modulation circuit . . . . . . . . . . . . . . . . . . . . IR receiver circuit block diagram . . . . . . . . . . . . . . IR received signal to digital conversion . . . . . . . . . . . Block diagram of the noise generator . . . . . . . . . . . . Output waveform of the noise generator . . . . . . . . . . Block diagram of the data sink . . . . . . . . . . . . . . . Block diagram of the data sink controller . . . . . . . . . Manchester decoding on four bits . . . . . . . . . . . . . . RS232 encoding on four bits of data . . . . . . . . . . . . Block diagram of clock recovery . . . . . . . . . . . . . . . State machine for USB controller . . . . . . . . . . . . . . Dierential Line Test . . . . . . . . . . . . . . . . . . . . . Received infrared signal . . . . . . . . . . . . . . . . . . . Received IR signal compared to ltered & amplied signal Saturated received signal . . . . . . . . . . . . . . . . . . . Eye diagram with stabilised clock . . . . . . . . . . . . . . Eye diagram with increased noise . . . . . . . . . . . . . . Photograph showing data source circuit . . . . . . . . . . Photograph showing line receiver . . . . . . . . . . . . . . Expected data patterns . . . . . . . . . . . . Bit period averages . . . . . . . . . . . . . . . Dierence function . . . . . . . . . . . . . . . Functional diagram of weighted average unit . Phase comparator state machine . . . . . . . Controller decision ow . . . . . . . . . . . . Example of clock recovery simulation . . . . . USB simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 4 5 5 6 7 8 8 9 9 9 10 11 12 13 13 14 14 15 16 16 21 22 22 24 25 26 27 27
The controller state machine . . . . . . . . . . . . . . . . . . . . . . . . . 30 A screenshot showing the received message and a couple of errors . . . . . 34 Receiver block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Passive Low Pass Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 LPF simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 v
LIST OF FIGURES 4.4 4.5 4.6 4.7 4.8 4.9 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 6.1 6.2 6.3 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 A1 Results of built LPF . . . . . . Line receiver circuit diagram . Waveforms for PLL using phase Logic diagram of PLL . . . . . PLL waves . . . . . . . . . . . Eye diagram . . . . . . . . . . . . . . . . . . . . . . . . . comparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi 37 38 39 39 41 42 45 45 45 46 46 46 47 48 48 49 49 50 51 51 52 52 53 53 54
A simplied Sallen & Key 2nd order low pass lter stage . Block diagram showing a Butterworth lter . . . . . . . . Fourth order low pass lter . . . . . . . . . . . . . . . . . Simulation Bode plot for a Sallen & Key 2nd order lter . Simulation Bode plot for a Sallen & Key 2nd order lter . Bode Plot for the simulation of the Butterworth lter . . A unity gain summing amplier using a standard op-amp Signal mixer circuit . . . . . . . . . . . . . . . . . . . . . . Simulation of mixer circuit . . . . . . . . . . . . . . . . . Simulation of mixer circuit . . . . . . . . . . . . . . . . . Audio bridge amplier circuit . . . . . . . . . . . . . . . . Simulated output from the dierential line driver circuit . Simple bias circuit for infra red receiver diode . . . . . . . Scan from logbook of wave form . . . . . . . . . . . . . . Fourth order high pass lter . . . . . . . . . . . . . . . . . Bode plot for simulation of 4th order high pass lter . . . Circuit diagram of gain stage . . . . . . . . . . . . . . . . Simulation of simple gain stage for the infra red receiver . Gain stage, gain of 50 . . . . . . . . . . . . . . . . . . . .
Block diagram of data source . . . . . . . . . . . . . . . . . . . . . . . . . 56 Controller ASM chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Simulated Waveform of the Data Source . . . . . . . . . . . . . . . . . . . 62 IEEE standard symbol for a random signal generator implemented as a shift register. Figure reprinted from [1] . . . . . . . . . . . . . . . . . . . Diagram illustrating simple digital to analogue converter . . . . . . . . . Illustrating the repeating nature of the random signal . . . . . . . . . . Waveform of output from random signal generator when simulated in Modelsim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Waveform of output from clock divider when simulated in Modelsim . . The completed noise generator circuit . . . . . . . . . . . . . . . . . . . Output wave from the noise generator system . . . . . . . . . . . . . . . Pspice circuit model of random signal generator . . . . . . . . . . . . . .
. 65 . 65 . 66 . . . . . 66 66 68 69 70
Full circuit diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
List of Tables
1.1 3.1 4.1 A1 A2 USB message format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 The sequence of bytes sent to the USB module for each received byte . . . 31 PLL component values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Clock recovery coecients . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 VHDL les showing dependencies . . . . . . . . . . . . . . . . . . . . . . . 74
vii
Listings
3.1 6.1 6.2 6.3 6.4 7.1 7.2 Part of the VHDL testbench to simulate Memory Testbench . . . . . . . . . . . . Controller Testbench . . . . . . . . . . . Encoder Testbench . . . . . . . . . . . . Serialiser Testbench . . . . . . . . . . . topentity.sdc . . . . . . . . . . . . . . . source.sdc . . . . . . . . . . . . . . . . . serial data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 57 59 60 61 75 76
viii
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 dierence 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 eects are more signicant. 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 allocated to individual team members. This is reected in the report which covers subsystems 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 specication suitable for interfacing with the digital stages.
Chapter 1 Team Report
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 nal 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 which manages timing of the data sends.
Figure 1.2: Data source overview
The data is then encoded by either Manchester encoding or RS232 encoding implemented as exible encoder blocks. Manchester encoding involves XORing the data with a clock signal which in eect 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 rst was using a dierential line, with a 100 impedance wire. This was driven using a series of op amps to create a dierential line driver and also a mixer for the noise. The receiver was a dual line receiver chip with two low pass lters. In our nal 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
Figure 1.3: Channel implementation block diagram
ready to be digitalised and then sent o 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 lter 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 dierential line would have needed a DC oset to operate
the emitter. It was calculated that an inverting amplier with a gain of 0.5 would suce [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 oset and low frequency noise due to variations in ambient lighting, the output needed processing through a high pass lter. The cut-o frequency needed to be no higher than 10kHz because with RS232 encoding you can get a byte of 0s and a higher cut o 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.
A low pass lter 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 lter, consisting of two Sallen and Key lters, combined to give a Butterworth Filter with cut o 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 dierential inputs, which allowed us to use this receiver for our dierential 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
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 dierential 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 rst 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 ve 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.
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 the following 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 le (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 rst 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 errors produced is summed and provided as an output.
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 padded with 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 o and then calculated the parity of the received byte. This was then checked and any disparity detected generated an error count output. In the nal 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 rst byte in the message.
Figure 1.12: RS232 encoding on four bits of data
10
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 rst a weighted average of the previous bits is calculated in order to minimise the eect of expected noise patterns. The peak dierences in this function are then used to nd transitions in the data and the timing of these is used to nd the phase dierence between the data and a reference clock. A controller unit acts on the phase dierence to correct the phase of the reference clock. The blocks from diagram in 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 coecients used are listed in Table A1.
11
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 buer 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 overow of this counter also triggers the send sequence. The VHDL implementation of state machine and its test bench may be found on the CD (USBcontrol.vhd, USBcontrol test.vhd). The test bench covers both the sending of a dened 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
12
1.13
Testing
A modular approach to testing was taken, so the smaller subunits were tested individually 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 benecial as it allowed problems to be recognised easily and xed so that when the system was tested for the rst 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 sucient to use to connect the data source and sink. As mentioned in the design stage, we rst made a dierential 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: Dierential Line Test
This shows the dierential channel between the driver and receiver was functioning correctly. The same method of testing was used for the infrared channel. The frequency generator was connected to the IR emitter driver. The received signal was ltered and amplied
13
to produce Figure 1.16 (running at 100kHz). Some low frequency noise on the signal can be seen, but this did not aect 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 ltered can be seen in Figure 1.17. This shows that the low pass lter and amplier worked correctly.
Figure 1.17: Received IR signal compared to ltered & amplied signal
The low frequency noise, seen in Figure 1.16, is not due to poor high pass lter 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 eect wasnt really noticeable on the 10kHz system, but as can be seen from Figures 1.16 and 1.17, it aects the input to the line receiver (SN75107A) by around 1Vp-p at 100kHz. Although it turns out that this natural oscillation didnt aect the digitally recovered signal, showing how robust
Chapter 1 Team Report the SN75107A is (see Figure 1.16).
14
The other signicant discovery during testing of our design was that the output impedance of the low pass lter 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 of the lter 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 o 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
15
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 the hierachy 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 le 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 conrmed it was not operational, and so a dierent push button was dened 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 xed 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 xed by rewriting the
16
way the software communicated with the USB device to make it much more ecient.
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.
17
The project proposal outlined several levels of progress of which all were completed. The basic specication was to achieve a functioning source and sink unit and this was demonstrated on the rst day of the laboratory week as recorded on the design completion 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, channel implementation and a noise source. Two dierent line coding schemes were used as specied 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 construction 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 nal 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 point becomes slew rate of the ampliers used, primarily the op-amp driving the LED. Further improvements to the channel would include ltering 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 estimate 13240
18
This gure suggests that while successful the project cost is twice over the original estimate. Much of this dierence results from the inclusion of time in the laboratory only in the original estimate. The project report also added to the time.
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 les 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 specied 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 failings. For example partitioning of work is not necessarily the most ecient method of
19
Chapter 2 Individual I Josh Bowman
20
allocation. Some parts invariably take longer to complete whilst the IR channel was implemented early due to slack time. There is also much benet from two people working on VHDL and C code as demonstrated during debugging including higher rates of fault nding. 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 eect 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 xed function and dierent methods will match better to dierent expected data patterns. The nature of any system expecting noise becomes probabilistic. The system must consider minimising bit errors and 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 rejection through 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 presented. 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 recovery scheme will fail as transitions do not indicate bit boundaries. The probability of a sample
21
(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
22
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 nd edges in this function the dierence 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: Dierence function
When the dierence 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 dierences from this shift will be symmetric and on average produce no resultant eect. In order to implement a full PLL system the phase dierences found are used to correct the phase or frequency of a reference clock. Digital systems add some complexity as the frequency of local clocks may not easily be altered by non integer quantities. This
Chapter 2 Individual I Josh Bowman results in high levels of jitter.
23
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 dierence in clock speeds is determined by the size of the standard operating phase correction relative to the oversampling rate. Where this clock dierence accumulates over the maximum run length of samples the following formula gives the maximum dierence in frequencies. relative correction maximum run length
max ferror =
(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 10 3 of a full bit period is required to match a change in the least signicant gure 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 on the 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 les 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 le has its own test bench with the test sux. The older naming convention is used where words are concatenate with underscored feature action.
24
2.6
Clock recovery VHDL design
The VHDL entities and corresponding les created are outlined in the body of the group project and can be seen in the block diagram shown in Figure 1.13. The justication 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 gure 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 dierence 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 nal design where integer adjustments were suitable.
25
2.8
Phase comparator (phasecomparator.vhd )
Figure 2.5: Phase comparator state machine
The phase comparator records the time since the last dierence peak or rising clock edge and analyses this using the state machine in Figure 2.5. This phase dierence 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 dierences 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.
26
Figure 2.6: Controller decision ow
2.11
Simulation and testing
In order to validate each VHDL le 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 no assertions 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 dierent 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 les 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 nal case is of the phase comparator which was tested using waveforms. This module is not suited to absolute testing due to the exibility 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.
27
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.
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 decoding 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 dierent 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. Each entity was designed to be as generic as possible to allow them to be reused in dierent instances and congured with minimal changes to the VHDL code.
3.2
Serial to parallel converter
The rst 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
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 dening the serial data stream for input to the deserialiser. To solve this I dened 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 a l T e s t D a t a : 2 3 4 5 6 7 8
s t d l o g i c v e c t o r ( s e r i a l D a t a S i z e 1 downto 0 ) : = 0100011001100011100001111 ; process i s begin for i in 0 to s e r i a l D a t a S i z e 1 loop d a t a I n <= s e r i a l T e s t D a t a ( i ) ; wait f or 2 0 NS ; c l o c k p e r i o d end loop ; end process ; Listing 3.1: Part of the VHDL testbench to simulate serial data
3.3
Decoders
The next stage was to decode the data so separate decoder entities were developed for each encoding scheme used so that the subsystem could be extended by including additional decoder entities later with minimal changes to the rest of the design. Data is provided by the deserialiser all of the time so the decoder was combinational in design, producing a decoded data byte every time the encoded input data changed. Since each new data byte is only available every n clock cycles the output from the decoder will be meaningless most of the time, so a separate controller was required to only use the decoder output when the data was valid. Manchester decoding requires that the encoded data is examined in two bit chunks. The rule was that a 01 represents a decoded 0 and a 10 represents a decoded 1. A loop was used to iterate through the encoded data and form the output vector. At the same time error detection is possible by an exclusive OR of each of the two bit chunks and summing the number of zeroes from this operation. The other function of the decoders was to recognise a preamble message so that there was synchronisation of the received data stream. The preamble was chosen such that it was not valid Manchester encoding (containing more than two successive identical bits) which meant it could not form part of the message and was unlikely to appear during transmission. The check for the preamble was made in each decoder and a signal indicating the preamble had been found was sent as an output from the decoder.
30
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.
31
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 modied 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 .NET BackgroundWorker was used. This presented a problem with cross-threadded operations
32
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 various error 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 ecient to read a number of bytes in one read operation than read one byte at a time, so the program was modied by Josh Bowman to wait until there was a signicant number of bytes in the buer when it then read them all at once and handled them programmatically.
3.7
Build and Test
The rst 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 denition with Synplify where I had used the wrong syntax and so pins were not assigned properly. This was xed by referring to the format of a working constraints le from a dierent Lab. Another problem with the FPGA board was that the global reset switch did not work because it was probably worn, so a dierent 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 rst 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 rst 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 feasible to 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 rst 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
33
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 rst 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 rst 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 aect 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 specied in the original individual design proposal were implemented at some stage although not all parts formed part of the nal working system due to technical limitations. Specically, 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
34
Figure 3.2: A screenshot showing the received message and a couple of errors
in the nal design the PC performed the running total calculation because the number of bits required for the count was too large.
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 dierential 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 dierential 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 lter 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 lter. The received noise would have a frequency at least 5 times as fast as the data. As we where rstly going to transfer data at 10kHz the noise would be 50kHz, so I used two low pass lters, with a cut o frequency of 10kHz. This would allow the data 35
Chapter 4 Individual III Nicholas Reynolds
36
through, but the noise would be reduced to a low enough voltage not to adversely aect 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 solution in the form of a SN75107A line receiver chip. This takes both dierential 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 lter simple was the best design philosophy. This would mean fewer components, less wiring and fewer things to go wrong. For the dierential line I knew what frequency the noise would be so this just required a simple lter with a cut o frequency of around 10kHz. The only other consideration was impedance matching. Our line would have an impedance of 100 to simulate real world
37
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 lter 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 rst lab session on Monday 23rd I built the low pass lters and tested that they cut o correctly. As can be seen from the bode plot, it starts to cut o at 10kHz. At 50kHz the signal was reduced signicantly. This concluded the testing of the lters.
38
4.5
Line Receiver
The line receiver SN75107A is very simple to use and wire. You just need to input both dierential lines through the lters and a square wave is output. This made for a simple receiver for our system. Just like the basic lters, 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 dierential inputs 1A and 1B are then summed together through the inverter, to create a square wave. 1A and 1B were connected to the dierential line channel. To properly test the chip, a dierential 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 specication 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 voltage is produced from the comparator, which is fed back to the input of the VCO. This
39
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 lter 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 oset 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 signal input.
Chapter 4 Individual III Nicholas Reynolds 10kHz R1 R2 R3 C1 C2 Cld 4.7k 8 56k 100n 1n 100n 100kHz 4.7k 8 5.6k 10n 1n 1n
40
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.54R1 C1 C1 = 100nF 2.5 10k = 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 been rebuilt on another board it started working as expected. I suspected that my original
41
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 sucient for the 10kHz system.
4.7
Infrared Channel
After the dierential 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 oset. 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 oset we tried using a pull up resistor, but it had no eect. 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. Although i did not design the IR receiver i assisted in the building and testing of the circuit. The
42
line receiver chip was still used, but one of the inputs was grounded, as we were not using a dierential 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 rst 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 dierence to the eye diagram. The more open rst diagram was mainly due to lining up the emitter and receiver diodes better. You can see that the clock trigger has the jitter removed in the rst graph.
4.9
Conclusion
The clock stabilisation was a good learning exercise for me, although its use in the nal system was limited. The dierential 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
43
the channel system working. The IR channel was good as it allowed for a variation of system channel without adding signicant complexity.
Chapter 5
Individual IV Daniel Spencer

5.1 Introduction
During the rst 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 dierential line driver to drive a 100 ohm impedance transmission line, and a low pass lter to shape digital pulses into a cosine wave. There are dierential line driver circuits available such as the SN7511OA or uA9636AC, however 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 lter
I rst started designing the low pass lter which was to shape digital pulses. I decided to design an active 4th order low pass lter, consisting of two Sallen and Key lters, combined to give a Butterworth Filter. This has already been achieved as part of the C3 lab with details shown in the second year undergraduate handbook [15]. The Butterworth Filter consists of two stages as shown in Figure 5.2. To get the correct lter I needed the rst lter to have a Q of 0.54. This meant making the resistor labelled 2
1 Q
have a value of 0.1481. The nearest value to this in the
E12 resistor series that is available in the lab is 0.15. Using this value would give a lter with cuto frequency of 1 radian per second and Q = 0.541. The next step was to increase all of the resistor values by 1000 times and reduce all the capacitors by 1000 times. This makes no dierence to the frequency performance of the circuit. To obtain the correct cut o frequency of 10kHz, 2 10kHz = 62832, I divided each capacitor by 44
Chapter 5 Individual IV Daniel Spencer
45
Figure 5.1: A simplied Sallen & Key 2nd order low pass lter stage with a gain 1 equal to (3 Q ) and a cut o frequency, 0 of 1 radian per second [15]
Figure 5.2: Block diagram showing a Butterworth lter with a cuto frequency of 10kHz
this value giving 1.592nF. The closest real value to this using the E6 capacitor series is 1.5nF. See Figure 5.3.
Figure 5.3: Fourth order low pass lter. 10kHz cuto frequency
The next stage was to simulate the circuit using PSpice. The two circuits were drawn and individually simulated using the AC analysis tool. The -3dB point is at 10.4kHz, using the cursor in the simulation. The real life circuit components have tolerances, meaning a lter with -3dB point at exactly 10kHz is not possible. The simulation shows a at response, with a gain of 8dB up to 10kHz, as desired. The increase in gain around 300kHz is at about -100dB and will not be detectable in the real circuit.
46
Figure 5.4: Simulation Bode plot for a Sallen & Key 2nd order lter with f0 = 10kHz and K = 0.54
Figure 5.5: Simulation Bode plot for a Sallen & Key 2nd order lter with f0 = 10kHz and K = 1.31
Figure 5.6: Bode Plot for the simulation of the Butterworth lter described in the block diagram in Figure 5.2
47
5.3
Mixer circuit
The next step was to design a mixer circuit to add the digital noise signal generated by the noise generating circuit to the data signal ready to be transmitted down the line. A resistor network would be one solution to this but I decided to use a circuit based on an op-amp since op-amps have high input impedances and therefore will not draw much current from the previous circuit. This is important because the data signal comes directly from an FPGA which can only source and sink a few mA of current. The noise signal is from a Programmable Logic Device, PLD which similarly will only drive a small current. Researching active summing ampliers on the internet, I found a circuit diagram for a unity gain summing amplier as shown in Figure 5.7
Figure 5.7: A unity gain summing amplier using a standard op-amp. reprinted from [16]
Figure
This is an inverting unity gain amplier with an output equal to the sum of the two inputs V 1 and V 2. By changing the ratio of the input resistors to the feedback resistor it is possible to weight the inputs by a known factor. This is needed so that the amount of noise to be added to the circuit can be uniformly varied. The values of the resistors were changed to achieve the correct ratio required. To model the input signals I used a 10kHz cosine wave with an amplitude of 2.5V and a DC oset of 2.5V, giving a wave that oscillates between 0.0 and 5.0V, modelling a series of digital pulses at 5V. The noise was modelled in the same way, except at 200kHz A time domain (transient) simulation was run on the circuit, producing the sum of the waves as shown in Figure 5.9. Reducing the value of the resistor Rnoise in Figure 5.8 to to 20k, increases the amount of noise to the circuit. This means that the noise can be quantitavely be added to the line by simply changing the value of Rnoise in the range 20k to 300k
48
Figure 5.8: Signal mixer circuit showing new values of resistors
Figure 5.9: Simulation of mixer circuit using a 10kHz and 200kHz signal, Rnoise = 150k
49
Figure 5.10: Simulation of mixer circuit using a 10kHz and 200kHz signal, Rnoise = 20k
5.4
Dierential line driver
The next stage was to design a dierential line driver, to drive around 10mA into a 100 transmission line. This means driving a signal of 100 10mA = 1V amplitude signal into the line. The circuitry would have to be analogue, since the noise has already been added to the signal, a digital line driver would lter out all the added noise. Recalling a circuit on the internet I had found while researching for a dierent project I found an audio bridge amplier circuit, shown in Figure 5.11 below.
Figure 5.11: Audio bridge amplier circuit. Figure reprinted from [17]
The circuit is a unity gain amplier that was designed to take an input from an audio source and output the wave on the output from the rst op-amp and the inverted wave on the second op-amp. Since the voltage output swing from the mixer circuit has an amplitude of 1V, the circuit above may be used as only unity gain is required. The above circuit in Figure 5.11 was simulated with the input connected to the output of the mixer circuit, detailed above. To model the transmission line, a 100 resistor was connected between outputs, +out and out, shown in Figure 5.11, with R6 and R7 removed from the circuit.
50
Figure 5.12: Simulated output from the dierential line driver circuit in Figure 5.11
The simulation shows the signal and inverted signal both centered around 0V with an amplitude of 1V. This meets the requirements to drive the line.
5.5
Testing
I built the low pass lter onto a breadboard and tested the circuit by taking values for the output voltage from a sinusoidal input wave. I then built the mixer and dierential line driver circuits, testing that they worked correctly using one of the oscilloscopes in the lab and two signal generators, one at 10kHz and 200kHz to model the data signal and noise signal for the mixer circuit. The next stage was to test my circuit block with the line receiver circuitry. The circuits were wired together, using an two ordinary pieces of wire with a 100ohm resistor across them to model the transmission line. The line receiver correctly received the 10kHz signal, producing a square wave output at 10kHz with no problems.
5.6
Infra red channel
The last stage in the design was to try and achieve an Infra Red channel as part of the teams advanced challenge, set in preparation to be done if the simple design worked correctly. For design and testing purposes, the IR transmitter was powered directly, using a 2.0v peak to peak, 10kHz sinusoidal wave from a pulse generator with a dc oset of 1.0v. The next step was to build the receiver circuit. A simple circuit was setup as shown below to reverse bias the photodiode. The resistor chosen was an educated guess to bias
51
the diode to about half the supply voltage, the photocurrent produced was not known, but guessed as a few mA. After testing it was found that 1Mohm gave the best biasing for the photocurrent produced when the data signal was received from a distance of 1m away.
Figure 5.13: Simple bias circuit for infra red receiver diode
The receiver circuit in Figure 5.7 was built onto breadboard, the transmitter was placed 5cm away, the output from the receiver circuit was viewed on an oscilloscope. The output was a 10kHz wave of about 20mV p-p with an added higher frequency noise signal around 40kHz summed with the transmitted signal. The 40kHz noise is from the lights in the laboratory.
Figure 5.14: Scan from logbook of wave form
The output was at a DC bias level that uctuated with the ambient light level in the room. To remove the DC oset and low frequency noise due to variations in ambient lighting, the output needed a processing through a high pass lter. The cut o frequency had to be less than 1kHz. The data was to be sent at 10kHz, but a long series of 0s or
52
1s in the data means a lower frequency wave . I designed a 4th order high pass lter simulation, by combing two equal 2nd order high pass lters in series. See Figure 5.15.
Figure 5.15: Fourth order high pass lter. 10kHz cuto frequency.
Figure 5.16: Bode plot for simulation of 4th order high pass lter, -3dB cut o frequency is 765Hz
5.7
Amplier Stage
The next stage was to amplify the signal to about 5 volts peak to peak, in order that the line receiver circuit can convert the wave to a 5v digital signal ready for the next stage of the circuitry. This was done using an op-amp gain stage set to about 50, since the low pass lter explained below has a gain of 5 times. An op-amp circuit was used since the infra red receiver circuit as shown in Figure has a very high output impedance so the gain stage used must have a high input impedance. The IR system as described above was used as the transmission medium for the overall system. The system worked correctly and it was decided to try to increase the speed of the system to 100kHz. This meant that the lters needed to be adjusted to cope with the higher bandwidth data. The low pass lter and the high pass lters cut o
53
Figure 5.17: Circuit diagram of gain stage
Figure 5.18: Bode Plot for simulation of simple gain stage for the infra red receiver, gain of 50 (33dB)
frequencys were increased by 10 times, 100kHz and 10kHz respectively, to cope with the change of speed. This was done by decreasing each capacitors size by 10 times. The system worked correctly, with a range of about 1m across the bench. The gain stage was also split into two separate stages, the rst with a gain of 5 and the second with a gain of 10. This was because the Op Amps used had a 3MHz unity gain, so would have a lower than expected gain at 100kHz. See Figure 5.19.
5.8
Conclusion
The wired system worked correctly rst time which left a lot of free lab time to experiment with the Infra Red system. The nal system allowed the transmitter and receiver to be aligned o centre by up to 20 degrees, which meant even if the system was knocked sightly, it still worked. The range of 1m was fair, but a lot more work would be required to improve this. A more advanced noise lter, with higher noise rejection would be an improvement to the system, allowing an increase in transmission range, had more time
54
Figure 5.19: Gain stage, gain of 50
been allocated to the project.
Chapter 6
Individual V Daniel Easton

6.1 Introduction
At the end of the group meeting on 16th April 2007, it was decided that my task would be to write up and simulate the VHDL code for the Data Source. This is the rst block of the transmission chain, of which the objective is to read up to 255 bytes of data, encode them using one of two encoding methods and then output them one bit at a time. The chosen encoding methods were Manchester encoding, which may be implemented as a mapping of 0 to 01 and 1 to 10, and RS232 encoding, which involves appending a start bit, parity bit and a stop bit to the byte. The data source required six separate VHDL entities and architectures. As shown by the Data Source block diagram in Figure 6.1, ve of these control the memory, controller, two encoders and the serialiser, while the sixth represents the whole box, mapping to each of the other ve entities.
6.2
Entities (18th April)
Having created the block diagram, some basic entities for the ve internal blocks were written, to give myself an idea of how each block would work. At this point in time, the multiplexer and the synchronous pulse blocks in the block diagram had not yet been inserted. The memory block, being only ROM, were simply given an address byte input and a data byte output, to and from the controller block. This means that these were also an output and input byte respectively for the controller block. It also had a data byte output to send to an encoder, and a clock, a reset, a repeat 55
Chapter 6 Individual V Daniel Easton
56
Figure 6.1: Block diagram of data source
and a data size input. The latter is sent from the serialiser to inform the controller of how long to wait before sending the next byte. Another requirement given by Josh Bowman was to divide the input 100MHz clock from the FPGA board by a thousand so the data source would run at 100kHz. Therefore to enable this wait, the slower clock was set as an output to the serialiser in order to synchronise the two blocks. A question mark was placed upon having a 2 bit mode input, which would determine which encoder to use, as it had not been conrmed whether this input would be acted upon in this block or in the general code. The encoders both had a data byte input and a data output. These outputs were both to be sent to the serialiser and therefore were set to the same size coming from each encoder, while another output representing the actual size of the data was to be sent to the serialiser. As described before, the serialiser had a data input and data size input from an encoder, along with a clock input and a data size output to and from the controller. It also had the general Data Source serial output bit.
6.3
Memory (19th April)
A decent set of code was found while searching the internet at [18], in which an array of arrays is created. This was taken and edited for this purpose, where the changes made were to increase the three-bit data to eight-bit data and to increase the number of bytes
Chapter 6 Individual V Daniel Easton from eight to eighteen.
57
It was expected that at the sink the data would be displayed on an LCD, so the data was set such that it would give a recognisable word/phrase. The rst byte gives the number of remaining bytes (i.e. seventeen) and when converting the other bytes to ASCII, it would spell the chosen phrase; Manchester United. The testbench shown in Listing 6.1 was used to test the memory code. When rst tested, the waveforms showed that the data arrived in the order of last byte, followed by second byte and then rst byte. This is the opposite of what was expected, which was because 0 to 17 had been changed to the preferred 17 downto 0. Changing back gave the three data bytes in the expected order, so then I concluded the memory VHDL code was successful.
1 library i e e e ; 2 use i e e e . s t d l o g i c 1 1 6 4 . a l l ; 3 4 entity memtest i s 5 end entity memtest ; 6 7 architecture mtest of memtest i s 8 9 begin 10 11 12 13 14 end architecture mtest ;
s i g n a l add , dat : s t d l o g i c v e c t o r ( 7 downto 0 ) ; n0 : entity WORK. memory port map ( add , dat ) ; add <= x 00 a f t e r 1 0 NS , x 01 a f t e r 2 0 NS , x 11 a f t e r 3 0 NS ; f i r s t , second and l a s t memory l o c a t i o n s
Listing 6.1: Memory Testbench
6.4
Controller (19th-22nd April)
The ASM chart in Figure 6.2 was drawn up to aid with writing the VHDL code for this block. This includes the extra requirements, agreed with Andrew Jordan, of the preamble byte 0x03 being sent before the data and the stop byte 0x04 after the data. The clock divider is separate from the state machine, and simply counts on rising clock edges before inverting the slowClock signal. The rst state is idle, which is for when the data has been sent once and is not to be sent any more, and goes to start if the resend input activates. The ASM begins at the start state when reset, which stores the rst data byte as the data size, then sends for the preamble to be sent. It remains in this state while the synchronous pulse is being sent. The prewait state then waits
58
Figure 6.2: Controller ASM chart
59
for the serialiser to send the preamble before the send state sends the rst data byte. The states pause and wait8 wait for the serialiser to send the byte (encoded) before returning to send to send the next byte. When all bytes are sent, send sends the stop byte and then stop waits for this byte to be sent before checking the repeat input. If the data is to be repeated, it goes to pause2 to allow time to begin resending the synchronous pulse before returning to start. Otherwise it goes to idle. The testbench in Listing 6.2 was created, compiled and run to test the controller. A few errors included an incorrect count in the clock divider and not using ip-ops to store the count values, and several additions and changes were required later on in the preparation week, such as the synchronous pulse to aid with clock recovery. Having obtained a waveform where the output data sent to the encoders remains the same for every 16 pulses on the slow clock, I concluded the controller VHDL code was successful.
1 library i e e e ; 2 use i e e e . s t d l o g i c 1 1 6 4 . a l l ; 3 use i e e e . n u m e r i c s t d . a l l ; 4 5 entity c o n t t e s t i s 6 end entity c o n t t e s t ; 7 8 architecture c t e s t of c o n t t e s t i s 9 10 11 12
signal f a s t c l o c k t : s t d l o g i c : = 0 ; s i g n a l r e s e t t , r e p e a t t , s l o w c l o c k t , endd : s t d l o g i c ; s i g n a l mem data t , a d d r e s s t , e n c d a t a t : s t d l o g i c v e c t o r ( 7 downto 0 ) ; s i g n a l s e r i a l s i z e t : s t d l o g i c v e c t o r ( 4 downto 0 ) ; n0 : entity WORK. c o n t r o l l e r port map ( f a s t c l o c k t , r e s e t t , r e p e a t t , mem data t , s e r i a l s i z e t , a d d r e s s t , e n c d a t a t , s l o w c l o c k t , endd ) ; f a s t c l o c k t <= not f a s t c l o c k t a f t e r 1 NS ; s h o u l d make s l o w c l o c k t have a p e r i o d o f 2 US r e s e t t < = 0 , 1 a f t e r 1 0 NS , 0 a f t e r 2 0 NS ; repeat t <= 0 ; s e r i a l s i z e t <= 10000 ; endd < = 0 ; d a t a w i l l c o n t i n u e t o be s e n t mem data t <= x 02 when a d d r e s s t = x 00 e l s e x 72 when a d d r e s s t = x 01 e l s e x 54 when a d d r e s s t = x 02 e l s e XXXXXXXX ;
13 14 begin 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

30 31 end architecture c t e s t ;
60
Listing 6.2: Controller Testbench
6.5
Encoders (21st-22nd April)
At rst, the two encoders created had one applying Manchester encoding only and the other applying Manchester encoding after appending a parity bit to the data byte, where in both the Manchester encoding is done by checking each input bit separately. The parity bit was set to be odd parity, created by XORing all input bits then inverting. The testbench shown in Listing 6.3 was used to test both encoders with both giving the expected encoded data for each input byte. On the nal day before the lab, the requirements for the second encoder were made clear. The Manchester encoding was removed and a start bit and stop bit were appended. Also, Andrew had used even parity, so the inverter was removed. Retesting this gave the expected extra bits at the output, so I could conclude the two sets of encoder VHDL code work.
1 library i e e e ; 2 use i e e e . s t d l o g i c 1 1 6 4 . a l l ; 3 4 entity e n c 1 t e s t i s 5 end entity e n c 1 t e s t ; 6 7 architecture e 1 t e s t of e n c 1 t e s t i s 8 9 10 11 begin 12 13 14
s i g n a l d i n : s t d l o g i c v e c t o r ( 7 downto 0 ) ; s i g n a l dout : s t d l o g i c v e c t o r ( 1 9 downto 0 ) ; s i g n a l s i z e : s t d l o g i c v e c t o r ( 4 downto 0 ) ; n0 : entity WORK. e n c o d e r p a r i t y port map ( din , dout , s i z e ) ;
d i n <= x 54 , x 77 a f t e r 1 0 NS , x 96 a f t e r 2 0 NS ; 3 d i f f e r e n t b y t e s t o encode 15 end architecture e 1 t e s t ; Listing 6.3: Encoder Testbench
6.6
Serialiser (21st-22nd April)
This was not as complicated as the controller so an ASM was not required. Instead the serialiser had a process in which it was to either send a synchronous pulse before the data,
61
a constant low signal after the data, or the next bit of the data itself. The synchronous pulse section was added on the nal day after being informed of this requirement. The testbench in Listing 6.4 was created to test the serialiser. Many errors were found and corrected, but at the end the simulation showed the serial output outputting the data one bit at a time starting with the LSB (least signicant bit), so I could conclude the serialiser VHDL code works.
1 library i e e e ; 2 use i e e e . s t d l o g i c 1 1 6 4 . a l l ; 3 4 entity s e r 2 t e s t 6 7 architecture s 2 t e s t of s e r 2 t e s t 8 9 10 11 12 begin 13 14 15 16 17 18 19 20 21 end architecture s 2 t e s t ;
is
5 end entity s e r 2 t e s t ;
signal signal signal signal
clk : pulse din : size ,
is std logic := 0 ; , dout , endd : s t d l o g i c ; s t d l o g i c v e c t o r ( 1 5 downto 0 ) ; b i t s : s t d l o g i c v e c t o r ( 4 downto 0 ) ;
n0 : entity WORK. s e r i a l i s e r 2 port map ( c l k , p u l s e , endd , din , s i z e , b i t s , dout ) ; c l k <= not c l k a f t e r 5 NS ; p u l s e < = 1 , 0 a f t e r 3 8 NS ; s i z e <= 10000 ; b a s i c 1 6 b i t s d i n <= x 3456 ; a l l b y t e s a r e t h e same endd < = 0 , 1 a f t e r 4 0 0 NS ;
Listing 6.4: Serialiser Testbench
6.7
General Code (22nd April)
The code for the Data Sink had been written before beginning to create the general code for the Data Source, so therefore the general code for the Data Sink was taken. The names of the entities mapped to were changed, as were the signals being mapped to these entities, in order to match the required connections shown on the block diagram. Added to the general code was the multiplexer, which works by setting the serialiser inputs to the outputs from one of the encoders depending on the input mode. The 32 bit synchronous pulse is formed by sending an active signal to the controller and serialiser while counting to 32, using the slow clock taken from the controller. The signal is inactivated when the count is over, and reactivates to resend the pulse when the repeatsyncPulse signal from the controller is activated.
62
Simulating the full set of code produces the waveforms shown in Figure 6.3. In this simulation the Manchester encoder was used. The third wave is the serial output, where there is a synchronous pulse followed by a 16 bit preamble and the rst 5 data bytes. This preamble, chosen at the end of the second week, has a section with three 1s in a row and a section with three 0s in a row. This ensures that no byte can be encoded into this.
Figure 6.3: Simulated Waveform of the Data Source
6.8
Programming the FPGA (23rd-28th April)
Using Synplify, it was found that several latches were created, so these had to be converted into ip-ops. This aected the timing between the serialiser and the controller, which had to be corrected. The code was then downloaded onto the FPGA. Using an sdc le to determine the pin locations of inputs and outputs, I observed a reasonable looking serial output on the oscilloscope. For this I used the DTB (Digital Test Bed) to provide a 20kHz input clock and switches for the inputs, as I was unable to use a clock on FPGA. By this time, the Data Sink had been downloaded and tested, so we decided to check the serial output was correct by connecting it directly into the data sink, and using the hex display on the DTB, we observed the same input bytes as stored in the memory. This was using RS232 encoding, as Manchester encoding did not appear to work yet. For this I attempted changing the preamble byte (before encoding) from 0x03 to 0xA3, as the former byte did not get recognised easily, but this did not solve the problem. This was eventually sorted at the sink. In the sdc le, I added a command to dene the clock, which then allowed me to use the FPGA clocks. However, increasing the clock input from 20kHz to 48MHz made the data arrive too quickly at the sink, and we were unable to observe the display. Another problem was that the repeat input did not appear to have any eect on the program. By adding an extra output which in the code gets set to the repeat input, I observed that it was not being input. I discovered that the word repeat is a reserved verilog word, and required changing to correct this problem. Having got the repeat working, we retested the data source with the data sink, and observed that the correct data only came through the rst few times. This was because
63
the synchronous pulse, which was currently set to be sent only when reset, was required between every message. Therefore the data source had to be edited to meet these requirements. At this point the data source appeared to be working, so therefore I looked into creating an extension, and began on a replacement for the memory block, where instead of using ROM, it takes in data from an external output. However, before this could be tested, Josh requested more changes to the data source. The synchronous pulse was made longer, the clock divider was reduced and a resend button was created. The resend button was necessary because the reset button produced problems from bouncing. The resend button also bounces, but does not produce problems because it is used dierently in the code. Also, for testing purposes, all inputs were directly set as outputs. For Manchester encoding, the preamble was changed once more to the special 16 bit signal visible in Figure 6.3. We decided not to use RS232 encoding any more because it is possible to get a string of 8 low bits, which would not be suitable for the high pass IR receiver. In the end the data source did not produce any problems when grouping all sections together.
Chapter 7
Individual VI James Snowdon

7.1 Introduction
I was nominated to produce a functioning noise generator, which would produce a signal with the specication of being a pseudo random analogue waveform with varying frequency and amplitude which could run at any frequency required by the overall system. This had to run independently of the rest of the system and could be summed with a digitally encoded signal.
7.2
Initial Implementation
My initial ideas for a noise generator were to produce a random signal generator which would output a pseudo random bit every clock cycle. I chose to adapt an example of this which was given in a former examination paper set for the module ELEC2014 which can be seen in Figure 7.1. This shows that when an input is set, the bits inside the shift register are all shifted and the new rst bit is the output of an EXOR operation on the nal two bits. This will produce a pseudo random rst bit at every clock pulse. I then decided to use a digital to analogue converter, which can be seen in Figure 7.2, to produce an analogue waveform. The output waveform produced by this method is not entirely random. As the new bit each time is the EXOR of last two bits of the cycle, it is possible to predict the entire bit pattern which will be produced. For example Figure 7.3 shows the pattern which a 3 bit shift register will follow when implemented with simply the last two bits going through an EXOR operation. Figure 7.3 also shows that when the system starts up it is necessary to somehow introduce a one into the system somewhere. This was achieved in my system by simply connecting a node in the shift registers up to 1 to start the process. 64
Chapter 7 Individual VI James Snowdon
65
Figure 7.1: IEEE standard symbol for a random signal generator implemented as a shift register. Figure reprinted from [1]
Figure 7.2: Diagram illustrating simple digital to analogue converter
66
Figure 7.3: Illustrating the repeating nature of the random signal
During the preparation week I developed code for the random signal generator, however it became increasingly dicult to t this implementation onto an ispGAL chip while retaining a good length of signal before it is repeated, which resulted in my decision that it would be better to create the design using standard logic chips available in the lab. The simulation results for this code however can be seen in Figure 7.4 and it clearly illustrates the pseudo random nature of the code and the design.
Figure 7.4: Waveform of output from random signal generator when simulated in Modelsim
I also designed and created a clock divider which could be used with a resonator to produce a fully independent system which can function without the need of a function generator to provide a clock input pulse. The code for this can be seen in appendix B. This code compiled onto the chip and the simulation waveform can be seen in Figure 7.5.
Figure 7.5: Waveform of output from clock divider when simulated in Modelsim
67
7.3
Producing the circuit
I made my circuit of standard logic gates using the 74HCT series chips available in the lab. Immediately upon completion and testing of the circuit it became obvious that the cycle repeated itself too often and as an extension I should focus on making the cycle have a much longer period. There are various ways of doing this; it is possible to extend the length of the shift register, since every extra bit doubles the period of the cycle. I rst tried this and altered the shift register such that it is ten bits long, this did produce an increased period but the resulting waveform could still be improved further. After some consideration and discussion I decided that I should split the shift register into two. This incorporates ideas involved in the central limit theorem and enables me to further randomize the signal. The central limit theorem is that the sum of one or more pseudo random signals will tend towards a random signal. The problem with amending the design with this method is that the two signals will eventually synchronize again, producing a periodic signal, which is not random. I decided to make the shift registers of size 11 and 7 since these both being prime numbers, their lowest common multiple is as high as possible. For example if I had chosen 5 and 10 the size 10 shift register would only run through one loop in the time it takes the 5 shift register to run through two. With choosing size 7 and 11 the size 11 shift register will run through 7 loops and the size 7 shift register will run through 11 loops before the signals synchronize again. The shift register starts in a state where everything is equal to zero. As I mentioned earlier in order to start the system it is necessary to introduce a one into one of the ip ops in the shift register. This was simply achieved by means of a simple switch on the input to a shift register, however a tri state buer would have been a more appropriate implementation. It also became apparent that we were going to want to vary the frequency of the noise generator a lot. We decided that the frequency of the noise should be at least ve times the frequency of the transmitted data. Because every time we wanted to alter the clock frequency with the ispGAL chip it would require a new resonator and reprogramming the chip we decided that it would be a more appropriate idea to simply use a signal generator as a clock. I used weighting resistors on the digital to analogue converter in order to produce an output wave of varying magnitude. Since this was only producing random noise the exact magnitude of the weighting was not important but I chose to use a standard weighting system whereby the resistors were as close as possible to multiples of 1, 2, 4 and 8. Thus the resistors I chose upon using were 1k, 1.8k, 3.9k, and 8.2k. I also used a low pass lter in order to make the resulting waveform smoother. I chose upon a value of a 680nF capacitor for this. The nal produced circuit can be seen in Figure
Chapter 7 Individual VI James Snowdon 7.6.
68
Figure 7.6: The completed noise generator circuit
7.4
Testing
After creating the circuit we were able to produce a waveform shown in Figure 7.7. We were able to add this to the digital signal which was being transmitted along the transmission line. The data was transmitted at 10kHz so we set the noise frequency at 50kHz.
7.5
Further implementation
Once we had the overall system working at 10kHz we wanted to amend it so that we could send the data from the source to the sink via infra red. We adapted the noise generator design to enable us to send noise wirelessly by feeding the output into a GaAlAs infrared emitter. This meant that our summer could be implemented as simply shining two infra red LEDs onto a receiver: one which carried the data, and another which carried the noise signal. The datasheet for the diode which we used [19] as the transmitter comments that the input voltage should be between 0V and 3V so it was
69
Figure 7.7: Output wave from the noise generator system
necessary to place a resistor between the output and ground in order to bring down the range of the signal.
7.6
Conclusion
I believe that the implementation of the noise generator was a success. I feel that my decision to implement the system using standard logic rather than an ispGAL pld as planned was both justied and appropriate. I feel that I learnt a lot from working within the group and I believe that the entire system beneted from the groups use of teamwork and pooling knowledge and resources. I feel that if I had had more time I could have created a superior noise generator, but I feel that with the pseudo random nature of working with a digital system meant that we could never acheive perfect white noise without re-designing the system with analogue componenents. I feel that bringing together aspects from both the digital and analogue aspects of the electronic engineering course meant that not only the noise generator system beneted but the system as a whole.
70
Figure 7.8: Pspice circuit model of random signal generator
Bibliography
[1] Semester 1 Examination 2000/01 Design and test of digital systems, Question number 3. [2] Neil Ross. Op-amp lecture notes. ELEC2012 Analogue Electronics, 2006. [3] https://secure.ecs.soton.ac.uk/notes/ellabs/2/e20167/m6/dlp-usb245m12.pdf. [4] Initial D4 project proposal for Team C. Submitted on 23/04/2007. [5] http://ugforge.ecs.soton.ac.uk. [6] Tim Forcer. Serial data transmission notes. Provided with D4 le pack. [7] Altera fpga board manual. 1C12 [8] http://www.peakfpga.com/vhdlref/refguide/language overview/test es/reading and writing les with text i o.htm. [9] Mark Zwolinski. Digital System Design With VHDL. Prentice Hall, October 2002. [10] http://www.ftdichip.com/Projects/CodeExamples/CSharp.htm. [11] Sn55107a,sn75107a,sn75107b,sn75108a duel line receivers. April 1998. [12] Cd74hc7046a, cd74hct7046a. October 2003. [13] W. M. Austin. Cmos phase-locked loop applications using the cd54/74hc/hct4046a and cd54/74hc/hct7046a. September 2002. [14] Gaalas infrared emitter sfh484/5. November 1997. [15] Undergraduate handbook. [16] Picture and circuit taken from http://hyperphysics.phybenchhttps://secure.ecs.soton.ac.uk/notes/elec2014/UP3-
astr.gsu.edu/hbase/electronic/ietron/summa.gif. [17] Picture and circuit taken from http://sound.westhost.com/p14 g1.gif. [18] http://www.velocityreviews.com/forums/t23124-rom-in-vhdl.html. 71
BIBLIOGRAPHY [19] GaAlAs INFRARED EMITTER Siemens
72 semiconductors
http://www.datasheetarchive.com/datasheet.php?article=2980387.
Appendicies
Appendix A Tables
Coecient Counter size Left shift count Half oversample rate Small phase correction Large phase correction Dierence Threshold Negative Dierence threshold Level threshold Small phase threshold Large phase threshold Value 8 3 8 8 32 30 -30 21 2 7 Meaning Size for counters in bits Fractional bits in counter Small phase correction left shifted by the fractional bit count Large phase correction as for small Minimum dierence to register a rising edge Minimum dierence to register a falling edge Weighed average threshold to determine 1 or 0 Phase dierence the controller interprets as small Phase dierence above which the controller interprets as far out of phase Coecients used to generate the weighted sum. Related to the relative probability of a sample being in error.
Coecients
1, 3, 4, 2,
1, 4, 4, 2,
2, 2, 4, 4, 4, 3, 1, 1
Table A1: Clock recovery coecients
Listings
73
Chapter 7 Appendicies
74
File Packagehope.vhd WSUM.vhd FractionalClock.vhd PhaseComparator.vhd Controller.vhd
Author jjb jjb jjb jjb jjb
Test bench WSUM test.vhd FractionalClock test.vhd PhaseComparator test.vhd Controller test3.vhd*
Dependencies WSUM, FractionalClock, PhaseComparator (bit)Controller, USBcontroller, DataSink srcounter.vhd srcounter.vhd srcounter.vhd, source data.vhd deserialiser.vhd, decoder manchester.vhd, decoder rs232.vhd, controller.vhd memory.vhd, sourcecontroller2.vhd, encoder0.vhd, encoder1.vhd, serialiser2.vhd
USBController.vhd TopEntity.vhd deserialiser.vhd decoder manchester.vhd decoder rs232.vhd counter.vhd source data.vhd controller.vhd datasink.vhd
jjb jjb acj acj acj acj acj acj acj
USBController test.vhd Topentity test.vhd* deserialiser test.vhd decoder manchester test.vhd -
memory.vhd sourcecontroller2.vhd encoder0.vhd encoder1.vhd serialiser2.vhd datasource2.vhd
dce dce dce dce dce dce
memorytestbench.vhd controllertestbench.vhd encoder0testbench.vhd encoder1testbench.vhd serialiser2testbench.vhd sourcetestbench2.vhd
*require test vector les to simulate

Table A2: VHDL les showing dependencies
75
1 # Pin a s s i g n m e n t f i l e used f o r t h e data s i n k FPGA 2 3 # 4 # Clocks 5 # 6 define clock disable
name { u s b c l o c k } f r e q 1 0 0 . 0 0 0 c l o c k g r o u p
default clkgroup 0
7 8 9 # 10 # A t t r i b u t e s 11 # 12 d e f i n e a t t r i b u t e 13 d e f i n e a t t r i b u t e 14 15 16 17 18 19 20 21
{ usb clock } a l t e r a c h i p p i n l c {29} { nreset } a l t e r a c h i p p i n l c {62} define attribute { debug out } a l t e r a c h i p p i n l c { 2 1 7 } define attribute { c o d i n g b i t } a l t e r a c h i p p i n l c {216} define attribute { s t a b l e o u t } a l t e r a c h i p p i n l c {215} define attribute { usb transmit } a l t e r a c h i p p i n l c {206} define attribute { state out [ 1 : 0 ] } a l t e r a c h i p p i n l c {53 ,54} define attribute { usb data lines [7:0]} altera chip pin lc {180 ,200 ,201 ,202 ,175 ,177 ,203 ,176} define attribute {serial input } altera chip pin lc { 207 } define attribute { debug out2 } altera chip pin lc { 208 } Listing 7.1: topentity.sdc
76
1 # Synplicity , Inc . c o n s t r a i n t 2 # H: \ d4\ s o u r c e . s d c 3 # Last e d i t e d 4 th A p r i l 2 0 0 7 4 # By Dan Easton 5 6 # 7 # Clocks 8 # 9 define clock disable
f i l e f o r t h e Data S o u r c e FPGA
name { Clock } f r e q 1 0 0 . 0 0 0 c l o c k g r o u p
default clkgroup 0
10 11 # 12 # A t t r i b u t e s 13 # 14 d e f i n e a t t r i b u t e 15 d e f i n e a t t r i b u t e 16 d e f i n e a t t r i b u t e 17 d e f i n e a t t r i b u t e 18 d e f i n e a t t r i b u t e 19 20 21 22 23 24
{ clock } a l t e r a c h i p p i n l c {29} { r e s e t I n } a l t e r a c h i p p i n l c {23} { repeatIn } a l t e r a c h i p p i n l c {216} { resendIn } a l t e r a c h i p p i n l c {48} { encodeMode [ 1 : 0 ] } a l t e r a c h i p p i n l c { encodeModeOut [ 1 : 0 ] } a l t e r a c h i p p i n l c { { { { { serialOut } a l t e r a c h i p p i n l c {168} resetOut } a l t e r a c h i p p i n l c {55} repeatOut } a l t e r a c h i p p i n l c { 2 2 4 } resendOut } a l t e r a c h i p p i n l c { 5 6 } slowClockOut } a l t e r a c h i p p i n l c { 2 2 5 }
{206 ,215} define attribute {53 ,54} define attribute define attribute define attribute define attribute define attribute
Listing 7.2: source.sdc
77
Figure A1: Full circuit diagram

One of References For Digital Signal Processing

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

One of References For Digital Signal Processing

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSITY OF SOUTHAMPTON

Digital Data Transmission

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

Chapter 1 Team Report

Figure 1.1: Block diagram of entire system

Data source overview

Chapter 1 Team Report

Figure 1.2: Data source overview

Chapter 1 Team Report

Figure 1.3: Channel implementation block diagram

Chapter 1 Team Report

Figure 1.4: IR modulation circuit

Figure 1.5: IR receiver circuit block diagram

Chapter 1 Team Report

Figure 1.6: IR received signal to digital conversion

Chapter 1 Team Report

Figure 1.7: Block diagram of the noise generator

Chapter 1 Team Report

Figure 1.8: Output waveform of the noise generator

Figure 1.9: Block diagram of the data sink

Chapter 1 Team Report

Figure 1.10: Block diagram of the data sink controller

Figure 1.11: Manchester decoding on four bits

Figure 1.12: RS232 encoding on four bits of data

Chapter 1 Team Report

Figure 1.13: Block diagram of clock recovery

Chapter 1 Team Report

USB debugging interface

Figure 1.14: State machine for USB controller

Table 1.1: USB message format

Chapter 1 Team Report

Figure 1.15: Dierential Line Test

Chapter 1 Team Report

Figure 1.17: Received IR signal compared to ltered & amplied signal

Chapter 1 Team Report the SN75107A is (see Figure 1.16).

Figure 1.18: Saturated received signal

Figure 1.19: Eye diagram with stabilised clock

Chapter 1 Team Report

Figure 1.20: Eye diagram with increased noise

Chapter 1 Team Report

Figure 1.21: Photograph showing data source circuit

Figure 1.22: Photograph showing line receiver

Performance and conclusion

Chapter 1 Team Report

Chapter 1 Team Report

Individual I Josh Bowman

Management and resource allocation

Chapter 2 Individual I Josh Bowman

Chapter 2 Individual I Josh Bowman

(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

Chapter 2 Individual I Josh Bowman

(a) Uniform average

(b) Weighted average

Figure 2.2: Bit period averages

Figure 2.3: Dierence function

Chapter 2 Individual I Josh Bowman results in high levels of jitter.