How Firm Is Firmware?

By Frank Schirrmeister

When blogging recently about Xilinx’s presentation at the Cadence DAC 2012 EDA360 theater, which was given by Dave Beal, I ran across the diagram he had used to outline the “development stack” from hardware to software. Dave had described a virtual prototype to the audience as a functional model that recreates the WHAT rather than the HOW, duplicating the result of a compute operation, but not showing how (or how long) that result was obtained. The virtual prototype, often written in a high level language such as C, C++, or SystemC, may take advantage of the host operating system and host hardware features like floating processor units.

The diagram associated with this description showed, at the bottom, a stack describing the information used to create the functional device model. It layered “Firmware” on top of “Hardware” with core algorithms and functions, but placed Firmware below “Hardware and Software Interface,” which provides access to registers, interrupts, and memory maps, typically exported directly by the device or by firmware. Dave characterized Firmware as the type of software which extends hardware functionality, and can range from either non-existent to being very large depending on the device.

On top of the functional device model, the actual software was stacked as a combination of the actual application writing to the operating system APIs, layered on top of the operating system writing to the device driver interface, which was in turn layered on top of the operating system device interface, often referred to as device driver.

This made me think. I was confused. I had just drawn a similar diagram as you can see in this post. The arrows on the right were meant to illustrate what I had seen users developing on virtual prototypes, and to show the wishful thinking of what we would like to enable, i.e. programming of applications using our development platforms. So I contacted Dave.

I asked him for the specific reason that he layered Firmware to be “under” the HW/SW Interface.” Specifically, wouldn’t the firmware be developed using a virtual prototype? If not, how does it interface to the hardware? The reason for my confusion was that I have seen several users developing the boot ROM code – which was to be mask programmed later – using virtual prototypes. In my mind I always thought of that as firmware as well. Was I wrong?

In my discussion with Dave he described the definition of “Firmware” as rather tricky, depending on whether it is suitable to be run on the VP. In his diagram, Dave defined “Firmware” as something which “Extends Hardware functionality.” For example, the Freescale QorIQ and PowerQUICC devices include a network accelerator that when one peels back the layers, is in reality a standalone-processor running a bit of code (firmware) to make it do what is needed.  In this case, the firmware actually defines how the device functions, and thus its operations are included in the TLM model.  One might also call it microcode in this example.

If we consider other “firmware” definitions we see that it interacts with really low-level details of the hardware. Therefore, the model which runs Firmware must be much more register/device accurate than the model which runs software that intends to interface at the OS API or device register – Interface level.

Looking at a first stage boot loader example (also, arguably “firmware” but within a different definition of the above), certainly the model can be made “good enough” so that the firmware will run, thus allowing the OS to start. But that use case relies on a model using skeleton code that only provides the read/write registers without backing functionality.  If users are actually going to develop the boot loader on the model, then a skeleton may not do it for them. They would need to see what happens to the hardware when each register is modified, so the model has to be more complex.

Due to the diverse expectations and definitions of “firmware”, and its need to operate with really low-level registers and bits of the hardware, Dave emphasized the development of software that needs OS APIs, CPU instructions, and registers/memory maps for talking to devices.  No matter how one defines it, “Firmware” drops to the next level down where users might be able to run some types of Firmware, but need a lot of work on the model to run other types of Firmware.

Interesting. Now I am no longer confused.

I think what all this means is that virtual prototypes can be hierarchical. What Dave described with the QorIQ example, may be considered as a subsystem containing hardware and software, together being delivered to the next level of hierarchy at which the programming API is elevated to a higher level . And as Dave pointed out, to develop the lower level of hierarchy may require different underlying accuracy of the model representing it.

The different layers of software may all be developed using virtual prototypes, but also can use RTL-based technologies, like RTL simulation itself, for very low levels of software that require full access to all hardware functions and representations. Designers can also use Acceleration/Emulation for cases in which access to selected regions of the hardware is needed but higher speed into the MHZ range also counts, and FPGA prototypes, which provide full hardware accuracy at multiple MHZ speeds , but do not provide as much debug insight as Acceleration/Emulation does.

Comparing Dave’s and my graphs it turns out that they are actually not that different. Dave’s graph just stops earlier — it omits the applications developed by end users, and introduces the sub-hierarchy of firmware as it is used in a sub-system like one can find in the QorIQ devices.

BTW, you can see Dave Beal from Xilinx talk about virtual prototypes here, and a DAC discussion I had with EETimes’ Brian Fuller on the continuum of development platforms can be found here.

—Frank Schirrmeister is group director for product marketing of the System Development Suite at Cadence.