[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [f-cpu] random number generator



hi !

Tobias Bergmann wrote:

Hi F-Gang,

I've been lurking around on this list for a long time. I am now going to
spend some more time on f-cpu since we just got a new emulation machine in
our department.

Can you give more details ? HW and SW specs ?

F-CPU is a nice test vehicle since it is so small.

well, it's not very good because it's not finished either.
25% completion is a rough estimate...

ben franchuk wrote:

Yann Guidon wrote:
I am confused here. What kind of bugs do you wish to uncover?
maybe I can add some confusion :)

you're welcome ;-)

i see two kinds of "bugs", that is : special cases that don't
give the expected results. There are "simple" problems,
such as wrong or incomplete carry routing, or things like that.
it's either a copy-paste error, or a syntax/semantic error
that is not detected at first read and it results in a signal being
not used correctly. A LFSR is a predictibly efficient
mean to generate the test patterns, it can be used during
design, verification and for production tests.

Right.
Although LFSR's are not able to reach high fault coverage on processors
without heavy tweaking (reseeding, bit-flipping, whatever).

To get you right: With verification you don't mean formal verification,
don't you? I easily get confused by this term since everybody is using it
for sth else.

i didn't mention the "f" word,
since it is out of reach of such a project.
it's not impossible but impractical,
not GPL'd solution exists yet.

And "formal verification" is pointless without a synthesizer.

Here the issue is to make a correct synthesizable source code first.

Here, the target is much more complex coding problems
or misunderstanding of the problem's definition, a higher
level of debugging. Because of the low entropy of LFSR,
it would take too much time to find a pattern that shows
an error, so a less correllated pattern generator has more
chances to find ery complex errors with less tests.

Right. Still you need lots of cycles to yield a high confidence.

yup but this does not need to be performed everytime :
the LFSR-based test can be performed quickly (1K steps) when
installing the source code and during regression tests,
and the heavy random search (millions of steps) can be performed by
designers from time to time on an emulator or overnight/week-end server idle time.

If a dumb error is introduced, chances are that it will be caught by the LFSR test,
but more subtle and fundamental design flaws need a deep randome search to
increase confidence.

OTOH, because a LFSR can startup with strings of 0s and 1s,
and progressively make more complex patterns, it is well
suited to find small coding errors, boundary condition effects
or rounding problems with much less computational efforts
than a real random pattern. Hence the recommendation
to use both methods, LFSR to start and X thousands of
"uncorrellated" tests.

That's a good way to validate the design since you don't have to invent (as
many test cases as before) on your own.
Did anybody look into equivalence checking of behavior vs. RTL?

It has been mentioned already but it is not available.

If you did the hardware design correctly it would have no bugs.
but there can be traps in other places, such as langage and
the widely varying VHDL support from different compilers/synthesisers....

Now you're talking about design validation.

The F-CPU source code base contains many testbenches
so regression tests can be easily automated. The code can go
wild if someone wants to port another compiler/simulator/synth
so it is necessary, call this "design validation" if you want.

The corect way to design the hardware is to have redundant
test logic for hardware bugs or design testing. This
I don't think is possble yet using a high level design
langauge becuase the macro blocks are not designed for this
redundant logic or the compiler removes the redudant logic.

unless you do it on a higher level that the compiler is not
able to "simplify" without changing the circuit's behaviour.

Anyway, redundant hardware doesn't help your testability (in terms of fault
coverage) not to speak of power consumption.

yup, but this must be traded off with process-dependence faults.
Redundant Booth-based multipliers exists to compensate fault-prone
silicon processes, it is probably 10% less power-efficient but certainly
reduces the fabrication costs :-)

Concerning the testing time : the issue comes from running
the "full build and test" script at home whenever a change
is made on other units. At the end of the development of a particular
unit, it is possible for someone to run a very long test,
feeding the design with millions of test patterns.
The computer could run a few days, just to be sure.
Others would not be required to do this,
only to run the test with a few thousands of patterns.
In fact, it's as simple as a compilation parameter
that says how much tests should be done, the less the faster.

If patterns would be really random (i.e. LFSR seed different) making it
parallel is trivial.

sure, but then who owns a cluster at home ?

Maybe passing the seed as a script parameter.

yup.
or an environment variable.

Speaking of these validation runs: I would like to test compile, analyze and
emulate the current version of f-cpu but the /new folder seems to be mapped
to "/old" :( Where can I find an up-to-date version?

latest versions AFAIK :
http://f-cpu.seul.org/new/?M=D
http://f-cpu.seul.org/new/fcpu-mr-regfile-20030616.tar.gz
http://f-cpu.seul.org/new/fcpu-mr-20030418.tar.gz
http://f-cpu.seul.org/new/snapshot_jws_03_08_2002.tar.bz2
http://f-cpu.seul.org/new/snapshot_yg_29_07_2002.tbz

yes, i know, a big merge is needed :-/

bis besser,
Tobias

YG

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