Re: compiler for asynchronous DSP core

"Mike Rosing" <rosing@neurophys.wisc.edu>
4 Aug 2002 11:40:39 -0400

          From comp.compilers

Related articles
compiler for asynchronous DSP core nixxlizzie@yahoo.com (Lizzie Ni) (2002-07-31)
Re: compiler for asynchronous DSP core rosing@neurophys.wisc.edu (Mike Rosing) (2002-08-04)
Re: compiler for asynchronous DSP core nixxlizzie@yahoo.com (Lizzie Ni) (2002-08-23)
Re: compiler for asynchronous DSP core rosing@neurophys.wisc.edu (Mike Rosing) (2002-08-24)
| List of all articles for this month |

From: "Mike Rosing" <rosing@neurophys.wisc.edu>
Newsgroups: comp.cog-eng,comp.dsp,comp.compilers,comp.realtime
Date: 4 Aug 2002 11:40:39 -0400
Organization: University of Wisconsin, Madison
References: 02-07-139
Keywords: architecture
Posted-Date: 04 Aug 2002 11:40:39 EDT

Lizzie Ni wrote:
> Hi all
>
> I am wondering whether there is some difference when we construct a
> compiler between an asynchronous DSP and a synchornous DSP core? Is
> there any main thing that we need concern on writing a compiler for an
> asynchronous DSP core?
>
> Respect any reponse.
>
> Thanks
> [I wouldn't think so. Some of the optimization heuristics might be
> a little different, but the major issues that affect a compiler are
> data representation, word size, and addressing. -John]


One of the important things with DSP is consistent timing. As long as
your asyncrhonous result is faster than the time constraints, you
don't need further optimizations. So an important input parameter is
sample rate, and you may want to put a limit on the fraction of sample
rate any particular task is allowed. If the compiled version doesn't
meet the spec, you have reason to try further optimization, and if it
does you can quit.


The next level up would be to specify a time constraint on the entire
process, and to be sure your resulting code meets the maximum limit.
You might be able to trade off some "slow" section which doesn't meet
it's spec with another one that came out faster and have the whole
thing be within spec. It's up to the humans to accept or reject the
result at that point (the user should re-spec the lower level
subroutines).


Patience, persistence, truth,
Dr. mike
--
Mike Rosing
www.beastrider.com BeastRider, LLC
SHARC debug tools


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.