Progress Report

advertisement

Final Year Project

“A Remote FPGA

Laboratory Environment ”

Progress Report

By

David Hehir

Abstract:

This report documents my Final Year Project progress to date. The aim of my FYP is to create a Remote FPGA Laboratory Environment essentially allowing a student/user to log onto a remote computer. The remote computer will be running

FPGA software and have a board connected to it . The users will then be able to upload code and compile it on the board. The board will be streaming a live feed which will show the user their application/code running on the board.

This report will detail (1) Hardware used, (2) Software/code implemented and being developed and (3) Project milestones and future work.

I would really like to thank my supervisor, Dr. Fearghal Morgan, for his guidance and help with any issues that have arisen with the project thus far. Also a mention to the lab technicians, Myles and Martin, who have also been extremely helpful and offered great assistance in setting up certain applications for me in the labs.

Table Of Contents

ABSTRACT: ............................................................ 2

INTRODUCTION: ................................................... 5

PROJECT GOALS & REQUIREMENTS................. 5

AVAILABLE HARDWARE....................................... 6

APPLIED VHDL COURSE & CODE (EXISTING

SOFTWARE) .......................................................... 7

OUTLINE OF SYSTEM IMPLEMENTATION: ....... 10

PROBLEMS ENCOUNTERED ............................. 16

FUTURE WORK ................................................... 16

REFERENCES ..................................................... 19

Introduction:

This Report documents all research, design and work carried out in the project so far, along with milestones, what has been achieved and future work to be carried out.

The reason I chose this project is because I was first proposed it by my supervisor, Dr. Fearghal Morgan, who suggested it would be quite useful to have a remote FPGA laboratory type environment for students to use on their own. I found this to be a very interesting idea and especially because of it being very relevant to the Electronic Engineering course right now. I decided that would be of great benefit to upcoming students and very practical for them to be able to make use of this technology when lacking access to a real laboratory and FPGA board.

Project Goals & Requirements

Create project webpage including all documents, status and categorised links, application downloads as each revision has been completed.

Develop top level drawings and specifications illustrating all elements of the project to date.

Develop GUI to incorporate remote/local hardware selection option and radio buttons on GUI to enable 8 x virtual toggle switches and 4 x virtual springloaded switches. These switch settings will be transferred to FPGA.

Incorporate security on remote computer/server running board.

Include settings to manage filespace and possibly chat to other users.

Future work will include possible implementation on NEXYS Spartan-3 system, its GUI and USB interface.

Available Hardware

Client/Server PCs

The user machine is the client machine. This is used to connect to the server PC.

The server PC will be a remote machine connected to a local FPGA board.

Digilent Spartan-3 E FPGA Board

These are boards we use in the labs. The possibility of using a NEXYS

Development system at a further date is also available to us.

Webcam

This will be a basic webcam connected to the remote machine that will be viewing the FPGA board and streaming back to the user.

Internet Link

The remote server PC will be always on a fixed IP address. However, there may be restricted access to the server allowing connections only from certain areas and domains for security reasons.

Applied VHDL Course & code (existing software)

Part of our course in VHDL this year was to complete an Image Processing System implementing VHDL capture, testbench, simulation, synthesis, FPGA implementation and hardware test.

Structured design documentation, implementation and test strategy used throughout. displayCtrlr Multiplexed 7-segment display and LED controller

CSRBlk

IOCtrlr datCtrlr

Control and status register block

Serial (UART) interface and I/O controller » Parses host

GUI commands and data

Datapath (8-bit UART ⇒ 32-bit SRAM data bundle and vice-versa) memCtrlr SRAM datapath select and SRAM controller FSM dspBlk Image pixel subtractor (delta-frame generation) appliedVHDL Complete applied system integration

Another DFD describing the system is shown below. This schematic details the project as a whole. The appliedVHDL GUI can be used to read/write from/to the CSR registers.

