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

Effective hardware/firmware co-design (Part 2)

Posted: 19 Sep 2013     Print Version  Bookmark and Share

Keywords:Buffer  embedded systems  interrupt  hardware  firmware 

When hardware is working on one chunk with its configuration settings, firmware can load up the hold register set with the settings for the next chunk. When hardware is done with the one chunk, it can then transfer settings from the hold set to the working set and continue with no delay. When the block transfers from one chunk to the next, it interrupts firmware, notifying it that the hold register set is empty and can be filled with the settings for the next chunk.

Best Practice Tips: Provide data buffering, queuing, and chaining to maximise data throughput. Provide double-buffered registers so that firmware can queue the next task while the block is still running the current task.

Tuning. When a system is being designed, a lot of study is put into optimising performance vs. power consumption. Educated guesses are used to figure out bus priorities, memory bandwidth, and clock speed.

Simulations are used to refine those numbers. But even after a thorough study, numbers may not be right because of incorrect assumptions or unanticipated use cases. This causes problems for fabricated chips if those numbers are hard-coded and need to change.

Some performance aspects in the chip can be designed to allow firmware to tune those numbers if the default values need to be changed. This could include being able to adjust bus priorities, DMA transfer sizes, clock speeds of different buses or blocks.

In some cases dynamic changes in the tuning numbers may be desired to alter the behaviour based on conditions. Many battery-powered products do this by switching between being optimised for battery life or for performance.

Best Practice Tip: Make the chip tunable so that firmware can adjust performance characteristics such as bus priorities and clock speeds.

Margins. Consumers always want the new model of the electronic devices to be faster than the previous model. To satisfy that demand, it is not uncommon for existing chips to be looked at for producing faster products.

However, it is difficult to know if there will be enough bandwidth. Existing products are known to work okay, but how much performance leeway is there? Is it running at 60% or 95%? If it is 95%, then it cannot go much faster.

If the chip were designed with a 10 or 20% performance margin, it will increase its chance of being usable in the next faster product, thus saving several months and millions of dollars of designing a new chip just to make it slightly faster.

Best Practice Tip: Maximise performance margins to increase the potential for chip reuse in faster products.

Handling hardware power-on
Hardware typically comes out of power-on reset very quickly. Firmware typically does not. Firmware takes a long time to boot; it tests memory, installs the OS, installs the device drivers, and launches the applications.

Each device driver and each application has to be launched serially. Each one starts, initializes its data structures, and opens any connection ports to other firmware components.

It is not until the device drivers are installed (one at a time) that firmware starts to communicate with hardware. Each device driver initializes their respective block by configuring registers and enabling interrupts.

Before one firmware component can interact with another firmware component, both need to be up and running before they can start talking to each other. This requires some agreement or protocol between the two.

Typically if one block needs to interact with another block, they wait until their respective device drivers are up and running to coordinate the interaction. If, however, blocks need to interact at power-on, they must be able to do so without firmware assistance.

Any results (such as success, failure, status) from that power-on interaction can be reflected in registers that their respective device drivers can read when they start up.

Best Practice Tips: Design the block such that it does not require firmware interaction immediately at power-on. Design each block such that is still works at power-on even if its collaborative blocks are not ready yet. (Power-on initialisation requires extra consideration because different hardware and firmware components are turning on in different states and initializing at different rates.)

 First Page Previous Page 1 • 2 • 3 • 4 • 5 Next Page Last Page

Comment on "Effective hardware/firmware co-desig..."
*  You can enter [0] more charecters.
*Verify code:


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


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top