DSPRelated.com
Forums

C6711: FFT without disabling interrupts

Started by Unknown January 22, 2003
Hi C6x !

I am currently developping an application on a C6711. I wanted to use a FFT
avaliable in the DSPLib but when I had a look to the code, I saw that they
disabled interrupts while computing the interrupt. Even if the algo is
optimized, it takes time to compute the FFT. Because I need to reconfigure
the acquisition frequency at each acquisition (timer interrupt), I need an
algo in which I don't need to disable interrupts. Does anybody have a
solution ?

Regards.

Cric.

************************************************
Cric CHARVET
Alstom T&D R&D Engineer
************************************************ CONFIDENTIALITE : Ce message et les entuelles pies attachs sont
confidentiels. Si vous n'es pas dans la liste des destinataires, veuillez
informer l'expiteur immiatement et ne pas divulguer le contenu une
tierce personne, ne pas l'utiliser pour quelque raison que ce soit, ne pas
stocker ou copier l'information qu'il contient sur un quelconque support.

CONFIDENTIALITY : This e-mail and any attachments are confidential and
may be privileged. If you are not a named recipient, please notify the
sender immediately and do not disclose the contents to another person, use
it for any purpose or store or copy the information in any medium.





Cric,

The C6711 C compiler disables interrupts whenever it produces a pipelined loop,
eg

for(i=0;i<nIter;i++)
{
a[i] = b[i] * c[i];
}

would generate a loop that has interrupts disabled.

You will get terrible performance if you have to disable all code pipelining.
There is a C compiler switch that limits the number of cycles that interrupts
are disabled for.

Andrew E. At 04:16 PM 1/22/2003 +0100, wrote:
>Hi C6x !
>
>I am currently developping an application on a C6711. I wanted to use a FFT
>avaliable in the DSPLib but when I had a look to the code, I saw that they
>disabled interrupts while computing the interrupt. Even if the algo is
>optimized, it takes time to compute the FFT. Because I need to reconfigure
>the acquisition frequency at each acquisition (timer interrupt), I need an
>algo in which I don't need to disable interrupts. Does anybody have a
>solution ?
>
>Regards.
>
>Cric.
>
>************************************************
>Cric CHARVET
>Alstom T&D R&D Engineer
>************************************************
>


Cric-

Only disable interrupts for specific number of cycles, as Andrew suggests.

No one says you have to disable, as long as the FFT is not working on the same
data
being brought in by analog or digital input interrupt, and as long as ISR saves
all
registers being used by FFT.

Jeff Brower
DSP sw/hw engineer
Signalogic wrote:
>
> Hi C6x !
>
> I am currently developping an application on a C6711. I wanted to use a FFT
> avaliable in the DSPLib but when I had a look to the code, I saw that they
> disabled interrupts while computing the interrupt. Even if the algo is
> optimized, it takes time to compute the FFT. Because I need to reconfigure
> the acquisition frequency at each acquisition (timer interrupt), I need an
> algo in which I don't need to disable interrupts. Does anybody have a
> solution ?
>
> Regards.
>
> Cric.
>
> ************************************************
> Cric CHARVET
> Alstom T&D R&D Engineer
> ************************************************




Guys

I think that the FFT in the DSPLib is hand coded assembler (not even
linear assembler). That means you have no chance to change the compiler
options lime -mi to set the un-interruptable time.

We tried to get a linear assebly version from TI and they
couldn't/wouldn't supply it. Hence you have no choice about interrupts
being off.

Sothe only alternative is to code it yourself or get one someone else
coded and _then_ use the -mi options that everyone is suggesting.

I might be wrong though.

