8bit peripheral to ADSP-21160

Good day,

Hopefully some of you can give me some enlightment to figure out a
solution on how to connect an 8bit-wide peripheral to an ADSP-21160.

It's a rather asymmetric bidirectional connection, the "traffic" is
higher from the DSP to the peripheral than from the peripheral to the
DSP.

Some of the features I want to use are:

- Memory mapped peripheral.
- Don't need to use the MS3-0 signals (useless for the peripheral I
work with).
- I want to use the EPort in Asynchronous Bus Master mode, so the
peripheral (which is much slower than the DSP) controls when _can_ the
DSP send data to it by means of the ACK input to the DSP.
- I would like to use DMA transfers from the DSP to the peripheral, so
the DSP can continue crunching data. The DSP determines when should
the data be transmitted, and how much data should be transmitted.
- For the transmission of data from the peripheral to the DSP, it can
be done by means of interrupts (generated by the peripheral). Data
transmitted in this direction is more targeted to control than to
streams of data.

My main doubt is about how to connect the peripheral to the DSP. From
figure 7-1, page 7-2 in the '160's manual, it states than for 32-bit
normal words, both W(R) L and w will be asserted alternatively,
between the accesses to even and odd addresses. Should I then use
these control pins ORed??? Isn't there a way to use them in a simpler
way? From the higher part of the same figure I deduce that all the
transfers done my means of DMA will be 64 bits long. What about that?
The data I'll transfer to the peripheral will be "chars" (8 bits
long). Where should I attach the peripheral? I mean: D7-0? D15-8?
D23-16? D31-24? D39-32? D47-40? D55-48? D63-56??

Thanks a lot for your advice, guys.

JaaC

"Jaime Andres Aranguren Cardona" <jaime.aranguren@ieee.org> wrote in message
news:14a86f87.0308151533.33817f76@posting.google.com...
> Good day,
>
> Hopefully some of you can give me some enlightment to figure out a
> solution on how to connect an 8bit-wide peripheral to an ADSP-21160.
>
> It's a rather asymmetric bidirectional connection, the "traffic" is
> higher from the DSP to the peripheral than from the peripheral to the
> DSP.
>
> Some of the features I want to use are:
>
> - Memory mapped peripheral.
> - Don't need to use the MS3-0 signals (useless for the peripheral I
> work with).
> - I want to use the EPort in Asynchronous Bus Master mode, so the
> peripheral (which is much slower than the DSP) controls when _can_ the
> DSP send data to it by means of the ACK input to the DSP.
> - I would like to use DMA transfers from the DSP to the peripheral, so
> the DSP can continue crunching data. The DSP determines when should
> the data be transmitted, and how much data should be transmitted.
> - For the transmission of data from the peripheral to the DSP, it can
> be done by means of interrupts (generated by the peripheral). Data
> transmitted in this direction is more targeted to control than to
> streams of data.
>
> My main doubt is about how to connect the peripheral to the DSP. From
> figure 7-1, page 7-2 in the '160's manual, it states than for 32-bit
> normal words, both W(R) L and w will be asserted alternatively,
> between the accesses to even and odd addresses. Should I then use
> these control pins ORed??? Isn't there a way to use them in a simpler
> way? From the higher part of the same figure I deduce that all the
> transfers done my means of DMA will be 64 bits long. What about that?
> The data I'll transfer to the peripheral will be "chars" (8 bits
> long). Where should I attach the peripheral? I mean: D7-0? D15-8?
> D23-16? D31-24? D39-32? D47-40? D55-48? D63-56??

I'm not expert in the hardware design aspects of the 21160 Jaime, so you may
want confirmation from others...
I think you just connect your peripheral to D39-D32 (as it shows for an 8
bit eprom on that figure).
Look at the note above "32-bit packed" - it says restricted DMA. So you
should be able to use DMA for this alignment - no reason for external port
DMA to be always 64 bits long.

If your peripheral is going to be an FPGA or pld, you *may* want to consider
implementing an link port on that end and use the link connection. However,
I have no idea on the complexity of this vs the straight forward approach.
It does free up your external bus.

Cheers
Bhaskar

