Re: [f-cpu] random number generator

["Tobias Bergmann" <Tobias.Bergmann@gmx.de>]

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.
F-CPU is a nice test vehicle since it is so small.

> 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 :)

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

My (informal) definitions:
validation: gives strong confidence that the design is correct.
verification: prooves that the design is correct. aka formal verification
test: gives confidence that the physical implementation on chip is equal to
the design specification.

Please note that those terms have a totally different meaning for software
guys vs. HW guys, company A vs. company B, university C vs. university D.

> The others are more subtile, less easy to uncover
> and are, indeed, the ones that are not typical, or specific
> to unknown data sets .... the point is that we don't know
> what it is, so we know what it is not : correllated.
> LFSRs have a low entropy and are not adapted.
> 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.

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

> > 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 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.
 
> 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.
Maybe passing the seed as a script parameter.

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?

bis besser,
Tobias

-- 
GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...)
jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++



-- 
GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...)
jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++

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