Pete Warnes
Technical director
HUNT ENGINEERING (U.K.) Ltd
email
URL http://www.hunteng.co.uk or http://www.hunt-dsp.com
phone +44 (0)1278 760188
direct +44 (0)1278 760966
GSM +44 (0)7711 190099
Fax +44 (0)1278 760199 > -----Original Message-----
> From: Jeff Brower [mailto:]
> Sent: Friday, January 24, 2003 12:58 AM
> To: Cric CHARVET
> Cc:
> Subject: Re: [c6x] C6711: FFT without disabling interrupts > Cdric-
>
> Only disable interrupts for specific number of cycles, as
> Andrew suggests.
>
> No one says you have to disable, as long as the FFT is not
> working on the same data
> being brought in by analog or digital input interrupt, and as
> long as ISR saves all
> registers being used by FFT.
>
> Jeff Brower
> DSP sw/hw engineer
> Signalogic > wrote:
> >
> > Hi C6x !
> >
> > I am currently developping an application on a C6711. I
> wanted to use a FFT
> > avaliable in the DSPLib but when I had a look to the code,
> I saw that they
> > disabled interrupts while computing the interrupt. Even if
> the algo is
> > optimized, it takes time to compute the FFT. Because I need
> to reconfigure
> > the acquisition frequency at each acquisition (timer
> interrupt), I need an
> > algo in which I don't need to disable interrupts. Does
> anybody have a
> > solution ?
> >
> > Regards.
> >
> > Cdric.
> >
> > ************************************************
> > Cdric CHARVET
> > Alstom T&D R&D Engineer
> > ************************************************
>
> _____________________________________
> Note: If you do a simple "reply" with your email client, only
> the author of this message will receive your answer. You
> need to do a "reply all" if you want your answer to be
> distributed to the entire group.
>
> _____________________________________
> About this discussion group:
>
> To Join: Send an email to
>
> To Post: Send an email to
>
> To Leave: Send an email to
>
> Archives: http://www.yahoogroups.com/group/c6x
>
> Other Groups: http://www.dsprelated.com > ">http://docs.yahoo.com/info/terms/






Jeff Brower wrote :
> No one says you have to disable, as long as the FFT is not
> working on the same data

I am sorry to say that you are totally wrong Jeff.

IT IS MANDATORY TO DISABLE INTERRUPT WHEN USING PIPELINNING
(sorry for my shouting)

Because saving registers in the ISR save only current
value of the register and not the content of the pipeline.

That is why CCS compiler insert natively interrupt disable/enable
when optimizing pipelinned loops.
That is why hand optimized code such as the ones provided
in TI's Foundation Software (dsplib/imglib) are also disabling
interrupts.

Lets compile this with -o3 -k -s

void mem_copy( int * restrict pDest, int * restrict pSrc, int count )
{
while ( count-- )
*pDest++ = *pSrc++;
}

You will get the asm file included in the mail.

Line 87 : CCS as inserted interrupt disabling
which are enabled at line 170

Why ?

Check the instruction on line 133
LDW .D1T1 *A4++,A3 ; (P) |6|
Because of pipeline, the loaded will reach the A3 register in 5 cycles
from there. The data could not be stored before the CPU reach store
instruction in line 153.
|| [!A1] STW .D2T2 B5,*B4++ ; |6|

See the lines between line 133 and line 153 : in each
instruction block you will find a LDW to A3.
For exampel in line 137 :
|| LDW .D1T1 *A4++,A3 ; (P) @|6|

The comment on the right says that this load is 1 cycle away
in the pipeline, ie there is already another data being loaded
to the same register in A3.
And this until line 147
|| LDW .D1T1 *A4++,A3 ; (P) @@@@|6|

When the CPU reach line 152, already 5 values are in the pipeline
ready to reach A3.

If an ISR fall in this, the ISR will be able to save the
value of A3 at the time of the PSH instruction but what
will happens to the other values ?

There will be lost.

And the when the CPU come back to the interupted sequence,
the pipeline context will not be the same

==> BROKEN.

I hope this little example is clear and helpfull.

What to do if you still want not to loose interrupts ?

Use -mi<n> option (in Advanced section of compiler options)
This tell CCS to reenable interrupts every <n> cycles.

Check the 2nd included file to see the difference.
This case is much extreme because CCS decide not to
optimize the loop, thus passing from 1 cycle per operation
(without -mi20) to 5 cycles per operation (with -mi20) Best regards, Jean-Michel MERCIER

--
dsp & imaging - www.ateme.com
ATEME - 26 Burospace - 91573 BIEVRES
Tel : +33 (0)1 69 35 89 73 (direct)
Fax : +33 (0)1 60 19 13 95


Attachment (not stored)
mem_copy.asm
Type: application/octet-stream

