On Wed, 04 Nov 2009 14:16:51 -0600, j...@somewhere.org wrote: >On Wed, 04 Nov 2009 18:10:55 +0000, ChrisQ wrote: >> Fred wrote: >>> I have begun to doubt that the Spin chip will be able to handle all the >>> cordic code in a timely manner.
>> So, use a lookup table. Cordic is iterative and the more accuracy you >> want, the more iterations you need.
>> It's much faster to use a lookup table, a single line of C or assembler >> in the best case: >> u16Sine = u16SineTable [u16Angle];
>> Ok, you need a few more to resolve over the full range for cos, but it's >> still lightspeed in comparison to cordic or other analytical methods,
>Presumably by "a few more" you mean lines of code to implement stuff >like cos x = sin(x+pi/2), sin(pi-x) = sin x, sin x = -sin(x+pi), and >so forth. Thus one can use one quarter-cycle table for both sin and >cos. Also it is straightforward to use a one-term Taylor series so >that a much-smaller table suffices. sin(x+h) ~ sin x + h*cos x and >cos(x+h) ~ cos x - h*sin x with accuracy improving quadratically as >table size increases. With n = 64, 128, 256 and 512 and |h| less >than pi/(2n) the maximum relative error and maximum absolute error >at angles (k*pi)/2^16 for any integer k are like in following table.
> n Max rel err Max abs err > 64 0.000502 0.000301 > 128 0.000125 0.000075 > 256 0.000031 0.000019 > 512 0.000008 0.000005
CORDIC is an acronym, it means COordinate Rotation by Digital Integrating Computer. It was chosen for implementing the transcendental functions on the 8087, 80287 and 80387 for because it was less computational effort for equivalent results. It is actually worthy of study in its own right.
> <frederick.br...@gmail.com> wrote: > >I see the Spin chip is 6 MIPS, at 48kHz sample rate that only allows > >about 125 instruction steps per sample. I was thinking of some thin > >with at least 30 MIPS.
> >I see those Silicon Labs devices run at 50 and 100 MIPS, that would > >allow a higher sampling rate. Other thatn that they seem overly > >capable.
> >I only need 1 ADC input and 1 DAC output, and whatever I/O necessary > >to support table data if used.
> >> > IOW, pretty trivial stuff. I'd likely use an 8051 for that too (and > >> > pass the crap job off to the firmware group ;-).
> >> In my small company, I *am* the firmware group, and think software > >> design far more than hardware these days :-).
> >> > Nonsense. I have two solutions (one Actel FPGA and the other an > >> > Altera CPLD) for another pretty trivial problem, both under $2.50, no > >> > EPROM/flash required.
> >> Not so cheap in the uk in small quantities and more expensive than an > >> silabs 8051. Using a gate array, would still have needed the eprom, as > >> the sine tables wouldn't fit, whereas they just go in code space using > >> an mcu. I get other benefits like self test, an a-d for soft start, > >> voltage regulation, current limiting etc and a serial port for status > >> messaging. There's even a temp sensor on chip !. Makes a far more > >> capable product for a couple of weeks of software effort, which you > >> would need anyway using vhdl.
> >> As an aside and have no commercial interest, the Silicon Labs fast 8051 > >> series are quite amazing. They are typically 50 mips risc cored updates > >> of the 8051 architecture and the dev kits range from ~$100 down, with > >> all the hardware and dev tools. You can get started building and running > >> the simple demos out of the box within 30 minutes or so. I don't really > >> rate the 8051 architecture that highly, but the latest versions do a > >> good job even with everything written in C.
> >> >> So what complex problems are you solving with gate arrays and what > >> >> speeds ?...
> >> > My current "problem" is also pretty trivial[*], yet an FPGA (or CPLD, > >> > not sure which) still makes a lot more sense than yet another micro > >> > and piles more software complexity.
> >> I guess everything's software now, even hardware design, so if there's > >> not much difference in cost, it probably comes down to what you are most > >> familiar with in the end...
> >> Regards,
> >> Chris
> A XO a 22V10 and an EPROM?
I presume you mean a Programmable Logic Array. I'm clueless about them as well as FPGAs. I lack any idea of how the arrays would/could be programmed to do my non-linear transform.
> <frederick.br...@gmail.com> wrote: > >On Nov 6, 2:13 pm, ChrisQ <m...@devnull.com> wrote: > >> Fred wrote: > >> > I see the Spin chip is 6 MIPS, at 48kHz sample rate that only allows > >> > about 125 instruction steps per sample. I was thinking of some thin > >> > with at least 30 MIPS.
> >> > I see those Silicon Labs devices run at 50 and 100 MIPS, that would > >> > allow a higher sampling rate. Other thatn that they seem overly > >> > capable.
> >> > I only need 1 ADC input and 1 DAC output, and whatever I/O necessary > >> > to support table data if used.
> >> > Regards,
> >> > Fred
> >> The si labs stuff is very good for a certain class of project and they > >> are fast, but couldn't say for sure that they would have enough real > >> time capability for audio sampling and processing. They are an 8 bit > >> architecture and any code that requires 16 or 32 bit operations will > >> result in a lot of code. The kits are very low cost though and modelling > >> the application, possibly at a lower data rate and resolution, would > >> provide a lot of insight in terms of what was really needed for the > >> task, especially if you have no previous experience of dsp solutions (I > >> don't, either :-).
> >> Some of the variants have 24 bit adc's which would be more than good > >> anough if the sampling rate is high enough. You could use a timer driven > >> interrupt level state machine to control the adc and to connect the > >> samples to the mainline code processing section. It may very well be > >> possible, but you may need to add an spi 16 bit dac to get the final > >> analog output...
> >> Regards,
> >> Chris
> >Analog and Infineon 16bit devices are looking good, their in the 40-80 > >MIPS range. There's a few PIC that might work too, 32MIPS though.
> >I guess it will take me a while to sort thouugh all the > >canidates... :)
> >***
> >BTW I just realized that I could easily sim the algorhythm with > >behavioral sources in SPICE, so I've been making audio clips and > >running PCM files though that.
> >It's good to see and hear the idea in action, especially since I've > >had it on hold for years now.
> >Regards,
> >Fred
> I don't know how versatile you are, but you could try capturing > several input waveforms, and running them through the algorithms on > your PC and playing them back.
Been doing that. I have a digital multi-track that that I record a guitar part on, then transfer to computer, through a digital to analog back to digital process. It's an old unit, although the results are tolerable.
After I have the wave file on the computer, I use that as input for a voltage source in SPICE and output the processed voltage to another wave file that I can play with a media player to hear.
It's really a trivial process. I could have done this years ago had I realized SPICE's PCM abilities. :)
> On Wed, 04 Nov 2009 14:16:51 -0600, j...@somewhere.org wrote: > >On Wed, 04 Nov 2009 18:10:55 +0000, ChrisQ wrote: > >> Fred wrote: > >>> I have begun to doubt that the Spin chip will be able to handle all the > >>> cordic code in a timely manner.
> >> So, use a lookup table. Cordic is iterative and the more accuracy you > >> want, the more iterations you need.
> >> It's much faster to use a lookup table, a single line of C or assembler > >> in the best case: > >> u16Sine = u16SineTable [u16Angle];
> >> Ok, you need a few more to resolve over the full range for cos, but it's > >> still lightspeed in comparison to cordic or other analytical methods,
> >Presumably by "a few more" you mean lines of code to implement stuff > >like cos x = sin(x+pi/2), sin(pi-x) = sin x, sin x = -sin(x+pi), and > >so forth. Thus one can use one quarter-cycle table for both sin and > >cos. Also it is straightforward to use a one-term Taylor series so > >that a much-smaller table suffices. sin(x+h) ~ sin x + h*cos x and > >cos(x+h) ~ cos x - h*sin x with accuracy improving quadratically as > >table size increases. With n = 64, 128, 256 and 512 and |h| less > >than pi/(2n) the maximum relative error and maximum absolute error > >at angles (k*pi)/2^16 for any integer k are like in following table.
> > n Max rel err Max abs err > > 64 0.000502 0.000301 > > 128 0.000125 0.000075 > > 256 0.000031 0.000019 > > 512 0.000008 0.000005
> CORDIC is an acronym, it means COordinate Rotation by Digital > Integrating Computer. It was chosen for implementing the > transcendental functions on the 8087, 80287 and 80387 for because it > was less computational effort for equivalent results. It is actually > worthy of study in its own right.
I read about that. Seems easy enough. I have to work out how many iterations would be required, how many instruction cycles each iteration would entail, and balance that with the controllers speed and sampling rate. Again easy enough.
First I have to re-verse myself with coding. It's been 5-6 years since I did anything in C, and even then it was only some basic numerical routines, Fibonacci stuff. And for assembler, that was only one class in college, uh, twenty five years ago. :)
That all should keep me from getting bored for a while...
Oh by the way, could you give me an overview of how a logic array could be programed to do this?
<frederick.br...@gmail.com> wrote: >On Nov 8, 2:18 pm, "JosephKK"<quiettechb...@yahoo.com> wrote: >> On Fri, 6 Nov 2009 13:36:41 -0800 (PST), Fred
>> <frederick.br...@gmail.com> wrote: >> >On Nov 6, 2:13 pm, ChrisQ <m...@devnull.com> wrote: >> >> Fred wrote: >> >> > I see the Spin chip is 6 MIPS, at 48kHz sample rate that only allows >> >> > about 125 instruction steps per sample. I was thinking of some thin >> >> > with at least 30 MIPS.
>> >> > I see those Silicon Labs devices run at 50 and 100 MIPS, that would >> >> > allow a higher sampling rate. Other thatn that they seem overly >> >> > capable.
>> >> > I only need 1 ADC input and 1 DAC output, and whatever I/O necessary >> >> > to support table data if used.
>> >> > Regards,
>> >> > Fred
>> >> The si labs stuff is very good for a certain class of project and they >> >> are fast, but couldn't say for sure that they would have enough real >> >> time capability for audio sampling and processing. They are an 8 bit >> >> architecture and any code that requires 16 or 32 bit operations will >> >> result in a lot of code. The kits are very low cost though and modelling >> >> the application, possibly at a lower data rate and resolution, would >> >> provide a lot of insight in terms of what was really needed for the >> >> task, especially if you have no previous experience of dsp solutions (I >> >> don't, either :-).
>> >> Some of the variants have 24 bit adc's which would be more than good >> >> anough if the sampling rate is high enough. You could use a timer driven >> >> interrupt level state machine to control the adc and to connect the >> >> samples to the mainline code processing section. It may very well be >> >> possible, but you may need to add an spi 16 bit dac to get the final >> >> analog output...
>> >> Regards,
>> >> Chris
>> >Analog and Infineon 16bit devices are looking good, their in the 40-80 >> >MIPS range. There's a few PIC that might work too, 32MIPS though.
>> >I guess it will take me a while to sort thouugh all the >> >canidates... :)
>> >***
>> >BTW I just realized that I could easily sim the algorhythm with >> >behavioral sources in SPICE, so I've been making audio clips and >> >running PCM files though that.
>> >It's good to see and hear the idea in action, especially since I've >> >had it on hold for years now.
>> >Regards,
>> >Fred
>> I don't know how versatile you are, but you could try capturing >> several input waveforms, and running them through the algorithms on >> your PC and playing them back.
>Been doing that. I have a digital multi-track that that I record a >guitar part on, then transfer to computer, through a digital to analog >back to digital process. It's an old unit, although the results are >tolerable.
>After I have the wave file on the computer, I use that as input for a >voltage source in SPICE and output the processed voltage to another >wave file that I can play with a media player to hear.
>It's really a trivial process. I could have done this years ago had I >realized SPICE's PCM abilities. :)
Yes. Kazaam. PWL (piece wise linear) sources in SPICE can illuminate many ideas nicely. Also PWL file IO.
<frederick.br...@gmail.com> wrote: >On Nov 8, 2:09 pm, "JosephKK"<quiettechb...@yahoo.com> wrote: >> On Fri, 6 Nov 2009 10:26:46 -0800 (PST), Fred
>> <frederick.br...@gmail.com> wrote: >> >I see the Spin chip is 6 MIPS, at 48kHz sample rate that only allows >> >about 125 instruction steps per sample. I was thinking of some thin >> >with at least 30 MIPS.
>> >I see those Silicon Labs devices run at 50 and 100 MIPS, that would >> >allow a higher sampling rate. Other thatn that they seem overly >> >capable.
>> >I only need 1 ADC input and 1 DAC output, and whatever I/O necessary >> >to support table data if used.
>> >> > IOW, pretty trivial stuff. I'd likely use an 8051 for that too (and >> >> > pass the crap job off to the firmware group ;-).
>> >> In my small company, I *am* the firmware group, and think software >> >> design far more than hardware these days :-).
>> >> > Nonsense. I have two solutions (one Actel FPGA and the other an >> >> > Altera CPLD) for another pretty trivial problem, both under $2.50, no >> >> > EPROM/flash required.
>> >> Not so cheap in the uk in small quantities and more expensive than an >> >> silabs 8051. Using a gate array, would still have needed the eprom, as >> >> the sine tables wouldn't fit, whereas they just go in code space using >> >> an mcu. I get other benefits like self test, an a-d for soft start, >> >> voltage regulation, current limiting etc and a serial port for status >> >> messaging. There's even a temp sensor on chip !. Makes a far more >> >> capable product for a couple of weeks of software effort, which you >> >> would need anyway using vhdl.
>> >> As an aside and have no commercial interest, the Silicon Labs fast 8051 >> >> series are quite amazing. They are typically 50 mips risc cored updates >> >> of the 8051 architecture and the dev kits range from ~$100 down, with >> >> all the hardware and dev tools. You can get started building and running >> >> the simple demos out of the box within 30 minutes or so. I don't really >> >> rate the 8051 architecture that highly, but the latest versions do a >> >> good job even with everything written in C.
>> >> >> So what complex problems are you solving with gate arrays and what >> >> >> speeds ?...
>> >> > My current "problem" is also pretty trivial[*], yet an FPGA (or CPLD, >> >> > not sure which) still makes a lot more sense than yet another micro >> >> > and piles more software complexity.
>> >> I guess everything's software now, even hardware design, so if there's >> >> not much difference in cost, it probably comes down to what you are most >> >> familiar with in the end...
>> >> Regards,
>> >> Chris
>> A XO a 22V10 and an EPROM?
>I presume you mean a Programmable Logic Array. I'm clueless about >them as well as FPGAs. I lack any idea of how the arrays would/could >be programmed to do my non-linear transform.
Actually it can be quite simple: The incoming stream goes into a tiny buffer (about 3 samples), the per sample mapping is looked up from EPROM, the output value is sent to the next thing.
The 22V10 is there control that process.
Yeah, i know that is unclear. But many other topics like state machines get involved quickly and i think trying to discuss them here may distract / bore others here. My real email is in the headers, Robert Baer and a few others have it as well.
<frederick.br...@gmail.com> wrote: >On Nov 8, 6:32 pm, "JosephKK"<quiettechb...@yahoo.com> wrote: >> On Wed, 04 Nov 2009 14:16:51 -0600, j...@somewhere.org wrote: >> >On Wed, 04 Nov 2009 18:10:55 +0000, ChrisQ wrote: >> >> Fred wrote: >> >>> I have begun to doubt that the Spin chip will be able to handle all the >> >>> cordic code in a timely manner.
>> >> So, use a lookup table. Cordic is iterative and the more accuracy you >> >> want, the more iterations you need.
>> >> It's much faster to use a lookup table, a single line of C or assembler >> >> in the best case: >> >> u16Sine = u16SineTable [u16Angle];
>> >> Ok, you need a few more to resolve over the full range for cos, but it's >> >> still lightspeed in comparison to cordic or other analytical methods,
>> >Presumably by "a few more" you mean lines of code to implement stuff >> >like cos x = sin(x+pi/2), sin(pi-x) = sin x, sin x = -sin(x+pi), and >> >so forth. Thus one can use one quarter-cycle table for both sin and >> >cos. Also it is straightforward to use a one-term Taylor series so >> >that a much-smaller table suffices. sin(x+h) ~ sin x + h*cos x and >> >cos(x+h) ~ cos x - h*sin x with accuracy improving quadratically as >> >table size increases. With n = 64, 128, 256 and 512 and |h| less >> >than pi/(2n) the maximum relative error and maximum absolute error >> >at angles (k*pi)/2^16 for any integer k are like in following table.
>> > n Max rel err Max abs err >> > 64 0.000502 0.000301 >> > 128 0.000125 0.000075 >> > 256 0.000031 0.000019 >> > 512 0.000008 0.000005
>> CORDIC is an acronym, it means COordinate Rotation by Digital >> Integrating Computer. It was chosen for implementing the >> transcendental functions on the 8087, 80287 and 80387 for because it >> was less computational effort for equivalent results. It is actually >> worthy of study in its own right.
>I read about that. Seems easy enough. I have to work out how many >iterations would be required, how many instruction cycles each >iteration would entail, and balance that with the controllers speed >and sampling rate. Again easy enough.
>First I have to re-verse myself with coding. It's been 5-6 years >since I did anything in C, and even then it was only some basic >numerical routines, Fibonacci stuff. And for assembler, that was only >one class in college, uh, twenty five years ago. :)
>That all should keep me from getting bored for a while...
>Oh by the way, could you give me an overview of how a logic array >could be programed to do this?
I was figuring on just storing the amplitude conversion data in EPROM. As in a simple state machine.
Implementing the serious math in an FPGA can be faster but seriously more difficult (expensive, i could have to go outside for that).
|
