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