DSPRelated.com
Forums

Will ADI ever make DSCs?

Started by Chris Carlen June 11, 2007
steve wrote:
> On Jun 12, 4:16 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > >> To me, a better question is why you want floating point at all? > > if the resources are available, why would you ever not want to use > floating point? > > Integer/fixed point math is purely a artifact of resource limited > architectures (driven by cost, size, and power constraints)
One of those resources is word width. Fixed point gives more resolution (and less range) for the same number of bits. Jerry -- Engineering is the art of making what you want from things you can get. &macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;
On Tue, 12 Jun 2007 13:21:25 -0700, steve <bungalow_steve@yahoo.com>
wrote:

>On Jun 12, 4:16 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > >> To me, a better question is why you want floating point at all? > >if the resources are available, why would you ever not want to use >floating point? > >Integer/fixed point math is purely a artifact of resource limited >architectures (driven by cost, size, and power constraints)
Floating point is just a artifact due to resource limited architectures, you could as well use 128.128 bit fixed point values instead of ordinary floats :-). Paul
On 12 Jun., 22:16, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> > I wondered about doubles on DSPs in the past, then got the impression > > that for DSP, single precision was all that was usually needed. AFter > > all, it's not for building PCs, it's for signals. I would like to learn > > more about this though. No expert here, just watching, tinkering, and > > learning. > > For audio and video signals, 24 bits is more than enough. 16 bits for > audio is something around 100dB signal/quantization noise, better > than the background noise for most rooms. Video needs even less.
The phrase "For audio ... 24bits is more than enough" is too simple to be meaningful statement. 24bits for what? Signal representation? Register width? Accumulator width? Memory bus width? In general, a 1 bit two operator NAND gate is enough to do _any_ processing (audio, video, scientific, cryptographic, astronomic, ...). This is because the NAND gate is a universal computing element. So in the spirit of the above paragraph, "For audio, 1 bit is more than enough". Regards, Andor
Un bel giorno Chris Carlen digit&#4294967295;:

>> We spoke about this some time ago. If you test the performances of 32-bit >> integer operations against 32-bit "soft float" operations on a TMS320F28xx >> processor, you won't find much difference (at least not the orders of >> magnitude that you could expect). > > Really!?!? Perhaps you are talking about the "IQ math" library > operations rather than the floating point calls in the C rts lib? The > true IEEE-754 calls are tens if not hundreds of instructions long. > Certainly they must perform at 1-2 orders of magnitude less speed than > 1-cycle integer ops.
I've found the thread: http://groups.google.com/group/comp.arch.embedded/browse_frm/thread/3036f9cdf5e7bce/3fb0ed7537c84885?lnk=st&q=&rnum=1#3fb0ed7537c84885 The test wasn't meant to be very representative, but it gives an idea of the 'worst case': with divisions involved, there was barely a factor 4 between fixed and float 32-bit operations. -- emboliaschizoide.splinder.com
On Jun 12, 10:30 pm, Steve Underwood <ste...@dis.org> wrote:
> steve wrote: > > On Jun 12, 8:03 pm, Steve Underwood <ste...@dis.org> wrote: > >> steve wrote: > >>> On Jun 12, 4:16 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > >>>> To me, a better question is why you want floating point at all? > >>> if the resources are available, why would you ever not want to use > >>> floating point? > >>> Integer/fixed point math is purely a artifact of resource limited > >>> architectures (driven by cost, size, and power constraints) > >> You mean its a well engineered solution? :-) > > >> Steve > > > Don't know, I would need to see the recurring vs non recurring costs, > > choosing a fix point processor for a million lines of code task on a > > 20 units/year production schedule is not a well engineered solution > > True, but its a pretty lousy market for DSP chips, too. :-) The buyers > of serious numbers are mostly doing portable consumer things, and RE, > size and power tend to matter more than NRE. There are quite a few low > volume specialist things were power matters above all else, too. > > It amazes me there is enough volume in floating DSPs to justify the > number that exist. They are certainly the way to go for most industrial > and other applications where NRE is critical, but how much does that add > up to?
Well we produce products in the 100's to 1000/year (that have DSP's), we would never even consider a fixed point DSP due to the high NRE. We have a product line of maybe 50, so that's around 20,000 floating point DSP's /year. I suspect there are a lot of low volume producers out in the market like us that keeps the volume of floating point DSP's reasonable. The portable consumer producers, true they buy fixed point DSP's in the 10's of millions, but there isn't many of them. It's still a 20 to 1 ratio of fixed point to float sales, from what I remember.

