Announcing AjarDSP - an open source VLIW DSP

M

Markus Lavin

Guest
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 am, 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
Click to expand...
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 am, 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.
Click to expand...
Thanks!

It looks to me that
your design was heavily influenced by TI's C55x family?
Click to expand...
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
Click to expand...
Markus
 
On 2010-07-21, Markus Lavin <markusl.se78pleasenospam@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/
Click to expand...
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.
Click to expand...
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?
Click to expand...
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 am, 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 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
Click to expand...
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 pm, rickman <gnu...@gmail.com> wrote:
On Jul 28, 8:40 am, 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 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

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
Click to expand...
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
 
On Jul 28, 1:48 pm, Gabor <ga...@alacron.com> wrote:
On Jul 28, 1:06 pm, rickman <gnu...@gmail.com> wrote:



On Jul 28, 8:40 am, 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 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

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

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
Click to expand...

Hmmm... that sounds to me like the instructions are stored in external
memory and the instruction decode is being done when the code is
fetched from external memory and the cache is actually real time
updated micro-code. But then I guess that is what VLIW is, pre-
decoded instructions.

I worked with an array processor (a double rack cabinet sized DSP
chip) which was microcoded. There was no instruction level, it was
all microcode. So in essence, it was a VLIW DSP processor... that
required 230 VAC power and its own AC to cool it!

Rick
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top