The UART is responsible for encoding and decoding data to enable communication with the host PC.

The IOCtrlr state machine reads and decodes commands received by the

UART and controls the operation of Control and Status Register Blocks

(CSR).

Depending on the command sent to the board CSR read/write can be performed. The display controller drives multiplexed 7 segment displays which are used to display commands sent and received by the board.

The values stored in the CSR Registers are used to control other parts of the system developed in latter parts of the course.

The GUI allows the user to pick the address of the register to be read/written to.

appliedVHDL

V1

Data Flow Diagram (DFD0.0 with DFD 1.0 expanded)

key

sequential combinational

CSR contents element names

Visual Basic Host Interface GUI

Supports CSR r/w access only

RAM access & DSP functions not included

NUIGProjectV1 datCtrlrV1

1.2

NUIGProjectV1 (DFD 1.0) is a combination of these two blocks

TxD RxD txDat(7:0) txDatValid

UART

TX : par2Ser

RX : ser2Par rxDat(7:0) rxDatValid

IOCtrlrFSM&CmdRegV1

1.1.1

IOCtrlrFSM V1 rxDatAck

1.1

IOCSRBlkV1 txDat(7:0)

Assignment

Instructions:

NUIGProjectV1 appliedVHDLV1

IOCtrlr State

Machine rxDat(7:0) enCSRWr

CSRBlk

CSR Add decode

1.1.2

CSR data wr on enable assertion rxDat(6:4, 1)

4 en CSR rd regCSRInfo, clrCSRInfo cmdRegV1 csrAdd(2:0)

DFD 1.1

V1

CSR register assignment csr(7)(7:0) csr(6)(7:0) csr(5)(7:0) csr(4)(7:0) csr(3)(7:0) csr(2)(7:0) csr(1)(7:0) csr(0)(7:0) appliedVHDL Top Level

Data Flow Diagram

[F Morgan, Ph.D]

V07_1 txDat(3:0) dpIn(3:0) rxDat(7:0) txDat(7:0) seg73In(3:0) seg72In(3:0) seg71In(3:0) seg70In(3:0)

DFD 3.0

displayCtrlr

3.0

anL(3:0) ld(7:0) dpL seg7L(6:0)

4x7-seg displays rxDat(7:0) ldIn(7:0)

8 LEDs

Outline Of System Implementation:

System Overview Diagram:

Client PC

Client PC connects to the server and uploads files

Host/Server PC

Webcam sends back the data from the webcam to the host PC which is then relayed back to the client PC, showing the board in operation

Webcam

Host PC relays the code uploaded from the client

PC to the board connected to it

FPGA Board

Controlling The FPGA Board Inputs & Outputs

The board itself will either accept inputs from real or virtual switches/buttons. One bit in the CSR Register will be used to select between the physical and virtual inputs being used.

Inputs: ext_sw, ext_btn, ext_rst and int_sw, int_btn and int_rst

The user will be able to control these switches/buttons but not be allowed to control the reset as this could destroy the system’s operation. rxDat

UART

IOCSRBlk

CSROut

SelIntorExt d3design

InvandExt1.vhd

4

4

8 leds seg73

Seg72

Disp_Ctrlr ld

7seg7

4

Anl 4 seg71

4 Seg70

Clk

Rst

Ext_Sw

Ext_Btn

Ext_Rst

Int_Sw

Int_Btn

Int_Rst

Synthesizing User Code

Because of the strong potential problem of a user uploading erroneous/malicious code to the system, which could cause damage to the system and board itself, the user will not be allowed to upload a bitstream file directly to the server. There are two options available to us thus far:

(1) The user could submit their code to the system by uploading it to their filespace. But it would have to be uploaded in a Zip file format and the system would create a new project for each user, then the skeleton/template files would be in this folder together with the user’s VHDL code.

(2) The user would download a version of the template/skeleton and fill it with their code, compile and check it for errors locally and then upload to the system.

