fpga report

ENG631 VHDL & FPGA Design - 2020-21 - Overview

Problem based coursework task:

Digital Modulation System

Aims of the coursework:

1. To create a modular system using VHDL.

2. To use simulation and test to verify the correctness of the design.

3. To demonstrate the milestones working on a target FPGA device.

4. To document the entire design process - recording the technical detail and justification of the work done.

VHDL as part of a design process:

A key to successfully developing a working system by the use of VHDL modelling is not to view the VHDL being written in isolation to the rest of the design process. To go from a behavioural description, through to being able to configure the target FPGA hardware, VHDL is just one jigsaw piece within a set of pieces that make up the design process.

Assessment and Milestones:

The design process to implement the task will take place around a set of milestones - where the objective of the first milestone will be to use example building blocks to become familiar with both VHDL and the computer-based tools. Later milestones will add progressive functionality and complexity towards the goal of achieving a completely working system on a target FPGA device. M21414 is assessed by two coursework artefacts - CW1 (50%) covering the milestones and CW2 (50%) covering the summary paper.

Milestone timeline and deadlines:

Mont h	Oct-20		Nov-20		Dec-20		Jan-21	Feb-21
w/c	12	1 9	2 6	2	9	1 6	2 3	3 0	7	4	1 1	18	1
Notes	Intr o Lab				M 1				M2			M3	P

M1	Friday	13th November	GDrive	Video/design record
M2	Friday	11th December	GDrive/Moodle	VHDL/design record
M3	Friday	22nd January 2021	GDrive/Moodle	VHDL/design record
Paper	Friday	5th February 2021	Moodle	IEEE formatted summary paper

Deadline Day Date @ 23:00 Upload to Evidence required

Design Process:

· A more detailed overview of the design process that needs to be followed to arrive at a working solution - and to break the requirement into simpler more manageable sections (Divide and Conquer) is shown in the table below.

· With any system's design task, there is more than one possible approach that may be taken - with more than one solution - where the design methods required at different stages of the design will vary depending on the building block being designed.

· Arriving at a working sub-system or milestone will not be achieved in a "one go" that "works first time". The design process needs to start simple and progressively add

detail/complexity/functionality as a series of steps. In early stages, it is often better to "try and fail" as part of the learning curve.

· Where a building block from an early milestone needs extended functionality in a later milestone - then this should be considered as much as possible throughout the design process to minimise the level of "re-write" that is required to achieve the later version.

· The overall goal of the design process is to arrive at the simplest solution, that also uses the least resources and functions correctly and reliably.

Requirement	Summary of overall system, current sub-system or lower level building block being defined.
Initial Ideas	…of what is inside - exploring top level implementation ideas architecture; block diagram; hierarchy - partitioning - How & Why - defining input & output signals; internal signals.
VHDL Model	Developing the VHDL syntax that describes the required behaviour or structure - pseudo code; flow-chart; signal flow diagram; state transition diagram or table; Karnaugh map, etc.
	Outcome - Complete commented VHDL Entity & Architecture - with syntax check errors
Simulate	Verification that the VHDL model has the correct behaviour define suitable test bench stimulus (test vector) to fully exercise the VHDL model
	Outcome - Annotated waveforms with - appropriate run-time; scale; waveform radix/display
Synthesize	verification that the VHDL model correctly translates into hardware
	Outcome - synthesis report with no errors and minimisation of warnings
Implement	Defining FPGA signal to pin mapping (.xdc) correctly mapping and place & route the design onto target FPGA device
	Outcome - mapping and place & route reports with no errors and minimisation of warnings - with output configuration (bitstream) file (.bit)
Hardware Test	Verification that the target FPGA device has the correct behaviour and meets the original requirement specification.
	Outcome - complete set of evidence / test results with analysis and comment - to confirm correctness of behaviour

Both assessment artefacts for this module will require the design process to be followed to reach a working solution. This process will need to be recorded in a Design Record using e.g. Google Docs, <your electronic software/format of choice> on a regular basis - and then uploaded as a single PDF file to Moodle when complete.

Assessment:

