Using the VLAB

Ask Ian if you need any help or encounter any problems with the VLAB or using the Xilinx tools remotely, or if you need a key to access the VLAB.

Read Me First!

A more "step by step" version of this page exists, particularly for EMBS students, at The VLAB Quickstart Guide.

The VLAB is complex infrastructure built specially for teaching here at the University. Please report any bugs or errors (or just annoying things) to us so that we can fix them.

If you're feeling motivated you can help us fix any issues on GitHub!




The Virtual Lab is a rack of FPGA boards that are kept in the RTS Lab and are connected to the internet for your use. These boards are identical to the boards that you have in the hardware lab and the same bitfiles will work. The only difference is that you will not be able to use the buttons on the board, or observe the LEDs, so all interactions with your design will have to be via the UART (serial line). You should plan for this when building your systems.

Key Facts

  • The VLAB lets you use your existing designs, it doesn't need anything changing in your hardware or software.
  • You will run the client script vlab.py to connect to a remote FPGA. 
  • Once connected, you can connect the Xilinx tools (Vivado) to the remote FPGA through the VLAB, in order to program and debug the board.
  • The VLAB gives you access to the serial (UART) to let you interact with your design.

Quick Start

The VLAB client requires Python 3, so install this first. The client is tested on Linux and macOS, but should also work on Windows.

You should have been given a Virtual Lab keyfile which allows you to access the VLAB. If not, speak to a demonstrator. To use the VLAB, run the script to connect and request a board. Note that you must run the VLAB script from the same place as you are running the Xilinx tools. If you are running Vivado remotely, run the script on that remote machine.

For example, to request an EMBS board, use the following:

./vlab.py -k <key file>

This defaults to requesting a Digilent Zybo Z7 FPGA, the boards used in EMBS. To request a different type of board use the -b flag. For example:

./vlab.py -k <key file> -b vlab_zc706

If the FPGA is available, you will be connected to the UART terminal on the board. Any keypresses will be sent to the FPGA, and any bytes it sends will appear in your terminal, the same as with a local screen connection. Whilst you are connected, the VLAB allows any of the Xilinx software tools to see the remote FPGA and program it (see below for instructions).

When you connect to the VLAB, you will get an exclusive lock on your allocated board for ten minutes. After this time you won't immediately be disconnected, but any other user wishing to connect to the same board type may cause your session to end. Your current lock expiry time is shown during connection and at the bottom of the VLAB shell window.

See the README file for more information on client installation and usage.

Recent VLAB status

Current status: OK

Check the commits on GitHub for more detail on the latest changes, or check/add to the issues page.

If the VLAB is down for maintenance or experiencing any issues, we'll try to document it here (latest at the top).

Start TimeStatusComments
21/04/2020 21:00

OK

Inactive boards will now be preferentially allocated over active ones (even if locks have expired), and FPGAs are now more reliably cleared when not in use.
21/04/2020 20:00

DOWN

VLAB will be briefly down for updates.
16/04/2020 18:30

OK

Minor updates done, and all Zybo boards power cycled.
16/04/2020 18:00

DOWN

VLAB will be briefly down for updates.
15/04/2020 17:00

OK

USB connections to boards should now be more reliable.
15/04/2020 16:30

DOWN

VLAB will be briefly down for updates.
07/04/2020 22:00

OK

Everything should be back and stable, with board allocations and script output improved.
03/04/2020 15:00

AT RISK

Updates complete, but we still have a few more changes to make over the coming days so occasional restarts are possible.
03/04/2020 11:00

DOWN

VLAB will be down for upgrading/testing for a couple of hours.
25/03/2020 12:00

AT RISK

General maintenance, updates and fixes. Everything should be mostly stable, but expect the occasional restart.
19/03/2020 20:00

OK

There are now 30 Zybo Z7-10 boards available to use
19/03/2020 12:00

AT RISK

Increasing available boards...
23/04/2019 14:20

OK


23/04/2019 13:30

AT RISK

Updating board hosts with bug fixes
16/04/2019 14:00

OK


16/04/2019 11:15

AT RISK

Fixing some bugs in the relay server
15/04/2019 18:50

OK


15/04/2019 17:30

AT RISK

Fixing some bugs in the relay server

Using Vivado over the VLAB

First connect to a VLAB board, as above:

./vlab.ky -k mykey

