Teaching Operating Systems with Simics: An Interview with Massimo Violante

By Jakob Engblom

Engblom_lg Wind River Simics has been used in teaching for as long as I have been aware of Simics. Indeed, my first contact with Simics was when it was used in a graduate computer architecture course at Uppsala University in Sweden. In that course, we modeled cache hierarchies and replacement strategies with Simics and measured the performance results. A few years later, I was part of a team that created a project course based on Simics where students got to write their own operating system from scratch. Using Simics in teaching is an ongoing interest of mine, and that's why I am very happy to present another interview with a Simics user. This time, it  is Professor Massimo Violante and the Politecnico di Torino in Italy, who is using Simics to teach operating systems.

E: We start with the basics. Can you introduce yourself?

Pics 20110503 MV: I'm Massimo Violante, Associate Professor of Computing Systems with the dep. of Automation and Computer Engineering at Politecnico di Torino, Torino, Italy.

JEWhat is your university and department/research group?

MV: My university is an engineering school with all the classical engineering faculties (from mechanics to computer engineering). My group, the Electronic CAD & Reliability Group, is with the department of Automation and Computer Engineering. Our research is focused on developing methods and architectures for designing reliable embedded systems, and we are investigating on a number of different subjects from aging phenomena of modern semiconductor technologies, to architectures for reliable embedded systems for mission critical applications (which is my research topic). For this topic, I'm using Simics to model high reliable computers running mission software, and to run fault injection. The purpose of fault injection is to measure the reliability of the system that is built using innovating concepts like exploiting hypervisor for time redundancy implementation.

JEWhat is your research and teaching about?

MV: As I said, my research focuses on architectures for reliable embedded systems for mission critical applications, and aims at developing solutions based of commercial off the shelf components (both hardware and software) to build computers for space and avionic use, which must combine tolerance against errors with high performance.

In my research 90% is COTS hw/sw and 10% is custom hw/sw. In case HDL modeling/simulation is used for developing the 10% custom hw, most of the time would be spent in writing and simulating HDL code (using VHDL we developed a custom hw checker working as AMBA master for the LEON3 processor and it took a couple of months). Using Simics we speed-up significantly the modeling of custom hw thus allowing concentrating on ideas rather than on implementing them (we modeled a similar hw as before for the MPC8641D and it took a couple of weeks).

In parallel to the research activity I'm in charge of teaching the course of Operating Systems for Embedded Systems in the Master Degree of Computer Engineering.

JE: Sounds like we could have a long and interesting discussion about your research as well! Really cool stuff!

JE: Anyway, back to today's main topic. Which courses do you teach using Simics?

MV: In the course about Operating Systems for Embedded Systems I'm relying heavily on Simics.

JE: How do you use Simics in your teaching?

MV: I'm using Simics during lab hours (4 hours each week). Students, working in groups of two, are asked to develop lab exercises focusing basically on device driver programming.

My course has a theoretical part where I explain concepts like architecture of operating systems for embedded systems, and scheduling for real time systems, and a practical part where I teach device driver programming.

In my vision an embedded system is a computer where at least one COTS processor communicates with custom hardware, and students should learn how to manage this situation. In the first edition of the course I used Linux (vanilla, RT-patched, and Xenomai), QNX, and RTEMS as case studies. I developed a simple custom hardware that maps on the processor local bus and generates one interrupt, and the students had to develop its device driver for the operating systems I presented. For this purpose I used the MPC8641D model (for Linux and QNX), and the LEON2 model (for RTEMS). I used the simulation in normal mode and in stall mode to measure interrupt latency for different operating systems, to show students this important concept on a testbench.

 Simics allows me to teach device driver programming with a less painstaking process than with real hardware. Moreover, it allows me to take measurements, like for example interrupt latency, to show important concepts that would be more difficult to understand with real hardware.

JE: That is pretty sophisticated. I like the idea of using a standard OS as the basis for teaching, as that makes exercises much more real. It also teaches students some skills that are otherwise pretty rare. Building an OS from scratch like I did teaches some concepts well, but does not really address how to program in the context of an OS (I taught myself this a couple of years ago). 

JE: What are the main problems the students have doing device drivers?

MV: I would say that there are three recurring issues with students dealing with device drivers: I'm listing them in order to importance.

One big issue is physical memory versus virtual memory. In the Simics model I'm using the physical address to map the custom device on the processor bus, while the virtual address should be used in the device driver. Moreover, depending on the configuration of the processor the same physical address may correspond to different virtual addresses (e.g., u-boot versus Linux), and this often makes the life of student complex. Simics is really useful to cope with this issue, as student can look at the MMU configuration, easily translate physical addresses to virtual ones, and look at each memory space of the system in an easily-readable way.

Another issue working with Linux system is the difference between user space and kernel space. When starting writing device drivers students tend to ignore the difference, with the obvious result of not being able to have their applications communicating with the custom hw. Again, if debug messages are used cleverly when writing the model of the custom hardware, students can see that something is not properly working because the custom hw is not providing the expected messages on the Simics console.

A final issue issue is related to the endianness of the data and the data size when accessing custom-hardware registers (e.g., big-endian versus little-endian, and bytes vs words). Sometime, students gets confused on this topic, and again Simics is helpful by providing warning messages (especially for what concerns register size).

JE: How does using Simics help you teach, and how does it compare to using hardware?

Using real hardware instead of Simics is more complex for two big reasons: a technical one and an economical one.

From the technical point of view, with Simics I can model any type of custom hardware, and I can plug it almost seamlessly to any interface of the virtual machine: the plb, the spi, the serial port, wherever. Moreover, I can easily use different architectures (e.g., PowerPC, and Sparc) and different operating systems. This is not possible with the real hardware unless a lot of implementation effort is done, including custom board designing, assembly, and testing. If I want to use the same custom hardware on a PowerPC and a Sparc as I'm doing in my course I need to have two different board designs; moreover, if I want to use different interfaces like expressPCI, AMBA, spi, the board designs starts becoming quite complex and expensive. And this brings me to the economical aspect of the game.

As my activities are supported by the Wind River Academic Program, and I have to thank Wind River for this opportunity, I received a number of licenses suitable for allowing every student in my class to use their own virtual platform. During lab hours one PC is all that is needed for a student to start developing, debugging and testing his/her own device driver. Moreover, students can use the virtual platform at home by connecting to the development host remotely.

With real hardware huge investments are needed for supporting a similar scenario. In my wildest dream this would require for each student: two evaluation boards (one with PowerPC and one with LEON), usb to serial cables, two hw emulators for debugging (one for PowerPC and one for LEON), and adequate power supply. The total bill would be quite high!

The number of students I had in the 2010/2011 academic year was 32, and I'm expecting more students for the next years. On top of this, using real hardware does not allow to scale easily with the number of students, it is prone to hardware obsolescence/aging, and does not offer the possibility of working from home.

Besides all these reasons, working with virtual platforms is much easier: in case of hardware hang-ups it is easy to stop the simulation and to analyze the state of the system to figure out what was wrong, there aren't dead times as using checkpoints it is easy to save time when bugs requires frequent booting, and infinite number of booting is possible without the risk of stressing to much the hardware.

JE: What do the students think about Simics?

MV: Some of them are very happy of working with Simics: they asked to know more about it, eventually deciding to do their Master Thesis under my supervision on projects using Simics.

JE: Thank you! I think that was very interesting, and it gives you a glimpse into what you can do with Simics as a teaching and training tool. Good luck to you, and your students are lucky to have such a creative and engaged teacher.