CW1 (50% of Module): Milestones (Group/individual work)

Milestone 1: 0 to 9999 counter Marks

Demonstration of working system (Own recording of working board, presenting code, see description further down under M1 exception)	/5
Supporting technical detail in design record	/5

Milestone 2: Data Generator & Symbol Converter

Demonstration & discussion of working system during online lab	/5
Supporting technical detail in design record & Vivado project archive	/5
XADC Temperature and averaging implementation	/5
Random number generator	/5

Milestone 3 (System Demo): Digital Modulator & Demodulator

Demonstration & discussion of working system during online lab	/5
Supporting technical detail in design record & Vivado project archive	/5
CRC implementation	/5
(Bi-directional) flow control implementation	/5

CW2 (50% of Module): Summary paper (2500 words, individual work)

Criteria	Mark s
Planning "How/Why" e.g. diagrams, ideas, etc	/15
Design & Development e.g. results, error resolution, modelling, highlights, etc	/15
Simulation e.g. expected vs actual waveforms, waveform annotations, errors & resolution, etc	/10
Presentation including e.g. layout, structure, referencing, adhering to IEEE style, etc	/10

Notes: (the small print)

1.	Milestone VHDL (Group CW1) - Complete sets of files - uploaded to the correct K: Drive Milestone team folder – this should be the Vivado project archive, include all VHDL source files (*.vhd) to build that specific milestone – Project Summary screenshots, .xdc & .bit configuration files. All files must be the version used for that milestone demonstration.
2.	All entity names and all .vhd, .xdc, .bit and .pdf filenames must have relevant names that also identify the milestone and be prefixed with a team number e.g.: "T77_M1_Clock_dividers.vhd"; "T77_M2_Top_level.bit".
3.	All text source files i.e. .vhd and .xdc must start with a comment line with the team number and student numbers. E.g.: – Team 42 – 666777 665888
4.	Design Record (Individual CW1): During each demo and submission, students will be asked to show their digital design record and a PDF file will also have to be submitted through Moodle each time using the following naming scheme (for detailed description see first page) e.g.M21414_CW1_T17_422366_M1.pdf.
5.	Milestone/System Demos (Group/Individual): The demonstrated implemented system on the Basys 3 board will be marked depending on the achieved functionality. During the demonstration of Milestones, both team partners are expected to be present. A technical discussion with each team member will be conducted during the testing, to ascertain the level of understanding and contribution towards each milestone. Depending on the discussion outcomes, the individual marks could differ for the milestone demonstration component. M1 exception: You will have to create a video/recording including both team partners (e.g. through Google Meet, WebEx, etc), demonstrating the boards functionality as per CW description and then showcasing the code that you have created, taking turns in explaining the code and how it works by e.g. sharing your screens with each other. Time scales: min: 3 minutes, max 10 minutes (Distorted recordings to make the time limits will be capped at 2 marks).
6.	Summary paper (Individual CW2): The title of the paper should be the same as the CW task. In the author’s section of the paper, you should clearly indicate student number, course, and university affiliation. Your IEEE conference-style paper should be around 2500 words long, excluding ancillary data like figure captions, source code, tables or list of references. Templates can be downloaded here -> https://www.ieee.org/conferences/publishing/templates.html You should (i) avoid repetitions of ideas/concepts, (ii) write efficiently and concisely, (iii) avoid copying/pasting. You must strictly apply the best practice in terms of copyright. For more information on this, please consult and/or contact the university’s ASK department for information on best practice https://www.port.ac.uk/student-life/guidance-and-support/learning-and-academic-support as well as the library regarding referencing https://library.port.ac.uk/w165 .
7.	CW1 & CW2 Moodle uploads must have the following filename – Please see description on first page.
8.	Not adhering to the above points will mean reduced marks.

The Design Task

Background

The PBL coursework has three main parts:

· A Transmitter - that uses a defined modulation scheme to send data as a sequence of waveform values.

· A Channel - that induces random errors in the transmitted waveforms.

· A Receiver - that demodulates the received waveforms to recover the original data.

To reduce the complexity of the design process and to allow for the learning curve in the early stages of the module - the coursework is split into three main milestones.