Attachment (not stored)
mem_copy_with-mi20.asm
Type: application/octet-stream



Jean-Michel,

Great response. Exactly what I was trying to say.

Andrew E.

At 11:26 AM 1/24/2003 +0100, Jean-Michel MERCIER wrote: >Jeff Brower wrote :
>> No one says you have to disable, as long as the FFT is not
>> working on the same data
>
>I am sorry to say that you are totally wrong Jeff.
>
>IT IS MANDATORY TO DISABLE INTERRUPT WHEN USING PIPELINNING
>(sorry for my shouting)
>
>Because saving registers in the ISR save only current
>value of the register and not the content of the pipeline.
>
>That is why CCS compiler insert natively interrupt disable/enable
>when optimizing pipelinned loops.
>That is why hand optimized code such as the ones provided
>in TI's Foundation Software (dsplib/imglib) are also disabling
>interrupts.
>
>Lets compile this with -o3 -k -s
>
>void mem_copy( int * restrict pDest, int * restrict pSrc, int count )
>{
> while ( count-- )
> *pDest++ = *pSrc++;
>}
>
>You will get the asm file included in the mail.
>
>Line 87 : CCS as inserted interrupt disabling
> which are enabled at line 170
>
>Why ?
>
>Check the instruction on line 133
> LDW .D1T1 *A4++,A3 ; (P) |6|
>Because of pipeline, the loaded will reach the A3 register in 5 cycles
>from there. The data could not be stored before the CPU reach store
>instruction in line 153.
>|| [!A1] STW .D2T2 B5,*B4++ ; |6|
>
>See the lines between line 133 and line 153 : in each
>instruction block you will find a LDW to A3.
>For exampel in line 137 :
>|| LDW .D1T1 *A4++,A3 ; (P) @|6|
>
>The comment on the right says that this load is 1 cycle away
>in the pipeline, ie there is already another data being loaded
>to the same register in A3.
>And this until line 147
>|| LDW .D1T1 *A4++,A3 ; (P) @@@@|6|
>
>When the CPU reach line 152, already 5 values are in the pipeline
>ready to reach A3.
>
>If an ISR fall in this, the ISR will be able to save the
>value of A3 at the time of the PSH instruction but what
>will happens to the other values ?
>
>There will be lost.
>
>And the when the CPU come back to the interupted sequence,
>the pipeline context will not be the same
>
>==> BROKEN.
>
>I hope this little example is clear and helpfull.
>
>What to do if you still want not to loose interrupts ?
>
>Use -mi<n> option (in Advanced section of compiler options)
>This tell CCS to reenable interrupts every <n> cycles.
>
>Check the 2nd included file to see the difference.
>This case is much extreme because CCS decide not to
>optimize the loop, thus passing from 1 cycle per operation
>(without -mi20) to 5 cycles per operation (with -mi20) >Best regards, > Jean-Michel MERCIER
>
>--
>dsp & imaging - www.ateme.com
>ATEME - 26 Burospace - 91573 BIEVRES
>Tel : +33 (0)1 69 35 89 73 (direct)
>Fax : +33 (0)1 60 19 13 95
>
>_____________________________________
>Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you want
your answer to be distributed to the entire group.
>
>_____________________________________
>About this discussion group:
>
>To Join: Send an email to
>
>To Post: Send an email to
>
>To Leave: Send an email to
>
>Archives: http://www.yahoogroups.com/group/c6x
>
>Other Groups: http://www.dsprelated.com >">http://docs.yahoo.com/info/terms/


Jean-Michel MERCIER-

I just meant control the number of cycles to disable, either via CCS, or by
hand, as
Andrew indicated. Clearly if you disable for the length of the total FFT
routine,
you can miss samples when performing high rate analog I/O and depending on
buffer
size, which would not be a good thing since the whole idea of an FFT is based on
linear, period sampling.

