How A Rocket Took Off: Juniper Founder Pradeep Sindhu (Part 2)

SM: What was your time at PARC like?

PS: I arrived in the midst of an exodus from PARC. It was a tumultuous time for the research center, but I had great fun. I worked on two primary projects. One was cache-coherent algorithms for multiprocessors. Some of the standard algorithms used in Intel CPUs were inspired by the work I did at PARC. The other project was design tools.

I have always been interested in complex system designs. We are always limited by the tools we have. How do you increase the capability of what you can do when the solutions require as simple of an approach as possible? The state of the art at the time was pretty pathetic. The tools we had back then are still tools we use today, but [the current tools are] not nearly as integrated as those tools were. We had a single integrated database for representing objects, geometry, object design and code. It was all seamless. If you wanted to do an electrical model of a circuit, you could compile it from logic because everything was compiled together. Layout was connected to it, so we could extract from layout to a model.

SM: Why was everything so integrated back then versus being segregated today?

PS: I wonder why that is the case as well. If you look at logic design, I believe you need to describe both the behavior and the structure at the same time. Without design and structure you do not get the geometry right. If the geometry is not right, the implementation will not be nearly as good as it can be.

I think what happened is this. The availability of useable area on chips was increasing faster than our ability to use that area. Being a little bit inefficient was not that big of a deal except in microprocessors. Microprocessors were lucrative, so companies like Intel could afford to apply manpower.

There was not a need. The EDA industry is not that large. The number of users is limited. My project with design tools was never going to be a large commercial product, and I knew that. I just found it interesting. On the one side I was building chips and on the other I was designing the tools. It gave me a great background to understand what the limitations are.

My projects cost a lot of money. If you are going to do systems work, you either need to be at a very profitable company or work for a company where systems work is at the core. We struck up a partnership with Sun Microsystems. At the time they did not have multiprocessor servers. They had a single product that could barley qualify as a multiprocessor. There was almost a religious belief at Sun, which Bill Joy was propagating, that multiprocessors were garbage.

SM: Why was he doing that?

PS: In a sense, if you can implement compute power with a single machine that is not a multiprocessor, which is single-threaded, and you can get flat-out performance with that, it is actually much better because the programming model is the simplest. Multiprocessors are hard to program. Even when you make the model simply, it is hard to write the correct programs for it. I understand why Joy took his position, but it was a religious-like position that was not relevant over time.

We made a deal with Sun wherein 10 or 11 of the researchers at PARC spent three years at Sun and helped them to build their first microprocessor workstation. The group that built this technology at PARC did not want the technology to disappear. They wanted it to get commercialized. It was commercialized through the first multiprocessor systems that Sun built. They eventually earned $2 billion to $3 billion for Sun. Xerox did not make much money, but it was a great deal for Sun.

SM: When did those come to market?

PS: That was in 1991 and 1992. In 1992 the team came back to PARC. We proposed that since we had already made the technology, we should make it useful to Xerox. The proposition was that we would build imaging machines. The idea was to start with printed material and bring it into the document with an electronic digital document processing system. It was not just image identification but also the ability to extract digitally text and other things from documents. The proposition was that it would require lots of computing power. The assumption we made, naively, was that since Xerox had a bunch of digital processing algorithms, all we needed to do was implement them on our technology.

That project was Xerox Impact. To make a long story short, we developed things for a couple of years, but Xerox never had any intent on spinning us out. They were afraid it would end up in the hands of the competition. At the same time there were internal battles with other divisions of Xerox that were supposed to be building the same technologies.

This segment is part 2 in the series : How A Rocket Took Off: Juniper Founder Pradeep Sindhu
1 2 3 4 5 6 7