>
> Thanks a lot for your advice, guys.
>
> JaaC

"Bhaskar Thiagarajan" <bhaskart@deja.com> wrote in message news:<bhjrsc$bfha$1@ID-82263.news.uni-berlin.de>...
> "Jaime Andres Aranguren Cardona" <jaime.aranguren@ieee.org> wrote in message
> news:14a86f87.0308151533.33817f76@posting.google.com...
> > Good day,
> >
> > Hopefully some of you can give me some enlightment to figure out a
> > solution on how to connect an 8bit-wide peripheral to an ADSP-21160.
> >
> > It's a rather asymmetric bidirectional connection, the "traffic" is
> > higher from the DSP to the peripheral than from the peripheral to the
> > DSP.
> >
> > Some of the features I want to use are:
> >
> > - Memory mapped peripheral.
> > - Don't need to use the MS3-0 signals (useless for the peripheral I
> > work with).
> > - I want to use the EPort in Asynchronous Bus Master mode, so the
> > peripheral (which is much slower than the DSP) controls when _can_ the
> > DSP send data to it by means of the ACK input to the DSP.
> > - I would like to use DMA transfers from the DSP to the peripheral, so
> > the DSP can continue crunching data. The DSP determines when should
> > the data be transmitted, and how much data should be transmitted.
> > - For the transmission of data from the peripheral to the DSP, it can
> > be done by means of interrupts (generated by the peripheral). Data
> > transmitted in this direction is more targeted to control than to
> > streams of data.
> >
> > My main doubt is about how to connect the peripheral to the DSP. From
> > figure 7-1, page 7-2 in the '160's manual, it states than for 32-bit
> > normal words, both W(R) L and w will be asserted alternatively,
> > between the accesses to even and odd addresses. Should I then use
> > these control pins ORed??? Isn't there a way to use them in a simpler
> > way? From the higher part of the same figure I deduce that all the
> > transfers done my means of DMA will be 64 bits long. What about that?
> > The data I'll transfer to the peripheral will be "chars" (8 bits
> > long). Where should I attach the peripheral? I mean: D7-0? D15-8?
> > D23-16? D31-24? D39-32? D47-40? D55-48? D63-56??
> 
> I'm not expert in the hardware design aspects of the 21160 Jaime, so you may
> want confirmation from others...
> I think you just connect your peripheral to D39-D32 (as it shows for an 8
> bit eprom on that figure).
> Look at the note above "32-bit packed" - it says restricted DMA. So you
> should be able to use DMA for this alignment - no reason for external port
> DMA to be always 64 bits long.
> 
> If your peripheral is going to be an FPGA or pld, you *may* want to consider
> implementing an link port on that end and use the link connection. However,
> I have no idea on the complexity of this vs the straight forward approach.
> It does free up your external bus.
> 
> Cheers
> Bhaskar

Hello,

Bhaskar: thanks a lot for your reply. Hopefully, some other people
will give (us) some advice and opinions in the subject.

Actually, the peripheral is an USB module, so there is no way (?) to
make it a link port. At least, I don't wanna use more glue logc, just
want to connect the module to the DSP in the simplest (but functional)
possible way.

I've also thought of connecting the peripheral to where the EPROM is
attached to (D39-32). However, some concerns arise: I'll also need to
have the EPROM (for bootup), won't there be any conflicts at start up?
Mmmm... yeah, we have the BMS signal, which is asserted when the DSP
is booting up. So maybe that's not the problem.

Every comments, opinions, advice and suggestions are _very_ welcome!!!

Regards,

JaaC

> 
> >
> > Thanks a lot for your advice, guys.
> >
> > JaaC

