Hi, I have a custom designed board which is based on an ADSP2187L dsp, with a 512KB FLASH, a 128KB SRAM (20 ns cycle) and an FPGA running at 50 MHz. The dsp task is mainly processing commands and data from external links (space-wire) on a 200~500 us cycle. Since the actual software has been written in assembler and there are some concerns about its reliability, I was wondering whether it is worth while considering the possibility to move to a higher language like C, in order to gain in maintainability and readability without loosing too much on performances. Thanks. -- Alessandro Basili CERN, PH/UGC Electronic Engineer
adsp2187L: assembler or C? [cross-post]
Started by ●November 4, 2010
Reply by ●November 4, 20102010-11-04
Alessandro Basili wrote:> Hi, > I have a custom designed board which is based on an ADSP2187L dsp, with > a 512KB FLASH, a 128KB SRAM (20 ns cycle) and an FPGA running at 50 MHz.ADSP218x is a dinosaur with the address space of 16K words; what is all that external memory for? This DSP is inconvenient for C programming as it doesn't support stack frames and base-index addressing.> The dsp task is mainly processing commands and data from external links > (space-wire) on a 200~500 us cycle. > Since the actual software has been written in assembler and there are > some concerns about its reliability, I was wondering whether it is worth > while considering the possibility to move to a higher language like C, > in order to gain in maintainability and readability without loosing too > much on performances.Yes, you can program ADSP218x in C; VDSP toolset recommended. Yes, there will be significant overhead. It is impossible to tell if there is enough of speed without actually knowing the application. Why getting stuck with the 20 year old technology? Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●November 8, 20102010-11-08
On 11/4/2010 4:24 PM, Vladimir Vassilevsky wrote:> > > Alessandro Basili wrote: > >> Hi, >> I have a custom designed board which is based on an ADSP2187L dsp, >> with a 512KB FLASH, a 128KB SRAM (20 ns cycle) and an FPGA running at >> 50 MHz. > > > ADSP218x is a dinosaur with the address space of 16K words; what is all > that external memory for? This DSP is inconvenient for C programming as > it doesn't support stack frames and base-index addressing. >The main purpose of the DSP is basically data compressing in a physics detector readout system. We have some 300'000 12 bit ADC channels to read out at a frequency of ~2KHz out of which only few signals are meaningful. That's why we use the external memory to store the raw event and then we try to compress using cluster reconstruction with cuts on the adc distributions. B.t.w. what are "stack frames" and "base-index addressing"?> >> The dsp task is mainly processing commands and data from external >> links (space-wire) on a 200~500 us cycle. >> Since the actual software has been written in assembler and there are >> some concerns about its reliability, I was wondering whether it is >> worth while considering the possibility to move to a higher language >> like C, in order to gain in maintainability and readability without >> loosing too much on performances. > > Yes, you can program ADSP218x in C; VDSP toolset recommended. > Yes, there will be significant overhead.Maybe I can think about having the framework in C, while the specific compression algorithms (which will be the most critical ones) maybe still done with the assembler.> It is impossible to tell if there is enough of speed without actually > knowing the application.Indeed I believe there is no general answer. But I believe that simply "translating" from assembler to C will be a bad idea and I should maybe focus the possibility of restructuring the whole program.> Why getting stuck with the 20 year old technology? >The 20 y.o. technology was the one which didn't suffer radiation effects for a low earth orbit exposure. At least this was the claim when the choice was made (some 10 years ago already!).> > Vladimir Vassilevsky > DSP and Mixed Signal Design Consultant > http://www.abvolt.com
Reply by ●November 8, 20102010-11-08
On 11/4/2010 4:24 PM, Vladimir Vassilevsky wrote:> > > Alessandro Basili wrote: > >> Hi, >> I have a custom designed board which is based on an ADSP2187L dsp, >> with a 512KB FLASH, a 128KB SRAM (20 ns cycle) and an FPGA running at >> 50 MHz. > > > ADSP218x is a dinosaur with the address space of 16K words; what is all > that external memory for? This DSP is inconvenient for C programming as > it doesn't support stack frames and base-index addressing. >The main purpose of the DSP is basically data compressing in a physics detector readout system. We have some 300'000 12 bit ADC channels to read out at a frequency of ~2KHz out of which only few signals are meaningful. That's why we use the external memory to store the raw event and then we try to compress using cluster reconstruction with cuts on the adc distributions. B.t.w. what are "stack frames" and "base-index addressing"?> >> The dsp task is mainly processing commands and data from external >> links (space-wire) on a 200~500 us cycle. >> Since the actual software has been written in assembler and there are >> some concerns about its reliability, I was wondering whether it is >> worth while considering the possibility to move to a higher language >> like C, in order to gain in maintainability and readability without >> loosing too much on performances. > > Yes, you can program ADSP218x in C; VDSP toolset recommended. > Yes, there will be significant overhead.Maybe I can think about having the framework in C, while the specific compression algorithms (which will be the most critical ones) maybe still done with the assembler.> It is impossible to tell if there is enough of speed without actually > knowing the application.Indeed I believe there is no general answer. But I believe that simply "translating" from assembler to C will be a bad idea and I should maybe focus the possibility of restructuring the whole program.> Why getting stuck with the 20 year old technology? >The 20 y.o. technology was the one which didn't suffer radiation effects for a low earth orbit exposure. At least this was the claim when the choice was made (some 10 years ago already!).> > Vladimir Vassilevsky > DSP and Mixed Signal Design Consultant > http://www.abvolt.com
Reply by ●November 8, 20102010-11-08
In comp.dsp Alessandro Basili <alessandro.basili@cern.ch> wrote:> I have a custom designed board which is based on an ADSP2187L dsp, with > a 512KB FLASH, a 128KB SRAM (20 ns cycle) and an FPGA running at 50 MHz.(snip)> Since the actual software has been written in assembler and there are > some concerns about its reliability, I was wondering whether it is worth > while considering the possibility to move to a higher language like C, > in order to gain in maintainability and readability without loosing too > much on performances.Much embedded programming is done in C with inline assembler. With some compilers, you can switch back and forth in the middle of a function. Depending or the processor, keeping track of which registers to use may or may not be a problem, but in most cases it can be done and result in fast code. -- glen
Reply by ●November 8, 20102010-11-08
glen herrmannsfeldt wrote:> Much embedded programming is done in C with inline assembler.Inline assembler is bad style and a characteristic feature of lame programmers. It combines disadvantages of both C and assembler. If there is a need to use an assembler, make a separate module in assembler and call it from C as an external function.> With some compilers, you can switch back and forth in the middle > of a function. Depending or the processor, keeping track of > which registers to use may or may not be a problem, but in most > cases it can be done and result in fast code.The result is incomprehensible, unalterable, undebuggable and unportable write-only code. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●November 8, 20102010-11-08
In comp.dsp Vladimir Vassilevsky <nospam@nowhere.com> wrote: (snip, I wrote)>> Much embedded programming is done in C with inline assembler.> Inline assembler is bad style and a characteristic feature of lame > programmers. It combines disadvantages of both C and assembler.Except for the "lame" part, I agree.> If there is a need to use an assembler, make a separate module in > assembler and call it from C as an external function.Usually a good idea, though it depends on the function call overhead. Sometimes it isn't so bad to have only the function statement in C, with all the code in assembler. Or use #ifdef to select between the assembler code and equivalent C code. It is then portable, but possibly too slow.>> With some compilers, you can switch back and forth in the middle >> of a function. Depending or the processor, keeping track of >> which registers to use may or may not be a problem, but in most >> cases it can be done and result in fast code.> The result is incomprehensible, unalterable, undebuggable > and unportable write-only code.Well, assembler is pretty much unportable anyway. If you only write the inner loops in assembler then you get speed, with only a small amount of write-only code. Last I did it, was for a Z280. There are few enough registers that you pretty much don't have to worry about them. It was surprisingly easy to write and debug. A big advantage for the Z280 is the bank switching function call. The compiler gets that right, while keeping track of which bank the code is in. -- glen
Reply by ●November 8, 20102010-11-08
Alessandro Basili <alessandro.basili@cern.ch> writes:> Hi, > I have a custom designed board which is based on an ADSP2187L dsp, > with a 512KB FLASH, a 128KB SRAM (20 ns cycle) and an FPGA running at > 50 MHz. > > The dsp task is mainly processing commands and data from external > links (space-wire) on a 200~500 us cycle. > Since the actual software has been written in assembler and there are > some concerns about its reliability, I was wondering whether it is > worth while considering the possibility to move to a higher language > like C, in order to gain in maintainability and readability without > loosing too much on performances."Some concerns about its reliability" is pretty vague. Is it broken? "If it ain't broke, don't fix it." You want to spend time rewriting working software so it's more maintainable, even though you have no clear problem with it? This sounds like a horrible idea to me. -- Randy Yates % "So now it's getting late, Digital Signal Labs % and those who hesitate mailto://yates@ieee.org % got no one..." http://www.digitalsignallabs.com % 'Waterfall', *Face The Music*, ELO
Reply by ●November 8, 20102010-11-08
Vladimir Vassilevsky <nospam@nowhere.com> writes:> glen herrmannsfeldt wrote: > > >> Much embedded programming is done in C with inline assembler. > > Inline assembler is bad style and a characteristic feature of lame > programmers. It combines disadvantages of both C and assembler. > > If there is a need to use an assembler, make a separate module in > assembler and call it from C as an external function.Amen, brother! My philosophy exactly! -- Randy Yates % "Bird, on the wing, Digital Signal Labs % goes floating by mailto://yates@ieee.org % but there's a teardrop in his eye..." http://www.digitalsignallabs.com % 'One Summer Dream', *Face The Music*, ELO
Reply by ●November 8, 20102010-11-08
On Nov 8, 9:24�pm, Randy Yates <ya...@ieee.org> wrote:> Vladimir Vassilevsky <nos...@nowhere.com> writes: > > glen herrmannsfeldt wrote: > > >> Much embedded programming is done in C with inline assembler. > > > Inline assembler is bad style and a characteristic feature of lame > > programmers. It combines disadvantages of both C and assembler. > > > If there is a need to use an assembler, make a separate module in > > assembler and call it from C as an external function. > > Amen, brother! My philosophy exactly! > -- > Randy Yates � � � � � � � � � � �% "Bird, on the wing, > Digital Signal Labs � � � � � � �% � goes floating by > mailto://ya...@ieee.org � � � � �% � but there's a teardrop in his eye..."http://www.digitalsignallabs.com% 'One Summer Dream', *Face The Music*, ELOThat was how I did with a large application for the ADSP-2187 I developed 15 years ago which needed much faster floating point than the IEEE library routines provided in the main computation function. The company I worked for has just upgraded to a Blackfin.
