Home -> Design Goals    

  On this page:  
  VL2 documentation:  

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: 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:

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:
  1. 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.
  2. 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.
  3. 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.
  4. Security features exist, but they can be bypassed.
  5. Mutual exclusion works, but the implementation is poor: the lab can become temporarily unusable when users do not disconnect cleanly.
  6. 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.
  7. 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.
  8. 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: 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