<frederick.br...@gmail.com> wrote: >On Oct 29, 4:39 pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote: >> Nico Coesel wrote: >> > Vladimir Vassilevsky <nos...@nowhere.com> wrote:
>> >>Les Cargill wrote:
>> >>>No, I gotcha. Audio-oriented DAC/ADC are generally going to support >> >>>20Hz to 20KHz well no matter what, though. Aliasing reall isn't a >> >>>consideration, unless the transform within the GPP in the middle >> >>>somehow causes it.
>> >>Aliasing is a BIG problem if doing non-linear audio effects in digital. >> >>You want the sample rate of 192kHz or even higher.
>> > Depends on the A/D D/A converter. All the codecs (A/D D/A converter in >> > one chip) I encountered so far have decent anti-aliasing filters >> > built-in. Aliasing shouldn't be a problem.
>> It is unrelated to A/D and D/A. If you do a nonlinear function with >> already sampled signal, you will get aliasing.
>> Let's say there is a sine wave at 10kHz, and a 48kHz ADC -> digital >> limiter -> DAC system. At the output, you will get 18kHz, 2kHz, 16kHz >> and so on, so forth.
>> Vladimir Vassilevsky >> DSP and Mixed Signal Design Consultanthttp://www.abvolt.com
>That's just about the picture. The Spin chip has 48kHz converters. >So, it'll be:
>48k ADC > Digital Compression > 48k DAC.
>What I am wondering about is hearing the aliasing. In the early CD >players I could hear it. In low quality digital effects like delay >and reverb I can still hear it.
I am not sure about what you hear (heard), but a lot of early CD players had lousy DACs. Lousy converters could be the problem in the early cheap effects devices. It is a very different sonic effect than aliasing. Then there are/were converters that lost resolution (ENOB) at higher frequencies (like 10 kHz).
JosephKK wrote: > On Sun, 25 Oct 2009 19:46:54 -0700 (PDT), Fred > <frederick.br...@gmail.com> wrote:
>>I was wondering what DSP chip would be appropriate for a guitar pedal >>effect. I need to sample the incoming signal preferably at 96kHz >>perform a simple numeric function upon each sample and output he >>result.
> Could work, just remember that you are always faced with two samples > of delay due to the data converters.
With audio delta sigma DACs and ADCs, you typically have the group delay of 15..20 samples on either side. That makes for the delay up to few hundred microseconds or so, however for audio effects that doesn't matter much as the speed of sound is only 330m/sec.
JosephKK wrote: > On Thu, 29 Oct 2009 15:39:07 -0500, Vladimir Vassilevsky > <nos...@nowhere.com> wrote:
>>>>Aliasing is a BIG problem if doing non-linear audio effects in digital. >>>>You want the sample rate of 192kHz or even higher.
>>>Depends on the A/D D/A converter. All the codecs (A/D D/A converter in >>>one chip) I encountered so far have decent anti-aliasing filters >>>built-in. Aliasing shouldn't be a problem.
>>It is unrelated to A/D and D/A. If you do a nonlinear function with >>already sampled signal, you will get aliasing.
>>Let's say there is a sine wave at 10kHz, and a 48kHz ADC -> digital >>limiter -> DAC system. At the output, you will get 18kHz, 2kHz, 16kHz >>and so on, so forth.
> No, not really.
Huh? Run the numbers.
> Not unless you are saturating the input ADC. If you > do that all bets are off (so to speak).
That has nothing to do with DAC and ADC. Once you do nonlinear functions in digital domain, you get aliasing.
If you apply nonlinear function to a perfect digital sine wave, you will get harmonics. If those harmonics are above Nyquist, they will be aliased down.
>> On Thu, 29 Oct 2009 15:39:07 -0500, Vladimir Vassilevsky >> <nos...@nowhere.com> wrote:
>>>>>Aliasing is a BIG problem if doing non-linear audio effects in digital. >>>>>You want the sample rate of 192kHz or even higher.
>>>>Depends on the A/D D/A converter. All the codecs (A/D D/A converter in >>>>one chip) I encountered so far have decent anti-aliasing filters >>>>built-in. Aliasing shouldn't be a problem.
>>>It is unrelated to A/D and D/A. If you do a nonlinear function with >>>already sampled signal, you will get aliasing.
>>>Let's say there is a sine wave at 10kHz, and a 48kHz ADC -> digital >>>limiter -> DAC system. At the output, you will get 18kHz, 2kHz, 16kHz and >>>so on, so forth.
>> No, not really.
> Huh? > Run the numbers.
>> Not unless you are saturating the input ADC. If you >> do that all bets are off (so to speak).
> That has nothing to do with DAC and ADC. Once you do nonlinear functions > in digital domain, you get aliasing.
> If you apply nonlinear function to a perfect digital sine wave, you will > get harmonics. If those harmonics are above Nyquist, they will be aliased > down.
> Vladimir Vassilevsky > DSP and Mixed Signal Design Consultant > http://www.abvolt.com
The successful ones like Line 6 are believed to increase the sampling rate before applying the non-linear function (i.e. upsample) and then LPF whilst downsampling; see http://www.mitpressjournals.org/doi/pdf/10.1162/comj.2009.33.2.85?coo.... Some (perhaps many) of their effects use ADC/DAC working at about 39 kHz sampling rate and they don't have a reputation for sounding bad.
>> On Thu, 29 Oct 2009 15:39:07 -0500, Vladimir Vassilevsky >> <nos...@nowhere.com> wrote:
>>>>>Aliasing is a BIG problem if doing non-linear audio effects in digital. >>>>>You want the sample rate of 192kHz or even higher.
>>>>Depends on the A/D D/A converter. All the codecs (A/D D/A converter in >>>>one chip) I encountered so far have decent anti-aliasing filters >>>>built-in. Aliasing shouldn't be a problem.
>>>It is unrelated to A/D and D/A. If you do a nonlinear function with >>>already sampled signal, you will get aliasing.
>>>Let's say there is a sine wave at 10kHz, and a 48kHz ADC -> digital >>>limiter -> DAC system. At the output, you will get 18kHz, 2kHz, 16kHz >>>and so on, so forth.
>> No, not really.
>Huh? >Run the numbers.
>> Not unless you are saturating the input ADC. If you >> do that all bets are off (so to speak).
>That has nothing to do with DAC and ADC. Once you do nonlinear functions >in digital domain, you get aliasing.
>If you apply nonlinear function to a perfect digital sine wave, you will >get harmonics. If those harmonics are above Nyquist, they will be >aliased down.
I read some articles about that. It does make me wonder whether you could rewrite the non-linear functions in a way so the harmonics are not created in the first place. This should be more efficient than upsampling -> non-linear function -> filtering -> downsampling.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" --------------------------------------------------------------
Nico Coesel wrote: > Vladimir Vassilevsky <nos...@nowhere.com> wrote:
>>That has nothing to do with DAC and ADC. Once you do nonlinear functions >>in digital domain, you get aliasing.
>>If you apply nonlinear function to a perfect digital sine wave, you will >>get harmonics. If those harmonics are above Nyquist, they will be >>aliased down.
> I read some articles about that. It does make me wonder whether you > could rewrite the non-linear functions in a way so the harmonics are > not created in the first place. This should be more efficient than > upsampling -> non-linear function -> filtering -> downsampling.
It could be done if you can approximate the input by an analytical function. Or approximate the nonlinearity by Volterra Series. Both ways require pretty involved math; brute force oversampling is usually simpler and cheaper.
> Nico Coesel wrote: > > Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> >>That has nothing to do with DAC and ADC. Once you do nonlinear functions > >>in digital domain, you get aliasing.
> >>If you apply nonlinear function to a perfect digital sine wave, you will > >>get harmonics. If those harmonics are above Nyquist, they will be > >>aliased down.
> > I read some articles about that. It does make me wonder whether you > > could rewrite the non-linear functions in a way so the harmonics are > > not created in the first place. This should be more efficient than > > upsampling -> non-linear function -> filtering -> downsampling.
> It could be done if you can approximate the input by an analytical > function. Or approximate the nonlinearity by Volterra Series. Both ways > require pretty involved math; brute force oversampling is usually > simpler and cheaper.
> Vladimir Vassilevsky > DSP and Mixed Signal Design Consultanthttp://www.abvolt.com
I think I'll flesh out the code in C, apply it to some PCM files, then analyze the results first.
Do you think the harmonics from the non-linear function on a digital sample would show up in the processed PCM file or would it have to be converted to analog then analyzed?
The compression itself is going to add harmonics, so how would I be able to separate the ones generated by the compression from the ones generated by applying the non-linear function to a digital signal and the conversion processes?
JosephKK wrote: > Nothing new here, move along. > The grandfathered old poor code already is an issue in the FPGA world. > As if you didn't already know.
Didn't know in fact, but can guess that could be a problem, just as it is with legacy asm and C. Have done very little with fpga's / vhdl as well. Every time I consider one for a project, a fast micro wins by getting the job done at lower cost and timescales...
Fred <frederick.br...@gmail.com> wrote: >On Nov 3, 4:30 pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote: >> Nico Coesel wrote: >> > Vladimir Vassilevsky <nos...@nowhere.com> wrote:
>> >>That has nothing to do with DAC and ADC. Once you do nonlinear functions >> >>in digital domain, you get aliasing.
>> >>If you apply nonlinear function to a perfect digital sine wave, you will >> >>get harmonics. If those harmonics are above Nyquist, they will be >> >>aliased down.
>> > I read some articles about that. It does make me wonder whether you >> > could rewrite the non-linear functions in a way so the harmonics are >> > not created in the first place. This should be more efficient than >> > upsampling -> non-linear function -> filtering -> downsampling.
>> It could be done if you can approximate the input by an analytical >> function. Or approximate the nonlinearity by Volterra Series. Both ways >> require pretty involved math; brute force oversampling is usually >> simpler and cheaper.
>> Vladimir Vassilevsky >> DSP and Mixed Signal Design Consultanthttp://www.abvolt.com
>I think I'll flesh out the code in C, apply it to some PCM files, then >analyze the results first.
>Do you think the harmonics from the non-linear function on a digital >sample would show up in the processed PCM file or would it have to be >converted to analog then analyzed?
It will also be visible in the digital domain. Cooledit is a very good tool for this sort of work.
>The compression itself is going to add harmonics, so how would I be >able to separate the ones generated by the compression from the ones >generated by applying the non-linear function to a digital signal and >the conversion processes?
Try different input frequencies. At frequencies closer to Fmax you'll see more aliasing.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" --------------------------------------------------------------
>>>>That has nothing to do with DAC and ADC. Once you do nonlinear functions >>>>in digital domain, you get aliasing.
>>>>If you apply nonlinear function to a perfect digital sine wave, you will >>>>get harmonics. If those harmonics are above Nyquist, they will be >>>>aliased down.
>>>I read some articles about that. It does make me wonder whether you >>>could rewrite the non-linear functions in a way so the harmonics are >>>not created in the first place. This should be more efficient than >>>upsampling -> non-linear function -> filtering -> downsampling.
>>It could be done if you can approximate the input by an analytical >>function. Or approximate the nonlinearity by Volterra Series. Both ways >>require pretty involved math; brute force oversampling is usually >>simpler and cheaper. > I think I'll flesh out the code in C, apply it to some PCM files, then > analyze the results first.
This makes perfect sense. Before doing anything with a DSP, get the stuff to work on PC with a sound card.
> Do you think the harmonics from the non-linear function on a digital > sample would show up in the processed PCM file or would it have to be > converted to analog then analyzed?
Aliasing is a natural phenomenon. You will see it in digital as well as in analog.
> The compression itself is going to add harmonics, so how would I be > able to separate the ones generated by the compression from the ones > generated by applying the non-linear function to a digital signal and > the conversion processes?
Harmonics are the multiples of the fundamental frequency; aliases are generally not.
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
> 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
That's neat. My math is old and I haven't needed extreme accuracy in the past, but that one goes in the methods logbook to look into further !. I use sin tables for embedded graphics work primarily. Things like object rotation, which needs a new x,y screen address calculated for every pixel within the object. It's very compute intensive and unusably slow using standard library calls. Table methods can allow the use of a much lower performance cpu while still getting adequate performance. Modern micros often have hundred's of k of flash code space, so it makes sense to do the math offline, rather than at runtime. For a 16 bit table, the entries are calculated and scaled so that sin (90) is close to 65535 to maximise accuracy, then scale the range of the system data to suit.
The 'added lines' for cos were just to handle the fact that with a one quadrant table, you need to start reading back from the end of the table for cosine, rather than from the start in the sin case. For graphics, you often need to work in all 4 quadrants, but that can be handled by inversion and reflection on a single quadrant table...
On Wed, 04 Nov 2009 18:31:01 +0000, ChrisQ <m...@devnull.com> wrote: >JosephKK wrote:
>> Nothing new here, move along. >> The grandfathered old poor code already is an issue in the FPGA world. >> As if you didn't already know.
>Didn't know in fact, but can guess that could be a problem, just as it >is with legacy asm and C. Have done very little with fpga's / vhdl as >well. Every time I consider one for a project, a fast micro wins by >getting the job done at lower cost and timescales...
> You must have some pretty trivial problems then.
One design was a legacy (1996) counter driven state machine pwm driver with less than a dozen ttl devices and an eprom. A gate array looked attractive and would have been a good excuse to get into a bit of vhdl, but it was a lower cost solution to use a silabs 8051 micro as a one chip solution and already had the tools from other projects. The other thing was design tools. Yes, you can download demo versions, but you end up with Gbytes of hard disk space. Even using the smallest gate array from Lattice would have been uneconomic compared to the micro solution, and would still have needed the eprom.
So what complex problems are you solving with gate arrays and what speeds ?...
On Thu, 05 Nov 2009 11:04:29 +0000, ChrisQ <m...@devnull.com> wrote: >krw wrote:
>> You must have some pretty trivial problems then.
>One design was a legacy (1996) counter driven state machine pwm driver >with less than a dozen ttl devices and an eprom. A gate array looked >attractive and would have been a good excuse to get into a bit of vhdl, >but it was a lower cost solution to use a silabs 8051 micro as a one >chip solution and already had the tools from other projects.
IOW, pretty trivial stuff. I'd likely use an 8051 for that too (and pass the crap job off to the firmware group ;-).
>The other >thing was design tools. Yes, you can download demo versions, but you end >up with Gbytes of hard disk space.
So what? A 1TB drive is under $100. BTW, they aren't "demo versions". They're fully capable versions, just somewhat limited (usually something like <1M gates and <10KLOC testbenches). I have Xilinx, Altera, and Actel software on my systems. Our disty said he was bringing the Lattice stuff by next week in case the Altera CPLD didn't work out (he gets paid for either). It's good to keep 'em guessing. ;-)
>Even using the smallest gate array >from Lattice would have been uneconomic compared to the micro solution, >and would still have needed the eprom.
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.
>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.
[*] Though it saves something like one-third of the $150 BOM times $5K-$10K, per year. The FPGA/CPLD is only a part of the savings, though.
> 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...
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
On Nov 6, 12:28 pm, ChrisQ <m...@devnull.com> wrote:
> > 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...
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...
> 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.
On Fri, 06 Nov 2009 17:28:03 +0000, ChrisQ <m...@devnull.com> wrote: >krw wrote:
>> 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 :-).
Obviously. ...even when the solution should be in hardware.
>> 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.
Why wouldn't they fit? Xilinx stuff has piles of RAM/ROM/dual-port stuff. The Actel and Altera stuff I'm using is just small enough that there is no block-RAM. I'd like to have it but for this application don't really need it.
>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.
There is no reason all that stuff couldn't be done in hardware.
>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.
C. Ick!
>>> 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...
Spoken like a true software weenie. There is a *tremendous* difference. You really should add another arrow to your quiver.
On Fri, 06 Nov 2009 17:28:03 +0000, ChrisQ <m...@devnull.com> wrote: >krw wrote:
>> 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
Part of the whole idea. The more tools in your toolbox (all reasonably well understood) the more and better tradeoffs you can make between different approaches. But then again i tend to be a specializing generalist.
<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...
<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.
|
