The Zynq Virtual Platform: Not Just for Pre-Silicon

One of the biggest misconceptions about Virtual Platforms is that they are only useful for pre-silicon software development, and once a chip and board is ready they are quickly discarded. Even after boards are available, Virtual Platforms are valuable for software development.

Last week I was talking with an engineer at a company that is working on a new system design and has started Virtual Platform development. He told me that one of the software engineers was working on a demo to showcase their new operating system running on the target CPU. The software engineer had a reference board with the CPU and enough hardware to run the OS and show a demo application, but after a number of days struggling to get the software working to his satisfaction, they decided to try the SystemC Virtual Platform to see if any more information could be obtained. In less than 30 minutes the problem was found and fixed. The success was due to the visibility provided by the Virtual Platform, visibility that is not possible with a board. The lesson learned was that after hardware registers are programmed, it's very difficult to see what the system is doing.

Another misconception about software engineers is they don't care about hardware or don't need to see what's going on. Its true, many application developers don't care about hardware details, but in the world of embedded systems many software engineers do care about hardware interactions. One of my friends is an embedded software developer. He told me embedded software engineers actually get paid more because of this hardware knowledge. While looking through new job opportunities he noted that many were offering salaries which were too low, not "embedded type salaries".

To illustrate my points let's look at the System Watchdog Timer from the Xilinx Zynq-7000 Extensible Processing Platform. Watchdog timers are commonly used in embedded systems to make sure the system doesn't get hung up and require somebody to hit the reset switch. I'm pretty sure my Android phone has one, because whenever it gets sluggish and then locks-up, it reboots itself instead of just freezing. In this case the watchdog timer saves me from having to take out the battery.

We can view the Zynq Watchdog Timer in 3 sections; the hardware, the Linux device driver, and the software application.

The hardware is pretty simple, it has only a few registers, but it does have programmability to enable and disable different actions when a timeout occurs; such a choice of different output signals to set and the length of time these outputs should be driven active (pulse width). It also has a programmable counter to set the time and a separate prescaler value to further divide the hardware clock. To make things more interesting, the counter value is shifted left to actually start with a larger value then the programmed value.

The purpose of device drivers is to abstract hardware by hiding the complexity and avoiding the perils of hardware programming. The Linux driver for the watchdog timer should help the application developer by eliminating the need to understand all of the details of the counter value, the prescaler, and the clock frequency.

An application using the watchdog timer would like to do something such as set watchdog timer to expire after 11 seconds, and then make additional system calls to keep it from timing out at intervals at less than 11 seconds to prove the system is still running fine. How the 11 seconds translates into details of programming the hardware is not important as long as it works correctly.

Here is a fragment of an application which uses the watchdog timer:

Here is the corresponding driver code which actually programs the hardware.

How do we know that the watchdog timer will actually expire after 11 seconds? Should we use a stop watch or count out loud? How can we test the watchdog timer? Should we stop the refresh on purpose and then see if the system reboots? What if it doesn't reboot? Can we tell if the refresh operation is happening at the expected frequency?

One way to confirm operation is by using a Virtual Platform. When we first created the Cadence Virtual System Platform product we received some feedback that Cadence as a company is too hardware centric. It's true that we did have a lot of work to do in the software side of the picture, but it's also clear that having a strong foundation to build on is a benefit.

Below is a screenshot of a waveform which captures all of the programmable registers in the watchdog timer and the outputs of the hardware model. It's easy to use the cursors to measure the actual time between when the software changes the register values until the output value changes. From the picture it's clear that it's 11 seconds. It's easy to confirm the refresh rate, and it's easy to disconnect signals and observe their behavior without causing an actual system reset to occur.

Over the years I have read many embedded systems magazines with articles like this one from Jack Ganssle about making sure to build hardware with software debugging in mind and teaching embedded software engineers to use logic analyzers for debugging. I don't even know what year this one was from, but I'm sure that there will always be embedded software engineers who care about hardware -- and providing good control and visibility is only going to get more difficult.

Jason Andrews