On Thu, 31 Mar 2016 23:16:20 +0300, Evgeny Filatov <e.v.filatov@ieee.org> wrote:>On 31.03.2016 22:25, Eric Jacobsen wrote: >> On Thu, 31 Mar 2016 22:16:37 +0300, Evgeny Filatov >> <e.v.filatov@ieee.org> wrote: >> >>> On 31.03.2016 20:13, Randy Yates wrote: >>> (snip) >>>> Hello Evgeny, >>>> >>>> I have been on comp.dsp since about 1993. It has been a real pleasure >>>> and privilege to hear and learn from folks like you. I can't really >>>> espouse this group enough - it has helped me greatly in my pursuit of >>>> DSP. >>>> >>> >>> I've learned about comp.dsp in early 2010s. I was offered a job I wasn't >>> qualified for; I needed to learn some DSP to do it, so I needed a DSP >>> text. That's how I've purchased a copy of "Understanding Digital Signal >>> Processing" by Lyons and learnt about this group. >>> >>> Evgeny >>> >> >> It's always good to hear the success stories! ;) >> >> >> Eric Jacobsen >> Anchor Hill Communications >> http://www.anchorhill.com >> > >Eric, by the way, after our recent discussion I've attempted to update >my library, and may be you'd like to have a look at these, too: > >1) >http://www.amazon.com/Trellis-Turbo-Coding-Graph-Based-Communication/dp/1118083164/ >2) >http://www.amazon.com/Fundamentals-Convolutional-Coding-Digital-Communication/dp/0470276835/ > >The book by Johannesson and Zigangirov contains a really accessible >description of the BCJR algorithm (okey, perhaps that can be useful for >anyone else). (The text can also be found in the web at some websites. >It's just when a book is useful I try to get a copy.) > >Evgeny >The second one looks like a nice reference, partly because it covers sequential decoding, which many texts skip. I'll stick it in my list for the next time I'm buying books...already got a few too many, though, I think, as I'm running out of space. ;) Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
sigmaDSP and similar devices
Started by ●October 24, 2010
Reply by ●March 31, 20162016-03-31
Reply by ●March 31, 20162016-03-31
On 9/12/2012 10:31 PM, chavez.miguel@gmail.com wrote:> Hi Rick: > > ADI and with the SigmaDSP do have a way for experience assembly code programmers to code their own algorithm. > > Let me know if you want to know more about the capabilities. > > MiguelThanks for the reply. That was some time ago. I'm not sure I even recall the application. lol No, I remember. In fact, there may be a new interest in this in the future as the existing design is becoming obsolete. I would be interested in learning more about this, but if it is such a struggle getting information about using assembly language on these devices, it doesn't seems like something that would be productive. I have a current app that requires extremely low power if these parts can keep up. It is about five times higher sample rate than typical audio work, but not a heavy processing load for each sample. Rick> On Tuesday, October 26, 2010 11:11:18 AM UTC-4, rickman wrote: >> On Oct 26, 2:39 am, emeb <ebromba...@gmail.com> wrote: >>> On Oct 25, 10:13 pm, robert bristow-johnson >>> >>> >>> >>> <r...@audioimagination.com> wrote: >>>> On Oct 25, 11:47 am, emeb <ebromba...@gmail.com> wrote: >>> >>>>> On Oct 24, 10:11 am, rickman <gnu...@gmail.com> wrote: >>> >>>>>> I have been watching the sigmaDSP from ADI and the similar part from >>>>>> TI. These parts seem ideal for a lot of applications but the problem >>>>>> I have is with the tools. They don't let you write your own code. >>>>>> You can only string together modules from their library. They are >>>>>> mostly filters and similar functions and I don't see how to do a lot >>>>>> of very basic stuff that any other processor can do. >>> >>>>>> I've contacted both TI and ADI support and they both say their tools >>>>>> still don't support user written code and I don't see where that is >>>>>> much of an issue with them. Is this because the parts are hard to >>>>>> program or because the parts are limited and they would be hard to use >>>>>> to implement control functions for example. >>> >>>>>> I wrote about this a couple of years ago and someone said I was >>>>>> mistaken and they did support assembly language programming by the >>>>>> user. Anyone know anything about that? Am I asking support the wrong >>>>>> questions? >>> >>>>>> Rick >>> >>>>> Have you looked at the Spin Semiconductor FV-1? >>> >>>>> http://www.spinsemi.com/ >>> >>>> hadn't heard of this chip, nor of the company. >>> >>> Founded by Keith Barr who started Alesis and just passed away a few >>> months back. He did the chip design on the FV-1 apparently. It bears a >>> striking resemblance to some of the older parts from Alesis / >>> Wavefront. >>> >>>>> While aimed primarily at inexpensive audio effects, it does have some >>>>> of the features you've mentioned, and the development environment is >>>>> free. It's an odd beast, with 24-bit precision codec and ALU, 128-step >>>>> stored program, 32k of 'floating point' buffer memory and a 3 channel >>>>> low-speed ADC for user input. >>> >>>> i couldn't find the programmer's reference manual (or whatever they >>>> call it at Spin). the only instructions the data sheet mentions is >>>> LOG and EXP. i usually don't think it's worth much real estate on >>>> silicon to implement log() and exp() at such a low level. i have yet >>>> to use a log() or exp() at full-bandwidth audio (well, maybe for >>>> limiting/compression, i guess i *did* use it once on every sample >>>> without skipping). >>> >>> All the instructions are described here: >>> >>> http://www.spinsemi.com/knowledge_base/inst_syntax.html >>> >>> The instruction set is very different from most DSPs - a lot of common >>> filtering and interpolation functions are compressed down into single >>> instructions. You can implement a 1st-order IIR in two instructions. >>> There's special hardware for doing LFOs that can be accessed sort of >>> like coprocessors. There is a true multiplier, but you can see that >>> it's buried inside more complex processing paths. >>> >>>>> It does have conditional execution >>>>> (skip) as well, and can load programs from an external I2C EEPROM. >>> >>>> does it have "jump" or "branch" instructions that can be conditionally >>>> skipped over? if not, i can't see how to split up the computational >>>> burden of a complex algorithm among many samples to spread the work >>>> out. >>> >>> Looks like all it does is test conditions and skip a preset number of >>> instructions ahead - no skipping back. Processing always starts at >>> location 0 when a new sample is available from the codec. >>> >>> As noted earlier this is not a general-purpose DSP - strictly geared >>> to a specific kind of audio processing. Reverbs, simple delays, >>> filtering, etc., but very concise at doing those tasks. >>> >>> Eric >> >> It also has a monster footprint. My goal is to replace a 6x7 mm CODEC >> with a CODEC/DSP. This part is four times that size. They even call >> it a Reverb IC in the data sheet. >> >> Thanks for all the responses. I think I can bury this one and just >> continue to do the DSP in the FPGA. >> >> Rick >-- Rick
Reply by ●March 31, 20162016-03-31
On 3/31/2016 7:57 AM, BEBSynthesizers wrote:>> Hi Rick: >> >> ADI and with the SigmaDSP do have a way for experience assembly code >> programmers to code their own algorithm. >> >> Let me know if you want to know more about the capabilities. >> >> Miguel >> > > Hi Miguel, > I know this thread is rather old, but I am very interested by your answer. > I have started a thread with a similar topic here : > https://www.dsprelated.com/thread/143/ and your help may be very useful > for that.Lol! You dredged up an old thread and I replied to Miguel thinking *he* had dredged it up. -- Rick
Reply by ●June 29, 20172017-06-29
Waking up an old thread... I have started my own investigations (as explained in this thread https://www.dsprelated.com/thread/143/) and I have created my own assembly tools for the Sigma100. Technically speaking, I have discovered that the Sigma100 is not very different from other DSP, whatever ADI claims. It makes me think a lot about the DSP56000 family, since most instructions fetch two coefficients and feed them into the MAC unit. The biggest difficulty is the lack of jump instructions which are replaced by conditional instructions (for each instruction, you have to describe a condition. If the condition is not met, the processor replaces dynamically the instruction by a NOP) The biggest issue I see with SigmaStudio is the difficulty to optimize the code. I estimate the loss of CPU power between 10% and 20% when compared with "raw assembly" code. BEB --------------------------------------- Posted through http://www.DSPRelated.com
Reply by ●June 29, 20172017-06-29
BEBSynthesizers wrote on 6/29/2017 3:45 AM:> Waking up an old thread... > > I have started my own investigations (as explained in this thread > https://www.dsprelated.com/thread/143/) and I have created my own assembly > tools for the Sigma100. > > Technically speaking, I have discovered that the Sigma100 is not very > different from other DSP, whatever ADI claims. It makes me think a lot > about the DSP56000 family, since most instructions fetch two coefficients > and feed them into the MAC unit. > > The biggest difficulty is the lack of jump instructions which are replaced > by conditional instructions (for each instruction, you have to describe a > condition. If the condition is not met, the processor replaces dynamically > the instruction by a NOP) > > The biggest issue I see with SigmaStudio is the difficulty to optimize the > code. I estimate the loss of CPU power between 10% and 20% when compared > with "raw assembly" code.Talk about conversations that wont' die. This is digging up a year old reply to a three year old reply to a five year old thread that seems to be in response to a seven year old thread. Whew! The bottom line is that my original interest was in suping up a design that used an FPGA and a CODEC by replacing the CODEC with a DSP/CODEC even getting rid of the FPGA if possible. Now the entire design is obsolete and out of production. I seem to recall receiving an email from a tech person about this where they offered to give me access to their assembly tools if I was really interested. By the time all that happened, I was no longer interested because the window of opportunity had passed. That said, if you are looking for help with this project, I might be interested in working with you. How far have you gotten? Do you have the instruction set mapped out? You can email me off list if you prefer. -- Rick C
