Eric- > Ok, I installed the latest Quartus II ver. 7.2 software onto a virtualized > WinXP guest hosted by a Linux x86_64 system running kvm/qemu. I > downloaded a recent revision of gnuradio (revision 6595) onto the host.
This should work Ok, but let me comment that based on personal experience FPGA tool software is some of the most fickle, easy-to-crash (/ hang up / produce inconsistent results / etc) software out there. If there is any little small thing wrong with the virtualization, you could get an incorrect result, and it might be very hard to pin down. I would suggest to install Quartus on a WinXP machine, build USRP logic to be sure it matches the defined results down to the last detail, and then compare that with the Linux-hosted virtualization. Let me put it another way -- if some day you have to ask an Altera/FPGA online tech group for assistance and you told them you were not running on native WinXP, they'd tell you to do that before spending time to help out. -Jeff > I started Quartus, and using a samba connection between the virtual guest > and the Linux host I opened the usrp_multi.qpf project file in: > usrp/fpga/toplevel/usrp_multi > > Not knowing anything about Quartus, I took a guess and hit "Start > Compilation" under the Processing menu. > > The compilation begins, a lot of green and blue lines go by including many > "Elaborating entity...", but after a short while the compilation fails > with an error: > > "Error: Node instance "cic_dec_shifter" instantiates undefined entity > "cic_dec_shifter" > > The line just before this, says: > > "Info: Elaborating entity "sign_extend" for hierarchy > "rx_chain:rx_chain_0|cic_decim:cic_decim_i_0|sign_extend:ext_input" > > Not sure what to do at this point.... > > thanks, > eric > > On Sun, 7 Oct 2007, Eric Blossom wrote: > > > On Fri, Oct 05, 2007 at 05:19:38PM -0400, [EMAIL PROTECTED] wrote: > >> Can anybody tell me why the multi_* versions of the fft and scope > >> applications (found in the multi-antenna directory) seem to have such a > >> large gain on the input signal for high decimation values (eg 250), > >> relative to the non-multi versions (at same -g gain setting) of the fft > >> and scope aps? I'm saturating the inputs for anything above .3 V p-p > >> using a function generator, whereas the non-multi versions work fine up to > >> the 2 V p-p limit of the A/D. > >> > >> I'm putting in frequencies of 10 kHz and tuning to 0 Hz. I also noticed > >> that the magnitudes of the values displayed by the multi_* programs is > >> dependent on the decimation. At lower decimation values the magnitudes > >> are much less. This variation is not as pronounced on the non-multi > >> versions, although there is a 'dip' in the response. To give you some > >> idea of the magnitude difference: > >> > >> for a .3 V p-p 10 kHz sine-wave input, here are the peak values: > >> > >> decimation usrp_fft.py (with -S) multi_scope.py > >> 64 1750 1750 > >> 128 1750 1750 > >> 144 1750 2900 > >> 188 1000 8000 > >> 200 1200 10000 > >> 250 1750 25000 > >> > >> So for decimations greater than 128 the mult_* applications cannot take 2 > >> V p-p. Any ideas? > >> > >> thanks, > >> eric > > > > The FPGA rbf's checked into the trunk are probably not up to date for > > the multi_scope case. I'm not in the habit of building multi-board > > versions since I'm not sure how to test them. > > > > If you've got the free (beer) Quartus tools installed, you can rebuild > > the rbf's and check. > > > > Eric > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
