[casper] fft_wideband_real bug identified and fixed

2015-04-27 Thread Arindam Sengupta



Hi all,

I encountered this issue when I first started to play around with the 
fft_wideband_real from the CASPER library on Xilinx 14.6


The default bit-width initialization for this block is set at 18_17. 
However, when we specify the 'word length' as 14 and 'binary point' as 
13, in the mask parameters dialog it returns the following error:


*/The following error occured with the 
filename/fft_wideband_real/fft_biplex_real_4x/bi_real_unscr_4x/mirror_spectrum/complex_conj0/imag_negate/neg1 
block://

//Illegal parameterization: Binary point//
//Binary point must be less than or equal to number of bits, 14. //
//Binary point is currently set to 17./**
***
The problem was somewhere between 'fft_wideband_real' and 'imag_negate', 
as the error link points. So, I dug down, starting from 
'fft_wideband_real_init',  until 'bus_negate_init', by following the 
functions invoked within each  other. I found out that the variable 
'bin_pt', that carries the value of the binary point we specified in the 
mask parameters, *did not* traverse from 'bi_real_unscr_4x_init' to 
'mirror_spectrum_init'. This resulted in 'mirror_spectrum_init' 
retaining the default 'bin_pt' value of 17. However, as the 'bit_width' 
was correctly transferred as 14, it produced the error above.


I could get the block running by adding the line *'**/bin_pt_in', 
num2str(bin_pt), .../* in the 'bi_real_unscr_4x_init' file (anywhere 
between lines 495-502), in the current mlib_devel (locally), to pass on 
the right value of the user specified 'bin_pt' to the lower layers.


The reason I bring this up is because I noticed that this line is still 
missing in the latest mlib_devel at github, which we are soon going to 
adapt on Xilinx 14.7, and that might cause the bug to show up again. We 
thought it would be a good idea to put this issue out to the CASPER 
community to take a look at, and for the users who currently (might) 
face a similar error message.  If this fix seems reasonable, maybe the  
'bi_real_unscr_4x_init' file can be updated on github with the line 
*'**/bin_pt_in', num2str(bin_pt), ... /*?


Thanks,
Arindam



Re: [casper] Skewed data samples

2015-04-27 Thread Tom Kuiper

On 04/28/2015 04:31 AM, David MacMahon wrote:

Have you calculated the skewness for some largish number of samples or are you 
just going by the appearance of the histogram?  If the latter, are you sure 
that the apparent skewness is not due to artifacts from the histogram bin 
limits vs discrete sample values?

If you swap ADCs, does the same input signal show the same skewness?
Thanks.  The problem is solved and the explanation to embarrassing to 
relate here.  If you offer me a beer...


Cheers

Tom

--
http://www.linkedin.com/pub/tom-kuiper/50/ba5/264




Re: [casper] Skewed data samples

2015-04-27 Thread David MacMahon
Hi, Tom,

Have you calculated the skewness for some largish number of samples or are you 
just going by the appearance of the histogram?  If the latter, are you sure 
that the apparent skewness is not due to artifacts from the histogram bin 
limits vs discrete sample values?

If you swap ADCs, does the same input signal show the same skewness?

Just some ideas,
Dave

On Apr 24, 2015, at 5:38 PM, Kuiper, Thomas (3266) wrote:

 Thanks, Dan.  Yes, we're using KAT ADCs.  I'm not worried about a DC offset 
 and I know about the slight ADC bias.  It's the skewness I'm wondering about. 
  It's just barely detectable by eye in a histogram.
 
 Tom
 
 From: dan.werthi...@gmail.com [dan.werthi...@gmail.com] on behalf of Dan 
 Werthimer [d...@ssl.berkeley.edu]
 Sent: Friday, April 24, 2015 5:34 PM
 To: Kuiper, Thomas (3266)
 Cc: G Jones; Casper Lists
 Subject: Re: [casper] Skewed data samples
 
 hi tom,
 
 if you are using casper adcs:
 
 all the casper adc boards are AC coupled
 (they have baluns and coupling capacitors),
 so  even if your input signal has a DC offset, it won't couple
 into the ADC.   however, there are slight DC offsets in the ADC,
 so there will be a small spike in the DC bin, but probably
 not from the signal your are injecting.
 
 best wishes,
 
 dan