Author: Keith Evans
Date: 20:40:53 04/09/03
Go up one level in this thread
On April 09, 2003 at 23:05:28, Robert Hyatt wrote: >On April 09, 2003 at 18:20:41, Keith Evans wrote: > >>On April 09, 2003 at 18:01:09, Robert Hyatt wrote: >> >>>On April 09, 2003 at 16:58:35, Tom Kerrigan wrote: >>> >>>>On April 09, 2003 at 12:14:37, Robert Hyatt wrote: >>>> >>>>>_IF_ it is verified. This is not easy. It means you have to run a program that >>>>>specifically >>>>>tests "edge conditions" by running sliding 1 patterns thru every instruction, to >>>>>see if there is >>>>>any unexpected cross-talk at higher frequencies, etc. >>>>> >>>>>Just because it runs some application correctly, does _not_ mean it will run >>>>>_all_ applications >>>>>correctly. >>>> >>>>Do you know what testing Intel/AMD does to determine rated clock frequency? >>>>Seems like you should be able to do that, or something similar, without too much >>>>effort. >>>> >>>>-Tom >>> >>> >>>I know what Intel used to do. In fact, most every hardware manufacturer has >>>such >>>tests for their products. IE disk drives manufacturers, SCSI controller >>>manufacturers, >>>etc. >>> >>>Hsu had to develop the same tools for deep blue and he found some interesting >>>problems in >>>DB2 chips, if you have read his book... >> >>Doing a static timing analysis and finding the worst paths would potentially >>help. You would want to exercise those paths for sure. Only the designers can do >>this of course... >> >>And/Or you could perform a fault grading analysis on your vectors and see what % >>of the design that you're exercising, and assume that a very high percentage of >>testing will catch problems. >> >>Most ASICs aren't speed binned, so I'm not sure how Intel/Amd handles this sort >>of thing. >> >>I know that Hsu had some interesting structures such as on-chip tristate busses >>which can make timing analysis difficult. > >His most complicated problem was long parallel pathways that would cross-couple >at reasonable clock speeds. IE two adjacent 1 bits would couple to a third >path and raise an artificial one there if it was supposed to be a zero. They >had to work around this in software... > >However, knowing what frequency would cause the cross-coupling would be tough >and the engineers designing the thing might know it is safe at X, but not at >1.1X for example, but since they don't run at 1.1X they don't care. It wouldn't surprise me if his tristate busses were more affected by this kind of thing too since they are probably weakly driven at times. His arbitration was tristate and would span the entire width of the move generator for instance. There are tools that most places use to detect and prevent this sort of problem - for both chips and PCBs. Thank god that's done "below" my level. Any typical design has multiple clock domains and I doubt that anybody tries to predict when crosstalk will be safe except for things like data busses. If there is crosstalk between control signals in different clock domains then you're having a bad day/week/month. I wouldn't be surprised if he had problems with his power distribution as well. That's another place tha people get burned. And very difficult to diagnose on the bench.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.