Subject: Response to SCI's "Evaluation."
To: NDSmith
cc: Ritchie, Spencer, Mau, Elkind, JWeaver, Printis, Dillon, DDavies, Korobkin, MLee, Fasnacht, Garner

(For anyone reading this message, please note that the following information IS confidential and proprietary to Silicon Compilers, Inc. (SCI))

Nancy,

After reading SCI's "Evaluation of Xerox P Chip Design Proposal, 10 Nov, '83" I feel obliged to respond.

I believe the memo represents an unprofessional endeavor.  SCI's evaluation of the chip, as represented in the memo, appears at best to be inadequate, the conclusions reached prematurely, and at worst to be highly unprofessional.  At the very least, it would seem essential for SCI to thoroughly study the design before conclusively dismissing it.  If I were in their shoes and were genuinely serious about taking on the project, I would have asked some simple questions before implicating the work or jumping to hasty conclusions.

It is important to point out that I am not disagreeing with their desire to create a new architecture for the P chip.  If I were in their shoes and needed to use existing library cells, or build new resuable ones, or increase "my" confidence of producing a working design with "my" "composition" software, I would probably come to the same conclusion.   I am only objecting to their disrespectful dismissal of the existing design.  

I understand that SCI analyzed our proposal from their perspective and consequently it would have been rational for them ONLY to have said (as they did) that they do not desire to embrace the P Chip for any of a number of reasons:  it does not match their "block" libraries; or it is too specialized for their "composition software;" or the design can not be "recycled into future designs;" or it might be too expensive for SDD; or they don't have enough people-power because their tool building work has priority over custom designs.  But, to go beyond these affirmations and altogether discredit the design without adequately examining it, is unmistakably unprofessional.

An example:  In the memo they estimate that the cycle time could be 240 nanoseconds, based on reading and decoding microinstructions.  This is the sum of four numbers:  50, 70, 20, and 100.  Instead of evaluating the circuits or approaches for obtaining the 4 numbers that we might expect (20, 50, 20, and 50), they prematurely conclude that "there is a mismatch between internal data path timing and external microcode store access time."   They go on to use this statement as support for their position that the current P chip architecture is not viable.   

What follows are some examples from SCI's memo of, what I think, are premature conclusions, inadequately examined material and potentially maligning statements.  Together, these and other statements from the memo presumedly imply "a total rethinking of the P chip architecture."

1.  "Comparing this design with the Dandelion processor (...) it becomes clear that there is very little difference between the P chip and the DLion CP."  They go on to say that the CP "has been optimized for the properties of SSI and MSI TTL."  And this factor (together with (2) and other statements) is "enough to require a total rethinking of the P chip..."

This is very strange reasoning.  It implies little understanding of the differences between the P chip and the DLion processor and/or their significance or the pragmatic basis upon which the design rests. 

2.  "Quite a bit of the [Dandelion] central processor design revolves around the effective handling of the I/O functions."  Again, this factor (together with (1) and other statements) is "enough to require a total rethinking of the P chip.."

This implies some grave misunderstanding.  Perhaps this assertion would be significant if the task-specific TPC and TC registers were included in the P chip.  Otherwise, this statement is generally false.  (See Dan about our "disk-tailored, DLion microcode functions.")

3.  "There is a PLL to regenerate the clock locally.  We are not quite sure this is needed, but in any case, we prefer not to deal with analog circuitry on our chips at this time."

"We are not quite sure?"  This can't be a suitable response.  ED's reaction (in "A and P Chip Technical Observations") was more sensible:  "Delay line scheme to reduce clocking delays seems like good approach but quite unconventional.  At the least more circuit design work is needed to make the PLL work without process tailoring."

I understand that SCI is looking after their own interests, but several people I know believe that the circuitry is more "digital" than it is "analog." 

4.  "If the pause logic (which stops the clock) is used for anything other than clock-to-clock syncronization, then dynamic nodes may discharge.  It is a bad practice to "spec" the problem away, by specifying minimum pause times."

This represents simple lack of communication.  We have never proposed a dynamic system.  We have always said that the design is pseudo-static (i.e., that the clock can be held indefinitely).

5.  "If a variable length pause is needed (similar to the "ready" lines on most microprocessors) then added latches can be placed at critical points in the data and control paths, to hold up instruction execution."

This demonstrates a discourteous approach to our design methodology.  Are they proposing that this gives a "clean, straightforward design" with better performance?  Did anyone mention how the A-chip works?

6.  "The microcode word is fairly heavily encoded, resulting in a large amount of decoders and random logic."

If they mean vertically encoded, I would have to disagree.  Generally, only one bit is required to "horizontalize" any field. 

7.  "Partial patching of the existing [Dandelion] microcode could easily result in as much lost time as re-doing it completely."

This should not be easy for them to say.  Witness any implementation of the Mesa microcode.  Furthermore, it did not require much effort from Amy to convert the current DLion microcode.  What happened to the hardware simulator?

8.  "..and [we] have come up with a die size estimate of about 124,000 square mils..."

Their sizing algorithm should be mentioned...

9.  "..so that a design that was done using realistic, manufacturable design rules and timings could slow the overall performance down from what was expected."

This conceivably disparaging remark is a hit below the belt.  MEC or ICL may not want to be told that they have unrealistic, unmanufacturable design rules.  (It is, of course, possible that our timings our unreaslistic.  But some examples would lend credence to that argument.)

10.  "Some aspects of the system partitioning and P chip architecture have improved since the last time we talked about the project in June..."

They did not know about the P chip architecture in June.

11.  "If one were starting from scratch, decisions on microcode word size, amount of encoding, and data path structures would be quite different."

Yes, this is true.  But the suggestion of starting from scratch should be more carefully weighted against the existing solution.  Is the implication that someone did not make a reasonable decision?  What are those reasons?  Schedule and resources are important.  

12.  "It is absolutely essential that the technical people who we work with have the ability to commit to major design decisions quickly."

No comment.

13.  "It is possible to build a P-chip design that is quite similar to the current P-chip proposal, but the complexity and size would put it on the same level of difficulty as current STATE-OF-THE-ART 16/32 bit microprocessors."

Again, an uncourteous statement.  Current 16/32 bit microprocessors achieve their complexity, size, and performance partly through pipelined architectures, prefetch instruction queues (which get interesting when page faults are supported (r.e. 16032, 68010)), on-chip microcode, DMA facilities, intelligent timers, specialized interrupt hardware, and about 60-150K transistors per chip.  

Note that the Xerox Mesa chip has 116K transistors.  My original estimate for the P chip was 30K transistors while my current estimate is xK transistors.

If they meant to include the iAPX432 in their allusion, well, I'm flattered.

	Robert


PS.  Note that SCI's "Evaluation" was written before the "Preliminary P chip Schematics" were made generally available on 18 Nov.  However, realize that no questions from SCI have yet to be directed my way.