Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Processors/DSPs
 
 
Processors/DSPs  

Issues in shifting from single to multi-core

Posted: 19 Mar 2014     Print Version  Bookmark and Share

Keywords:embedded development  user interface  Multi-threaded  multi-core  instrumentation 

What has the mitigation for such risks been historically? Answer: people. Mitigation plans often add developers during the later phases of the development to fix the issues. But bringing in a team at that point has its own set of risks. There is the required "ramp-up time" for new team members as well as the need for the current team to set aside cycles to train the new developers brought in.

Couple that with the fact that a percentage of the issues will be very difficult to root cause, thus requiring the attention of the experts on the team, adding developers can cause a project to actually lose ground. To provide the senior developers with every advantage in solving these complex issues, traditional software debugging techniques are no longer adequate on their own. The experts on the team need new methods to efficiently resolve these problems.

Leveraging instrumentation
The new method proposed herein is the incorporation of software instrumentation to analyse the behaviour of the system and help debug complex issues in a way that complements traditional software debug. Instrumentation, in this case, is defined as the insertion of code that generates trace data, which in turn reveals important information about the state and flow of a software application.

Though instrumentation has been used informally for many years, it has matured greatly from the days of "printf", and its inclusion in the formal software development processes for complex system analysis is long overdue. However, it's an investment that must be designed in from inception if a project is to maximise the benefits. Instead of a developer putting all that they learn into a debug session which is lost when the target power is turned off, when a project invests in instrumentation, the team is putting much of what they learn into the code itself to be leveraged over the life of the program.

Establishing a process
To incorporate instrumentation into a project, an implementation process could be outlined as follows:

1. Expect and plan up front for integration challenges in complex systems. Also, envision the long-term use, leveraging, and ROI that instrumentation can provide on your current project and any future projects.

2. Define up front the complementary technical solution that will be most able to help the development teams to analyse, understand, and characterise system behaviours. This understanding will aid in debugging complex interdependent system issues. This solution is to instrument the code in preparation for use in future analysis. The solution should also define the Analysis Tool that will be used for the project.

3. Modify up front the software development processes that every developer on the project must adhere to and enforce these throughout the development efforts.

4. Resolve the issues as they occur – aided by capturing and visualizing the software flow in the selected Analysis Tool.

Instrumentation and software application analysis
In complex embedded systems, standard debug is no longer enough. The sooner project teams realise that analysis of software system behaviour is just as critical as traditional debug, the sooner projects will begin to benefit.

When coupled with Analysis Tools, or even "trace viewers," instrumentation can provide insights into the system's behaviour that are nearly impossible any other way. Some trace viewer tools are available as open source and can be helpful. Commercially available tools take this to the next level, and provide insight into interdependent behaviours of the system as well as tuning views to analyse a developer's specific use case.

Figure 2 provides a snapshot from Mentor's Sourcery Analyser as an example. The tool is able to extend beyond a typical trace viewer by obtaining complex measurements, performing mathematical transforms on waveforms, and creating custom analysis agents, as well as supporting multiple input trace data formats.

Figure 2: Sample waveform view using Mentor's Sourcery Analyser.


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



Comment on "Issues in shifting from single to mu..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

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