Cinematronics Testing (Was: Re: Speech board idea...)

> NOOOOOOOOOO!!!!! [Hands held up in the form of a cross] I have plenty to
> do, and for the amount of work I'd put into, I'd be able to fix all the
> non-working CPU cards I have and still have time for a nice vacation.

        This is the main reason why I made this a low priority -- I fixed all my CPU boards!

> Now your talking the Cinematronics Excersizor. Steve O. has one of these,
> you'd be better off getting his working since all the expected signals are
> already accounted for and marked on the CPU schematics.

        Not quite......I've talked to Steve about the exercisor. From what I remember about our discussion(s), the exercisor needs to be used with a signature analyzer, and what it does is basically keep pumping nops through the CCPU. You look at the signatures (after time) of a certain point with the signature analyzer, and you eventually find the signature(s) that are bad. IMHO, you can do the same thing almost as well with 1 nop and a logic probe.

> If nothing works you obviously can't use software to test anything. If you
> light up all the outputs by placing LED's on them and one doesn't work,
> you've obviously found a bad output. Software testing get grey between
> those two points. I spent 2 1/2 years as a hardware test engineer (as a
> software engineer writing hardware test code) and know it can be pretty
> tricky at times.

        If nothing works you have to replace every TTL chip anyways, so what's the point in testing...Any test program methodology is based upon the assumption that you use what's working to test what isn't. Since you don't know what's working and what isn't, you have to go through and assume, each time, that something different is working. After you've accumulated the results of all your tests, you will see a pattern, depending what is working and what isn't.

        There are all kinds of algorithms to come up with test code nowadays, and that's why I wrote the verilog model. I was going to run it (with the controllability and observability points that I defined) through an ATPG (Automatic Test Pattern Generator) and create ROM code based upon the vectors that get returned. The ATPG will also tell you what sort of fault coverage that you get based upon those vectors. This is the only time-effective way to test VLSI circuits (which I design for a living) but there is no reason why it should only work on VLSI stuff. ATPG should work on any [known] arbitrary network of combinational and sequential logic whose controllability and observability points are defined. The CCPU board meets all those criteria, and the controllability and observability points are actually pretty good (some were created by Cinematronics themselves, for the very purpose of testing the CCPU board with their exercisor.)
 
> And just to be disagreable (since I have no intentions of verifying this ;^)
> I think the %50 is a bit too high. There are too many parts on the board
> that if they were to die, all software execution would come to a halt. I've
> fixed a few of these boards, and the parts I've had to replace (outside of
> I/O), would have kept even the first instruction from executing properly.

        You can't reliably test any complete system (using its defined inputs and outputs) with any reasonable amount of fault coverage -- You need to break it up by defining several [internal] controllability and observability points. Thus, you can put some vectors on the "real" inputs of the system, and observe them at some intermediate point before the output, where you've "broken the loop." Then, on the other side of the break, you put a new set of vectors in and observe them and some other observability point, etc. If all but one of those sets of vectors pass, you've narrowed down the cause of the problem (i.e. you don't have to bother testing ANYTHING in those other areas.) Am I making sense?
 
        If you're still feeling disagreeble, I LOVE talking about this stuff. I'm going back to school at the end of August to get a Ph.D. in Electrical Engineering, most likely specializing in, guess what, VLSI test methodology (The Prof. that I'm most likely studying under has done a lot of work with Built-In-Self-Test, etc...) In modern-day VLSI design, any sort of coverage less than 90 or even 95% is entirely unacceptable, so there are all sorts of sophisticated tools around for coming up with these vectors. The only thing different about the testing work that I do, and the CCPU board is that I have the luxury to set my controllability and observability points wherever I want to (i.e. the best possible places.) Since Cinematronics DID define controllability and observability points (those DIP shunts) I'm assuming that they were as well thought out......I could easily be wrong.

        I'm getting excited about this project again. Anybody got a broken board to sell? ;)

Joe
Received on Fri Jun 27 12:34:30 1997