There are also other issues that will need to be resolved with regards synthesizing user code on the system which I have written about in pages further on.

Remote Access Requirements And Security Issues

As of now, the primary remote access will be given to the user by logging on through

VNC. They will simply download and run VNC from http://www.realvnc.com

and log on to the remote machine (the address of the host machine will be given). Once the user logs on, restricted remote access will be given to them, primarily running

Xilinx/ISE Tools and allowing them live view of the webcam.

There are also other options available such as logging on through a virtual online window but this is for future work.

However, there are security issues with regards to giving remote access to users.

With a simple processor, when you execute programs on it, you are simply changing its logic behaviour. But with a reconfiguring an FPGA device can change not only its logic behaviour but also its electrical properties (pin types, power consumption). A

malicious user can exploit these properties to cause actual physical destruction to the board (i.e. by overheating). Quite unlikely to happen but possible nonetheless.

Therefore primarily, the connection will be password protected and may be restricted to certain IP addresses. Users from a certain area or domain may only be granted access, such as student complexes/villages in and around Galway. More to follow on this later.

Implementation Of A Virtual FPGA Lab

Hardware

The commands from the server are used to control the contents of the CSR registers. Part of these are used to control other parts of the AppliedVHDL system

(i.e. dspblk, disp_ctrlr, etc). We use the spare registers to implement: (1) virtual inputs and (2) the bit that controls whether external or virtual inputs are used.

Other parts of the appliedVHDL system are reused to reduce the development time.

For example, the display controller can be used directly by the design submitted by the user.

Basic layout of the internal muxes:

CSR Register

Real buttons

Virtual buttons

Compiling User Submitted Code

Internal buttons

The base system consists of the hardware outlined above and the user submitted design. The remote user is given a “skeleton” with predefined interface that will be connected to the base system during synthesis. In the basic case, the user just fills in the code in the “skeleton” file and uploads it to the remote server. However, in more complex hierarchical designs consisting of multiple source files can be submitted. In this case, the “skeleton” would have to be considered as the top level entity by the user.

After the user submits their code, the server creates a new ISE Project. The user submitted files are then copied into the project directory and the synthesis is run on the server. The log file is presented interactively to the user together with the

progress report. In case of errors in the design implementation stage, bitstream upload is disabled. In the case of successful synthesis the resulting bitstream file is uploaded to the board and then the user can interact with the prototype using remote

GUI.

Remote GUI Application

The functionality of the appliedVHDL GUI will be enhanced by the ability to remotely control the inputs of the board and observe the outputs and the board using the webcam.

The remote GUI application will be designed in VB/C++ and capable of performing different operations on the board.

Problems Encountered

By design only slow frequency inputs to the board can be controlled remotely.

However, in the case of controlling buttons or switches that would be otherwise operated by a human this does not degrade functionality of the system. But, for example, remotely controlling an input to the UART component could not be accomplished.

Because the user submitted design files are synthesized as a part of a bigger system, the synthesis and simulation flows on server and client machine differ. For example, the test bench that has been developed by a client to test his design would have to be modified to work within the full system.

It is possible that the user might choose the same component names as the ones that already exist in the system that is being synthesized. In that case, a method of resolving or flagging conflicts must be determined.

Future Work

Testing of the hardware implementation of the base system and integration on a NEXYS system.

Implementing the client and server part of the system, that is the GUI and the compilation flow.

Enhancing the GUI application to allow for multi-user collaboration with the same board. Extensions would allow for users to have video conferencing, whiteboard support and chat functionality between users connected to the server.The possibility of adding a “queue” for users wishing to take control of the board and showing how much time they have left in command of the server.

References

Hadzic, Ilija and Udani, Sanjay (2003), FPGA Viruses , Distributed Systems

Laboratory, University of Pennsylvania.

Morgan, Fearghal (2005), Applied VHDL , Electronic Engineering Department,

National University of Galway, Ireland.

Download