If you are running Vivado on a remote server, ensure that you also run the VLAB scripts on that server (not on your local computer). Now in Vivado click "Open Hardware Manager" in the Flow Navigator in the left-hand column. Then click "Open Target" | "Open New Target" in the Flow Navigator. In the Open wizard click Next, select Remote Server, Next, and use the following settings:

VLAB Hardware Server Settings
Hostname: localhost
Port: 12345

Click Next and the tools should connect and see a Zybo Z7:

Click Next and Finish. You can send bitfiles to the FPGA by selecting Program Device from the Flow Navigator.

The process in SDK is similar. In the bottom left should be a Target Connections panel (Window -> Show View -> Other if it is not visible.) Click Add New Target Connection. Set the name to VLAB and the host and port as above, and click OK. To use this new connection you need to set your Run Configuration to use it. In the menus select Run -> Run Configurations and for the configuration you are using change the connection to the VLAB. This will allow you to upload code, bitfiles, and use the debugger all remotely.

Exiting the VLAB

Please close your VLAB connection when you are not using it so that other students can use the board (remember that your exclusive lock on a board will expire ten minutes after connecting anyway.).

The VLAB terminal window is running screen. To close it, press and release Ctrl-a, then press 'k' and confirm with 'y'.

When using a Virtex FPGA board (or anything other than a Zynq), errors following the line "fpga configuration failed. DONE PIN is not HIGH" when disconnecting are normal, and can be ignored (we will tidy this up one day...).

Connecting through the SSH Gateway

Due to the university's firewall rules, the virtual lab relay server (rts001.cs.york.ac.uk) is only accessible from departmental machines (including student compute serversstaff Linux compute servers, anything on the RTS lab network, and all student lab PCs), or via the IT Services SSH service. Therefore, when off campus or using eduroam, the easiest way to access the VLAB (and other departmental servers) is through the IT Services SSH gateway. You will need to request access to this service before you can use it - see https://www.york.ac.uk/it-services/services/ssh/ for more information.

Once you have been granted access to the SSH gateway, the following SSH rules can be used to connect directly through to the VLAB by adding them to the ~/.ssh/config file on the computer you're connecting from.

~/.ssh/config
Host ssh.york.ac.uk
   User YOUR_ITSERVICES_USERNAME

Host rts001.cs.york.ac.uk
   User YOUR_VLAB_USERNAME
   ProxyCommand ssh -A -T -o Compression=no ssh.york.ac.uk -W %h:%p

The SSH gateway server also accepts key-based authentication, using the ~/.ssh/authorized_keys file from your standard university Linux home directory.



Graphical Output over the VLAB

Viewing HDMI output is not natively supported by the VLAB. However, it is possible to use Xilinx's USB debugging interface to download the contents of the video frame buffer straight out of the FPGA and view that. Because USB debugging is rather slow, and the video frame is uncompressed it take take a while (around 16 seconds) to pull an entire video frame. However this might still be useful to get an idea for how your code is progressing.

Note that this script assumes that you are running on Linux because it uses ImageMagick and the Gnome Image Viewer. These can be installed on a Debian-based Linux with the following:

> sudo apt-get install eog imagemagick

You can avoid installing Eye of Gnome by switching the image viewer the script uses. On the "exec eog $filename.png" line, switch eog to (for example) gwenview for KDE or open for macOS.


The first task is to get the memory address of the video frame you want to view. In the HDMI example code which you are probably working with, two frame buffers are set up with the following code.

u32 frameBuf[DISPLAY_NUM_FRAMES][MAX_FRAME] __attribute__((aligned(0x20))); // Frame buffers for video data
void *pFrames[DISPLAY_NUM_FRAMES]; // Array of pointers to the frame buffers 

This is called multiple buffering and allows the video hardware to be drawing one frame to the screen, whilst the CPU is preparing the next frame. You can get the memory address of a frame by simply printing it out to the console.

printf("Address of frame: %p\n", pFrames[0]);

In the HDMI example this will be 0x11ce80 but this is likely to change frequently as you edit your code. Once you have the address of the frame you are interested in, download this script:

In XSDK's menus, select Xilinx | XSCT Console to view the debugging interface. The XSCT console has the promt xsct%. Set the target address of frame and then run the script.

xsct% set base 0x11ce80
xsct% source /path/to/videograb.tcl

This will fetch the frame, convert it to a PNG, and show it in an image viewer. By default the script only grabs every 20th line, but to make it grab the entire frame set the following:

xsct% set stride 1