Hi all,

This is a post to announce the existence of the AjarDSP project, an
attempt to design and implement an open source VLIW DSP with an open
source tool chain (assembler, simulator/debugger and C compiler).

Check out the details at: http://code.google.com/p/ajardsp/

regards
Markus

On Jul 21, 3:27=A0am, Markus Lavin
<markusl.se78pleasenos...@gmail.com>
wrote:
> Hi all,
>
> This is a post to announce the existence of the AjarDSP project, an
> attempt to design and implement an open source VLIW DSP with an open
> source tool chain (assembler, simulator/debugger and C compiler).
>
> Check out the details at:http://code.google.com/p/ajardsp/
>
> regards
> Markus

Looks like a pretty ambitious project; good luck. It looks to me that
your design was heavily influenced by TI's C55x family? It does appear
to have a number of enhancements above any of those devices though
(more registers, more parallelism).

Jason

On 21 Juli, 16:26, Jason
<cincy...@gmail.com> wrote:
> On Jul 21, 3:27=A0am, Markus Lavin <markusl.se78pleasenos...@gmail.com>
> wrote:
>
> > Hi all,
>
> > This is a post to announce the existence of the AjarDSP project, an
> > attempt to design and implement an open source VLIW DSP with an open
> > source tool chain (assembler, simulator/debugger and C compiler).
>
> > Check out the details at:http://code.google.com/p/ajardsp/
>
> > regards
> > Markus
>
> Looks like a pretty ambitious project; good luck.

Thanks!

> It looks to me that
> your design was heavily influenced by TI's C55x family?

That is possible, but not really intentional. I would say that given
that certain design parameters are fixed (like 16-bit dual-mac, 64-bit
VLIW bundles, etc) then once you start to consider instruction
encoding you aren't left with that much freedom. At least not if one
wants to go for the more obvious solutions.

> It does appear
> to have a number of enhancements above any of those devices though
> (more registers, more parallelism).
>
> Jason

Markus

On 2010-07-21, Markus Lavin
<m...@gmail.com> wrote:
> Hi all,
>
> This is a post to announce the existence of the AjarDSP project, an
> attempt to design and implement an open source VLIW DSP with an open
> source tool chain (assembler, simulator/debugger and C compiler).
>
> Check out the details at: http://code.google.com/p/ajardsp/

This sounds very interesting. I have contemplated doing something similar
a long time as there were no FPGA optimized DSP processor available that
I'm was aware of, but in the end I got stuck creating a fairly general
purpose FPGA optimized processor instead.

Are you doing this just for fun or do you have some specific applications
in mind?

/Andreas

On 27 Juli, 20:21, Andreas Ehliar
<ehliar-nos...@isy.liu.se> wrote:
> On 2010-07-21, Markus Lavin <markusl.se78pleasenos...@gmail.com> wrote:
>
> > Hi all,
>
> > This is a post to announce the existence of theAjarDSPproject, an
> > attempt to design and implement an open source VLIW DSP with an open
> > source tool chain (assembler, simulator/debugger and C compiler).
>
> > Check out the details at:http://code.google.com/p/ajardsp/
>
> This sounds very interesting. I have contemplated doing something similar
> a long time as there were no FPGA optimized DSP processor available that
> I'm was aware of, but in the end I got stuck creating a fairly general
> purpose FPGA optimized processor instead.

I agree, this is a very interesting subject and there does indeed seem
to be a lack of open source DSP implementations available on the net.
However, at this point in time I would not consider AjarDSP to be in
any way FPGA optimized. It is approaching a feature complete phase and
after that focus will naturally shift to trying to increase speed and
reduce area. Somewhere inbetween it would also be interesting to
evaluate the 'compiler friendliness' of certain architectural
features...

>
> Are you doing this just for fun or do you have some specific applications
> in mind?

No, there is no specific application in mind except perhaps some demo
in the area of audio processing. The goal for the project is simply to
provide the DSP and the tools. In the end hopefully someone will find
it useful and maybe consider it for use in some product. In the
meantime I consider this CV improvement and of course I can't deny
that it is quite fun to work on every now and then :)

/Markus

