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, i.e. looking for changes to existing methods that are as simple as possible in the expectation that small changes are more likely to be accepted by engineers and other researchers.

To date, I've completed a PhD thesis, for which I implemented a time-predictable CPU design. It was specifically designed to exploit instruction-level parallelism (for improved performance), while still supporting worst-case execution time (WCET) analysis. Later, I applied the work to a more conventional CPU design.

A time-predictable CPU is useless without a time-predictable memory subsystem. So, my research interest shifted from CPUs towards the challenge of reducing worst-case memory latency. Existing solutions such as caches are not time-predictable because their behaviour depends on recent accesses. A cache can service most accesses quickly, 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 only for special cases and with caveats. A cache alternative known as a scratchpad is far more time-predictable, but scratchpads can introduce new problems. I have proposed a solution for these. Two conference papers have been submitted on the subject.

I am studying single-threaded C programs on single-core systems, which is arguably the simplest case, but one that has not been adequately addressed. The vastly more complicated cases of multi-core systems and Java support are both of concern to my EMUCO and JEOPARD projects.

Writing papers and research reports

• Current: In progress: I am submitting a paper about the SMMU to the ECRTS conference.
• 2010: My article on virtual traces and trace scratchpads was accepted by IEEE Transactions on Computers.
• 2010: The second conference paper on the SMMU will appear at RTAS 2010.
• 2009: I presented my first conference paper on the SMMU at EMSOFT 2009.
• 2009: A paper co-authored by myself with Martin Schoeberl and Neil Audsley regarding our work on JEOPARD appeared at JTRES 2009.
• 2009: I wrote a web page and technical report about the SMMU.
• 2009: I wrote an EU deliverable report and a conference paper regarding the first part of my work on the JEOPARD project. The papers describe an interface linking Java code with custom application-specific co-processors. I co-authored the conference paper with Martin Schoeberl and Neil Audsley, collaborating through email and CVS.
• 2009: I have written 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.
• 2008: Published: I presented my paper on "virtual traces" at the RTSS 2008 conference in Barcelona.
• 2008: Unpublished: I wrote a six page paper about my work on JEOPARD.
• 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.

• 2009: I updated the virtual lab client software for Neil Audsley's EMS course. The new version still uses wxWidgets, Python and Twisted, but adds streaming video from the FPGA board. I also ported some demo applications to the S3ESK board.
• 2009: I wrote a Linux kernel driver for the Xilinx PCIe DMA core (xapp1052). The kernel driver supports DMA-based reads and writes across the PCIe bus. It is used for high-speed communication between co-processors on an FPGA and an x86_64 CPU.
• 2009: The SMMU project includes embedded software, simulators, and hardware.
• 2009: I have now written two Linux kernel drivers for the virtual lab project: a JTAG output driver, and a serial UART driver named Teaport. Both are configured by "Open Firmware".
• 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.

• 2009: I designed a VGA graphics IP core for the Spartan-3E Starter Kit. The core acts as a PLB bus master, so the board's main memory also acts as a framebuffer. It uses upsampling and Bayer dithering to give the illusion of full RGB colour using the extremely limited capability of the FPGA board (each RGB line is either "on" or "off").
• 2009: I adapted the Xilinx bus master PCIe DMA core for the JEOPARD project.
• 2009: I implemented the SMMU in VHDL and attached it to the Microblaze CPU.
• 2009: I implemented an interface to link the JOP CPU (a Java processor for real-time systems) with application-specific co-processors.
• 2009: I implemented a high-speed UART named Teaport for the virtual lab project. It uses a large FIFO and allows Linux programs to send and receive serial data reliably at high speeds (several megabits per second). This is designed as a "Xilinx LogiCore"-style component and can be easily imported into EDK. It uses a PLBv46 bus.
• 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.

• Microprocessors and Microsystems
• Software practice and Experience

• 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-2010