I'll start this note with something about 4Links, describe some of the books and articles I've read this year, and from them brashly draw analogies between everything. Of course these ‘laws’ apply to links. Barry Cook, with whom I've been working for a few years now, has shown how they even apply to computers!
4Links has become global this year. We previously had customers in several countries of Europe, and one in Japan. In 1999 we have added more of Europe, also the USA and India, and indirectly a customer in China. I'd like to thank all these customers, not only for their orders, but also for their patience, because they have all had to wait longer than I'd like for me to respond.
The mix between boards, IP and consultancy has been remarkably even, and each has grown this year. The C111 chips are so inexpensive that it would need large quantities to match the revenue on the other areas. We are now selling the SpaceWire-PCI board, developed under contract from Dundee University, themselves under contract from ESA. We now also have the C113 FPGA design, which integrates three links and improves on all previous 1355-DS devices for initialization and hot-plug.
The mix between industries has been mostly at the extremes of the Space industry at one end and consumer electronics at the other end. This year we have added the computer industry and more and more companies in industrial controls are discussing how to get involved. As well as customer work in consumer e lectronics, 4Links is providing a small seed funding for a PhD student researching home networks at Keele University. The Space industry is particularly keen, and is producing a SpaceWire standard both to overcome a few inconsistencies in the original IEEE 1355 standard and to incorporate some special features for Space.
We're not quite at the stage of links in everything, or even links everywhere. But the diversity in both geographical and application spread is encouraging.
Diversity brings me to one of the books I’ve read during the year, "Guns Germs and Steel" by Jared Diamond, subtitled "A short history of everybody for the last 13,000 years". Europe, where the guns germs and steel came from, is not populated by a people inherently better than those who did not invent such things. But Europe and the Near East did have a very diverse range of flora and fauna, they had a temperate climate, and they had a wide east-west spread that encouraged communication. He shows how these natural advantages inevitably resulted in faster progress in civilisations than was possible on continents less blessed.
Tim Berners-Lee’s "Weaving the Web" has many themes. Perhaps the strongest coming across to me was his vision, which even in his own first implementation went way beyond what we now use as products. Diversity is another theme, in the range of incompatible computer and network systems that he overcame, and even more in the range of applications to which the web has been used. He talks about the absolute need to have no centralised control, and later on he talks about delay and connectivity in networks. Most incredible is that it is only ten years since the first world-wide-web program, and I suppose that is really what is meant by "Internet Time".
I have not managed to develop things in Internet Time this year. I was fortunate to have more work than ever before, but it was too much, I was overloaded, and my response time stretched to infinity. You know that I ought to know better. Most of you will have come across the analogy between links and modern manufacturing – both ensure spare capacity, both use small packets, both are completely distributed with no central monolithic control, both use local consumer-driven flow-control, ... .
The analogy was forcefully brought home by a short column in Electronic Design magazine by Don Reinertsen, co-author of "Developing Products in Half the Time", which I read several years ago, and "Managing the Design Factory" which I've not yet read. His column simply commented that queuing theory says that the more the load the slower the response, and that this applies to design just as much as to traffic on the roads or to access of a shared bus such as PCI or 1394 or to cars on the assembly line.
A few days after reading Reinertsen's column, I came across "Embracing Change with Extreme Programming" by Kent Beck in IEEE Computer (Oct. '99). Beck takes the idea of iterative design to its limit by starting with something that works, however little it does, and then adding the next small feature that the customer most wants. So here we have the tiny packets, the minimal latency, and the customer-driven flow control of links and the modern factory.
I shared this article with Barry Cook, of Keele University, who has been an immense help to me for the last four years. His immediate response was that he is an "Extreme Programmer". He then went on to discuss his vision of how computers should be built. Guess what, his vision does not have a CPU because any central control must be eliminated. In place of the CPU, his vision is that programs compile direct to hardware, and the only sequence involved where one piece of compiled hardware has to wait for another.
It sounds far fetched, but what is a program doing? In hardware terms a program is a state machine that responds to inputs and produces outputs. What would you think of a hardware engineer who collected all the state of all the state machines together in main memory and accessed them through a narrow bottleneck? But that is exactly what a von Neumann computer is, that we've been building for the last fifty years.
To put the vision into effect, Barry Cook has written an Occam compiler – not a conventional compiler to a machine instruction set, although he did get a student to compile to the Java Virtual Machine. Barry's compiler really does go straight to hardware, to the EDIF that is output by all the VHDL synthesizers and used by place and route tools for FPGAs. So far there are two designs that have used it. One is a processor for the old Occam Portakit, done by Roger Peel at Surrey, the other a routing switch that Barry has done himself. Roger Peel says that when the Xilinx engineers were shown his processor, compiled from a high level language and without any VHDL optimization, their jaws dropped when they heard it ran at 50MHz. High level languages are ‘known’ to run dreadfully slowly on hardware, and 50MHz was way too fast.
But shouldn't we expect this performance? Occam uses lots of little processes, without any centralised control. Each of the little processes talk to a few neighbours across Occam channels, with consumer-controlled flow. These are exactly the characteristics that make modern factories efficient, that lead to products and programs developed in half the time.
Barry Cook is not alone in thinking along these lines. He pointed me to Electronic Times, 6 December, p18, about an MPEG decoder that decodes and displays up to eight streams at the same time. Quintessential Architectures (QuArc) who designed the chip may never have heard of Occam, but they have "Atoms" and "Molecules" – small processes and collections of them – that communicate by unidirectional data signals and a request/ready handshake – that are exactly Occam channels.
Nor are computers and MPEG decoders and links and production lines and product development and software engineering the only areas where these ideas apply; why not to companies and governments and universities? They all need to be efficient and effective, and if spare capacity and low latency and small packets and local customer-controlled flow apply to such a diverse range, why not to everything? And if so, the Occam channel – whether described as such, or as an empty tray with a kanban card returning for more components, or as a request/ready handshake, or as an IEEE 1355 link – seems to be close to universal.
It certainly applies to 4Links, and I need to wake up to it this year. Two major jobs have now been invoiced, which should make a little more time. We are looking at larger premises, and I'll take a risk on a continuing increase in revenues by employing a design engineer so we have some spare capacity. I've signed a non-exclusive collaboration agreement with Satellite Services in the Netherlands, and expect do more collaboration. We already have some excellent subcontractors, and will subcontract more. We'll use Barry Cook's Occam to hardware compiler to increase productivity. Even if the job we take on is large, we will split it into small packets and deliver them at frequent intervals. If the work starts to slip, we will negotiate to deliver only what is most important to the customer. And it looks as if we need to increase consultancy fees both to cover some of the spare capacity and in line with supply and demand.
I owe a huge debt of thanks to Barry Cook, not only for his vision, but for the C113, the test programs, and his compiler. Thanks to Steve Bickerdike, who started with 4Links for three months and is still here. Thanks to Peter Thompson and Bob Dobinson, who got the 1355 Association going, and I hope that we can now take it forward and that 1355 can become more widely known. Thanks to Dick Selwood, who did a great job of revamping the 1355 web site content when I realised I did not have the time to do it. Thanks to Steve Parkes, not only for commissioning the SpaceWire-PCI board, but also for his work on SpaceWire.
Whatever the growing pains of success, I still find it astonishing and very rewarding that such a tiny company as 4Links has so many blue-chip customers around so much of the world.
So thanks to all of you who have found IEEE 1355 links, and who have become customers of 4Links. And thanks to all those not mentioned who contributed to Occam channels in their many forms. Happy 2000!