Jeff Brower
DSP sw/hw engineer
Signalogic > Jeff Brower wrote :
> > No one says you have to disable, as long as the FFT is not
> > working on the same data
>
> I am sorry to say that you are totally wrong Jeff.
>
> IT IS MANDATORY TO DISABLE INTERRUPT WHEN USING PIPELINNING
> (sorry for my shouting)
>
> Because saving registers in the ISR save only current
> value of the register and not the content of the pipeline.
>
> That is why CCS compiler insert natively interrupt disable/enable
> when optimizing pipelinned loops.
> That is why hand optimized code such as the ones provided
> in TI's Foundation Software (dsplib/imglib) are also disabling
> interrupts.
>
> Lets compile this with -o3 -k -s
>
> void mem_copy( int * restrict pDest, int * restrict pSrc, int count )
> {
> while ( count-- )
> *pDest++ = *pSrc++;
> }
>
> You will get the asm file included in the mail.
>
> Line 87 : CCS as inserted interrupt disabling
> which are enabled at line 170
>
> Why ?
>
> Check the instruction on line 133
> LDW .D1T1 *A4++,A3 ; (P) |6|
> Because of pipeline, the loaded will reach the A3 register in 5 cycles
> from there. The data could not be stored before the CPU reach store
> instruction in line 153.
> || [!A1] STW .D2T2 B5,*B4++ ; |6|
>
> See the lines between line 133 and line 153 : in each
> instruction block you will find a LDW to A3.
> For exampel in line 137 :
> || LDW .D1T1 *A4++,A3 ; (P) @|6|
>
> The comment on the right says that this load is 1 cycle away
> in the pipeline, ie there is already another data being loaded
> to the same register in A3.
> And this until line 147
> || LDW .D1T1 *A4++,A3 ; (P) @@@@|6|
>
> When the CPU reach line 152, already 5 values are in the pipeline
> ready to reach A3.
>
> If an ISR fall in this, the ISR will be able to save the
> value of A3 at the time of the PSH instruction but what
> will happens to the other values ?
>
> There will be lost.
>
> And the when the CPU come back to the interupted sequence,
> the pipeline context will not be the same
>
> ==> BROKEN.
>
> I hope this little example is clear and helpfull.
>
> What to do if you still want not to loose interrupts ?
>
> Use -mi<n> option (in Advanced section of compiler options)
> This tell CCS to reenable interrupts every <n> cycles.
>
> Check the 2nd included file to see the difference.
> This case is much extreme because CCS decide not to
> optimize the loop, thus passing from 1 cycle per operation
> (without -mi20) to 5 cycles per operation (with -mi20)
>
> Best regards,
>
> Jean-Michel MERCIER
>
> --
> dsp & imaging - www.ateme.com
> ATEME - 26 Burospace - 91573 BIEVRES
> Tel : +33 (0)1 69 35 89 73 (direct)
> Fax : +33 (0)1 60 19 13 95





Jeff wrote :
> I just meant control the number of cycles to disable, either via
> CCS, or by hand, as
> Andrew indicated. Clearly if you disable for the length of the
> total FFT routine,
> you can miss samples when performing high rate analog I/O and
> depending on buffer
> size, which would not be a good thing since the whole idea of an
> FFT is based on
> linear, period sampling.

It is not a problem of loosing sample interrupts.

It is a problem that if you get an interrupt
while in optimzed pipelined code, you will
break the pipeline context whatever you
will try to save in the ISR.

If you have a code such as :

LDW xxx, A1
some instruction
some instruction
some instruction
some instruction
ADD A1, A2

This code MUST be interrupt-protected.
If any interrupt come between the LDW and the ADD,
the data that have started its journey in the
pipeline will be lost because the ISR will
not be able to save the content of the pipeline,
but only what have already reached register content.

That is why CCS compiler introduce som many NOPs
This code should be written as :

LDW xxx, A1
NOP 4
ADD A1, A2

because "NOP n" is not interruptable !

Best regards, Jean-Michel MERCIER

--
dsp & imaging - www.ateme.com
ATEME - 26 Burospace - 91573 BIEVRES
Tel : +33 (0)1 69 35 89 73 (direct)
Fax : +33 (0)1 60 19 13 95


Jean-Michel MERCIER-

> It is not a problem of loosing sample interrupts.

It is if you leave interrupts disabled too long -- that's my main point, and I
think
it's important that anyone learning DSP knows that if you miss analog input
samples
by paying too much attention to optimizing code, the game is over.

Maintaining real-time operation with analog or digital I/O at the same time as
code
optimization, piplelining, linear assembly, etc. is a real-world trade-off that
must
be dealt with in most systems.

