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

Re: [f-cpu] random number generator



Hi,

> Tobias Bergmann wrote:
> >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
> Can you give more details ? HW and SW specs ?

About 1.5 Mgates (2-input AFAIK). 

> 25% completion is a rough estimate...

That's promising: Many things to improve!

I heard from Michael that even the behaviour has not come very far.

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

I think you're right. It is hard to find good&free SW for HW development.

> And "formal verification" is pointless without a synthesizer.

OK. We'll have to wait for such a free FV tool to emerge. Could take years.
:(

What synthesizer is currently in use? I once saw Kim (sp?)  post numbers
using as commercial tool, but is there a free one?
I can only think of SIS, Espresso and FBDD-synthesis.

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

Right. 75% missing. I remember.

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

This deep search was what I meant with 'lots of cycles'.
But I guess the current test is enough for the first prototypes.

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

So it helps quality but not testability. But quality is what matters :)

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

Not @home, but at work. I can always add some idle jobs on weekends.

> >Maybe passing the seed as a script parameter.
> yup.
> or an environment variable.
 
> >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

Got them. I will play a bit with it after work.

> yes, i know, a big merge is needed :-/
I always wondered why f-cpu is not using CVS or sth similar. 

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

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