[Dspforum] Lab 5 Question
doug wenstrand
dougwen at gmail.com
Tue Oct 13 12:51:26 MDT 2009
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://echelonembedded.com/pipermail/dspforum_echelonembedded.com/attachments/20091013/e1a138d5/attachment.html>
More information about the Dspforum
mailing list