"Bhaskar Thiagarajan" <bhaskart@deja.com> wrote in message news:<bhjrsc$bfha$1@ID-82263.news.uni-berlin.de>...
> "Jaime Andres Aranguren Cardona" <jaime.aranguren@ieee.org> wrote in message
> news:14a86f87.0308151533.33817f76@posting.google.com...
> > Good day,
> >
> > Hopefully some of you can give me some enlightment to figure out a
> > solution on how to connect an 8bit-wide peripheral to an ADSP-21160.
> >
> > It's a rather asymmetric bidirectional connection, the "traffic" is
> > higher from the DSP to the peripheral than from the peripheral to the
> > DSP.
> >
> > Some of the features I want to use are:
> >
> > - Memory mapped peripheral.
> > - Don't need to use the MS3-0 signals (useless for the peripheral I
> > work with).
> > - I want to use the EPort in Asynchronous Bus Master mode, so the
> > peripheral (which is much slower than the DSP) controls when _can_ the
> > DSP send data to it by means of the ACK input to the DSP.
> > - I would like to use DMA transfers from the DSP to the peripheral, so
> > the DSP can continue crunching data. The DSP determines when should
> > the data be transmitted, and how much data should be transmitted.
> > - For the transmission of data from the peripheral to the DSP, it can
> > be done by means of interrupts (generated by the peripheral). Data
> > transmitted in this direction is more targeted to control than to
> > streams of data.
> >
> > My main doubt is about how to connect the peripheral to the DSP. From
> > figure 7-1, page 7-2 in the '160's manual, it states than for 32-bit
> > normal words, both W(R) L and w will be asserted alternatively,
> > between the accesses to even and odd addresses. Should I then use
> > these control pins ORed??? Isn't there a way to use them in a simpler
> > way? From the higher part of the same figure I deduce that all the
> > transfers done my means of DMA will be 64 bits long. What about that?
> > The data I'll transfer to the peripheral will be "chars" (8 bits
> > long). Where should I attach the peripheral? I mean: D7-0? D15-8?
> > D23-16? D31-24? D39-32? D47-40? D55-48? D63-56??
> 

Hello,

I am posting this reply I got from adsp@yahoogroups.com (by Clifford van Dyk
). Any comment? More ideas which arise from th is posting? Thanks a lot

Hi Jaime

Firstly, the 21160's native word type is 32-bit. Bytes (chars) are 
treated as 32-bit wide and are stored in consecutive 32-bit locations 
in 
memory, with the remaining 3 bytes of each word being wasted. The DMA 
transfers to the external port will also be 32-bit. Setting up a 32-bit 
DMA with an incrementing address will result in the WRL# strobe being 
asserted for even address accesses and the WRH# strobe being asserted 
for odd address accesses. If your peripheral only has one address 
location (e.g. a FIFO), then the address does not increment for 
consecutive writes, and only one of the two strobes is asserted. If 
your 
device has multiple memory locations, you can set up the DMA with a 
stride of 2 to ensure that accesses only take place to either an even 
or 
an odd memory location. You should then not use ADDR0 as part of the 
addressing to the device. Note: This affects the alignment of the 
address to the device (SHARC ADDR1<->Device ADDR0, etc.), as well as 
the 
addresses used in software (which will be all even or all odd).

The MSx# lines  are necessary when you have more than on device 
(including HOSTs and other DSPs) on the external bus, and they 
effectively act as built-in address decoding. If you have more than one 
device on the external bus, then I would highly recommend that you use 
them. Essentially, they eliminate the requirement that you have to 
fully 
decode the entire 32 bits of addressing, as well as allowing for 
different timing to peripherals on the external port. They essentialy 
segment the external memory space into multiple regions. Devices may be 
placed in each of the regions, and the timing to each region can be 
different. No peripheral should drive the bus unless the external 
address has been fully decoded. The MSx lines make this simpler, 
particularly if only one device is placed in each memory space, since 
as 
soon as the MSx line is asserted, the peripheral knows that it is the 
only device that may drive the bus.

So, in summary:

* Use MSx as part of your address decoding.
* Connect Address lines as follows: SHARC ADDR[1..N] <-> DEVICE  
ADDR[0..N-1]
* Choose whether to use even or odd addresses.
* Connect SHARC DATA[0..7] to device DATA[0..7] for even addresses or 
SHARC DATA[32..39] to device DATA[0..7] for odd addresses. (any other 
configuration will require bit shifting in software).
* Use only WRH#(for odd addresses) or WRL#(for even addresses) strobe 
for writes, and RD# strobe for reads.
* Set up DMA to perform 32-bit DMA with a stride of 2.
* Use ACK to control timing, if you cannot meet the required timing of 
the peripheral by means of internal wait cycles alone.

