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 VL2:
-
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.
In general, these problems can be classified into one of two groups:
- 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
and experiments.
- 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 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.
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
|
|
