[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/