Regards,
Clifford van Dyk

Design Engineer
Peralex Electronics (Pty) Ltd.

*******
JaaC

"Jaime Andres Aranguren Cardona" <jaime.aranguren@ieee.org> wrote in message
news:14a86f87.0308161051.a661ea2@posting.google.com...
> "Bhaskar Thiagarajan" <bhaskart@deja.com> wrote in message
news:<bhjrsc$bfha$1@ID-82263.news.uni-berlin.de>...
> > "Jaime Andres Aranguren Cardona" <jaime.aranguren@ieee.org> wrote in
message
> > news:14a86f87.0308151533.33817f76@posting.google.com...
> > > Good day,
> > >
> > > Hopefully some of you can give me some enlightment to figure out a
> > > solution on how to connect an 8bit-wide peripheral to an ADSP-21160.
> > >
> > > It's a rather asymmetric bidirectional connection, the "traffic" is
> > > higher from the DSP to the peripheral than from the peripheral to the
> > > DSP.
> > >
> > > Some of the features I want to use are:
> > >
> > > - Memory mapped peripheral.
> > > - Don't need to use the MS3-0 signals (useless for the peripheral I
> > > work with).
> > > - I want to use the EPort in Asynchronous Bus Master mode, so the
> > > peripheral (which is much slower than the DSP) controls when _can_ the
> > > DSP send data to it by means of the ACK input to the DSP.
> > > - I would like to use DMA transfers from the DSP to the peripheral, so
> > > the DSP can continue crunching data. The DSP determines when should
> > > the data be transmitted, and how much data should be transmitted.
> > > - For the transmission of data from the peripheral to the DSP, it can
> > > be done by means of interrupts (generated by the peripheral). Data
> > > transmitted in this direction is more targeted to control than to
> > > streams of data.
> > >
> > > My main doubt is about how to connect the peripheral to the DSP. From
> > > figure 7-1, page 7-2 in the '160's manual, it states than for 32-bit
> > > normal words, both W(R) L and w will be asserted alternatively,
> > > between the accesses to even and odd addresses. Should I then use
> > > these control pins ORed??? Isn't there a way to use them in a simpler
> > > way? From the higher part of the same figure I deduce that all the
> > > transfers done my means of DMA will be 64 bits long. What about that?
> > > The data I'll transfer to the peripheral will be "chars" (8 bits
> > > long). Where should I attach the peripheral? I mean: D7-0? D15-8?
> > > D23-16? D31-24? D39-32? D47-40? D55-48? D63-56??
> >
>
> Hello,
>
> I am posting this reply I got from adsp@yahoogroups.com (by Clifford van
Dyk
> ). Any comment? More ideas which arise from th is posting? Thanks a lot

What he said jives with my earlier post. I recommend using odd addresses.

BTW, In the recent past, I have been pleasantly surprised by some of ADI
support's responses to questions - fairly clear, detailed and informative
responses. In fact I have one response which I think they should just cut
and paste into their user manual.


