DSP and FPGA

Hi Al,

Al Clark wrote:

> We started with an Analog Devices ADSP-2126x or ADSP-2136x DSP. This
> gives us three main interfaces:
>
> DAI - This interface is kind of a crossbar switch in front of high
speed
> serial ports (SPORTs) and other I/O.
>
> SPI - Convenient as the for control bus, we use it all over
>
> Parallel Port - A muxed data bus on these DSPs with lines AD15-AD0,
ALE
> RD & WR. We mostly use it for SDRAM expansion

These members of the SHARC family have no on-chip SDRAM controller, as
far as I recall.

So, you implement a full SDRAM controller in the FPGA, and access it
from the DSP (the SDRAM) as a simple memory mapped periheral?

JaaC

Hi Al,

Al Clark wrote:

> We started with an Analog Devices ADSP-2126x or ADSP-2136x DSP. This
> gives us three main interfaces:
>
> DAI - This interface is kind of a crossbar switch in front of high
speed
> serial ports (SPORTs) and other I/O.
>
> SPI - Convenient as the for control bus, we use it all over
>
> Parallel Port - A muxed data bus on these DSPs with lines AD15-AD0,
ALE
> RD & WR. We mostly use it for SDRAM expansion

These members of the SHARC family have no on-chip SDRAM controller, as
far as I recall.

So, you implement a full SDRAM controller in the FPGA, and access it
from the DSP (the SDRAM) as a simple memory mapped periheral?

JaaC

> These chips emphasize CPU performance and on-chip memory at the
> expense of on-chip I/O, which is limited to the four link ports and
> the 64-bit local bus.

When you say "at the expense of on-chip I/O" you must be meaning variety (as 
in serial ports, etc) as opposed to bandwidth, because those 4 links ports 
can run at 500 MBytes/sec each full duplex, plus the 64 bit bus can run at 
up to 125 MHz, providing an I/O bandwidth of up to 5 GBytes/second!

On our latest board family, the T2 (for TigerSharc 2), we combine 4 TS201s 
with a VirtexII Pro FPGA (V2Pro30), connecting 2 full duplex links per DSP 
to the FPGA.  The FPGA is also accesible from the DSPs over a parallel bus 
for control register access, etc.  Using the links is extremely poweful, as 
the TigerSHARC has a dedicated DMA engine for each one, so you can use DMA 
to stream data to/from the FPGA in the background while the DSP core is 
doing it's own work.

------------
Ron Huizen
BittWare


"David Tweed" <dtweed@acm.org> wrote in message 
news:41F8259D.74743C5D@acm.org...
> Randy Yates wrote:
>> Al Clark <dsp@danvillesignal.com> writes:
>> > We will soon be releasing a new set of dsp boards that feature
>> > both an Altera Cyclone FPGA and an Analog Devices SHARC DSP.
>> > You can use the FPGA for additional signal processing or
>> > general purpose I/O
>>
>> Al, how do you plan on interfacing the DSP to the FPGA in a
>> general manner?
>
> I'm working on an embedded project based on the TigerSharc (TS201).
> These chips emphasize CPU performance and on-chip memory at the
> expense of on-chip I/O, which is limited to the four link ports and
> the 64-bit local bus. I'm hanging a (Xilinx) FPGA onto one of the
> link ports to provide all of the application-specific I/O (primarily
> async and sync serial ports of various types). The link port carries
> a fairly general-purpose message protocol that allows data to be
> directed to or received from any of the FPGA ports.
>
> -- Dave Tweed 

"Jaime Andr&#4294967295;s Aranguren Cardona" <jaime.aranguren@gmail.com> wrote in 
news:1106828532.146781.101160@z14g2000cwz.googlegroups.com:

> Hi Al,
> 
> Al Clark wrote:
> 
>> We started with an Analog Devices ADSP-2126x or ADSP-2136x DSP. This
>> gives us three main interfaces:
>>
>> DAI - This interface is kind of a crossbar switch in front of high
> speed
>> serial ports (SPORTs) and other I/O.
>>
>> SPI - Convenient as the for control bus, we use it all over
>>
>> Parallel Port - A muxed data bus on these DSPs with lines AD15-AD0,
> ALE
>> RD & WR. We mostly use it for SDRAM expansion



> 
> These members of the SHARC family have no on-chip SDRAM controller, as
> far as I recall.
> 
> So, you implement a full SDRAM controller in the FPGA, and access it
> from the DSP (the SDRAM) as a simple memory mapped periheral?
> 
> JaaC
> 
> 

Yes. 

The SDRAM controller was the original motivation for using the FPGA. It 
uses about 15% of the FPGA's internal resources for this purpose and 
about 1/2 the pins. This opens a lot of opportunities to do more with the 
remaining resources of the FPGA

-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com

"Ron Huizen" <rhuizen@bittware.com> wrote in
news:10vhv3lsves4of5@corp.supernews.com: 

>> These chips emphasize CPU performance and on-chip memory at the
>> expense of on-chip I/O, which is limited to the four link ports and
>> the 64-bit local bus.
> 
> When you say "at the expense of on-chip I/O" you must be meaning
> variety (as in serial ports, etc) as opposed to bandwidth, because
> those 4 links ports can run at 500 MBytes/sec each full duplex, plus
> the 64 bit bus can run at up to 125 MHz, providing an I/O bandwidth of
> up to 5 GBytes/second! 
> 
> On our latest board family, the T2 (for TigerSharc 2), we combine 4
> TS201s with a VirtexII Pro FPGA (V2Pro30), connecting 2 full duplex
> links per DSP to the FPGA.  The FPGA is also accesible from the DSPs
> over a parallel bus for control register access, etc.  Using the links
> is extremely poweful, as the TigerSHARC has a dedicated DMA engine for
> each one, so you can use DMA to stream data to/from the FPGA in the
> background while the DSP core is doing it's own work.
> 
> ------------
> Ron Huizen
> BittWare
> 
>

