Manage CPU time: Use dedicated hardware to handle real-time tasks whenever possible

By: Steve Leibson, Director of Strategic Marketing and Business Planning, Xilinx

In 2009, Michael Barr published a blog post titled “5 Simple Steps to a More Robust Embedded Software Architecture.” Barr was the editor-in-chief of Embedded Systems Programming magazine, so you should consider him an expert on writing embedded code, I think.

In the blog post, Barr wrote:
"I have gathered a lot of evidence that most programmers, technical managers, or teams don't really understand what a good firmware architecture looks like, how to implement it, or even how to recognize when they are looking at a good architecture. This includes the most experienced developers on the team."

Later, Barr's blog post gives a 5-step process for developing a stable embedded firmware architecture.
1. Identify requirements
2. Separate architecture from design
3. Manage CPU time
4. Test design
5. Plan for change

The entire post is worth the time to read, but here I want to focus on Step 3: Managing CPU Time, where Barr writes:

"Most products are a mix of non-real-time, software real-time, and hardware real-time requirements. Software time constraints are usually the most challenging to define, test, and enforce in an explicit way. For example, in a set-top box design, it may be acceptable to drop an occasional frame of video data, but not drop more than two frames in a row, and not drop any audio data, which is included in the same digital input data stream. The simplest way to deal with software time constraints is to treat them like hardware time constraints that must be met.

Once the timing constraints are identified, the first architectural step is to move as many timing-critical requirements out of software and into hardware. Figure 1 shows the order of precedence for how real-time functions should be handled. As shown, the ideal place to handle real-time functions is in an FPGA or a dedicated CPU (regardless of the length of the timing constraints). Only when this is not possible should an interrupt service routine (ISR) be used, and when an ISR is not available, a high-priority task should be used.

Note that Barr recommends using dedicated hardware to handle real-time tasks, such as an FPGA or a dedicated processor, and he explains why:

“First, because it simplifies the design and implementation of non-real-time software, architecturally separating the timing requirements from the bulk of the software, which allows the use of code written by novice code without compromising user safety. Another benefit of putting the real-time functionality together is that it simplifies the analysis process of verifying that all timing constraints are met.”

Barr wrote these words less than eight months before Xilinx announced the Zynq SoC in 2010, but he should have been more direct. The Zynq SoC 's programmable logic ( PL ) is exactly the kind of resource you need to implement custom hardware to handle hardware real-time requirements, including those tasks that require some dedicated I/O, as Adam Taylor describes in his blog post today, " Adam Taylor's MicroZed 34: Driving the Adafruit RGB NeoPixel LED Array with MicroZed... " In this simple example, a dedicated serial driver for the Adafruit NeoPixel LED strip was implemented using the PL hardware logic in the Zynq SoC. If you need to do something more complex, there are many ways to use the Zynq PL. You can instantiate complex hardware blocks in the Zynq's PL, including memory controllers, Ethernet MACs, DSP blocks, and many other types of hardware blocks. These blocks can be commercial IP or your own blocks developed in Verilog, VHDL, or designs synthesized from C/C++ code using Vivado HLS.

If for some reason your system needs to be extremely complex in terms of real-time performance, then consider using a multi-core design. The multi-core Zynq SoC has two ARM Cortex-A9 MPCore processors that can run at frequencies exceeding 1GHz. If necessary, you can use one of the ARM processor cores to handle real-time code and a real-time operating system (RTOS), and the other ARM processor core can run code that does not require or cannot work in real time (read "Linux," GUI, and apps here).

Again, I recommend you read Barr’s entire blog post, and if you liked it, why not sign up for a free webinar on June 3rd hosted by Barr: “ Bug-Killing: The 10 Most Important Coding Standards Rules”