JACK WHITHAM PhD MEng Professional Activities - Publications - Software - Articles
		Home -> Professional Activities

Professional Activities An overview and a detailed list of my recent activities at work. Publications A list of my peer-reviewed academic publications; most are available for download. Software Software written by myself, not necessarily work-related. Articles Written works that are not formal publications.

On this page, I have attempted to list all of the work I have been involved with at the University of York in the last year or two. My curriculum vitae gives a concise summary that omits most of the details, but covers a longer period of time. This page is organised by category as follows:

In my research, I'm trying to find new ways of building computers to maximise guaranteed rather than average performance. I advocate an evolutionary approach to this problem, looking for changes to existing methods that are as simple as possible.

To date, I've completed a PhD thesis, for which I implemented a predictable CPU design. The predictable CPU was able to run accelerated sections of code called "traces"; although traces have been understood for some time (they underpin VLIW research), this was the first time they had been applied to allow timing analysis of out-of-order code execution. Some of the assumptions made by this work were addressed by my subsequent work on "virtual traces", which allow the use of any CPU core rather than requiring a specific custom design. However, some restrictions must still be applied to the core in order to support the paradigm.

My intepretation of the results I've found so far is that data accesses (the effects of load and store instructions) are the most significant problem for guaranteed performance. Although modern computer memories are very fast, they are slower than current CPUs, and worse, there is a high latency for each access, because of the time taken to send a request along the bus and receive an answer. This means that load and store instructions can be blocked for long periods of time.

The most successful solution to this problem is the data cache, but caches are inherently unpredictable because their behaviour depends on recent accesses. A cache can service most accesses, but not all, and this is a problem for guaranteed performance. That doesn't mean caches are useless for real-time systems, since methods do exist to analyse their behaviour, but such analysis is not able to classify accesses precisely; rather, accesses are classified as "cache miss no more than X times out of Y", and some must be classified as "don't know". While useful, this might be inadequate for a fully predictable system, because the possible interactions between the cache and other CPU components aren't captured, and understanding those interactions is necessary to compute the worst-case behaviour.

As an alternative to caches, scratchpads are far more predictable, but unfortunately it is difficult to choose which data objects should be placed in scratchpad. Programs tend to create space for data objects dynamically (during execution), making offline timing analysis difficult. However, some preliminary steps have been taken by others.

My research tells me that (a) the data scratchpad allocation problem needs to be solved, and (b) the solution will also help us to resolve some of the data dependences that can exist within a program offline. These are currently handled dynamically (through memory dependence prediction) and this is a source of unpredictability.

The solution may help improve the predictability of multi-core CPU systems, and could also inform some of the design decisions made within such systems, since the performance of multi- and many-core systems is limited by memory accesses, and the current solution of heuristically-controlled memory systems is potentially wasteful of both time and energy.

Writing papers and research reports

• Current: Work in progress: I have written most of a manual for the virtual lab project. The manual documents all aspects of the virtual lab: it is a user guide, system administration manual and a design document.
• Current: Work in progress: I am working on a journal article on the subject of trace scratchpads, which also appear in some previous work.
• 2008: Unpublished: I wrote a six page paper about the requirements for an interface to link Java code with custom application-specific co-processors, for the JEOPARD project. The aim of the interface is to allow co-processors to access Java functionality (provided by the JVM) and memory areas used by Java objects.
• 2008: Published: I presented my paper on "virtual traces" at the RTSS 2008 conference in Barcelona.
• 2008: Published: I presented my paper on "virtual traces" at the RTCSA 2008 conference in Taiwan.
• 2008: Published: I wrote a paper on "virtual traces" for the Worst Case Execution Time Workshop, co-located with the ECRTS 2008 conference in the Czech Republic.
• 2008: Published: My PhD thesis passed with minor corrections.
• 2008: Unpublished: I wrote a seventeen page manual for the hardware Ethernet driver (see Hardware).
• 2007: Published: My paper on "trace scratchpads" was accepted by the RTAS 2008 conference in St Louis, Missouri.

• the ARM Realview and SOC Designer tools for the EMUCO project.
• the JOP CPU for real-time systems.
• the LCC compiler.

