SPANKy Performance Analysis
SPANKy!
Brought to you by group GAMMA:
Victoria Smith (vics@rice.edu)
Mara Prandi-Abrams (mabrams@rice.edu)
Dennis Geels (geels@rice.edu)
Overview -
Functional Specifications -
ISA -
Controller -
Design and Layout -
Performance Analysis -
Summary
Performance Analysis
Our longest path, assuming infinitely fast memory, passes through the decoder
and then the adder. This path is 19.8ns long, giving us a maximum clock
speed of 50MHz.
That timing information comes from Crystal, however, which uses inexact
scaling information for the 0.6 lambda process. We don't think it will be
exactly right, but it is a good ballpark figure. We also ran crystal with an
lambda value of 1.0, and using those numbers we get a clock speed of 30MHz.
View Crystal results for low-level blocks
We tried to run spice on our adder and decoder, which are the blocks in our
critical path. Unfortunately, spice never converges on the decoder, because it
runs out of memory too soon. Nevertheless, the spice times we got on the 4
input nor (which we used in the decoder) were similar to the crystal results
(the 4-input nor had a
rise time of about 2.2ns and a
fall time of .6ns), so
we can assume a certain amount of faith in the crystal results for the larger
blocks as well.
For one bit of the adder, Spice gives a
5.8ns fall time and 5.6ns rise time
for the carry-out signal. This is quite different from the crystal output,
which predicts a 16.96ns delay for the entire 8bit adder. Extrapolating the
Spice results suggests a much slower, 45ns delay, giving us a maximum
clock of 20Mhz. Either way, neither clock speed will be realizable, due to
the slow speed of the memory, so we won't be able to test these upper bounds.