Talkative modelsIt's great to see a growing amount of IP suppliers providing models that enable early, hardware-dependent software development in the context of virtual prototypes. The value of models is not just in their earlier availability but in the way they can help the software developer. I've been writing about this topic earlier ("Model Behavior" on Chipdesignmag.com). I'll get more explicit and take the opportunity to list some characteristics of models that greatly increase their usefulness by easing and assisting developers during software bring-up.
Activity and status reporting
Exposing information about the internal model status can provide important information to the programmer. It gives confidence that the hardware is programmed properly and eliminates uncertainties about the hardware operating mode and the correct interpretation of the reference manual. Is the timer now in periodic tick mode or is it in one-shot mode? This type of information helps to narrow down the cause of a potential problem and gives clarity rather than forcing the developers to bet on whether they've made the right assumptions about the operation of the hardware. Models should inform the programmer of a couple of standard "vital signs":
- Supplied frequency and voltage
- Operating mode
- Masked interrupt generating events (such as off-chip bus and wake-up events)
- Internal FIFO full/empty
- Peripheral DMA events
- Reset status
Here's a simple example where the above information is of great help when things don't work as expected: A simple UART and the corresponding PHY require voltage and frequency (1) in order to function. If the baud rate is not initialized, no data will be transmitted over the serial line. During the Linux boot, the UART first operates in the polling mode (2) since interrupt handling services are not yet available. Once, the system timers are initialized, the UART is used in the interrupt mode and data is written and read from transmit and receive FIFOs. If the OS interrupt handler is not functioning in the expected way, such as not being called or not reading from the receive FIFO, FIFOs may soon be full (4).
By providing the above information about the hardware state, the programmer gets immediate clarity about whether the hardware is following what the software intends to achieve. If the hardware is not functioning as intended, there is enough information to point the programmer in the right direction to fix the problem.
Programming error reporting
Models should "care about" some obvious things to make the gap between the real hardware's behavior and the model as small as possible. This is concerning the model fidelity or the sensitivity of a false operating condition:
- Supplied frequency and/or voltage is not within a valid operating limit while programming the peripheral
- Read/write to/from write-only/read-only register
- Reset is asserted while peripheral is programmed
Often, the above items are not considered when creating a model. There is an upside and a downside to this. Not being concerned with power management can greatly ease initial phase of the driver bring up. You're able to focus on the functional aspects rather than caring about the clock and voltage framework and their getter/setter functions through the complex PRCM (Power Reset Clock Management) unit. However, it causes a problem when the driver should be completed. Here, models have to provide the right level of fidelity to let the software run into the fault handler. For example, trigger a data-abort exception if the peripheral is programmed without any clock supply.
I just ran into this problem while bringing up a driver for a Mobile Storage Card Controller (MMC). Everything had been working fine (probing, initializing) except the fact that all of my commands to the MMC card timed out. If I would have taken a look at the log file earlier, it would have saved me almost a day of debugging: The card voltage supply was not set!
Listing 1: DesignWare MMC model debug messages while mounting a card.
000070:2acc:.i_DWC_MobileStorageHost: 000070:2acc:Card 0 Inserted, Card Detect = 0x3FFFFFFE 000070:2acc:Received ClkIn(240000000) signal 000070:2acc:Received Reset(0) signal 000076:2acc:.i_DWC_MobileStorageHost: 000076:2acc:WrCMD(): Warning Card 0 Power Is Off
Programming sequence error reporting
Models can be even made smarter if we add some intelligence that tries to detect what the programmer is doing. While it's hard to do and may result in a lot of false positives, it's worthwhile just to catch some access patterns that violate the Technical Reference Manual. As an example, the model could assert that a control register should not be reprogrammed when interrupts are unmasked.
Energy efficiency is a growing concern of embedded systems software developers--draining a battery too fast is as severe as a functional defect. In order to help software developers implement the most optimal power management, which fully exploits the power saving capability of the hardware, the model should be verbose about the power state. Also, the model should report if the power-saving modes are not taken advantage of. For example, the sensors are still turned on even though the software sent the sensor controller into a suspend mode.
Most of the above items are easily possible to realize and almost all information are already tracked and considered inside a model. Often, it is just a simple addition of a log message that is required to expose valuable information for the programmer. A white-box model that is talkative can have a very high impact on the efficiency of the software developer.
Achim Nohl is a technical marketing manager for virtual prototyping at Synopsys. He actively publishes technical articles, conference papers and blog posts around the topic of developing embedded software using virtual prototypes. His specialty is bringing up firmware, drivers and operating systems for the most recent CPUs and IPs. Achim holds a diploma degree in Electrical Engineering from the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany. Before joining Synopsys, Achim has worked in various engineering and marketing roles for LISATek and CoWare.