[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] testing



Kim Enkovaara wrote:
> 
> > With all this talk of testing -- why not a have nice 12 bit micro -
> > micro computer add,nor,store,jc - instructions and have it test out the
> > main F-cpu. If you really want to be sneaky have a core logic block
> > tested by normal means of a minimal F-cpu that then tests out the rest
> > of system. All that cache and main register file is a good bit of
> > program space.
> 
> The problem is still the speed of testing. To get good coverage from the
> edges of the chip huge amount of vectors is needed. This is same problem
> that is visible between block and toplevel verification of chips. If
> blocks are not well verified on their own it is almost impossible to
> verify them from the toplevel.

Very true and more so since the F-CPU is vector style computer. Now if
you had a front panel with lights and switches like a real machine you
could do real testing.:)

> Also normal tool flows do not fit into this kind of design. How do you
> for example optimize the vectors this small CPU feeds into the design.
> There are some formal tools (model checkers etc.) that can be used to
> deduct the needed steps on chip edge to get it into certain state, but
> those tools are slow and they can't optimize the vectors. If you create
> one vector for each node first and then optimize them it would take years
> of CPU time to first create the vectors :)

All my testing of computers has been done with a logic probe and a
brain!
I still feel if you can't design by hand the system may be too complex
to work properly. If you have system of X alu's and Y thing-a-bobs and Z
do-dads expect longer testing if you can't test in parallel. From what
little I read vector testing is that it is a go-no-go style check good
for testing a chip before packaging. Yet even then you your modules with
proper testing signals as to make gates more visible and break feed back
loops or long logic paths like carry signals. With FPGA's you don't have
the gate level testing so for the first round design the sub-modules
don't need a low level test mode like real silicon would.   

> Some scripting and Solidify could do the vectors, but it can take minutes
> for each node and if we have about 500kgates that means little over and
> year of calculation. And then the duplicated patterns need to be found
> etc.

I have never used it, can't afford it. You may have 500k gates but a
module may have 5k. Divide and conquer, start small and work out. The
problem is you have serial testing of each node,you need to parallel the
testing as you well know. 
 
> What if we just use the existing ATPG methodology with scan chains. That
> is known technology and well tested.

Never heard of it so I can't comment on it. I can understand scan chains
as serial access of internal sub systems but I think direct tri-stating
of control and module outputs from a test module or internal test pads
would make more sense. How did the big machines like CRAY's test their
subsystems and modules.  
 
> --Kim

Don't get discouraged testing people, here is a nice quote I read on the
net
"The difficult we do immediately, the impossible takes a bit longer"
Philo T. Farnsworth
Inventor of television.

-- 
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/