On Thu, 31 Mar 2016 23:16:20 +0300, Evgeny Filatov
>On 31.03.2016 22:25, Eric Jacobsen wrote:
>> On Thu, 31 Mar 2016 22:16:37 +0300, Evgeny Filatov
>> <firstname.lastname@example.org> wrote:
>>> On 31.03.2016 20:13, Randy Yates wrote:
>>>> 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
>>> 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.
>> It's always good to hear the success stories! ;)
>> Eric Jacobsen
>> Anchor Hill Communications
>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:
>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.)
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. ;)
Anchor Hill Communications
Posted by rickman●April 1, 2016
On 9/12/2012 10:31 PM, email@example.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.
Thanks 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
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.
> 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
>>>>> Have you looked at the Spin Semiconductor FV-1?
>>>> 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 /
>>>>> 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:
>>> 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
>>> 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.
>> 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.
Posted by rickman●April 1, 2016
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.
> 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.
Posted by BEBSynthesizers●June 29, 2017
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.
Posted through http://www.DSPRelated.com
Posted by rickman●June 29, 2017
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.
DSP Engineer (Columbia, MD) DSP Engineer will have an intimate understanding of wireless communications, signal processing and the implementation of algorithms efficiently in digital hardware, primarily DSP, CISC, and RISC processors. The engineer will design, debug, and test signal processing algorithms running on a variety of platforms and work with a product development team to help meet customer requirements.