I found some interesting reads, but no clear cut template on what a complete architecture migration guide should specify.

Some of the interesting hits included:

• Porting an existing embedded system to Linux (http://www.embedded.com/columns/technicalinsights/185300272?_requestid=175826By David Knuth and Daniel Daly, Intellibot Robotics, LLC)
  Designers from Intellibot Robotics chronicle the transformation of their microcontroller-based embedded design ” a mobile robot - from one without an OS to one built on Linux.
  
• Migrating from x86 to PowerPC (http://www.ibm.com/developerworks/library/pa-migrate/)
  Low-cost real-time development with Linux on PowerPC
  By Lewin Edwards (sysadm@zws.com), Author, Freelance
• Intel Migration Center (http://www3.intel.com/cd/ids/developer/asmo-na/eng/dc/migration/index.htm)

The first two links detail case studies in performing a migration.  This is nice because it shows a real example.  The drawback to case studies of course is in sometimes being too specific; if your planned migration doesn’t match what’s detailed in the case study, you may be no better off for having read.  The last link is a website with a number of articles on the topic of migrating and seemed motivated by the move to the Intel 64 ISA from 32-bit platforms.  The linked papers on the site provide some helpful information, but are topic specific and either hit or miss.

If you are performing a migration to Embedded Intel Architecture a good resource is chapter 4 of my book, “Software Development For Embedded Mulit-core Systems.” 

http://www.elsevier.com/wps/find/bookdescription.cws_home/714327/description

I don’t mean to toot my own horn, but the chapter was written with such a migration in mind so it’s pretty complete.  Of course, there’s always room for improvement.  The chapter provides a good general overview of migrating to Intel Architecture.  I believe it could be improved by providing a comparison/contrast on the architectures from which you’d be migrating such as ARM, PPC, MIPS, and a couple of case studies. 

With that in mind, here’s a high level outline on what I think is needed to fully cover the topic of architecture migration. 

• General introduction
  • Discuss Application-level vs. System-level migrations
  • Compare/contrast architectures
  • Compare/contrast operating systems
• Discuss choosing an operating system and pros/cons of each
  • Proprietary – pros – if it’s your OS, you should be familiar with it.  Cons – must roll everything yourself, especially support for SMP, next instruction sets, tools
  • Linux – pros – high level of support, lots of choice, dev machines can be same as target OS – cons – may not meet real time requirements, code rewrite probably required for system level stuff
  • Embedded Linux
  • Embedded OSes (VxWorks, FreeBSD, QNX of the world)
• Boot/Bios – Discuss bootup/BIOS
• 32 vs. 64 bit – Compare/contrast
• Architecture extensions – Discuss SIMD instruction sets
• Endianness – Discuss big & little endian and possible issues in porting code.  Some solutions to the problems.
• Multicore specific – Discuss SMP or AMP support and ramifications
• Tools Support
  • Compiler, debugger – typically required
  • Performance analysis, threading tools – typically nice to have
• Case Studies
  • System-level migration running the gamut of embedded issues
  • Application-level migration focusing on SW issues (library support, etc.)

Thus, there it is - the perfect migration guide.  The problem: someone has to write it.  Perhaps, this will serve as input into a 2^nd edition of my book J.

Some strong points about the artice:

• Very concise coverage of the challenge with multicore, basic performance terms, parallel programming terms, and race conditions in the introductory sections.
• Good simple critique of roll your own multithreading - I agree when you do this typically your parallel version becomes very different than the serial version and typically scalability is limited due to the developer more or less hard coding for one multicore processor.
• Good summary of existing concurrency platforms.
• 20 questions cover several aspects of software product development, not just the technical ones
• Loved the bios - always good to add a personal touch

With the positive out of the way, my two main nits, perhaps they boil down to one which is the paper seems focused on homogenous multicore:

• Seemed to be a bit Intel focused - with respect to the company I work for, this is fantastic and I suppose you could make the case that many/most of the multicore in desktop/server is x86, but there are other programming models and architectures. 
• I believe many customers are eschewing multithreading and partitioning/multiprocessing instead.  It may have been good to comment on why this approach won’t necessarily scale in the long term.

That said, again I really enjoyed the article and recommend it.  It has given me some things to think about as we pursue the Multicore Programming Practices guide in MCA (http://www.multicore-association.org/workgroup/mpp.php).

One of our challenges in the group will be giving good coverage of best practices for several different multicore architectures split among multiple vectors, e.g. homogenous/heterogeneous, shared/distributed memory, symmetric/asymmetric.  It will be interesting to see how/if the practices generalize.  

Max  
 

I was in Las Vegas last week for some vacation (NBA Summer League) and learned there was a pretty large technical conference occuring at the same time that I missed.  The conference was WorldComp’08 (http://www.world-academy-of-science.org/worldcomp08/ws) and featured tracks on embedded, communications, and parallel processing, to name a few.  Looking at the agenda online, this would have been a pretty good conference for me to attend and this got me wondering: are there other conferences coming up in 2008 that I should know about and that provide a good pulse on what is going on in embedded.

With that, I’ll share my list of what I know about.  I’d be happy to know about pointers to others so please feel free to share:

- NI Week, Austin, August 5-7
- Embedded Systems Conference, Boston, October 26-30
- Multicore Expo, Tokyo, November 6-7

Best regards,

Max

• Multicore Programming Practices - defining industry-wide, best practices to leverage existing code in multicore environments.

The working group is a part of the Multicore Association (www.multicore-association.com), a cross industry, vendor-neutral body defining standards to help with the multicore transition.  I am co-chairing the working group with David Stewart, CEO of CriticalBlue.

Our goals are pretty simple.  I’ve been involved with the embedded market segments’ transition to multicore processors for the past 5 years and see a real need for basic agreement and education on terms and best practices.  So that’s really it.  We’re not inventing something grand like a new language or API.  We are agreeing upon and documenting best practices aimed at taking legacy code in C/C++ and making the code run in parallel.

On June 5 in Austin, the working group had its first meeting.  We asked each member company to detail what they would consider their top fives issues when it comes to taking advantage of multicore.  The next step is to categorize and create an ‘outline’ that could possibly serve as the outline for the end document.  It will certainly be more work than simply outline and write and we’ll certainly learn and adjust as we go, but I was encouraged by the initial meeting.  11 companies provided input during this discussion. 

I’ll write more as the group and its work takes shape.

On a personal note, the 3 weeks of straight travel are over.  Nothing on the boards until August except a July trip to Vegas for NBA summer league. 

One part of my talk that I find particularly compelling is research Intel is doing in heterogeneous multi-core programming using extensions to OpenMP, one of my favorite APIs for parallel programming.  The power of OpenMP is ease of use.  If you’ve never seen OpenMP… it is possible to transform a serial program into a parallel program with one OpenMP statement, or pragma.

The particular extension, called EXOCHI (pronounced X-O-Cha), extends OpenMP by adding clauses to support spawning threads (called shreds) on processors with different instruction set architectures.  In effect, it is possible to have one piece of code that contains instructions for different types of processors.  It is certainly possible to program for these coprocessors today with one code base through the use of libraries (Direct X is an example of such a library), however these approaches abstract away the low level hardware which is what some developers would like to access.  In addition, EXOCHI enables virtual shared memory through hardware support which grants the nice properties of shared memory while limiting the performance penalties.  Very powerful.

In two weeks, I’ll be participating on a panel at Design Automation Conference which will seek answers on why tools to aid with heterogeneous multi-core and multi-processor SOCs have not really caught on.  My suspicion is a tool like EXOCHI may be just what is needed to lower the barrier for heterogeneous multi-core software development.

One more rehearsal of my talk before I go onstage, give the presentation, and then hopefully talk my colleagues into Kobe beef.

If you need a reference on EXOCHI, the paper can be found at,

http://portal.acm.org/citation.cfm?id=1250734.1250753

Max

Sometimes you can fall for a trap when you work on the same project with the same people for years on end.  You start assuming that the thoughts and state of mind shared by the folks you iteract with completely represents the state of mind of the general engineering community.   I may have recently fallen into this trap with regard to the adoption and leveraging of multicore processors in the embedded community.

Last month at Multicore Expo, I heard a speaker comment on the need to make code “Multicore ready”.  My initial thoughts in reaction were “What do you mean Multicore ready?  I’ve been pitching software techniques for Multicore for over 3 years now.  Everyone should be moving already.”

I could sense many attendees responded positively to the speaker’s comment.  This led me to wonder if I’d fallen into the trap of having a perspective limited by the engineers I have the most contact with (other engineers at Intel) and the work I’ve been doing.

So my question is where are folks at with leveraging multicore processors in their embedded design?  Are we still predominately in a state of wondering what to do with multicore processors and how to make code ‘Multicore ready’?  Or are we well past that point and into planning our next design to take further advantage of multicore processors?  

I’m basically asking - what help do customers need?