Re: [f-cpu] testing

[Kim Enkovaara <embo@mpoli.fi>]

> > It would be much easier to test it with normal scanchains.
> "easy" ? hmmm then please calculate how many cycles it will take to
> fully verify (100% or 95%, whatever you want) the multiplier unit,
> for example. By having the BIST unit tied to the Xbar, it IS 64x faster.
> then comes the algorithm, but 64x is already nice, no ?

How many cycles does it take to test the multiplier with BIST that
goes trough all the possible states :) With logic BIST you are also
restricting the state space by simulating the fault coverage during
design. You don't have to run all the possible states of the flipflops
with vectors. You just have to guarantee that each flipflop has been
tested for both 0 and 1 values (and the transitions). Then you need
vectors that test the combinatorial logic in between, one vector can
detect quite big amount of errors because errors paropagate. It
is hard to say the needes amount of vectors but it is not very big.

> seriously, it is impossible to know because fault coverage tools
> work on already synthesized designs, where all the wires and gates
> are flattened. unless you know another method that directly
> works at the behavioural VHDL level ?

There are tools that quickly synthesize the design and tell possible
problems that affect the test coverage. That is the first phase.

> and what an error is). Remember, every Execution Unit has a testbench
> that verifies that the unit works as expected : at that level,
> we can start to think about the best way to ensure that the BIST will work.

I doubt that the test bench can test all possible combinations of the
functionality either so that is guarantees reuirement that in synthesized
design each node is tested for common fault types :)

> Currently, the ASU and IMU use an "exhaustive" approach (around 15 minutes
> of VHDL simulation :-/) but we can find a better way from the start.

Hmm.. can you actually loop trough all combinations at that time. I just
woke up and Espresso machine is warming up but isnt that already with 32
bits 2^64 cycles :)

> When applied to all the modules, and with a well designed BIST unit,
> we can already cut a large portion of the ATPG's effort, right ?

Maybe, combining ATPG and BIST coverage is not trivial, it is possible :)

> 10 seconds ? that's long ! :-)

That time can be spent easily with 64k depth memory even if the test is
running at full speed. The memory space need to be marched trough many
times.

--Kim


*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/