>
> Hi Jaime
>
> Firstly, the 21160's native word type is 32-bit. Bytes (chars) are
> treated as 32-bit wide and are stored in consecutive 32-bit locations
> in
> memory, with the remaining 3 bytes of each word being wasted. The DMA
> transfers to the external port will also be 32-bit. Setting up a 32-bit
> DMA with an incrementing address will result in the WRL# strobe being
> asserted for even address accesses and the WRH# strobe being asserted
> for odd address accesses. If your peripheral only has one address
> location (e.g. a FIFO), then the address does not increment for
> consecutive writes, and only one of the two strobes is asserted. If
> your
> device has multiple memory locations, you can set up the DMA with a
> stride of 2 to ensure that accesses only take place to either an even
> or
> an odd memory location. You should then not use ADDR0 as part of the
> addressing to the device. Note: This affects the alignment of the
> address to the device (SHARC ADDR1<->Device ADDR0, etc.), as well as
> the
> addresses used in software (which will be all even or all odd).
>
> The MSx# lines  are necessary when you have more than on device
> (including HOSTs and other DSPs) on the external bus, and they
> effectively act as built-in address decoding. If you have more than one
> device on the external bus, then I would highly recommend that you use
> them. Essentially, they eliminate the requirement that you have to
> fully
> decode the entire 32 bits of addressing, as well as allowing for
> different timing to peripherals on the external port. They essentialy
> segment the external memory space into multiple regions. Devices may be
> placed in each of the regions, and the timing to each region can be
> different. No peripheral should drive the bus unless the external
> address has been fully decoded. The MSx lines make this simpler,
> particularly if only one device is placed in each memory space, since
> as
> soon as the MSx line is asserted, the peripheral knows that it is the
> only device that may drive the bus.
>
> So, in summary:
>
> * Use MSx as part of your address decoding.
> * Connect Address lines as follows: SHARC ADDR[1..N] <-> DEVICE
> ADDR[0..N-1]
> * Choose whether to use even or odd addresses.
> * Connect SHARC DATA[0..7] to device DATA[0..7] for even addresses or
> SHARC DATA[32..39] to device DATA[0..7] for odd addresses. (any other
> configuration will require bit shifting in software).
> * Use only WRH#(for odd addresses) or WRL#(for even addresses) strobe
> for writes, and RD# strobe for reads.
> * Set up DMA to perform 32-bit DMA with a stride of 2.
> * Use ACK to control timing, if you cannot meet the required timing of
> the peripheral by means of internal wait cycles alone.
>
> Regards,
> Clifford van Dyk
>
> Design Engineer
> Peralex Electronics (Pty) Ltd.
>
> *******
> JaaC

"Bhaskar Thiagarajan" <bhaskart@deja.com> wrote in message
news:bhqsgt$26si9$1@ID-82263.news.uni-berlin.de...
>
> "Jaime Andres Aranguren Cardona" <jaime.aranguren@ieee.org> wrote in
message
> news:14a86f87.0308161051.a661ea2@posting.google.com...
> > "Bhaskar Thiagarajan" <bhaskart@deja.com> wrote in message
> news:<bhjrsc$bfha$1@ID-82263.news.uni-berlin.de>...
> > > "Jaime Andres Aranguren Cardona" <jaime.aranguren@ieee.org> wrote in
> message
> > > news:14a86f87.0308151533.33817f76@posting.google.com...
> > > > Good day,
> > > >
> > > > Hopefully some of you can give me some enlightment to figure out a
> > > > solution on how to connect an 8bit-wide peripheral to an ADSP-21160.
> > > >
> > > > It's a rather asymmetric bidirectional connection, the "traffic" is
> > > > higher from the DSP to the peripheral than from the peripheral to
the
> > > > DSP.
> > > >
> > > > Some of the features I want to use are:
> > > >
> > > > - Memory mapped peripheral.
> > > > - Don't need to use the MS3-0 signals (useless for the peripheral I
> > > > work with).
> > > > - I want to use the EPort in Asynchronous Bus Master mode, so the
> > > > peripheral (which is much slower than the DSP) controls when _can_
the
> > > > DSP send data to it by means of the ACK input to the DSP.
> > > > - I would like to use DMA transfers from the DSP to the peripheral,
so
> > > > the DSP can continue crunching data. The DSP determines when should
> > > > the data be transmitted, and how much data should be transmitted.
> > > > - For the transmission of data from the peripheral to the DSP, it
can
> > > > be done by means of interrupts (generated by the peripheral). Data
> > > > transmitted in this direction is more targeted to control than to
> > > > streams of data.
> > > >
> > > > My main doubt is about how to connect the peripheral to the DSP.
From
> > > > figure 7-1, page 7-2 in the '160's manual, it states than for 32-bit
> > > > normal words, both W(R) L and w will be asserted alternatively,
> > > > between the accesses to even and odd addresses. Should I then use
> > > > these control pins ORed??? Isn't there a way to use them in a
simpler
> > > > way? From the higher part of the same figure I deduce that all the
> > > > transfers done my means of DMA will be 64 bits long. What about
that?
> > > > The data I'll transfer to the peripheral will be "chars" (8 bits
> > > > long). Where should I attach the peripheral? I mean: D7-0? D15-8?
> > > > D23-16? D31-24? D39-32? D47-40? D55-48? D63-56??
> > >
> >
> > Hello,
> >
> > I am posting this reply I got from adsp@yahoogroups.com (by Clifford van
> Dyk
> > ). Any comment? More ideas which arise from th is posting? Thanks a lot
>
> What he said jives with my earlier post. I recommend using odd addresses.
>
> BTW, In the recent past, I have been pleasantly surprised by some of ADI
> support's responses to questions - fairly clear, detailed and informative
> responses. In fact I have one response which I think they should just cut
> and paste into their user manual.

