Re: [Discuss-gnuradio] benchmark_* not working correctly
On Tue, Oct 02, 2007 at 03:42:43PM -0700, Tim Meehan wrote: > The update seems to work. I re-ran configure and verified that the SSE code > was being used. make check passes and the original code Dev had a problem > with "benchmark_loopback.py" works correctly. > > Tim Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Default FPGA I/O standard
Thanks everyone for the help and information. I also discovered that if you want to increase the drive strength for any IO standard for the FPGA IO pins it is possible through the Assignment Editor in Quartus II under Logic Options by setting current_strength_new to Thanks again for all the information. Nirali -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bahn William L Civ USAFA/DFCS Sent: Tuesday, October 02, 2007 5:15 PM To: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Default FPGA I/O standard > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Brian Padalino > Sent: Monday, October 01, 2007 5:53 PM > To: Matt Ettus > Cc: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Default FPGA I/O standard > > On 10/1/07, Matt Ettus <[EMAIL PROTECTED]> wrote: > > I think 3.3V LVTTL and LVCMOS are really the same. > > > > Matt > > According to this: > > http://www.interfacebus.com/voltage_LV_threshold.html > > They are, indeed, basically the same. > > Brian They're the same only different. For most purposes, the differences don't matter too much. The biggest difference is in the output drive capability. LVTTL outputs are required to be able to source/sink 2mA while remaining compliant while LVCMOS outputs are only required to source/sink 100uA. For those interested in the "official" word, refer to the actual JEDEC standard: http://www.jedec.org/download/search/jesd8c.pdf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark_* not working correctly
The update seems to work. I re-ran configure and verified that the SSE code was being used. make check passes and the original code Dev had a problem with "benchmark_loopback.py" works correctly. Tim On 10/2/07, Eric Blossom <[EMAIL PROTECTED]> wrote: > > Tim, > > I've checked a trial fix into the trunk as of r6575. > Can you please update and let me know if it fixes your problem? > > Thanks, > Eric > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Default FPGA I/O standard
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Brian Padalino > Sent: Monday, October 01, 2007 5:53 PM > To: Matt Ettus > Cc: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Default FPGA I/O standard > > On 10/1/07, Matt Ettus <[EMAIL PROTECTED]> wrote: > > I think 3.3V LVTTL and LVCMOS are really the same. > > > > Matt > > According to this: > > http://www.interfacebus.com/voltage_LV_threshold.html > > They are, indeed, basically the same. > > Brian They're the same only different. For most purposes, the differences don't matter too much. The biggest difference is in the output drive capability. LVTTL outputs are required to be able to source/sink 2mA while remaining compliant while LVCMOS outputs are only required to source/sink 100uA. For those interested in the "official" word, refer to the actual JEDEC standard: http://www.jedec.org/download/search/jesd8c.pdf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Vista, Xp, or Linux?
On the ubuntu live cd (the installation CD) use gparted. It is already there and ready for that purpose without having to resort to "your favorite bittorrent copy" of partition magic. Bob Eng. Firas wrote: Hi, I suggest you run partition magic and divide your hard disk into a new partition and install Ubuntu in the new partition. In this way, you can keep your Vista and run gnuradio safely in Linux. Firas Kevin Rudd (Contractor) wrote: Hello all, I just got my new notebook computer with Vista pre-installed. I have a couple questions. 1) Has anyone had any luck installing GNURadio under Vista using Cygwin or MinGW method? 2) Are there any performance issues running GNURadio under windows (XP or Vista) as opposed to Linux? Thanks! Kevin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair "If you're going to be crazy, you have to get paid for it or else you're going to be locked up." Hunter S. Thompson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark_* not working correctly
Tim, I've checked a trial fix into the trunk as of r6575. Can you please update and let me know if it fixes your problem? Thanks, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark_* not working correctly
On Tue, Oct 02, 2007 at 08:52:06AM -0700, Tim Meehan wrote: > > > In the production code, I.e., where you are seeing problems (was it > > around gri_mmse_fir_interpolator?), do you see the alignment > > problem occur? > > > In the production code the "input" is declared in gr_mpsk_receiver_cc.h line > 300 > > gr_complex d_dl[2*DLLEN]; > > http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/general/gr_mpsk_receiver_cc.h Great troubleshooting! I'll fix it a bit later today. IIRC correctly there's an align attribute that should do the trick. > > I agree. A check in the SSE code will be required if addressed by a caller > fix, else someone in the future will repeat the same effort we are going > through > today. I'll add that too. Thanks again for your efforts! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark_* not working correctly
On 10/2/07, Eric Blossom <[EMAIL PROTECTED]> wrote: > > > > > > Yes I do see the 0RCR or R case. For example when I change the QA > code > > to use stack allocation for the input (uncommenting a piece of code > that > > was originally there, lines 110 and 111 in the QA code from trunk) the > check > > will fail. > > OK, I'm not surprised by that. I wouldn't consider that a problem, > unless we get in the habit of calling this with stack allocated > input. It could of course be worked around with an attribute((...)) > on the array definition. agreed. But I am not sure placing a restriction (no stack allocation) makes sense. > In the production code, I.e., where you are seeing problems (was it > around gri_mmse_fir_interpolator?), do you see the alignment > problem occur? In the production code the "input" is declared in gr_mpsk_receiver_cc.h line 300 gr_complex d_dl[2*DLLEN]; http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/general/gr_mpsk_receiver_cc.h If so, I think we should fix the caller. If the calling site is using > stack or heap allocated data, we should fix it there. If it's using > input passed to it by "work" or "general_work", they are already > aligned. In any case, we should add a check at the site of the call > to the SSE code that checks the alignment and raises an exception in > the bad cases. Of course the SSE code could be modified to handle the > other two alignment cases, but I'd like to know the performance cost > of doing it that way before committing to that path. I agree. A check in the SSE code will be required if addressed by a caller fix, else someone in the future will repeat the same effort we are going through today. Summary question: is there an alignment problem when called from the > non-QA code? If so, where? Yes Line 300 of gr_mpsk_receiver_cc.h Tim > Eric > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark_* not working correctly
On Tue, Oct 02, 2007 at 04:10:07AM -0700, Tim Meehan wrote: > Eric, > > See reply embedded Thanks. > On 10/1/07, Eric Blossom <[EMAIL PROTECTED]> wrote: > > > > On Mon, Oct 01, 2007 at 06:07:51PM -0700, Tim Meehan wrote: > > > Eric, > > > > > > > > > The QA code (qa_gr_fir_ccf.cc) forces a 16 byte alignment. When the > > > malloc16Allign is replaced with a regular malloc in the QA code, make > > check > > > fails. > > > > > > I believe that there is an additional requirement that the data passed > > to > > > the low-level SSE code have the real sample start on the 0th or 2nd 4 > > byte > > > float. For example the R / C represents 4 byte floats (Real, Complex) , > > 0 > > > represents "forced alignment" from gr_fir_ccf_simd.cc > > > RCRC... OK > > > 00RC... OK > > > 0RCR... Not OK > > > > Hmmm. Does it ever use the 0RCR case? I would expect only the first > > two. It may be reusing the fff simd code which generates all 4 > > alignments for the taps, but I wouldn't expect to see the 0RCR or 000R > > input cases. > > > Yes I do see the 0RCR or R case. For example when I change the QA code > to use stack allocation for the input (uncommenting a piece of code that > was originally there, lines 110 and 111 in the QA code from trunk) the check > will fail. OK, I'm not surprised by that. I wouldn't consider that a problem, unless we get in the habit of calling this with stack allocated input. It could of course be worked around with an attribute((...)) on the array definition. > Input is at address 0xbcd87d4 this gets 16-byte aligned to address > 0xbfcd87d0. This illustrates the 0RCR case. > > Q: Is my assumption of the additional requirement correct? > > > > > > Q: I don't think it will be easy to force the additional requirement > > with > > > the same trick used in gr_fir_ccf_simd.cc; do you agree? > > > > I don't see that this as an additional constraint. > > gr_complex == std::complex is always laid out (,). > > sizeof(gr_complex) == 8, so with 16-byte alignment, we still always > > have good alignment. Are you seeing a case where the input has the > > real on a mod 8 == 4 boundary instead of a mod 8 == 0 boundary? > > > > yes, see example below. > > If so, (1) where's the input data coming from, (2) what version of the > > compiler are you using? > > > > 1) > In the example above the data was allocated on the stack from the qa code > with > *i_type input[INPUT_LEN];//(i_type is gr_complex)* > > which will case the QA code fail > instead of > > i_type *input = (i_type *)malloc16Align(INPUT_LEN * *sizeof*(i_type)); > > which is in the QA code, and will make it pass. > > 2) > I am using three different compiles / versions of gcc on two different > machines getting the same results > > gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) > gcc (GCC) 4.2.1 (Debian 4.2.1-3) > gcc (GCC) 4.1.2.20070502 (Red Hat 4.1.2-12) > > However, back to your first point, if we are using the 0RCR case, then > > the code is completely wrong, and I don't see how it could ever pass > > the QA tests (which it seem to). On the other hand, there could be > > some problem with how the float taps are mapped across the complex > > input (It's been along time since I looked at the code...) > > > The QA tests are passing because they force the 16-byte alignment. OK. This is as expected. In the production code, I.e., where you are seeing problems (was it around gri_mmse_fir_interpolator?), do you see the alignment problem occur? If so, I think we should fix the caller. If the calling site is using stack or heap allocated data, we should fix it there. If it's using input passed to it by "work" or "general_work", they are already aligned. In any case, we should add a check at the site of the call to the SSE code that checks the alignment and raises an exception in the bad cases. Of course the SSE code could be modified to handle the other two alignment cases, but I'd like to know the performance cost of doing it that way before committing to that path. Summary question: is there an alignment problem when called from the non-QA code? If so, where? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] No horizontal sync with ntsc tv reception
I believe Daniel Garcia implemented this a while ago. Check http://www.danielgarcia.info/thesis/ for info. I tested it and it seemed to work, but only when my TVRX was connected to cable TV. When hooked to an antenna, apparently the signal was not strong enough for the sync to function. Rob >On Mon, Oct 01, 2007 at 01:55:30PM -0500, Nirali Patel wrote: > Hi, > > > I am working on ntsc tv reception as a precursor to hdtv reception. I am > using usrp_rx_cfile.py to capture samples to a file from the TV_RX board and > then playing back using usrp_tv_rcv_nogui.py. The picture displayed does not > seem to have horizontal sync (picture keeps moving from left to right). I > have tried setting different decimation factors, the best I can use without > overruns is a factor of 8 and the picture still rolls in horizontal > direction. My understanding was that the decimation factor would only affect > the horizontal resolution not the ability to sync, but I could be wrong. The > commands that I use for capture and playback are: > > ./usrp_rx_cfile.py -R B -d 16 -f 531.25M -s tv1.out > > ./usrp_tv_rcv_nogui.py -f 531.23M -n -i tv1.out sdl > > > > where 531.25 Mhz is the picture carrier of the ntsc channel with lower band > edge at 530Mhz. > > I have also tried using -f 533M to set the tuning frequency to centre of the > band but no significant change in picture sync. > > If anyone has experienced similar problem I would appreciate the guidance. > Does the antenna setting have any influence on h-sync? My office is in the > interior of the building so would it help to move towards the exterior? > > Thanks in advance for any help. > > Nirali Patel > > >If you look at the code, there's a comment at the top that says that >synchroniziation isn't implemented: > > > """ > Reads from a file and generates PAL TV pictures in black and white > which can be displayed using ImageMagick or realtime using gr-video-sdl > (To capture the input file Use usrp_rx_file.py, or use usrp_rx_cfile.py >--output-shorts if you have a recent enough usrp_rx_cfile.py) > Can also use usrp directly as capture source, but then you need a higher >decimation factor (64) > and thus get a lower horizontal resulution. > There is no synchronisation yet. The sync blocks are in development but not >yet in cvs. > > """ > > >Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark_* not working correctly
Eric, See reply embedded On 10/1/07, Eric Blossom <[EMAIL PROTECTED]> wrote: > > On Mon, Oct 01, 2007 at 06:07:51PM -0700, Tim Meehan wrote: > > Eric, > > > > > > The QA code (qa_gr_fir_ccf.cc) forces a 16 byte alignment. When the > > malloc16Allign is replaced with a regular malloc in the QA code, make > check > > fails. > > > > I believe that there is an additional requirement that the data passed > to > > the low-level SSE code have the real sample start on the 0th or 2nd 4 > byte > > float. For example the R / C represents 4 byte floats (Real, Complex) , > 0 > > represents "forced alignment" from gr_fir_ccf_simd.cc > > RCRC... OK > > 00RC... OK > > 0RCR... Not OK > > Hmmm. Does it ever use the 0RCR case? I would expect only the first > two. It may be reusing the fff simd code which generates all 4 > alignments for the taps, but I wouldn't expect to see the 0RCR or 000R > input cases. Yes I do see the 0RCR or R case. For example when I change the QA code to use stack allocation for the input (uncommenting a piece of code that was originally there, lines 110 and 111 in the QA code from trunk) the check will fail. Input is at address 0xbcd87d4 this gets 16-byte aligned to address 0xbfcd87d0 This illustrates the 0RCR case. > Q: Is my assumption of the additional requirement correct? > > > > Q: I don't think it will be easy to force the additional requirement > with > > the same trick used in gr_fir_ccf_simd.cc; do you agree? > > I don't see that this as an additional constraint. > gr_complex == std::complex is always laid out (,). > sizeof(gr_complex) == 8, so with 16-byte alignment, we still always > have good alignment. Are you seeing a case where the input has the > real on a mod 8 == 4 boundary instead of a mod 8 == 0 boundary? yes, see example below. If so, (1) where's the input data coming from, (2) what version of the > compiler are you using? 1) In the example above the data was allocated on the stack from the qa code with *i_type input[INPUT_LEN];//(i_type is gr_complex)* which will case the QA code fail instead of i_type *input = (i_type *)malloc16Align(INPUT_LEN * *sizeof*(i_type)); which is in the QA code, and will make it pass. 2) I am using three different compiles / versions of gcc on two different machines getting the same results gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) gcc (GCC) 4.2.1 (Debian 4.2.1-3) gcc (GCC) 4.1.2.20070502 (Red Hat 4.1.2-12) However, back to your first point, if we are using the 0RCR case, then > the code is completely wrong, and I don't see how it could ever pass > the QA tests (which it seem to). On the other hand, there could be > some problem with how the float taps are mapped across the complex > input (It's been along time since I looked at the code...) The QA tests are passing because they force the 16-byte alignment. Thanks for looking at this! > > Eric > > > Tim > > > > > > > > > > > Yes, it does get called at "make check" time. > > > > > > FWIW, it's run by way of gnuradio-core/src/tests/test_all > > > > > > It's possible that there's an alignment requirement that's not being > > > honored at runtime. The low-level SSE code (fcomplex_dotprod_sse64.S) > > > requires that its input and taps be 16-byte aligned. gr_fir_ccf_simd > > > allocates 16-byte aligned buffers for the relevant buffers, so it > > > should be working OK. Perhaps one of you seeing the problem could > > > add an assert or two to confirm that the alignment is correct. > > > > > > Eric > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