WOW! Do your boards pass the Turing test yet?


-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com

"Al Clark" <dsp@danvillesignal.com> wrote in message 
news:Xns95EB58D63A246aclarkdanvillesignal@66.133.129.71...
> "Ron Huizen" <rhuizen@bittware.com> wrote in
> news:10vhv3lsves4of5@corp.supernews.com:
>
>>> These chips emphasize CPU performance and on-chip memory at the
>>> expense of on-chip I/O, which is limited to the four link ports and
>>> the 64-bit local bus.
>>
>> When you say "at the expense of on-chip I/O" you must be meaning
>> variety (as in serial ports, etc) as opposed to bandwidth, because
>> those 4 links ports can run at 500 MBytes/sec each full duplex, plus
>> the 64 bit bus can run at up to 125 MHz, providing an I/O bandwidth of
>> up to 5 GBytes/second!
>>
>> On our latest board family, the T2 (for TigerSharc 2), we combine 4
>> TS201s with a VirtexII Pro FPGA (V2Pro30), connecting 2 full duplex
>> links per DSP to the FPGA.  The FPGA is also accesible from the DSPs
>> over a parallel bus for control register access, etc.  Using the links
>> is extremely poweful, as the TigerSHARC has a dedicated DMA engine for
>> each one, so you can use DMA to stream data to/from the FPGA in the
>> background while the DSP core is doing it's own work.
>>
>> ------------
>> Ron Huizen
>> BittWare
>>
>>
>
> WOW! Do your boards pass the Turing test yet?
>

Don't know about that, but I bet they could determine the seashore and even 
maybe find those pirates if someone can come up with the algorithm :-)

----
T2
oops, I mean Ron Huizen :-)
BittWare

Hi,

Al Clark wrote:
>
> The SDRAM controller was the original motivation for using the FPGA.
It
> uses about 15% of the FPGA's internal resources for this purpose and
> about 1/2 the pins. This opens a lot of opportunities to do more with
the
> remaining resources of the FPGA

It's nice. But that is really one of the things that I miss from newer
SHARCs, and that made the 21065L and 21161N so interesting. Those newer
DSPs are great in terms of processing power and audio specialized
peripherals. They also come with good amounts of internal SRAM, but
which sometimes is not enough. Some models include ROM with/for
propetary algorithms, so this is useless for general purpose
applications which don't need the licensed audio processing algorithms.
With newer SHARCs Using SDRAM can be justified only in case when the
benefit of high performance processing and LOTS of memory is much
higher than the cost of an external SDRAM controller, and even better
if you can take good advantage of the additional logic and IO available
on the FPGA. Being FPGAs lower and lower cost, this is certainly a good
option. One could even add one of those embedded processors which are
becoming so popular nowadays: Nios (II), PicoBlaze, MicroBlaze, or
whatever.

A question out of curiosity: how big is your FPGA? which one are you
using?

Regards,

JaaC

Errata:

Jaime Andr=E9s Aranguren Cardona wrote:

> It's nice. But that is really one of the things that I miss from
newer
> SHARCs, and that made the 21065L and 21161N so interesting. Those
newer

Read as either:

" It's nice. But that is really one of the things that I miss from
older
SHARCs, and that made the 21065L and 21161N so interesting. Those
newer"

JaaC

"Jaime Andr&#4294967295;s Aranguren Cardona" <jaime.aranguren@gmail.com> wrote in 
news:1106840533.428552.292360@z14g2000cwz.googlegroups.com:

> Hi,
> 
> Al Clark wrote:
>>
>> The SDRAM controller was the original motivation for using the FPGA.
> It
>> uses about 15% of the FPGA's internal resources for this purpose and
>> about 1/2 the pins. This opens a lot of opportunities to do more with
> the
>> remaining resources of the FPGA
> 
> It's nice. But that is really one of the things that I miss from newer
> SHARCs, and that made the 21065L and 21161N so interesting. Those newer
> DSPs are great in terms of processing power and audio specialized
> peripherals. They also come with good amounts of internal SRAM, but
> which sometimes is not enough. Some models include ROM with/for
> propetary algorithms, so this is useless for general purpose
> applications which don't need the licensed audio processing algorithms.
> With newer SHARCs Using SDRAM can be justified only in case when the
> benefit of high performance processing and LOTS of memory is much
> higher than the cost of an external SDRAM controller, and even better
> if you can take good advantage of the additional logic and IO available
> on the FPGA. Being FPGAs lower and lower cost, this is certainly a good
> option. One could even add one of those embedded processors which are
> becoming so popular nowadays: Nios (II), PicoBlaze, MicroBlaze, or
> whatever.
> 
> A question out of curiosity: how big is your FPGA? which one are you
> using?
> 
> Regards,
> 
> JaaC
> 
> 

We use an Altera Cyclone EP1C3 - 144 pins

-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com

"Ron Huizen" <rhuizen@bittware.com> wrote in message
news:10vi1jv29hq2g54@corp.supernews.com...

<Snipped>

> >> On our latest board family, the T2 (for TigerSharc 2), we combine 4
> >> ------------
> >> Ron Huizen
> >> BittWare

Hey Ron
Do you guys have a rubber TigerSharc yet? It's been ages since I visited you
guys in a conference or something and haven't had a chance to add to my
(rubber) Sharc and Hammerhead collection.

Cheers
Bhaskar