Prev: Xilinx' partition flow in ISE12.1
Next: How to create a LVPECL_25 output pair (Spartan3, ISE 9.1)
From: rickman on 28 Jul 2010 13:06
On Jul 28, 8:40 am, Markus Lavin <markusl.se78pleasenos...(a)gmail.com>
wrote:
> On 27 Juli, 20:21, Andreas Ehliar <ehliar-nos...(a)isy.liu.se> wrote:
>
> > On 2010-07-21, Markus Lavin <markusl.se78pleasenos...(a)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
From: Gabor on 28 Jul 2010 13:48
On Jul 28, 1:06 pm, rickman <gnu...(a)gmail.com> wrote:
> On Jul 28, 8:40 am, Markus Lavin <markusl.se78pleasenos...(a)gmail.com>
> wrote:
>
>
>
> > On 27 Juli, 20:21, Andreas Ehliar <ehliar-nos...(a)isy.liu.se> wrote:
>
> > > On 2010-07-21, Markus Lavin <markusl.se78pleasenos...(a)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
From: rickman on 28 Jul 2010 19:10
On Jul 28, 1:48 pm, Gabor <ga...(a)alacron.com> wrote:
> On Jul 28, 1:06 pm, rickman <gnu...(a)gmail.com> wrote:
>
>
>
> > On Jul 28, 8:40 am, Markus Lavin <markusl.se78pleasenos...(a)gmail.com>
> > wrote:
>
> > > On 27 Juli, 20:21, Andreas Ehliar <ehliar-nos...(a)isy.liu.se> wrote:
>
> > > > On 2010-07-21, Markus Lavin <markusl.se78pleasenos...(a)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


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
First  |  Prev  | 
Pages: 1 2
Prev: Xilinx' partition flow in ISE12.1
Next: How to create a LVPECL_25 output pair (Spartan3, ISE 9.1)