Hardware Architectures

An important aspect of the research in the UTC is the creation of SEVA prototypes based upon commercial devices.

The first generation SEVA prototype of a Coriolis mass flow meter consisted of

  • the flowtube
  • conventional commercial transmitter connected to a PC.

The PC and the modified transmitter together showed how a SEVA device would behave. This prototype demonstrated an ability to detect and correct for several fault modes, as well as the generation of SEVA metrics.

Validation leads to redesignValidation leads to redesign

In practice, it was not viable to incorporate the validation functionality within the existing commercial transmitter. However, one of the benefits of carrying out a sensor validation analysis is that it leads to fundamental redesign. The identification of the major limitations and fault modes of an instrument, and their impact on measurement quality, provides strong motivation for improvements in the basic design (or indeed manufacturing, installation, characterisation, and/or operating procedures where weaknesses are revealed).

The second generation SEVA prototype has an all-digital design, offering a low component count with a high software content, based on rapidly evolving, competitive, mainstream technology. However, prototype development raises several of the same issues facing manufacturers as described above. The choice of implementation technology is important, as it has a strong influence on the quality of validation that can be carried out. On the other hand, it is impossible for a research group to keep up with the continuous improvements in component performance offered by the market.

The Valcard research programmes have addressed this issue through the use of a hardware/software co-design approach called hardware compilation; the required functionality is defined in software using software tools and techniques . Research prototypes are implemented using off-the-shelf processors to run software and Field Programmable Gate Arrays (FPGAs) to build hardware. A commercial implementation may use a different partition of functionality into hardware and software, and use different technologies - e.g. Application Specific Integrated Circuits (ASICs), low power processors, Analogue to Digital Converters (ADCs) etc. - while still being largely automatically (and therefore quickly and cheaply) generated from the original software functional specification, which is the core intellectual property. This approach is intended to shorten the delay from prototype to final product, and offers manufacturers the possibility of very late decisions over product implementation technology, based on the most recent commercial and technical information.

Although there are several tools for defining FPGA functionality, the language Handel-C has proved extremely effective for rapid development and debugging of complex real-time applications. This language was developed by the Hardware Compilation Group at Oxford's Computing Laboratory, and is now available commercially.

Handel-C is a programming language designed for compiling programs into hardware images of FPGAs or ASICs. It is basically a small subset of C, extended with a few constructs for configuring the hardware device and to support the generation of efficient hardware. It comprises all common expressions necessary to describe even complex algorithms. The programs are mapped into hardware at the netlist level, currently in xnf or edif format. The Handel-C programming language is a derivative of occam (Inmos, 1988) and is therefore highly effective at describing parallel processing requirements not possible in a purely sequential step approach.

The Valcard platformValcard architecture

The Valcard platform has a commercial PC-104 processor card at the base, thus additional cards can be stacked above it. A series of general-purpose FPGA cards has been developed at Oxford to interface to the PC104 stacked bus. The latest card (version 7) includes a Xilinx Spartan IIE series FPGA with up to 300,000 configurable gates, tightly coupled to a 256k x 16bit RAM, a set of LEDs for debugging and a daughtercard connector. Daughtercards have been developed for a variety of applications, as described below. In addition, application-specific cards which integrate the FPGA card function with application-specific circuitry have been developed for the Coriolis and railway points machine projects.

A variety of software can be run on the PC104 while interfacing to application-specific Valcard modules, including:

 

  • DOS (both 16 and 32 bit) applications
  • VxWorks
  • The Matlab/Simulink software environment, running under a Windows operating system.

    With these software options available, the same mixture of commercial-off-the-shelf (COTS) and application-specific hardware can be used for research (under Matlab/Simulink/Real Time Windows Target) and for industrial demonstration (under VxWorks).

    VxWorks is a robust and widely used Real Time Operating System (RTOS), aimed at embedded applications. It provides software applications such as http (i.e. Web access), ftp and telnet to allow remote monitoring and upgrading of prototype systems. Under the development environment, Tornado, platform-independent code is developed. This can subsequently be targeted at a particular processor architecture via compiler switches. This approach simplifies technology transfer; code developed on the PC-104 architecture under VxWorks is readily transferred to another architecture (e.g. PowerPC or ARM) in a commercial development.