[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: [f-cpu] the ghdl bomb
On Wed, 20 Nov 2002 whygee@club-internet.fr wrote:
> >you will have a simulation time around 1:100000
> > and you want to debug program !
> At least if the program fails, we can know where the
> RTL model fails. And before giving numbers, one
> has to measure it....
Usually what I use is behavioral- and RTL-model running at the same time.
Then just generate huge amount of input data and compare the two
"designs" on the output. Of course in real life the checking needs much
more visibility. One problem is to generate huge amounts of pseudorandom
but sane command stream. There are solutions for that, OpenVERA (only
spec is open) verification language for example has nice "stream generation"
framework where the language can be described with BNF.
> The problem with an "emulator" is that it completely
> skips all the RTL level and dirty hacks are necessary
> to make it behave the same way. Sure it's "fast" (depending
With emulator/model it is easy to test the architecture selections. You
can even add some peripherial emulation to the model and run first
versions of the OS inside the model. This is the way all commercial
processors are finetuned. It's quite difficult to predict real
functionality and bottlenecks from spec.
--
=============================================================================
Mr. Kim Enkovaara | kim.enkovaara@iki.fi | Microelectronic Riemannian
Vasamatie 1 C 16 | IRC: embo | curved-space fault in
02630 Espoo | | write-only file system
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/