These web pages provide the user manual and design documents
for Virtual Lab II (VL2), the second generation
of the remote FPGA development system. The purpose of the system is
to provide a centralised shared resource for all experiments that use
FPGAs. The system was designed and built within the Department of
Computer Science at University of York. The design
goals of VL2 are documented.
The following map shows all of the components in a typical VL2
system. You can click on the components to reach associated
documentation. If you want to use VL2, you might want to skip to
the User Guide. Some of the components
can be downloaded. There is a complete
sample application in addition
to a number of shorter sample programs.
Virtual Lab Map
The image above shows the architecture of VL2. As
in VL1, a relay server (running the relay shell)
acts as the head of the service, connecting
users (clients) to FPGA boards and enforcing a security policy. In VL2,
the security policy is enforced by SSH authentication in place of PHP.
(It was possible to bypass VL1 security by connecting directly to a
TCP/IP port: this is not possible in VL2.) The relay shell also
logs commands and FPGA bitfiles.
On the user's side of the relay server, the communication is normally
carried out via the vlab module (a code library
written in Python) although it is also possible to connect
directly to the relay service using SSH software
and operate it in a sort of "console
mode". This was not possible in VL1 because (1) the protocol was
binary and (2) a timeout would occur after a few seconds of
On the lab side of the relay server, an embedded system
called the board server provides
all services that are local to a single board. These services are
documented in the vlab protocol documentation.
The minimal bus between the FPGA and the board interface is designed
to avoid the problems encountered with VL1's bus, which was
(a) application-specific, (b) very wide (and hence difficult
to connect to new FPGAs), and (c) required custom driver hardware
at both ends. We use a simple and well-known standard for
communication: RS232. Activating the appropriate
links the FPGA serial port to the user program, so the
user program can interact with programs on the FPGA. This could
be used for debugging, software downloads, a user interface, or
as a signal carrier for a VL1-style interface.
List of Components
VL2 is actually implemented as seven distinct components. These are:
- FPGA Board. A custom ``quad FPGA'' board is being manufactured
for VL2. It will host the board server and four user-programmable
FPGAs. However, this is not the only board that can be programmed
using VL2. In principle, VL2 can support any FPGA that is
programmable via JTAG or the Xilinx parallel interface. VL2 could
also be extended with new drivers for other types of FPGA. The
wiring arrangements are described
- Board server hardware. A number of Xilinx FX12
FPGA boards have been sourced to host board servers;
these include PowerPC 405 CPUs, Ethernet,
64Mb of RAM and 4Mb of Flash. This is sufficient for
a self-contained Linux system on each FX12 board. The
FPGA hardware configuration
includes 4 16550A serial ports (for communication
with up to 4 FPGAs), a JTAG/parallel FPGA programming interface,
and outputs for the clock generator and reset lines.
- Linux kernel modifications. A custom
is used on the board interface, with support for the custom
hardware extensions. This part of the system is free
software (GNU GPL).
- Board server software. The board server is a program
that runs on each FX12 FPGA board. It implements the
vlab protocol. The
design details are given on this page.
- Relay shell software. The relay shell
is a program
that runs on a Linux server. It acts as a shell replacement
and is the authentication point for VL2.
- VL2 client library. The
vlab module provides an
API for programming FPGAs and communicating with the software
running on them. This hides the details of the
vlab protocol from the user
and handles SSH authentication.
- Virtual Lab Hardware Interface. This component is a higher-level
service implemented on top of VL2. It is (1) a
generic hardware component that provides debugging and
channel functions, and (2) the vlabif module
which communicates with the interface using the
vlabif protocol. This component
is completely optional in any VL2 system. It also does not require
VL2; it can be operated using an RS232 serial connection.
Copyright (C) Jack Whitham 1997-2011