Oops - undue credit to ADI support (I thought Cliff was from ADI).
Nevertheless, I did get some decent responses.


> >
> > Hi Jaime
> >
> > Firstly, the 21160's native word type is 32-bit. Bytes (chars) are
> > treated as 32-bit wide and are stored in consecutive 32-bit locations
> > in
> > memory, with the remaining 3 bytes of each word being wasted. The DMA
> > transfers to the external port will also be 32-bit. Setting up a 32-bit
> > DMA with an incrementing address will result in the WRL# strobe being
> > asserted for even address accesses and the WRH# strobe being asserted
> > for odd address accesses. If your peripheral only has one address
> > location (e.g. a FIFO), then the address does not increment for
> > consecutive writes, and only one of the two strobes is asserted. If
> > your
> > device has multiple memory locations, you can set up the DMA with a
> > stride of 2 to ensure that accesses only take place to either an even
> > or
> > an odd memory location. You should then not use ADDR0 as part of the
> > addressing to the device. Note: This affects the alignment of the
> > address to the device (SHARC ADDR1<->Device ADDR0, etc.), as well as
> > the
> > addresses used in software (which will be all even or all odd).
> >
> > The MSx# lines  are necessary when you have more than on device
> > (including HOSTs and other DSPs) on the external bus, and they
> > effectively act as built-in address decoding. If you have more than one
> > device on the external bus, then I would highly recommend that you use
> > them. Essentially, they eliminate the requirement that you have to
> > fully
> > decode the entire 32 bits of addressing, as well as allowing for
> > different timing to peripherals on the external port. They essentialy
> > segment the external memory space into multiple regions. Devices may be
> > placed in each of the regions, and the timing to each region can be
> > different. No peripheral should drive the bus unless the external
> > address has been fully decoded. The MSx lines make this simpler,
> > particularly if only one device is placed in each memory space, since
> > as
> > soon as the MSx line is asserted, the peripheral knows that it is the
> > only device that may drive the bus.
> >
> > So, in summary:
> >
> > * Use MSx as part of your address decoding.
> > * Connect Address lines as follows: SHARC ADDR[1..N] <-> DEVICE
> > ADDR[0..N-1]
> > * Choose whether to use even or odd addresses.
> > * Connect SHARC DATA[0..7] to device DATA[0..7] for even addresses or
> > SHARC DATA[32..39] to device DATA[0..7] for odd addresses. (any other
> > configuration will require bit shifting in software).
> > * Use only WRH#(for odd addresses) or WRL#(for even addresses) strobe
> > for writes, and RD# strobe for reads.
> > * Set up DMA to perform 32-bit DMA with a stride of 2.
> > * Use ACK to control timing, if you cannot meet the required timing of
> > the peripheral by means of internal wait cycles alone.
> >
> > Regards,
> > Clifford van Dyk
> >
> > Design Engineer
> > Peralex Electronics (Pty) Ltd.
> >
> > *******
> > JaaC
>
>

Thanks for the comments,

