[Dspforum] Lab 5 Question

Tue Oct 13 14:37:44 MDT 2009

Thanks, that helps.  I was thinking of time domain and freq domain
interpolation using the FFT.  I think I must have been getting tired....
For this answer though:

*"adding a bunch of 0 taps will make no difference right? (are you thinking
of the FFT?) 0-weights simply can't contribute to the convolution sum, since
you are just multiplying by 0, and adding to the sum.  Testing your existing
filter with a bunch of zeros is ok -- you won't get the great filter
performance, but it will give you an idea of how fast your filter can go.
to do this, I'd just make a loop in your code itself that initializes some
of the weights to 0 if thats what you want."*

I was using an equiripple filter like in lab 3 but with an order of 1023 and
it keeps on giving me errors.  I tried a kaiser window but couldn't get the
40dB attenuation at 1000Hz past the passpand on either ends of the frequency
spectrum.  Any advice?

~Alan

On Tue, Oct 13, 2009 at 2:51 PM, doug wenstrand <dougwen at gmail.com> wrote:

> I'll CC this to the forum also, as I'm sure others will benefit
>
>  On Tue, Oct 13, 2009 at 10:51 AM, Alan Ding <alan33d at gmail.com> wrote:
>
>> Thanks Doug.  I tried making a 1023 order filter that matched our specs in
>> the fdatool and I was having issues.  Instead, I tried to  increase the
>> frequency resolution (not accuracy) of the filtered output by zero-padding
>> the filter.  Is there an easy way to get this output?  I'd rather not copy
>> and paste ~900 zeros.
>>
>
> adding a bunch of 0 taps will make no difference right? (are you thinking
> of the FFT?) 0-weights simply can't contribute to the convolution sum, since
> you are just multiplying by 0, and adding to the sum.  Testing your existing
> filter with a bunch of zeros is ok -- you won't get the great filter
> performance, but it will give you an idea of how fast your filter can go.
> to do this, I'd just make a loop in your code itself that initializes some
> of the weights to 0 if thats what you want.
>
>
>>
>> What is the difference between what -s, -on2 -o3 provides me and what -os
>> provides?  (I couldn't find any literature on the -os option)  I also could
>> not get the consultant to work, I followed the direction step by step in the
>> SPRAA1.pdf mp3 decoder example but I think the profile viewer does not
>> like our target (I get some red markings regarding using a 62XX simulator
>> instead on the profile window in the bottom left corner of the IDE).  I will
>> take your advice and give up on this one.
>>
>>
>
> Yes, please do give up on the consultant.
> as far as the compiler options:
> -os : interlists optimizer comments with assembly statements
> -on2 : produces a verbose optimization info file
> -ss : interlists C source and assembly statements
>
> If you want a more complete list of all the choices, its in the "optimizing
> compiler user's guide", which you should be able to get through "help"->User
> Manuals
> (or google spru187)
>
>
>> Regarding my timing, I do not see any loop advice on the DSPLIB function
>> as expected.  Although the .asm file also states that it is using a
>> pessimistic approach on pointer variables since it doesn't know if they
>> overlap.  Do I have to restrict the var inputs for the sp_dotprod()
>> function?  I've already done the DATA_ALIGN with pretty good results
>> (~0.000000492 sec for 64 taps).  My overall processing loop is 0.000001333
>> sec for 64 taps which doesn't seem that great compared to what it takes just
>> to do the filtering.
>>
>>
>
> the DSPLIB function is already optimized, you aren't going to improve that
> -- it is already written in hand assembly, and the compiler is not doing
> anything with it (save calling it).  Thats why it won't generate any
> comments.  I'm not sure exactly what you mean by restricting the var inputs
> for the function, your vectors should by very nature not overlap, so it
> shouldn't be an issue.  Again, the DSPLIB function isn't going to get faster
> if you restrict its inputs -- any restrictions are already built in by the
> writer of the DSPLIB function when he wrote it.  For instance, it does
> require that arguments to it be aligned on a double-word boundary.
>
>
>> There are a couple of things I would like to try.  First of all, I want to
>> try to change my index variables for the phase step and input array index to
>> signed values instead of using unsigned values that wrap around.   I was
>> curious why this might buy me some additional optimization?   And just to
>> make sure...your solution from lab3 isn't supposed to be what we did for lab
>> 3 correct?  (I didn't see a float cast on the input or the use of double
>> buffering)  I was looking at it to get ideas on how to speed up my floating
>> point DDS...etc.
>>
>>
>
> Lab3 : double buffering was not required, I just asked you to do a circular
> buffer, and not shift data around.  The double circular buffer is a way to
> make it go even faster, that you would use in lab4.  It was ok to use it in
> lab3 as well, but I didn't
>
> I don't have that solution in front of me, but if I read in data and assign
> it to a floating point variable, the promotion is done automatically.  so
> there might not have been an explicit float cast, but my computation was all
> done in floating point math
>
> Don't look at my DDS from that lab though!  That is a floating point DDS,
> and was slow (I think I even wrote it in the comment)  If you want to have a
>  fast DDS, look at the solution for the DDS lab.  The fixed point DDS can be
> used much like the fixed point data from the CODEC (cast to a float when you
> want to use it) That said, I think you should stop for a second before
> trying to optimize your DDS.  You have 20.8 us for each sample.  You
> shouldn't start spending your time on a portion of the program that takes
>  less than 1us?? (1.3us-..4us from your data above)
>
>
>
>> Thanks,
>>
>> Alan
>>
>>
>>
>> On Tue, Oct 13, 2009 at 9:56 AM, Wenstrand, Doug S. <
>> Douglas.Wenstrand at jhuapl.edu> wrote:
>>
>>> Alan,
>>>
>>> "Use compiler comments, LEDs, or timer code to estimate what you think is
>>> the maximal length
>>> filter that you can implement using this method, and design that filter
>>> (e.g. in FDAtool.)"
>>>
>>> All that was meant by this is that you should use whatever means
>>> necessary to determine how fast you think you can run, and hence what the
>>> maximal length filter you want to try is.  You could use anything you think
>>> is convenient : the comments from the compiler in the ASM which tell you
>>> what the "ii" is for your convolution loop, hooking an LED to the scope, or
>>> using the on-chip hardware timer.  All three can be used to determine
>>> execution time of a section of code, which would give you the data you need.
>>>
>>>
>>> Doug
>>>
>>>
>>> -----Original Message-----
>>> From: dspforum-bounces at echelonembedded.com [mailto:
>>> dspforum-bounces at echelonembedded.com] On Behalf Of Alan Ding
>>> Sent: Monday, October 12, 2009 10:44 PM
>>> To: dspforum at echelonembedded.com
>>> Subject: Re: [Dspforum] Lab 5 Question
>>>
>>> Never mind, I should have realized the "mystery" numbers meant obtainable
>>> points for the problem.  Although, I was wondering if we are allowed to do
>>> anything and everything from the readings (including optimizations -o flags
>>> and disabling sym debug) for both parts of the lab.
>>>
>>> > The instructions also mentioned including compiler comments.  Are those
>>> > found in the .asm file?  Or just what's printed from compiler
>>> consultant?
>>>
>>> Thanks,
>>>
>>> Alan
>>>
>>> ----- Original Message -----
>>> From: Alan Ding <alan33d at gmail.com>
>>> Date: Monday, October 12, 2009 5:24 pm
>>> Subject: [Dspforum] Lab 5 Question
>>> To: dspforum at echelonembedded.com
>>>
>>>
>>> > >= 1024 taps = 25, >= 800 taps = 20, >= 512 taps = 15, <512 taps = 12
>>> >
>>> > Sample rate not preserved : 0
>>> >
>>> > What do the requirements above mean (from Lab 5)?    Are the numbers
>>> after
>>> > the taps in microseconds?  If that's the case, wouldn't the first
>>> > requirement (25) fail to meet our 48kHz deadline?  I was also unsure
>>> what
>>> > "sample rate not preserved: 0" means.
>>> >
>>> > The instructions also mentioned including compiler comments.  Are those
>>> > found in the .asm file?  Or just what's printed from compiler
>>> consultant?
>>> >
>>> > Thanks,
>>> >
>>> > --
>>> > -------------------------------------------------------
>>> > Alan Ding
>>> > Master of Sci, Electrical Engineering
>>> > Johns Hopkins University
>>> >
>>> > Email: alan33d at gmail.com
>>> > Contact #: 4844593290
>>> > _______________________________________________
>>> > Dspforum mailing list
>>> > Dspforum at echelonembedded.com
>>> >
>>>
>>> _______________________________________________
>>> Dspforum mailing list
>>> Dspforum at echelonembedded.com
>>> http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com
>>>
>>> _______________________________________________
>>> Dspforum mailing list
>>> Dspforum at echelonembedded.com
>>> http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com
>>>
>>
>>
>>
>> --
>>  -------------------------------------------------------
>> Alan Ding
>> Master of Sci, Electrical Engineering
>> Johns Hopkins University
>>
>> Email: alan33d at gmail.com
>> Contact #: 4844593290
>>
>
>

-- 
-------------------------------------------------------
Alan Ding
Master of Sci, Electrical Engineering
Johns Hopkins University

Email: alan33d at gmail.com
Contact #: 4844593290
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://echelonembedded.com/pipermail/dspforum_echelonembedded.com/attachments/20091013/15c68a92/attachment-0001.html>