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.

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

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.

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.


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.

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.
V1
key
sequential combinational
CSR contents element names
Visual Basic Host Interface GUI
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)
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

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.

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.


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.

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.