On Jul 28, 8:40=A0am, Markus Lavin
<markusl.se78pleasenos...@gmail.com>
wrote:
> On 27 Juli, 20:21, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote:
>
> > On 2010-07-21, Markus Lavin <markusl.se78pleasenos...@gmail.com> wrote:
>
> > > Hi all,
>
> > > This is a post to announce the existence of theAjarDSPproject, an
> > > attempt to design and implement an open source VLIW DSP with an open
> > > source tool chain (assembler, simulator/debugger and C compiler).
>
> > > Check out the details at:http://code.google.com/p/ajardsp/
>
> > This sounds very interesting. I have contemplated doing something simil=
ar
> > a long time as there were no FPGA optimized DSP processor available tha=
t
> > I'm was aware of, but in the end I got stuck creating a fairly general
> > purpose FPGA optimized processor instead.
>
> I agree, this is a very interesting subject and there does indeed seem
> to be a lack of open source DSP implementations available on the net.
> However, at this point in time I would not consider AjarDSP to be in
> any way FPGA optimized. It is approaching a feature complete phase and
> after that focus will naturally shift to trying to increase speed and
> reduce area. Somewhere inbetween it would also be interesting to
> evaluate the 'compiler friendliness' of certain architectural
> features...
>
>
>
> > Are you doing this just for fun or do you have some specific applicatio=
ns
> > in mind?
>
> No, there is no specific application in mind except perhaps some demo
> in the area of audio processing. The goal for the project is simply to
> provide the DSP and the tools. In the end hopefully someone will find
> it useful and maybe consider it for use in some product. In the
> meantime I consider this CV improvement and of course I can't deny
> that it is quite fun to work on every now and then :)
>
> /Markus

Why did you want to provide a VLIW DSP processor?  Did you have any
specific goals in mind?  VLIW devices have problems with bandwidth to
external memory which can limit the ultimate speed of the processor.
Of course many apps and/or the key portions of apps can be put in
internal memory to run at full speed, but again a VLIW processor has a
limitation, program memory usage.  The program code tends to be very
large which can eat up internal memory quickly.

Why go with a VLIW when a more conventional processor can do most jobs
very well?  It could be very interesting to use the dual port feature
of internal FPGA memory to allow two DSPs to share one instruction
space.  They can be executing the code independently, but the code
storage would be half.  In FPGAs with limited memory, this can be
important.

Rick

On Jul 28, 1:06=A0pm, rickman
<gnu...@gmail.com> wrote:
> On Jul 28, 8:40=A0am, Markus Lavin <markusl.se78pleasenos...@gmail.com>
> wrote:
>
>
>
> > On 27 Juli, 20:21, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote:
>
> > > On 2010-07-21, Markus Lavin <markusl.se78pleasenos...@gmail.com>
wrot=
e:
>
> > > > Hi all,
>
> > > > This is a post to announce the existence of theAjarDSPproject, an
> > > > attempt to design and implement an open source VLIW DSP with an ope=
n
> > > > source tool chain (assembler, simulator/debugger and C compiler).
>
> > > > Check out the details at:http://code.google.com/p/ajardsp/
>
> > > This sounds very interesting. I have contemplated doing something sim=
ilar
> > > a long time as there were no FPGA optimized DSP processor available t=
hat
> > > I'm was aware of, but in the end I got stuck creating a fairly genera=
l
> > > purpose FPGA optimized processor instead.
>
> > I agree, this is a very interesting subject and there does indeed seem
> > to be a lack of open source DSP implementations available on the net.
> > However, at this point in time I would not consider AjarDSP to be in
> > any way FPGA optimized. It is approaching a feature complete phase and
> > after that focus will naturally shift to trying to increase speed and
> > reduce area. Somewhere inbetween it would also be interesting to
> > evaluate the 'compiler friendliness' of certain architectural
> > features...
>
> > > Are you doing this just for fun or do you have some specific applicat=
ions
> > > in mind?
>
> > No, there is no specific application in mind except perhaps some demo
> > in the area of audio processing. The goal for the project is simply to
> > provide the DSP and the tools. In the end hopefully someone will find
> > it useful and maybe consider it for use in some product. In the
> > meantime I consider this CV improvement and of course I can't deny
> > that it is quite fun to work on every now and then :)
>
> > /Markus
>
> Why did you want to provide a VLIW DSP processor? =A0Did you have any
> specific goals in mind? =A0VLIW devices have problems with bandwidth to
> external memory which can limit the ultimate speed of the processor.
> Of course many apps and/or the key portions of apps can be put in
> internal memory to run at full speed, but again a VLIW processor has a
> limitation, program memory usage. =A0The program code tends to be very
> large which can eat up internal memory quickly.
>
> Why go with a VLIW when a more conventional processor can do most jobs
> very well? =A0It could be very interesting to use the dual port feature
> of internal FPGA memory to allow two DSPs to share one instruction
> space. =A0They can be executing the code independently, but the code
> storage would be half. =A0In FPGAs with limited memory, this can be
> important.
>
> Rick

Actually many VLIW processors work around the memory issue by
compressing the code and un-compressing it as it gets loaded into
cache.  Granted they typically use more silicon resources than
you would put into a typical FPGA design, but the compression
algorithm doesn't need to be very sophisticated as the code word
tends to be mostly zero (assuming active high function enable).

Take a look at the NXP Nexperia series (formerly TriMedia).

Regards,
Gabor