The coursework will normally be undertaken in teams of two - to enable discussion, problem solving within each team - and to be able to award an individual mark for each team member, two different modulation / demodulation schemes will be implemented in Milestone 3.

The milestones enable each stage of the design process to be designed, simulated, synthesised and tested on the target FPGA board, before moving onto the next milestone - that in turn will be designed, simulated, synthesised and then integrated with the previous milestone for hardware test.

Milestone 1: Counter, clock divider, clock enable (CE), and seven-segment display

This is a "getting started" milestone that provides the first exposure to:

· The design process of: Analyse, Design, Capture VHDL model, Syntax check, Simulate, Synthesize, Map pins, Implement, Download to FPGA and Test on the target board - using Xilinx’s Vivado software; and

· Full recording all of the design process in detail - including ideas, sketches, commented listings, annotated simulation results, results of hardware tests, etc.

To capture the required functionality in VHDL for Milestone 1 the system could be modelled as follows:

· A clock enable signal with a frequency of 250Hz that drives the seven-segment display from the 100MHz (represented as C100Mhz) system clock configured through the Clocking Wizard on the Basys 3 development board.

· A 1Hz clock enable signal that is used to drive a counter, which counts from 0 to 9999 and then rolls over. The counter has four outputs, one for each digit.

· A Binary Coded Decimal (BCD) to seven-segment display decoder that converts the input values to drive the appropriate segments on the display.

· A digit selector module will route each of the 4 digits to the seven-segment decoder in turn - and also enable the active low common anodes in a sequence - to display the digit in the correct position as shown in the figure.

· The “Reset” input will set each (clock enabled) component to a known initial condition.

· A “fast” input should also be included. This will change the behaviour of the clock enables to

e.g. see the counter go from 0-9999 in a shorter period of time as well as allowing faster simulations.

These VHDL models cover various techniques for modelling similar behaviour, so the main requirement is to study what is provided, decide which approach you wish to follow and to capture, simulate, synthesize, implement and test the design on the target FPGA board - recording full technical detail to justify decisions made and the outcome of the various stages of the design process.

It is expected that the submitted design will be modelled as a hierarchical VHDL model, with a toplevel entity instantiating VHDL components.

