The following features are implemented by VL2:
The general design goal is to maximise the simplicity of the
system by eliminating all unnecessary features. We aim to minimise
development and support costs.
In particular, the VL2 exists only to ``connect calls'', not
to provide any of the following:
- Allow users to upload bit files to remote FPGAs using
TCP/IP network connections.
- Allow users to monitor FPGA IP cores using a serial
link (routed over the network by VL2 hardware).
- Allow users to reset IP cores remotely using a single reset line.
- Allow users to set FPGA clock frequencies remotely by programming
a phase-locked loop (PLL) IC, local to each FPGA.
All of these features can be provided by a server acting as a gateway
between the lab hardware and the users. However, users will normally
interact with VL2 directly by:
Application-level features such as:
switches, and terminal services.
- Uploading/downloading data
using file transfer protocols.
- User interface features such as:
A secure TCP/IP connection to the lab hardware,
which allows direct access to all of the features listed
above (uploading bit files, using serial connections, etc.).
This is expected to be used primarily for debugging.
- Python/C libraries to allow user programs (running on
workstations or servers) to control FPGAs.
These libraries are expected to be used
primarily for automated experiments and functional tests, but they
could also be used to replicate the features of VL1.
Problems with VL1
VL1 works, but a wide range of problems limit the possibilities
for improvement. Here are some of the problems that must be avoided
In general, these problems can be classified into one of two groups:
In VL1, application-level features are present at every level of the
hardware and software. This makes VL1
inflexible. In particular, users are expected to interact
with FPGAs via a Java applet that always provides the same
services regardless of the FPGA configuration. Application-specific
features also exist within the server software, the control hardware,
and the bus linking the control hardware to the FPGA.
- The Opal Kelly board is not a good hardware platform for VL1:
the drivers are very poor. In particular, there is no support
for sending interrupts from the hardware to the server, so the
server is forced to poll the hardware continuously.
- The bus used to control hardware is complicated. The original
form is a wide parallel bus, which is good for the original
BurchEd B5 FPGA boards used in VL1, but poor for almost all of
the FPGA boards that were subsequently added.
- Security features exist, but they can be bypassed.
- Mutual exclusion works, but the implementation is poor:
the lab can become temporarily
unusable when users do not disconnect cleanly.
- The lab automatically disconnects users when activity isn't
detected for a while (about 10 seconds), which turned out to
be a problem for some experiments.
- The lab does not facilitate automated experiments and tests
because it expects users to interact via a PHP/Java web service.
This can be bypassed by a direct TCP/IP connection, but such
connections do not appear in the PHP interface.
- The lab's communication protocol is not extensible because
it relies on ad hoc binary messages. There is no standard
format for these messages; they are parsed by a switch statement
that uses a different parser for each message type. The
message codes are hard coded into the server software and
the Java applet so there is no single shared definition
for the protocol.
To address the first class of problem, VL2 will assume that users require
only the features listed in the previous section. Users will have to
implement application-level features on top of these. For example, if
EMS students need access to VL2 via a Java applet as in VL1, then
the Java applet can be provided by a service that translates their
requests to the VL2 protocol. In this way, researchers can also use
VL2 without being affected by the requirements of the EMS students.
- Uncertainty about user requirements. When VL1 was designed,
nobody was sure exactly what it would be used for. It was thought
that it would probably be used by students on the embedded
systems (EMS) course, and the course requirements
drove the design of the system.
However, the primary use of VL1 has been for research. At least
two PhD students have made use of VL1: unfortunately, VL1
has not been ideal for this purpose.
- One PhD student was frustrated on several occasions
by stability problems in the platform, requiring a
reboot of the server.
- Another was frustrated by the lack of support for
automatic control: he wanted to be able to connect
to VL1 using a program in order to run test cases
- General design issues. The Opal Kelly board has caused
many problems, not least because of its lack of support for
interrupts. But there are other design issues in the hardware,
such as the bus which cannot easily support new types
of FPGA. Software design issues include the lack of effective
security and the problems with timeouts.
To address the second class of problem, VL2 will use new
hardware and software designs. The design decisions will be informed
by the problems found with VL1.
Copyright (C) Jack Whitham 1997-2011