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

Re: [f-cpu] testing



GOOOOOOooooood evening, F-CPUers ! :-)

Kim Enkovaara wrote:
> > PS: to answer Kim, there must be a dedicated "BIST" unit in the pipeline,
> > which overrides the scheduler and performs the integrity check of most
> > of the ressources (let's say : 80%). The rest is done with a scan chain
> > for the ressources which are not directly addressable by the execution
> > pipeline. BIST could be extended later to include a L2 and SDRAM check
> > routine (it's not difficult).
> 
> Why is is a must to have BIST in the pipeline?
for me it's obvious : access the register set and all the units
in a single cycle !
FC0 is a modular design and there is no performance hit to add another unit,
even though it is not an "execution" unit.

> 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 ?

> For memories MemoryBIST is needed, but
> that is quite different story. Also dividing the work between atpg and
> bist is quite difficult, how do you calculate real fault coverage?
i'll use HILO at the university ;-)

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 ?

However, "divide and conquer" (quote from another post) works
well during tests (in fact, it's often the only way to find where
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.

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.
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 ?

> If the test coverage is not in the ballpark of 95% the chip is not usable for
> mass production, you just get too much broken chips to end products.
right. But i hope that with this thread, you are reassured that we won't
get to F-CPU rev. 0.5 before 99% coverage is achieved. There is reasonably
no silicon before Rev. 1, btw.

> Also remeber that in ASIC tester you have about 5-10s of time for the
> testing. Each second costs real money in the tester, there is no time to
> run minutes of tests.

10 seconds ? that's long ! :-)
oh yes, i have forgotten that F-CPU can be mixed with other modules
on the same chip and that you design 50M+ circuits, sorry...
i'm such a naive guy, sometimes :-)

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