To generate a configuration (bit-)file for the Basys 3 board (Artix-7 XC7A35T-1CPG236C FPGA) you will also need to define a design constraint file (XDC) to map the signal names used in the entity port list to pins on the FPGA. For this milestone, the minimum required I/O components are the 100MHz system clock (CLK100MHZ), a reset button (BTNU), a “fast” switch (SW0) and the seven segment display cathodes and digit anodes. All other IO is optional in this milestone. The FPGA pin-to-hardware configuration can be found in the Basys 3 board reference manual ( https://reference.digilentinc.com/basys3/refmanual ) or printed onto the board e.g. for switches (e.g. SW0 = V17, etc)/push buttons.

●

The DG should be clocked at 1Hz. A "Start / Stop" button (push to start, push to stop latch) will control the output of the data. All inputs (except reset) should be "de-bounced". All sub-systems should use the Clock Enable scheme. Within the Digital Modulation system - each 4-

1 1 1 1 1 1 1 1 1

0000 0001 0010 0011 0100 0101 0110 0111 1XXX

0 1 2 3 4 5 6 7 8

Fixed “0001” Fixed “0111” Fixed “1110” Fixed “1000” Count 0 – F Random number* Student number 1 Student number 2 Temperature*

Milestone 2: Data generator & Symbol Convertor

Start

/Stop

Data

Select

BIN

Data

Select

DEC

Data Values

XXXX

The two subsystems for this milestone are a Data Generator (DG )and a Symbol Convertor (SC):

● The DG will produce various 4-bit data sequences to provide the input stimulus for simulation and test of the VHDL models for later milestones, and to test the system on the target FPGA. The specific data sequences will be selected by a set of "Data

Select" switches as shown in Table 1. 0 - Fixed “0000”

bit data value will need to be represented by two 2-bit "symbols" (e.g. "1011" becomes symbol "10" followed by symbol "11";) For each 4-bit value from the DG, a SC entity should output two 2-bit symbols - which will therefore be running at 2Hz.

The display driver will need updating to be able to display the following on the following digits (D4=leftmost and D1=rightmost digit):

D4: The Data Select switch setting [0-8]

D3: - The current data value - which, when running, will be: - a fixed value in Data Select modes 0 to 3;

- a changing value in Data Select modes 4 to 8.

D2 & D1: Symbol values for each of the data value as pairs of 0's and 1's which will therefore need to be updated at 2 Hz.

See the Switch, Button and LEDs assignment table at the back for detailed, expected, I/O settings.

*Additionally: Incorporate the onboard XADC’s internal temperature continuous reading into the DG. The temperature will be used as another DG output option, when switch SW15 is set high, see table 1. The entity for this should output the temperature as a sequence in degree Celsius (neglecting decimal places) thus being in line with the other cycling DG outputs e.g. 25ºC should be output as “2” then “5” (as 4bit SLVs), repeat, … . You will need to instantiate the XADC and set it up correctly to achieve a continuous XADC temperature output, see following user documentation from Xilinx

(https://www.xilinx.com/support/documentation/user_guides/ug480_7Series_XADC.pdf ) as a starting point. You should also include an averaging of the values received by the XADC, as these can fluctuate within a few degrees each time read.

And/or implement a random number generator as part of the DG, see table 1 for the data selection switch setting to use.

Milestone 3: Digital Modulator, Error Block and Digital Demodulator

Information often has to be transmitted from one location to another such that it is correctly received despite being sent through a noisy environment that could introduce errors. To achieve this a Digital Modulation Scheme can be used where specific modulation I & Q waveforms are then used to represent each of the four possible symbols 00,01,10 & 11 when it is transmitted. In general, modulation schemes are based on Sine and Cosine waveforms, but a simplification for this coursework is to use triangular waveforms as shown below. The proposed subsystem graphs in the coursework description have been split in two (3a, 3b), in order to help your team in laying out a plan to tackle M3, thus 3b shows the overall M3 implementation at a high level incorporating modulator, error and demodulator.

As work on the coursework normally takes place in teams of two - then two alternative modulation schemes have been specified enabling each member of a team to work independently on one of these schemes to be implemented in an individual modulator, channel block and demodulator entity (i.e. writing their own VHDL implementations, testbench, etc, which will then have to be combined later on into a single Vivado project for the demo and submission ).

Modulation Scheme A

Modulation Scheme B

Each cycle of an I or Q waveform will be represented by a sequence of eight 8-bit values:

Arithmetic values in a modulation scheme can range ±128DEC. To simplify the need to use a sign bit, then any value sent can be offset by +128DEC such that the number range is from 0 to 255DEC.

To enable "noise" to be added to the transmitted values, the triangular waves

ENG631/M21414 CW1&2 2020-21 Page 1 of 13

ENG631/M21414 CW1&2 2020-21 Page 1 of 13

ENG631/M21414 CW1&2 2020-21 Page 1 of 13

should have a range of ±64DEC and with the +128DEC offset, becomes +64DEC to +192DEC (40HEX to C0Hex).

Channel Block

Within a communication system the signals received will be different from the original transmitted signal due to noise and other propagation effects.

To test the robustness of the prototype modulation scheme, a Channel Block will add (or subtract) a random value to the transmitted I & Q waveform signals before they are passed onto the demodulator. "Error Select" switches will control the range of the generated (pseudo) random numbers.

Error Select	PRNG Range
00	No change
01	±16
10	±32
11	±64

Digital Demodulator

The purpose of the demodulator is to process the received waveform

values to decide which symbol has been received, and to combine symbol pairs to form data values. A multiply accumulate operation with each of the received I & Q waveforms against a Reference Waveform would generate specific results that can then be used for the decision process (shown as block D in the diagram) as to which symbol has been received. [The Display Select switches will also set which A or B modulation scheme is in use.]

System Demo Integration

For the final demonstration of a working system the various sub-systems will need to be integrated into an overall top-level system. The Display Diver will require a change to include Display Select settings such that both transmitted and received data values can be checked - when no errors are present, and with increasing levels of error. Milestone 2 values will also need to be displayed :

Display Select D4 D3 D2 D1

X00	As for M2	See M2	DS DV	Symbol
001 010	(M3a) A (M3b)	I & Q Tx Data Values Tx, Rx	I Tx Data Value Tx	Q Tx Data Value Rx
011	(M3b)	I & Q Rx	I Rx	Q Rx

101 (M3a) B I & Q Tx I Tx Q Tx

110 (M3b) Data Values Tx, Rx Data Value Tx Data Value Rx

111 (M3b) I & Q Rx I Rx Q Rx

Additionally (marked as group work): Implement a Cyclic Redundancy Check, which will be added to each data packet before being sent out sent by the data generator. If the received packet had errors, the Data Generator needs to resend it until a correct one is received and/or implement a bi-directional flow control between Data generator and Demodulator (or entity behind it reassembling originally sent data packets from symbols) in order to ensure data packet flow is managed (see RS232, TCP, etc) i.e. to ensure that both sides know when a packet can be sent, when it starts/ends etc.

Controlling, Demonstrating and Testing the System.

All development will be towards getting a working system based on a VHDL model, Synthesized and implemented on a Digilent Basys 3 board.

To Control, Demonstrate and Test the Digital Modulation System the following inputs will be required:

Note: for consistency between teams, specific switches and buttons and LEDs must be allocated to each function to avoid any confusion.

Switch, Button, and LED assignments

Switches	Function	Action
SW15 to SW12	Data generator - Data Select	Start Data Data Data Values /Stop SelectBIN SelectDEC 0 XXXX - Fixed “0000” 1 X000 0 Fixed “0001” 1 X001 1 Fixed “0111” 1 X010 2 Fixed “1110” 1 X011 3 Fixed “1000” 1 X100 4 Count 0 – F 1 X101 5 Random number 1 X110 6 Student number 1 1 X111 7 Student number 2 1 1XXX 8 Temperature
SW11 and SW10	Error Select
			Error Select	PRNG Range
			00	No change
			01	±16
			10	±32
			11	±64
SW9 to SW7	Display Select	Display Select X00 As for M2 See M2 001 010 (M3a) A (M3b) I & Q Tx Data Values Tx, Rx 011 (M3b) I & Q Rx 101 (M3a) B I & Q Tx 110 (M3b) Data Values Tx, Rx 111 (M3b) I & Q Rx
SW0	Fast	"Fast" mode

Buttons	Action
BTND	"Start/stop" button - Tx zero's until pressed and then sends complete packets.
BTNU	“Reset”

LEDs	LD15, LD14, are used to indicate which symbol is being transmitted LD13, LD12, are used to indicate which symbol has been received

System Clock: 100 MHz

The Basys 3 board has a 100MHz system clock and needs to be pre-configured through the DCM IP in Vivado.

Switch Order (for clarity) to be used with the above tables:

		Switches (assuming a X downto Y SLV)
SW1 5		SW1 4	SW1 3	SW1 2	SW1 1	SW10	SW9	SW 8	SW7	SW0
	Data Select		Error Select	Display Select	Fast
(3)		(2)	(1)	(0)	(1)	(0)	(2)	(1)	(0)	n/a

Recording the design process should be done as soon as possible (i.e. "As you go" - NOT "written up later") Doing this will mean that what is recorded is not missing any relevant detail - capturing the thinking and decision process as it happened, recording what actuality took place (rather than being a work of fiction), such that the work can be fairly assessed and marks awarded.

Work on this Module is covered by the plagiarism regulations of the University of Portsmouth where any work you submit for assessment should be the product of your team effort ONLY and not the work of others - e.g. other students, or external sources such as the internet. Warning - Breaking these rules could mean a mark of ZERO% will be awarded for the complete Module.

ENG631/M21414 CW1&2 2020-21 Page 10 of 13

ENG631/M21414 CW1&2 2020-21 Page 10 of 13

ENG631/M21414 CW1&2 2020-21 Page 10 of 13