Chris Carlen <crcarleRemoveThis@BOGUSsandia.gov> wrote in news:f4p6ur030ro@news2.newsguy.com:> 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.We have a dspblok 21369/FPGA in the works. The dspblok is a subcomponent of our dspstak boards so this extends to these boards as well. The FPGA will be an Altera Cyclone III. Our I/O boards are often driven by customer requests.> > >-- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com
Will ADI ever make DSCs?
Started by ●June 11, 2007
Reply by ●June 13, 20072007-06-13
Reply by ●June 13, 20072007-06-13
Andor <andor.bariska@gmail.com> wrote in news:1181723255.872891.254340@o11g2000prd.googlegroups.com:> 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..... This response is not Andor's original statement, he responded to the original post...... I also take issue with 24 bits is enough for audio. The best audio ADCs and DACs are good to 20-21 bits. Depending on the algorithm, you often need more bits of precision for the actual calculations. A basic rule of thumb is 8 bits more for fixed point than the converters. This typically means 28 bits for highest quality audio. A 32 bit fixed point processor or double precision using a 16 bit processor is often used. This was one of the reasons Motorola (new Freescale) lost so much market share in audio to Analog Devices. The 56K is 24 bits fixed whereas the SHARC is 32 bits fixed and 32/40 bits IEEE float. Motorola used to make the case that for 16 bit audio, you needed 24 bits. This bit them when audio converters improved by 4-5 bits in performance. Another issue where precision is very important in audio is the situation where a high Q filter is needed at low frequency (as compared to Nyquist). The coefficients are almost on the unit circle. Precision and choice of filter structure are very important in this situation. We routinely recommend DFI fixed point structures with either double precision implementation or single precision with 1st order error shaping. This assumption starts with 32 bit fixed point word length and a double wide accumulator. There are lots of papers in the AES journal discussing these issues. Al Clark Danville Signal> > 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 > >-- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com
Reply by ●June 13, 20072007-06-13
dalai lamah wrote: (snip)> I also agree on your point that fixed point is quite enough in a lot of > circumstances. The strong advantage of floating point is that it eases the > development cycle: it allows you to write cleaner and leaner (and easier to > maintain) code, and to avoid a lot of programming errors and pitfalls. And > if you have a FPU, the code will be probably faster too.It avoids some programming pitfalls, and adds even more. -- glen
Reply by ●June 13, 20072007-06-13
steve wrote: (snip)> if the resources are available, why would you ever not want to use > floating point?In cases where you require known rounding, especially in division, fixed point is a much better choice. This is often the case for quantities that have an absolute uncertainty. That is, the uncertainty does not depend on the size of the quantity (relative uncertainty). As GPS coordinates were mentioned, consider ony might measure angles to some fraction of a degree, maybe with five places after the decimal point. Is there a reason why angles near one degree should have a smaller uncertainty than angles near 100 degrees? Financial and typesetting calculations also tend to have an absolute uncertainty (fractions of cents and pixels on a page), and again fixed point is a better choice.> Integer/fixed point math is purely a artifact of resource limited > architectures (driven by cost, size, and power constraints)I disagree. -- glen
Reply by ●June 13, 20072007-06-13
On Jun 13, 5:30 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:> steve wrote: > > (snip) > > > if the resources are available, why would you ever not want to use > > floating point? > > In cases where you require known rounding, especially in division, > fixed point is a much better choice. This is often the case for > quantities that have an absolute uncertainty. That is, the uncertainty > does not depend on the size of the quantity (relative uncertainty). > > As GPS coordinates were mentioned, consider ony might measure > angles to some fraction of a degree, maybe with five places after > the decimal point. Is there a reason why angles near one degree > should have a smaller uncertainty than angles near 100 degrees? >I guess I don't understand, uncertainly for a GPS or INS system at various angles is not just of function of rounding (or resolution in general) but of trigonometric relationships at 0 or 90 degrees (difference between sin of 1 and 2 degrees is different then the difference between sin of 88 and 89 degrees), among other things. Anyway I would use whatever floating point precision was necessary to meet the spec, the inaccuracy would be nonlinear (different for different degrees), but it would be because of many other factors.> Financial and typesetting calculations also tend to have an absolute > uncertainty (fractions of cents and pixels on a page), and again > fixed point is a better choice.isn't the financial problem a base 2 vs base 10 problem, not a fixed vs float problem
Reply by ●June 13, 20072007-06-13
Chris Carlen wrote:> Al Clark wrote: > >> 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.I see Microchip has just added more dsPICs and now have sub $2 ones, with small packages. Also, STm have just added some TQFP48 ARM devices - with 12 bit ADCs, and USB/CAN [but it seems USB and CAN conflict/share pins ?!! ] Expands the choices for a two-chip solution: you can use a higher end RAM.DSP for the grunt, and a small, cheap Flash device for the Peripheral Mix for each project. -jg
Reply by ●June 13, 20072007-06-13
glen herrmannsfeldt wrote:> steve wrote: > (snip) > >> if the resources are available, why would you ever not want to use >> floating point? > > In cases where you require known rounding, especially in division, > fixed point is a much better choice. This is often the case for > quantities that have an absolute uncertainty. That is, the uncertainty > does not depend on the size of the quantity (relative uncertainty). > > As GPS coordinates were mentioned, consider ony might measure > angles to some fraction of a degree, maybe with five places after > the decimal point. Is there a reason why angles near one degree > should have a smaller uncertainty than angles near 100 degrees? > > Financial and typesetting calculations also tend to have an absolute > uncertainty (fractions of cents and pixels on a page), and again > fixed point is a better choice. > >> Integer/fixed point math is purely a artifact of resource limited >> architectures (driven by cost, size, and power constraints) > > I disagree.There are a number of sliding window things which will only work if things falling out of the window have *precisely* the reverse effect they had going in. Floating point will not, in general, ensure that, and these algorithms can wander aimlessly. "Floating point makes life easy" is a very naive attitude, though it works fine in some spheres. Steve
Reply by ●June 13, 20072007-06-13
glen herrmannsfeldt wrote:> steve wrote: > (snip) > >> if the resources are available, why would you ever not want to >> use floating point? > > In cases where you require known rounding, especially in division, > fixed point is a much better choice. This is often the case for > quantities that have an absolute uncertainty. That is, the uncertainty > does not depend on the size of the quantity (relative uncertainty). > > As GPS coordinates were mentioned, consider ony might measure > angles to some fraction of a degree, maybe with five places after > the decimal point. Is there a reason why angles near one degree > should have a smaller uncertainty than angles near 100 degrees?How about: rounded = (100.0 * value + 0.5) / 100; which is accurate to 0.01 over the range. -- <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> <http://www.securityfocus.com/columnists/423> <http://www.aaxnet.com/editor/edit043.html> <http://kadaitcha.cx/vista/dogsbreakfast/index.html> cbfalconer at maineline dot net -- Posted via a free Usenet account from http://www.teranews.com
Reply by ●June 14, 20072007-06-14
steve wrote: ...> isn't the financial problem a base 2 vs base 10 problem, not a fixed > vs float problemNo. An integer is an integer. Changing the representation base doesn't change the number. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by ●June 14, 20072007-06-14
On Jun 13, 11:06 pm, Jerry Avins <j...@ieee.org> wrote:> steve wrote: > > ... > > > isn't the financial problem a base 2 vs base 10 problem, not a fixed > > vs float problem > > No. An integer is an integer. Changing the representation base doesn't > change the number. > > Jerry > -- > Engineering is the art of making what you want from things you can get. > =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF==AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF No, I am referring to binary math (implicit in modern processors) and BCD math (commonly used by calculators) and the methods used to represent the number (for instance strings in BCD). You can have fixed point BCD or floating point BCD, just like you can have fixed point base 2 math and floating point base 2 math. The whole point of BCD is that it is able to represent any decimal number exactly, of course that doesn't eliminate division rounding problems it just changes where they occur. For instance, how do you divide $1 among three people? But that is a real world money problem that has to be resolved in the real world so the BCD model is appropriate for the financial world. My point was this has nothing to do with fixed vs floating point math.
