|
|
|
|
||||||
| September 2002 | Vol. 3 Issue 8 | |||||||
|
|
Inside This Issue
|
|||||||
|
****** NEW! ****** |
JTAG Debugging for SCORETM PowerPC By Karl Rehmer JTAG (Joint Test Action Group pronounced "jay-tag") is an IEEE specification (IEEE 1149.1). It was originally implemented to allow testing of all the pin connections of a chip and its interconnections to other chips on the circuit board. It is a serial protocol and chips on the board may be daisy-chained together. The chain may be very long. There is no specification stating any inclusion of resources for software debug nor is there a prohibition. JTAG debugging provides the advantage of having the debugger communicate directly with the target hardware, avoiding the use of a debug monitor on the target. Because of this, the environment in which your program runs when it is debugged using JTAG debugging is closer to the actual environment in which it will run in production. There is no debug monitor that is in actual control of the target board. DDC-I's SCORE multi-language debugger for the PowerPC provides support for JTAG debugging, communicating with devices provided by Macraigor Systems. The supported devices for the NT hosted debugger are Wiggler, Raven, and mpDemon. For the Solaris hosted debugger, the mpDemon is supported. The Macraigor web site (www.macraigor.com) has a link to an interesting article "The Zen of BDM" written by Criag A. Haller of Macraigor Systems. This article describes the historical approach to debugging and how the advantages of BDM (background debug mode) debugging overcome some of the limitations of the traditional methods. JTAG debugging is a kind of background debug mode debugging. This article even provides some helpful information for those designing their own custom boards with a JTAG interface. In order to use the JTAG debugging capabilities of the SCORE multi-language debugger, the JTAG device should first be connected to the target as described by the Macraigor documentation. Four command line options have been added to the SCORE multi-language debugger to support JTAG debugging. In addition, the meaning of several other options have been extended. These are described below. The added command line options are:
The expanded command line options are:
The supported PPC board kinds and their equivalent numeric codes are given below:
A -board_kind Excimer is equivalent to -board_kind PPC603RR (numeric code 7). For a Sandpoint board with Altimus PPMC750, the correct numeric code for the -board_kind is 82 (-board_kind 82 or -board_kind PPC7xx_Rev2 or -board_kind Altimus750). For a Sandpoint board with Altimus PPMC755, the correct numeric code for the -board_kind is 83 ( -board_kind 83 or -board_kind PPC7xx_Rev3 or -board_kind Altimus 755). The case used to specify the board_kind or the device is not important. Thus on NT, to invoke the debugger to JTAG debug to an Excimer board using a Macraigor Raven connected to LPT1 with the debugger handling target input and output over com1, you would issue the command
On Solaris, to JTAG debug to a Sandpoint with Altimus PPMC750 with target input and output NOT handled by the debugger, an invocation line would be like
To have the debugger also manage I/O, add the appropriate -target line option. Within the SCORE Graphical User Interface, the Project | Tool Options tabs for "Run" and "Debug" allow setting of all of communication parameters for JTAG debugging except the -lpt option. If you are doing JTAG debugging using a parallel port other than LPT1, specify this using the "additional options".
For Solaris hosts, the only supported JTAG device is the mpDemon which has an ethernet connection to the host. From the GUI, the device Ethernet is correct for connection via the mpDemon. The same options are added for SCORE PowerPC loader (load_ppc603e), where -jtag should be used (not -firmware or -omi). The communications options described above also apply to the loader. In the GUI, the options for loading are added on the "run" tab of the Tool Options.
On the Front Lines
Introducing David Colyn, DDC-I, Inc. Western Regional Sales Representative. Entering his 4th year at DDC-I, David’s responsibilities include sales related activities for Western U.S and Canada. In his role as Sales Rep, David is authorized to represent DDC-I for existing customer relationships as well as new sales in his territory. David holds a BS in Business Management from the University of Phoenix. An avid golfer, David was a Head Golf Professional for American Golf Corporation (the world's largest golf management company) from 1991 - 1999. During his tenure, he obtained extensive management and sales experience. David lives in Peoria, Arizona with his wife Rebecca, son Johnathan and new baby girl Abby. He enjoys spending time with his family and playing golf any chance he gets! For more information on Front Liners and DDC-I's organizational structure click here.
3rd Party Update
Macraigor Systems is a leading supplier of BDM / JTAG (Background Debug Mode / Joint Test Action Group) connection solutions for on-chip debugging of 32 and 64-bit embedded microprocessors. Macraigor Systems’ solutions are designed for price-sensitive customers. These solutions include a suite of software tools which supports Windows 9x, NT, ME, XP, Linux and Solaris host systems. Macraigor Systems supports all major embedded microprocessor architectures, including AMD, ARM, ColdFire, CPU32 Series, PowerPC, MIPS, and the XScale™ microarchitecture.
Tech Talk: Improved Interface
Between SCORE GUI By Lisa Jett With Release 2.3 of SCORE, a new and improved interface has been implemented between the SCORE GUI and the SCORECast (module testing) tools. When the AdaCast or CCast tools are invoked, SCORE automatically generates a configuration file that the SCORECast tools read during startup that contain the definition of environment variables key for the compile, link, debug, and load steps used by the SCORECast tools to test a particular module. Now users define communication and build options all within the SCORE Tool Options dialog and that information gets automatically communicated to the SCORECast tools, eliminating the need for specification of the options again in the SCORECast tools. AdaCast Configuration file TARGET_VARIANT:
PPC_SCORE_BARE (For Native this is set to "HOST"). CCast Configuration file TARGET_VARIANT:
PPC_SCORE_BARE (For Native this is set to "HOST"). SCORE also generates the run_prog.bat and debug_prog.bat files to contain the proper load and debug options from the Tool Options | Run | Communications and Tool Options | Debug | Communications pages in the Tool Options dialog. In this way, all the various communication methods can be easily utilized by the SCORECast tools. These files are stored in the $PROJECT\$USER\$TARGET directory and executed by the AdaCast or CCast tools when running or debugging the test application.
Chaordic Organizations By Linda Rising "Geesh, Linda, not another buzzword! We’re drowning in them already. We know you love to read about all the latest and greatest, but come on! What the heck is this chaordic stuff?" Sorry, guys, I’ve been thinking about this for some time and I’ve decided to share what little insight I have because I think this is an important topic. I say, "share what little insight" because I’ve been looking for answers, for a nice set of rules or guidelines and I’ve finally realized that there aren’t any. So, I might as well go ahead and maybe we can work this out together. Here’s the problem. All those nice agile methods are really taking the software development world by storm. I wrote earlier about the different agile approaches and how small teams are successfully battling the development chaos we face today. The question in the back of my mind was: I can see how agile approaches work for small teams. It’s a no-brainer. But what about unavoidably large projects? What about the Boeing 777? What about some of the large military projects I’ve seen? There is no way those could have been done with a team of less than ten—even a team of incredibly great people. Is the answer a collection of small teams? For Scrum users, would you have a Scrum of Scrums? Is there a limit to the number of teams you would have on a really big project—like the "no more than 10" limit on team size? What lessons can we apply from studying the agile approaches? But, sorry, I couldn’t make it work. I kept coming back to a hierarchical, structured, top-down approach and somehow, deep down, I knew that wasn’t right. Then I started reading about complexity theory, the edge of chaos, and then, chaordic organizations. I think this is it—I just don’t know what it is! This article is just to share information. I’ve tried to include references that you can find on the web, so if you want to know more you have a good place to start. This is not the answer for all your problems. I don’t know any software projects that are run this way. My examples are all from other domains—but when I read these other accounts, I believe I can see how they could apply to software. Let me know what you think. The structure of the organizational world in which we develop software is pretty old. In fact, the organizational structure of everything—church, university, corporation, nation-state—has been pretty much the same for more than three hundred years. This exists in a time of rapid change. The Web has made more information available than we can handle and it is available instantaneously. As futurist, James Burke, pointed out, it took centuries for the knowledge of the smelting of ore to cross a single continent and bring about the Iron Age. When man stepped onto the moon, it was known and seen in every corner of the world 1.4 seconds later. It seems we’re ready for something a little more flexible! All our institutions concentrate decision-making in the hands of relatively few people. The explosion of information chokes these decision-making systems, making them slow to respond and certainly not agile. [Hock98] The world-shaking (in the 17th century, at least!) ideas of Newton and Descartes led to a machine metaphor that is still heavily used today. We see the entire universe and everything in it as a giant mechanism where each and every component acts on the other components in a precise way with clearly understood cause and effect. We don’t realize how powerful this metaphor is and how it affects our thinking about people, who, we know are not components and do not behave in a mechanistic fashion. Our organizations are built to treat the people who work in them as cogs in a machine. We hire, reward, and fire them in the same way we have been for hundreds of years—even though the world has changed—drastically. [Hock98] Moving away from a hierarchy means more control is given to the teams and to the individuals on the teams. This is more complicated than simply saying, "OK, you guys are in charge. Go for it!" The answer seems to come from some high-powered folks in the research community who are looking at complexity theory. The basic idea is that organizations should be like biological organisms. The researchers say, "This is not a metaphor. Organizations really are alive." Let’s try to understand this model to take advantage of the best way to harness the power in this living organism. [Senge+99] Managers unconsciously follow the second law of thermodynamics, the belief that everything in the universe tends toward disorder, unless it is managed. Modern managers might be better off dropping the title of manager, following the dynamics of complexity, and discovering that natural systems tend to move toward and find their most vital form at the boundary between chaos and order. One step too much to one side or another, and like most companies in a fast-developing market, they will not survive their particular generation. Evidence from the science of complexity says that given certain clear parameters, communities or teams will become self-organizing. [Whyte94] "Hmmm…complexity science. OK, now you’ve lost me. I need something to hang on to, Linda. How about some real-life stories?" OK, you’re right, this complexity and chaos stuff can get out of hand in a hurry! I’ll tell you the Visa story, not only because it’s compelling, but it’s also what got me started down this road. It’s about a guy named Dee Hock. I’ve never met him but I’ve heard he’s a dynamic speaker but that’s not why people want to hear what he has to say. They listen because he has a success story to share—a powerful success story. Over 25 years ago, he had a chance to put ideas about restructuring organizations, moving beyond hierarchy and command-and-control to an organization that followed biological principles. He named this structure, "chaordic." [Waldrop96] After searching in vain for a more suitable word, it seemed simpler to construct one. Since such systems, perhaps even life itself, are believed to arise and thrive on the edge of chaos with just enough order to give them pattern, he borrowed the first syllable of each, combined them and produced—chaord (cha from "chaos" + ord from "order"). [Hock00] The business that Dee Hock inspired has prospered. Since 1970 it has grown by something like 10,000%. It continues to expand at roughly 20% per year. It now operates in some 200 countries worldwide and serves roughly half-a-billion clients. And this year (1996), its annual sales volume is expected to pass $1 trillion. [Waldrop96] Visa was created as a non-stock, for-profit membership corporation with ownership as nontransferable rights of participation. The organization is highly decentralized and highly collaborative. Authority, initiative, decision-making, wealth—everything possible is pushed out to the periphery of the organization, to the members. This resulted from the need to reconcile a fundamental tension. On the one hand, the member financial institutions are fierce competitors: they—not Visa—issue credit cards, which means they are constantly going after each other's customers. Members must also cooperate with each other. Participating merchants must be able to take any Visa card issued by any bank, anywhere. Banks follow standards on issues such as card layout. They participate in a common clearinghouse operation that reconciles all accounts and makes sure merchants get paid for each purchase, the transactions are cleared between banks, and customers get billed. This blend of cooperation and competition allows the system to expand worldwide in the face of different currencies, languages, legal codes, customs, cultures, and political philosophies. No one way of doing business, dictated from headquarters, could possibly have worked. The organization had to be based on biological concepts to evolve, to invent, and to organize itself. [Waldrop96] "Nice story, Linda. But Visa is a banking study and maybe one of a kind! Got anything else in the treasure chest?" Sure! Lots more. But realize that the Visa story is more powerful than you might imagine. Our first response to almost any case study or pilot project is to say, "BUT!" It’s human nature. We hang on to what we know. It’s actually, the sane thing to do. Otherwise, we’d be blown around by every new idea that comes along. I respect your skepticism! Here are some more stories. But remember, my goal is not to convince. My goal is to learn together. I’m looking for answers, not presenting the final solution to all our problems. The following story is especially interesting to me as an amateur musician. I see a lot of similarities between software developers and orchestral musicians. See what similarities and differences you can find! Orpheus Chamber Orchestra is an orchestra with a difference: it has no conductor. The group was founded in 1972 by cellist Julian Fifer and a small group of musicians to bring democracy, personal involvement, and mutual respect into an orchestral setting. Orpheus, considered to be one of the world's great orchestras, comprises 27 permanent members—employees who cannot be fired—and a number of substitute players who fill in where necessary, a board of trustees, and administrative management. In most orchestras, the conductor not only decides what music will be played but how it will be played, with little room for opinions or suggestions from the musicians. Musicians follow the conductor’s direction. Anything less invites humiliation before one's colleagues and may be grounds for immediate dismissal. As a result, orchestral musicians are notoriously unhappy employees. When a Harvard Business School professor studied job attitudes, orchestral musicians ranked below prison guards in job satisfaction. [Seifter01] Orpheus applies collaborative leadership—any member can lead a rehearsal and performance as concertmaster, or lead one of the orchestra's formal or informal teams. This system is extremely flexible—musicians freely move in and out of positions of leadership—and it can quickly adapt to changing conditions in the marketplace or within the group itself. The free flow of leadership positions within the group encourages all the members to give their best. Cellist Eric Bartlett says, "When there's an important concert, everybody feels it, and everybody does their absolute best work, giving it their utmost concentration, playing off of each other, and making sparks fly. In a conducted orchestra, you have a more passive role. You have to play extremely well, but you're not playing off your colleagues—you're playing off the person with the baton. People in regular orchestras are not emotionally involved in the same way." [Seifter01] Members of Orpheus are energized and responsive to the needs of the organization and to the desires of its leaders. Turnover is extremely low and employee loyalty is extremely high. The result is a better product, increased customer satisfaction, and a healthier bottom line. According to double-bass player Don Palma, a founding member, "I took a year off from Orpheus and went to the Los Angeles Philharmonic. I hated it. I didn't like being told what to do, being treated like I wasn't really worth anything other than to just sit there and be a good soldier. I felt powerless to affect things, particularly when they were not going well. I felt frustrated, and there was nothing I could do to make things better. Orpheus keeps me involved. I participate in the direction the music is going to take." [Seifter01] How about that story? Inspiring? Next time you hear an orchestra, I’ll bet you’ll think about the experience in a new light. OK, one more and this one is impressive because it’s the military! Who would have thought that they would be a prime example of an agile organization! In the late 1980s, the U.S. Army’s senior leaders studied complexity theory and began to apply them as an alternative to their command-and-control paradigm. According to General Gordon R. Sullivan, retired Chief of Staff of the Army, "The paradox of war in the Information Age is one of managing massive amounts of information and resisting the temptation to over-control it. The competitive advantage is nullified when you try to run decisions up and down the chain of command. All platoons and tank crews have real-time information on what is going on around them, the location of the enemy, and the nature and targeting of the enemy’s weapons system. Once the commander’s intent is understood, decisions must be devolved to the lowest possible level to allow these frontline soldiers to exploit the opportunities that develop." [Pascale+00] The Army has improved the quality of the recruits and their training and the electronic communications among the members of a fighting unit. Typically, military services languish during peacetime and then misapply the most recent war’s doctrine to the challenges of the next. Since the Vietnam War, the Army has made technological obsolescence "the enemy." The introduction of distributed information allows the foot soldier or tank commander in the field to know roughly as much about what’s going on as the generals in the command center. This doesn’t mean that tank crews fly helicopters or that soldiers spontaneously decide to support Kurdish rebels. The Army uses a Commander’s Intent, which defines the scope of an engagement. This concept traces its origins to General Patton who said, "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." Combat units are encouraged to improvise and initiate within the structure of the Commander’s Intent. When that intent is clearly communicated, fighting units can exploit opportunities or regroup when things don’t go as planned. [Pascale+00] For those who love stories, I’m going to give you a URL for another great one—how GE builds jet engines. Enjoy! http://www.fastcompany.com/online/28/ge.html Let’s summarize some lessons learned from the stories. Although creating a chaordic organization does not mean following a set of guidelines or procedures. These seem to be characteristic of the projects I’ve studied. Distribute power and functionality to the lowest
level possible. Instead of a chain of command, create a framework
for dialogue, deliberation, and coordination among equals. Take a minimalist approach to rules. I think the story telling has gone on long enough. Thank you for your patience. There’s a lot more to be said about complexity theory and how its tenets can be applied in organizations. If you’d like to read "all about it," and see a follow-on for this article, send me an e-mail: risingl@acm.org. I’d also like to hear your ideas about applying complexity theory to organizations. I’m sure your insights can help me understand some of this better. References [Hock98] Hock, D., 1998 ODN Annual Conference Keynote: An Epidemic of Institutional Failure, "Organizational Development and the new Millennium" Organization Development Network Annual Conference, New Orleans, Louisiana, November 16, 1998. http://www.odnetwork.org/odn98/followup/deehock.html [Hock00] Hock, D., "The Art of Chaordic Leadership," Leader to Leader, Winter 2000. http://www.pfdf.org/leaderbooks/l2l/winter2000/hock.html [Norman99] Norman, D.A., The Invisible Computer, The MIT Press, 1999. [Pascale+00] Pascale, R. T. Pascale, M. Millemann, and L. Gioja, Surfing the Edge of Chaos, Crown Business, 2000. [Seifter01] Seifter, H., "The Conductor-less Orchestra," Leader to Leader, Summer 2001. http://www.pfdf.org/leaderbooks/l2l/summer2001/seifter.html [Senge+99] Senge, P., A. Kleiner, C. Roberts, R. Ross, G. Roth, B. Smith, The Dance of Change: The Challenges to Sustaining Momentum in Learning Organizations, Doubleday, 1999. [Waldrop96] Waldrop, M.M., "The
Trillion-Dollar Vision of Dee Hock," Fast Company,
November 1996, 76-86. [Whyte94] Whyte, D., The Heart Aroused: Poetry and the Preservation of the Soul in Corporate America, Currency Doubleday, 1994. About the Author Linda Rising has a Ph.D. from Arizona State University in the area of object-based design metrics. Her background includes university teaching as well as work in industry in telecommunications, avionics, and strategic weapons systems. She is the author of numerous articles and has published three books: Design Patterns in Communications, The Pattern Almanac 2000, and A Patterns Handbook. She is currently writing a book with Mary Lynn Manns: Introducing Patterns (or any Innovation) into Organizations, to appear in Fall 2002. |
Introduction to Ada95: --------------- FAA DO-178B Basic Seminar FAA DO-178B Applied Seminar --------------- Seating is Limited!
|
||||||
DDC-I Online News is published by DDC-I, 400 N.
5th Street, Phoenix, AZ 85004. Editor Jennifer Sanchez.
Comments and submission of articles are welcome and should be sent to the
editor at the address above or via email at editor@ddci.com.