Jeff Brower
DSP sw/hw engineer
Signalogic > It is a problem that if you get an interrupt
> while in optimzed pipelined code, you will
> break the pipeline context whatever you
> will try to save in the ISR.
>
> If you have a code such as :
>
> LDW xxx, A1
> some instruction
> some instruction
> some instruction
> some instruction
> ADD A1, A2
>
> This code MUST be interrupt-protected.
> If any interrupt come between the LDW and the ADD,
> the data that have started its journey in the
> pipeline will be lost because the ISR will
> not be able to save the content of the pipeline,
> but only what have already reached register content.
>
> That is why CCS compiler introduce som many NOPs
> This code should be written as :
>
> LDW xxx, A1
> NOP 4
> ADD A1, A2
>
> because "NOP n" is not interruptable !
>
> Best regards,
>
> Jean-Michel MERCIER
>
> --
> dsp & imaging - www.ateme.com
> ATEME - 26 Burospace - 91573 BIEVRES
> Tel : +33 (0)1 69 35 89 73 (direct)
> Fax : +33 (0)1 60 19 13 95



Hello is this thing on?

I have to agree with everything that Jeff says, Real time issues are
vital -- something that TI don't care about when making benchmarks.

I still think you are ignoring the fact that you have NO control over
what a function written in hand coded assembler does. It is already
compiled and has interrupts OFF -- no choices.

This is why the TI functions are not useful in real life.

Pete Warnes
Technical director
HUNT ENGINEERING (U.K.) Ltd
email
URL http://www.hunteng.co.uk or http://www.hunt-dsp.com
phone +44 (0)1278 760188
direct +44 (0)1278 760966
GSM +44 (0)7711 190099
Fax +44 (0)1278 760199

> -----Original Message-----
> From: Jeff Brower [mailto:]
> Sent: Friday, January 24, 2003 5:49 PM
> To: Jean-Michel MERCIER
> Cc:
> Subject: Re: [c6x] C6711: FFT without disabling interrupts > Jean-Michel MERCIER-
>
> > It is not a problem of loosing sample interrupts.
>
> It is if you leave interrupts disabled too long -- that's my
> main point, and I think
> it's important that anyone learning DSP knows that if you
> miss analog input samples
> by paying too much attention to optimizing code, the game is over.
>
> Maintaining real-time operation with analog or digital I/O at
> the same time as code
> optimization, piplelining, linear assembly, etc. is a
> real-world trade-off that must
> be dealt with in most systems.
>
> Jeff Brower
> DSP sw/hw engineer
> Signalogic > > It is a problem that if you get an interrupt
> > while in optimzed pipelined code, you will
> > break the pipeline context whatever you
> > will try to save in the ISR.
> >
> > If you have a code such as :
> >
> > LDW xxx, A1
> > some instruction
> > some instruction
> > some instruction
> > some instruction
> > ADD A1, A2
> >
> > This code MUST be interrupt-protected.
> > If any interrupt come between the LDW and the ADD,
> > the data that have started its journey in the
> > pipeline will be lost because the ISR will
> > not be able to save the content of the pipeline,
> > but only what have already reached register content.
> >
> > That is why CCS compiler introduce som many NOPs
> > This code should be written as :
> >
> > LDW xxx, A1
> > NOP 4
> > ADD A1, A2
> >
> > because "NOP n" is not interruptable !
> >
> > Best regards,
> >
> > Jean-Michel MERCIER
> >
> > --
> > dsp & imaging - www.ateme.com
> > ATEME - 26 Burospace - 91573 BIEVRES
> > Tel : +33 (0)1 69 35 89 73 (direct)
> > Fax : +33 (0)1 60 19 13 95
>
> _____________________________________
> Note: If you do a simple "reply" with your email client, only
> the author of this message will receive your answer. You
> need to do a "reply all" if you want your answer to be
> distributed to the entire group.
>
> _____________________________________
> About this discussion group:
>
> To Join: Send an email to
>
> To Post: Send an email to
>
> To Leave: Send an email to
>
> Archives: http://www.yahoogroups.com/group/c6x
>
> Other Groups: http://www.dsprelated.com > ">http://docs.yahoo.com/info/terms/