Earlier this year, I was invited by Alberto Garcia Ortiz to give a course at the University of Bremen. The course took place in two 1-week stints during May and June, and was included in Bremen's "Internationalization at home" programme, which provides funding to international academics to come to Bremen and contribute with teaching activities in leading-edge areas that are not covered by their existing curricula.
I know Alberto since the early 2000's when we were doing our PhDs under Manfred Glesner at TU Darmstadt. We have collaborated in research ever since, mainly because of our complementary research expertise and interests - he works in digital and analog electronics, while I position myself at the interface between digital hardware and software. For the course, we agreed that I would cover both the hardware and software aspects of multiprocessor embedded systems based on Networks-on-Chip. I cover some of that material here at York within my Embedded Systems Design and Implementation module, which is part of our Computer Science undegraduate degree. My plan was to reuse and extend that material and therefore sail through known waters.
Before the first lecture, as I was showing Alberto my slides and my plan for the whole 2-week period, he looked concerned and said that while he was expecting a couple of students from the Computer Science department to attend the lectures, most of the class would be students from his own department: Electronics Engineering. I replied that this should not be a problem, since the course was reasonably self-contained and included most of the necessary Computer Science background on concurrency, models of computation and specification languages. I actually intended to start the course by covering those foundations during the first lectures, just as I do in York, and then move towards embedded software and operating systems, and finish with the underlying hardware architectures for multiprocessors. But that was exactly his concern, it turns out: that I would start from a completely unknown territory to Electronics students, and slowly move towards the hardware-related topics that they were more familiar with. After a few minutes of brainstorming, it was clear to me that the only way to take onboard Alberto's suggestions would be to follow the original teaching plan, but upside-down.
I was not fully convinced (and not really keen to update all my teaching plans and slides in such a short notice), so I went to the first day of lecturing with my regular "overview and motivation" slides, and finished the lecture by showing the students the original teaching plan and its bottom-up alternative. After a show of hands, it was clear that all students (except two or three from Computer Science) preferred the alternative. So I had no choice but spend a couple of hours every morning rearranging the plans and slides to make sure that the course would also work upside-down.
In some senses, it was much harder than I thought it would be, but this was mainly because I had to redo many slide sets to make sure I would cover the pre-requisites ahead of each major topic. But the teaching plan worked quite well from a bottom-up perspective. I started with a review on single-processor architectures, instruction sets and co-processing. Then, I introduced in more detail the driving forces behind multiprocessors (which were hinted during the first lecture) and spent a good amount of time talking about on-chip interconnects and memory hierarchies. This was followed by different ways to evaluate performance and power dissipation in such architectures: simulation, emulation, static analysis, prototyping. At that point, I could make a strong case for having models of the application and system software in order to obtain accurate figures for performance and power. With that link, I then introduced the system software stack that can be used in multiprocessors (OS, virtualisation, communication libraries) and the models of concurrency supported by them. I finalised the course explaining the different kinds of guarantees that can be granted by the different models of concurrency (e.g. predictable worst case behaviour for sporadic processes, bounded communication buffers for synchronous dataflows, etc.), thus justifying the use of each of them.
There are many ways to teach a lecture, and I believe a lecturer should be able to adapt the teaching plan to the audience. That's what I tried to do, and I actually enjoyed doing it (except all the Power Point fiddling, which was simply boring).
