Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Performing hardware/firmware co-design (Part 1)

Posted: 28 Oct 2013 ?? ?Print Version ?Bookmark and Share

Keywords:Hardware? firmware? co-design? OS? timers?

While hardware and firmware each have their respective tasks to do, they must also work together as a system. Such is the case in embedded systems. Coordination must occur between hardware and firmware, especially to keep both working optimally.

However, if the system is not balanced, performance could be impacted if firmware is waiting for hardware to finish something or if hardware is waiting for firmware to say what to do next.

Firmware has to wait for hardware to complete a task. In the meantime, firmware often busies itself with other tasks. But if hardware does not generate any kind of task completion signal, firmware is often left guessing and accommodating a worse-case scenario. On the other hand, if firmware is too busy to respond to interrupts from hardware, hardware is left idling and possibly could miss external events it needs to handle.

Timing is not the only aspect, but efficiency across the hardware/firmware interface is a factor, too. Inefficient designs are prone to defects that need to be detected and resolved. In this chapter I will discuss several design aspects that will help hardware and firmware work more efficiently to increase performance and reduce unnecessary waiting.

Event notification
When some event occurs in the block that firmware needs to respond to, firmware needs to be notified. Events in the block result from block tasks that were launched. Launches can be divided into two categories: external launches and firmware launches. Events from external launches come as a result of something from outside the block launching a block task, such as an incoming data packet or a signal from another block.

They come asynchronously; neither the block nor its device driver can anticipate when it will come. The block is set up to watch for it and generate an interrupt for the device driver to handle it. Events from firmware launches come as a result of firmware having launched some task in the block, such as process some data or send out a packet.

Often the hardware engineers designing the block have a good idea as to how long the task will take. However, that information may not be very useful for firmware. For example, if it is known that a block task will take 2000 clock cycles, how can firmware use that information? Firmware engineers do not know what that means for a number of reasons:
???The CPU and the chip are not necessarily running at the same frequency.
???Firmware engineers typically do not know how many CPU clock cycles a section of code takes (unless they are writing in assembly).
???A CPU with a multiple core or that reorders instructions makes it difficult to calculate.
???When idle, a CPU could shut itself down, which stops its own clocks.
???Other system interrupts will stop the current firmware thread from executing temporarily, and the thread will not know that it occurred.
???The CPU may be busy working on some other firmware task.
???I/O reads and writes from the CPU to the chip typically take a few extra clock cycles.
???The CPU can buffer up I/O reads and writes, so others may be in front.
???Different CPUs have different read/write characteristics.

So how should firmware know when the task is done? Firmware can only know how much time passes by reading some counter in the CPU or chip. But firmware is not so concerned with how much time has passed; it is more concerned about when some event has occurred.

Different methods have been used, each with their own advantages and disadvantages. Events from external launches always generate an interrupt. But if firmware just launched a task with a very short time, generating an interrupt right back to firmware might not be optimal. Firmware finds out that it can proceed with the next step using one of these four methods:
???No indication
???Timed delay
???Status bit

No Indication. The block does not have a way to notify firmware that the task is complete. This is often used when the task completion is immediate; or, in other words, synchronous with firmware's access of the block, such as changing configuration settings or an instantaneous abort. This is okay because firmware can safely and immediately write something else to the block.

However, when designs evolve and tasks that used to be instantaneous are delayed or take time to complete, there is the risk that firmware could access the block again before it is ready.

It is not good design to not indicate to firmware that a task has completed or that an event has occurred that is not synchronous to firmware's access to the block.

1???2???3?Next Page?Last Page

Article Comments - Performing hardware/firmware co-desi...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top