dalai lamah wrote:


>>>We spoke about this some time ago. If you test the performances of 32-bit >>>integer operations against 32-bit "soft float" operations on a TMS320F28xx >>>processor, you won't find much difference (at least not the orders of >>>magnitude that you could expect).
According to my measurements, on the 16bit CPU with the hardware multiplication, the single precision IEEE-754 float is somewhat 20 times slower then the same math in the integer. Of course, it depends; however this estimate is good enough to check the feasibility of the floating point implementation. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com

Andor wrote:


> In general, a 1 bit two operator NAND gate is enough to do _any_ > processing (audio, video, scientific, cryptographic, astronomic, ...).
:)))
> This is because the NAND gate is a universal computing element.
NOR gate will do it as well. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Andor wrote:

   ...

> In general, a 1 bit two operator NAND gate is enough to do _any_ > processing (audio, video, scientific, cryptographic, astronomic, ...). > This is because the NAND gate is a universal computing element. So in > the spirit of the above paragraph, "For audio, 1 bit is more than > enough".
More? How much more? :-) Jerry -- Engineering is the art of making what you want from things you can get. &macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;
On 13 Jun., 16:13, Jerry Avins <j...@ieee.org> wrote:
> Andor wrote: > > ... > > > In general, a 1 bit two operator NAND gate is enough to do _any_ > > processing (audio, video, scientific, cryptographic, astronomic, ...). > > This is because the NAND gate is a universal computing element. So in > > the spirit of the above paragraph, "For audio, 1 bit is more than > > enough". > > More? How much more? :-)
Admittedly, not much. :-)
Al Clark wrote:
> Chris Carlen <crcarleRemoveThis@BOGUSsandia.gov> wrote in > news:f4n31302uss@news5.newsguy.com: [edit] >>Summary: >> >>uC = standalone capable thus contains *both* internal nonvolatile >>program memory and integrated IO peripherals. >> >>uP = not standalone capable. Lack of either internal nonvolatile >>program memory or integrated IO peripherals, or both. >> >>DSP = uP with special DSP instructions and capabilities. >> >>DSC = uC with special DSP instructions and capabilities. > > So, if I understand your definition correctly, the only feature that a > SHARC like the ADSP-21369 lacks is an internal boot ROM to make it a > "DSC". > > The ADSP-21369 certainly acts more like a DSP uC than uP. It includes two > SPI ports, I2C, 8 SPORTs, 2 UARTs, an SDRAM controller, timers, etc..... > > Once the ADSP-21369 boots (from a 8 pin serial flash), it runs completely > standalone using its internal memory. > > Sure the dsPIC includes internal flash. It also has about 1/2 the > performance of DSPs, I used 10-15 years ago (ADSP-2105 for example).
Hmm. ADSP-21369 is certainly appealing, and will probably be high on my radar screen for something needing the power. We have a TMS320C6711 board here from another vendor, which was quite costly and has much more complexity than needed. But we needed its 16 SAR ADC and DAC channels. What causes a lot of trouble with off the shelf SBCs is that "how they did it" never quite agrees with "how we want it to work." Perhaps you could consider implementing something akin to the event manager peripherals of the TI motion control DSCs on an FPGA (with user programmable resources left available as well) combined with the 21369. That would be killer. Even let the user license and modify the FPGA source, or be real open to tweaking the peripheral architecture to suit customer needs. That would provide the thing which keeps me drawn to the F28xxx, the four additional timers and all the compare/capture/PWM/QEP capability. As for the dsPICs, they obviously have a market which is why they exist. It's not all about performance. -- Good day! ________________________________________ Christopher R. Carlen Principal Laser&Electronics Technologist Sandia National Laboratories CA USA crcarleRemoveThis@BOGUSsandia.gov NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.