What Have Models Got to Do with It? Pre-Silicon SoC Software Bring Up

Transaction-level models are the main building blocks of virtual prototypes, which are used for early software development. In my last blog post, I briefly introduced the different kinds of software tasks and the implications for models. Today, I want to talk about the modeling requirements for early SoC bring up. As I mentioned, understanding the software requirements correctly provides two clear benefits: 1) it makes modeling easier through a more focused application and 2) it increases the value for the software developer through more tailored modeling capabilities such as debug features.

Within the context of pre-silicon software development for SoCs, the dominate use model for virtual prototypes is the bring-up of both the operating system and the chip validation suite. To bring up an operating system such as Linux, you must consider multiple aspects: primarily the CPU architecture specific code, the peripheral device specific drivers and the SoC/platform (aka machine) specific configuration.  Once a new CPU architecture is supported, or a device driver is available, they can be leveraged by the different platforms. Still, it is surprising how much code you have to write (and validate) to support a new platform. Of course, this platform support code will need to register all the different devices and set up the memory map and interrupts of the platform, but interestingly a lot of the platform specific code just deals with clock and voltage control (e.g. TI OMAP). Power domains are defined; voltage levels and frequencies are configured all over the place. Linux provides specific clock and regulator frameworks as well as the so called CPUFREQ framework for DVFS which are also used by the various power management frameworks.  Most of the settings are managed by the board’s power management IC (PMIC), or the on chip power-reset-clock-management-unit (PRCM).

This is not just happening for advanced features such as DVFS.  These techniques are also employed to get the simplest peripherals to work such as a UART. Before the UART driver can access the UART, it has to be clocked and powered. If this is not the case, the register interface of the UART will be in an undefined state and many TLMs do not take care of this situation today. In order to have a model support these aspects of the software, the model should perform a simple check to verify any abnormal operating conditions and inform about them. This simple addition to the model will greatly improve the value of the model and make software development and debugging more efficient.

Of course, it is necessary that these models are also equipped with ports that provide information about voltage and frequency, so that the model can check whether the levels are within acceptable limits. This does not mean that we need cycle accuracy with sensitivity to the clock, but rather we are interested in supplying the model with numeric information about the frequency and voltage.

The software is driving the clock tree and power network by configuring the power reset clock management (PRCM) unit or the power management IC. Thus, our virtual prototype should have an abstract model of this component that provides an accurate register interface. The internals of this model are not relevant in this context unless we also want to develop the firmware here. All that is required is that the clock and voltage lines are driven correctly by this model and the topologies of these networks are accurate.

So, in summary, with three relatively simple additions to an abstract, loosely timed virtual prototype we can greatly increase its value:

• TLM should check voltage and frequency values are in acceptable ranges
• A register accurate model of the power management IC and/or power management IC
• Accurate topology of the clock, reset and voltage networks.

By the way, did you know that wrong constraints and settings of the software-driven voltage regulators can result in hardware damage? I bet you’d love to be able to just restart your simulation rather than explaining to your management why the board can now only be used for decoration in the office lobby.