The Power Architecture™ specification is something of a standard already. After all, you can run PowerPC® code on Motorola® and IBM® chips, and the instruction set has always been governed by the Power Architecture "Books" (see Resources). However, there is more to an architecture than its instruction set, and many fields related to Power Architecture development haven't received as much public scrutiny or standardization.
IBM and other leaders from the electronics industry are launching a new organization, called Power.org, which will serve to greatly increase support for developers working with Power Architecture technologies. The creation and promotion of standards is a key element in making this happen. So, this month, instead of looking at a single standard, we'll look at the kinds of planning that go into building a standards organization, and what the implications of this particular standards organization might be.
Note that Power.org isn't just a standards organization. This column space, though, is devoted to standards work, so it will focus on that aspect. For more on Power.org, see also the companion piece to this article, About: Power.org.
Thanks must be extended to Bill Dykas and Mark Ireland, of IBM, who gave the interviews used as a primary source for this column.
The history of Power Architecture technology shows an early interest in cooperation and comparative openness. Formed in the late 1980s, the Apple, IBM, and Motorola (AIM) partnership set the stage by establishing the idea that vendors could cooperate on large projects, giving up some of their control in exchange for a broader and more capable product base. The conflict between AMD™'s 64-bit architecture, and Intel™'s 64-bit architecture shows how important it can be to get the right people involved; the fragmentation of the x86 64-bit market highlights the importance of cooperation in maintaining a microprocessor architecture.
IBM and several other companies (see Resources for a link to the full announcement) are coming together to form an organization to expand the collaboration model pioneered by AIM, and to prevent similar fragmentation of the architecture. So far so good: the 64-bit PowerPC implementations are of course compatible, thanks to the Power Architecture "Books," which thoughtfully discussed the 64-bit architecture even before anyone needed to build one (64-bit is not an "extension" to the architecture -- it is the architecture.)
On the other hand, there is a clear potential risk down the road that other vendors or developers could start diverging from the central architecture in ways that hurt the overall market. More generally, there has been some tumult in architecture licensing in the marketplace of late. With Power.org, IBM looks to be betting that a more open philosophy will both mitigate potential risks and move the architecture forward.
The scope of standards organizations can be a little hard to predict: I don't think the people who started IEEE in 1963 anticipated the need for floating point math standards (IEEE 754), let alone operating systems (IEEE 1003). In the case of Power.org, the overall scope is fairly well-defined, and narrower than, say, the mandate of an ANSI or an IEEE.
On the other hand, that mandate could be pretty broad. It's not just the architecture itself, but just about anything related to it (again, see also the companion piece to this article, especially to see how the mandate of Power.org extends even beyond standardization).
But even the standardization part of Power.org has a broader scope than a single standard or specification. Should some future generation of Power Architecture chips use a standardized pinout so they can get economies of scale on chip sockets? Should the developers of single-board computers (SBCs) based on PowerPC standardize the address layout they'll use for access to hardware registers or the system's boot ROMs?
The goal, here, is to develop an organization to support and host any and all standards efforts relevant to the growth and development of the Power Architecture market. In particular, the idea is that if everyone plays well with others, the whole Power Architecture market will grow larger, benefiting everyone. If PowerPC chip developers are cooperating and sharing resources, they will produce better chips and better designs, and do so more cheaply.
Any standards organization needs members. In general, these are often anything from independent experts to large corporations. In the Power.org standards organization, membership levels are still being defined. At this phase in its history, they include Participant, Founder, and Sponsor levels (see the developerWorks article, About: Power.org). The issue of dues also will be refined and tweaked over time; currently they range from about US$25,000-US$100,000 annually. This is a bit steep for end-users -- but quite affordable for vendors. It is also a practical way to try to keep membership focused towards people who have a real economic interest in the platform.
Membership in individual committees or subcommittees might be different from membership in the organization as a whole. For instance, while membership in ISO requires you to be in possession of an actual country, participation on a specific technical committee might be quite a bit more attainable. Many people attend the joint ISO/ANSI® C committee meetings based on US$800/year of dues (regular attendance at meetings is also required).
There is a strong interest in broader involvement from more companies. A lot of people, when they hear the term "Power Architecture," think only of PowerPC processors; and for many, these are very strongly associated with the AIM alliance. The truth is that many other companies are involved in the Power Architecture ecosystem to varying degrees, and the announcement of Power.org is one way of formalizing that -- and also of getting those other companies to know one another, and creating a framework for collaboration and communication. It's a community for companies that might want to get involved in building systems, or even chips, using Power Architecture technology -- a place where compiler vendors can talk to embedded developers, and so on.
Standardization is hard work, and specialized work at that. One of the things that can make or break a standard is access to expertise in running standards. A good standards organization can help provide this expertise, organizing committees, helping the members arrange meetings, and providing the infrastructure needed. IBM's involvement with technical standards probably indicates that, in its role as a standards body, Power.org will be experienced and effective.
The exact set of technical committees hasn't yet been nailed down. Part of this is the realization that there could be a need for committees to look into things that no one has thought of yet. The basic plan is for a general technical committee that would form subcommittees to look into specific things. The exact structure will probably evolve some over time, but the basic idea is probably reasonable. I have not previously seen such a broad mandate for a committee, and it will be interesting to see how this compares with the "multiple committees" model that other standards organizations have.
Only a few things will stay under IBM's control. Specifically, IBM will continue to own the instruction set architecture -- taking guidance from a special Advisory Council made up of Power.org members -- to ensure stability of the core and the instruction set for everyone. Outside of the instruction set, Power.org will have free reign.
On the other hand, a committee might, for instance, look into questions related to the needs of developers who want a low-power (no pun intended!) Power Architecture chip. Or, for instance, there might be a committee for PowerPC compiler developers to work on standardizing things like the syntax for vector instructions.
Alignment and liaison work
One of the functions of a standards body is to arrange communications between different groups. Most of the time, liaison work involves different technical standards. For instance, the C standard tries to avoid conflicts with the C++ and POSIX standards.
In the case of Power.org, an additional avenue of alignment work becomes possible: alignment with marketers. Now I know what you're thinking. Some marketing departments in the world of tech have very bad reputations (see Resources). And nobody would want a technical standard constrained by the beliefs and goals of entirely non-technical marketers. On the other hand, keep in mind that the converse is also possible: this alignment work could stop people from making promises they can't keep. And think of what a wonderful outcome that could be! If it works, it might even send a message to other large vendors whose marketing and engineering efforts have gotten out of sync.
That isn't to say that supposedly technical meetings will be swamped with marketers asking for fire which can be inserted nasally (see Resources for a link of you are not familiar with that reference). Rather, it means that if the marketing folks want to be sure they're not selling something they can't deliver, they have a good channel to talk to the right people.
Intellectual property rights
When a standard is controlled by a body such as ANSI or ISO, generally the standards body asserts some ownership over the resulting materials, which are sold to help fund the standards body. There has been a lot of talk as of late about the importance of considering intellectual property rights in standardization. What happens if, after everyone's committed to a new standard, someone reveals a patent, and demands licensing fees from anyone trying to comply with that standard?
Power.org is taking this question into account, in advance, which is a very sensible thing to do. Bill Dykas, manager of Power Ecosystem Development at IBM explains (see the companion piece for more from Bill):
... part of the prerequisite for joining that sort of technical subcommittee is that subcommittees will be formed either on a royalty-free basis or on a RAND basis, a RAND meaning reasonable and nondiscriminatory terms ...
In short, if you want to be involved with a standardization subcommittee, everyone has to agree up front on what the terms will be of any IP used in the standard, and if you don't want to agree to that, you can't push for the use of your patented technology.
This policy is an attempt to preserve some rights for people, while serving the interests of the organization as a whole. The technology industry has seen specs and standards become commercially unusable due to patent issues in the past; this is a good start at preventing that kind of problem up front, and it illustrates the kind of refereeing role that Power.org can play for its members.
One weakness in the IP strategy is that this doesn't cover the case where the patent is held by a third party. But then, it's hard to see how the standards organization could do anything about the possibility that someone, somewhere, already has a patent on something that a committee is about to invent independently. What they can do is require people to play fair if they want to be involved with standardization, and right now, it looks like they plan to do just that. Yet another view of the matter is that, when faced with a patent dispute, having a company like IBM on your side can come in quite handy.
Finally, an organization like this can provide a jumping-off point for collaborative work. Members can streamline negotiations, possibly forming a working group rather than trying to hash out every detail of an IP agreement from scratch. A lot of the overhead of collaborative efforts comes down to negotiating IP rights; simplifying those negotiations makes everybody happy and more productive.
The real key, I think, will be the question of what committees or subcommittees get formed, and how their work is received.
I'm hoping to see a lot of interest in developing a variety of standards. Unfortunately, standardization isn't a lightning-fast field, so it may take a while to find out how the first few come out. The danger of forming a new organization is that it's hard for people to be sure how much they're willing to commit to it until they've seen how well it works.
In this case, there's no track record yet for Power.org; we don't know how they'll work out. What we do know is that there is a history of comparative openness to Power Architecture technology, and this looks like it has the potential to open it up even more. It is certainly too great an investment on the part of IBM and the other founders to be put down to a public relations stunt, and so I think it will be taken seriously -- I hope also by other chip vendors out there.
The good news is, IBM and the other founders are demonstrating a real commitment to making this standards organization work. If they pull it off, there will be a lot of new standards work in this area in years to come, and that's probably good for everybody.
- Visit Power.org and see the site that all the excitement is about! See also the press release for this announcement.
- The companion piece to this interview, a About: Power.org An interview with Billy Dykas and Mark Ireland provides more information on Power.org's proposed mandate, both in the standards arena, and outside of it.
- Power.org is in many ways a continuation of Power Everywhere initiative announced in March. See also press coverage of that announcement: IBM's Power Play (Electronics Weekly, 2004) and IBM opens up its Power line (ZDNet, 2004).
- IBM is a founding member of several open consortia including (but in no way limited to) the Eclipse Consortium as well as Open Source Development Labs (OSDL) -- so they have had a lot of practice lately with starting committees and initiatives from scratch.
- Have experience you'd be willing to share with Power Architecture zone readers? Article submissions on all aspects of Power Architecture technology from authors inside and outside IBM are welcomed. Check out the Power Architecture author FAQ to learn more.
- Have a question or comment on this story, or on Power Architecture technology in general? Post it in the Power Architecture technical forum or send in a letter to the editors.
- Get a subscription to the Power Architecture Community Newsletter when you Join the Power Architecture community.
- All things Power are chronicled in the developerWorks Power Architecture editors' blog, which is just one of many developerWorks blogs.
- Find more articles and resources on Power Architecture technology and all things related in the developerWorks Power Architecture technology content area.
- Download a IBM PowerPC 405 Evaluation Kit to demo a SoC in a simulated environment, or just to explore the fully licensed version of Power Architecture technology. This and other fine Power Architecture-related downloads are listed in the developerWorks Power Architecture technology content area's downloads section.
Dig deeper into developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.