• 2008: I implemented the software for the virtual lab project being supervised by Dr Neil Audsley. The project is an online service, involving client-side software and libraries, and a two-layer server architecture involving Linux-based embedded systems at the back end.
• 2008: I have modified the M5 simulator to support "virtual traces": a predictable CPU technology described by this page. This has involved programming in C++ and Python, and changes to the SWIG interface between the two.
• 2004-2008: I wrote a large number of programs for my PhD thesis in order to carry out experiments. I used the C and Python languages for the majority of this work, but some components also use GNU Makefiles and Unix shell scripts. All of this work is available for download.

• Current: I am implementing an interface to link the JOP CPU (a Java processor for real-time systems) with application-specific co-processors. The implementation will use both the VHDL and Java languages, and is described by a work-in-progress paper.
• 2008: I implemented hardware for the "virtual lab" project on the FX12 FPGA using Xilinx EDK tools. This hardware only uses Xilinx IP cores at present - no custom VHDL has been necessary.
• 2008: I implemented a complete IP core that acts as an Ethernet driver. Data received from other cores via a channel is relayed across an Ethernet network; similarly, data received via Ethernet is relayed to other cores. The driver includes a Picoblaze CPU core (programmed using an assembly code) and connects to 100Mbit Ethernet via an SMSC 91C111 chip. I wrote the IP core in VHDL, reusing Picoblaze IP along with FIFO buffers provided by Xilinx.
• 2008: I developed Debug Chain from my earlier PhD work. It generates a debugging system for VHDL hardware designs, allowing inspection of registers, single stepping etc., via a serial cable.
• 2008: I contributed to the design of schematics for the virtual lab quad FPGA board. This is currently being manufactured.
• 2004-2008: For my PhD thesis, I implemented a generator for a predictable CPU design. The CPU supported large subsets of the OpenRISC and Microblaze instruction sets. The generator produced VHDL code using templates; I also wrote
• 2007: I wrote a VGA graphics IP core in VHDL for Spartan-2E FPGAs. The core used SRAM as a 512 by 480 video memory, with 4-bit colour. It was used by taught-course students for project work at York. The video memory could also be used as general purpose RAM; the IP core included an arbiter to ensure that this usage did not interfere with the display. I also designed a demonstration system for this core using an OpenRISC CPU.
• 2007: I built a power switching module to control the power supply of lab equipment. This simple module uses a relay, transistor and diode to absorb back emf.

• RTAS 2008 and 2009,
• RTSS 2006, 2007 and 2008,
• ECRTS 2008.

• CCC: "crash course in C". Over two days, I assisted a class of up to thirty students learning the C language, which is extremely familiar to me. The work included resolving compile-time errors and bugs in their code, as well as explaining C language features.
• DAD: "digital and analogue design". Across an entire term, I worked with another teaching assistant in an electronics laboratory to assist with circuit design and construction. Our students learned about combinational logic, synchronous and asynchronous circuits, and some aspects of analogue circuit design.
• CTS: "chips to systems". A follow-on course from DAD, CTS covers the construction of a complete computer on prototyping boards, using a Z80 CPU and 2764-series EPROMs. I helped students resolve problems with their circuits using oscilloscopes, logic analysers, and experience.
• EMS: "embedded systems". With another teaching assistant, I helped students with FPGA-based embedded systems design, using Handel C tools.
• CGO: "code generation and optimisation". In this course, I helped students with paper exercises and programming work as they implemented a compiler for a subset of C.

• The need to provide users with a flexible way to program FPGAs with bit files and gain debugging access to the resulting hardware, while making no assumptions about the nature of the user application. For example, some users might want to debug software applications running on soft CPU cores such as Microblaze, while others might want to test application-specific circuits using Handel C.
• The need to support both automated experiments and interactive usage. For example, some users might want to interact directly with their designs using a serial console while others might want to use a program to run hundreds of tests on their behalf.
• The importance of supporting multiple simultaneous sessions while also assuring mutual exclusion where necessary and minimising resource usage. For example, only one FPGA programming job can be active at once, but it is still useful to allow many users to send commands and requests to the virtual lab system.
• The need to secure the system against malicious hacking (it is an online service) while allowing access to legitimate users from anywhere in the world.
• The need to maximise the reliability of the system.

		Copyright (C) Jack Whitham 1997-2008