I've decided to connect the peripheral D7-0 to DSP's D39-32. That way,
I can use either 32 bit DMA with stride of 2, or 32 bit packed DMA (at
the moment I don't know which one exactly to use). Could someone,
please, elaborate further on 32bit packed DMA? How to use that? I am
affraid, that if I use 32 bit DMA with only the odd addresses, and a
DMA stride of 2, I'll waste internal memory on the DSP, because I'd
had to write my data to a buffer which is twice as big as needed, and
only half of it will be actually read, specifically, the locations
with odd addresses.

My peripheral has no CS signal, for using the MSx signal of the DSP.
Besides that, I've found on the HW system that MS2 and MS3 are free,
so I've decided to use this kind of connection:

DSP Side                Peripheral
MS2# or'ed WRH#    ---->   WR#
MS2# or'ed RDH#    ---->   RD#

(Or'ed means using a logic "OR" gate) Any opinions about this?

Another issue: I need to use the ACK signal, to control the speed at
which data is written to the peripheral, but the transfes should be
started by the DSP. I've found in the 21160's manual, that in Master
Mode, the DSP initiates the transfers, but at a speed that the DMA
buffers are always full. Isn't it possible to use the ACK signal in
this mode? What about waitstates (can they be used)? It could be
helpful to use the Paced Master mode, bucause I could use the ACK
signal (as states on the manual). However, the drawback is that in
this mode the transfer is initiated by the peripheral with a DMA
request (DMARx#), which is something I can't do with my peripheral.
Any suggestions?

More generally: What's the relation between the DMA modes (Master,
Paced Master, Slave, Handshake, External Handshake) and having an
Asynchronous or a Synchronous transfer? I understand each concept
separately, but not the relation (or rejection) between them. All of
your comments and clarifications are VERY welcome (indeed, they are
NEEDED!)

Regards,

JaaC

"Jaime Andres Aranguren Cardona" <jaime.aranguren@ieee.org> wrote in message
news:14a86f87.0308181934.321b92ce@posting.google.com...
> Thanks for the comments,
>
> I've decided to connect the peripheral D7-0 to DSP's D39-32. That way,
> I can use either 32 bit DMA with stride of 2, or 32 bit packed DMA (at
> the moment I don't know which one exactly to use). Could someone,
> please, elaborate further on 32bit packed DMA? How to use that? I am
> affraid, that if I use 32 bit DMA with only the odd addresses, and a
> DMA stride of 2, I'll waste internal memory on the DSP, because I'd
> had to write my data to a buffer which is twice as big as needed, and
> only half of it will be actually read, specifically, the locations
> with odd addresses.

Read page 6-29 - section on 32 bit external transfers. You will want to use
PMODE = 100. See table 6-2 for details on this mode.
It says in page 6-29 that all values of EI, Em and EC are allowed.
When you do DMA transfers from internal to external , you can specify the
internal step as well as the external step (as well as the count and
starting address) using the IMx and EMx registers. So I don't see the stride
of 2 as a problem for you (esp. on the internal side). You can set the
internal stride to 1 and external to 2.

> My peripheral has no CS signal, for using the MSx signal of the DSP.
> Besides that, I've found on the HW system that MS2 and MS3 are free,
> so I've decided to use this kind of connection:
>
> DSP Side                Peripheral
> MS2# or'ed WRH#    ---->   WR#
> MS2# or'ed RDH#    ---->   RD#
>
> (Or'ed means using a logic "OR" gate) Any opinions about this?
>
> Another issue: I need to use the ACK signal, to control the speed at
> which data is written to the peripheral, but the transfes should be
> started by the DSP. I've found in the 21160's manual, that in Master
> Mode, the DSP initiates the transfers, but at a speed that the DMA
> buffers are always full. Isn't it possible to use the ACK signal in

What this means is that the DMA makes sure that the buffers aren't starved
for data. So if your peripheral slows down the transfer rate using the ACK
signal, the DMA engine will also adjust and slow down. So you should be able
to use the Master mode (unless my understanding of how the ACK works is
wrong).

Cheers
Bhaskar

> this mode? What about waitstates (can they be used)? It could be
> helpful to use the Paced Master mode, bucause I could use the ACK
> signal (as states on the manual). However, the drawback is that in
> this mode the transfer is initiated by the peripheral with a DMA
> request (DMARx#), which is something I can't do with my peripheral.
> Any suggestions?
>
> More generally: What's the relation between the DMA modes (Master,
> Paced Master, Slave, Handshake, External Handshake) and having an
> Asynchronous or a Synchronous transfer? I understand each concept
> separately, but not the relation (or rejection) between them. All of
> your comments and clarifications are VERY welcome (indeed, they are
> NEEDED!)
>
> Regards,
>
> JaaC