🚀 go-pugleaf

> The demo did not state this this was a simulation, but rather mislead people
> into thinking that the 32332 was going to 3x of a 32032.  Why do you think
> some people bitched and moaned when the 32332 was showing a performance
> increase of less than half that amount?
> 
May I point out that this demo was used BUT ONCE at the stock holders
meeting.  Not a single observer bitched.  Many asked questions and were
told exactly what it was doing.  Several others as expected just didn't
care.  This is quite often the case with financial analyists.  If
my memory serves me right, you were the only one who moaned.  Since you
were not in attendance at the meeting, I'm not sure how you can say "some".
Let me interpret this as "1".  We have many satisfied 32332 customers
today all of whom would be pleased to describe the performance increase
they got.

> 
> This kind of benchmark (showing raw CPU increase) is somewhat comic when you
> remember that the selling pitch of "32000 vs 68000" was based on total system
> performance, discounting MOTs raw-cpu performance.  But that seems to all
> be "water under the melons" now, if you know what I mean.

What you are getting to here is what you could call "useable performance".
I don't think that even you would disagree that it has always been easier
to design a memory sub-system for any 32000 cpu versus the equivalent 68000
cpu.  The 32000 has always allowed the designer more margin and the
ability to use slower and CHEAPER memories.  How much performance loss
per wait state do you get on the 68020? or did you pay mega bucks for the
fast RAMs.

> What am I looking/hoping for?  Well:
> 
>    * What kind of system thur-put increase will I see in a 32532 vs 32x32?
> 
      Lets try "external bus bandwidth" ......... 532 @30 =  96 Mbytes/sec
					......... 032 @10 =   8 Mbytes/sec
	using the same code as a test case.  This is as we said befor
	an improvement of 12X.  If that doesn't count and you say that
	the CPU can't sustain that, let me just say that the internal
	hardware has a sustained thruput of 240 Mbytes.  Yes, the number is
	correct.

> 	32332, then you do the same on a 32032.   (your code compat, remember?)
> 	The compiler improvement should be factored out.  Or, if I have XYZns
> 	rams in my system, increasing the clock rate may likely lead to more
> 	wait states than more performance.

This is a two part answer, all the performance increase factors I've posted
(ie: 11.7x or 12x above ) don't INCLUDE improvements in compilers. As it
relates to RAM speed, I'll agree that using slow rams may cause a problem
when you integrate in new CPUs.  These are trade-offs designers of systems
have to make.  Where does it say that ALL SYSTEMS must be designed with
XYZns rams.  Befor I leave this subject, to operate at 0 wait states
at 30 MHZ, the address to ready time is 49 nsec.  Not bad.  How much
will you get for a 20 MHZ 030 when it comes out.  Whats more, if you
have wait states (which in many cases is likely), you will see about 3%
performance degradation per wait state, also not bad if you compare
that to what happens today on the 020 and other processors.

>    * How soon after the 'on-time project' delivers a working 32532 in samples 
>      might I see 19800 Dhrystone systems?

30 MHZ parts are due out the first half of CY88.

>    * How has NSC changed the way the 532 is being developed/built in order to
>      prevent a repeat of the past problems?

The original NS16032 (using the old numbers) was designed virtually by hand.
There were very few simulation tools available at the time.  As was done on
the 32332 and the 32382 (both of which are in full production), the design
of the 32532 was done with very sophisticated software tools.   

We have a complete vme based demo system in design today and it is scheduled
out simultaneously with the silicon.  We will not sample the 532 until it
works on our own hardware.