DSPRelated.com
Forums

Re: Switching speed of GPIO

Started by Jeff Brower July 8, 2008
Albert-

If you expect 30 Mbit/sec for *processed* data output to the MCU, then what is the
total bandwidth of all the unprocessed codecs? It sounds to me like if you have
enough codecs -- doubled on two separate FPGAs -- then your serial data rate will be
far higher than 25 to 35 Mbit/sec on each McBSP, which is a "safe" rate for McBSP.

I might suggest you consider UTOPIA for the "third pipe" (MCU or other). Other than
HPI and EMIF, there isn't going to be an another peripheral alternative that gives
you sustained, high bandwidth if, at the same time, you have 2 McBSP ports pushed to
the limit. Maybe the EMAC is an option, but I'm guessing you need the processed data
flow to be tightly synchronized with what's happening on the codec side, not as easy
to do with packet data.

-Jeff
>
> Actually in my experiment I just pump data to the GPIO to implement the SPI and do
not do any other task so I can get the 5Mbit/s. Which means that in real life I
cannot get this 5Mbit/s since I need to perform many other different task.

In my current design, I connect a huge amount of audio CODEC to a FPGA. All the
CODEC will work in an almost real time continuously. MCBSP channel switching seems
not allowable due to the almost real time continuously data sampling requirement.
Those CODEC sample data will pass to the DSP for processing form the FPGA via the
MCBSP port. Since computering power of DSP is quite large so I design to use both
MCBSP channel of the DSP to connect to two different FPGA for receiving more
sampled data in parallel.

The serial interface is just use to send the processed data from the DSP to another
FPGA / MCU ... for next stage of data processing. Actually it is not limited to
serial bus it can be a parallel bus but I think the SPI serial bus is more easily
to implement so use it as a trial. The only limitation about this bus is the data
rate and it is expect to be ~30Mbit/s per each FPGA connected to the DSP via the
MCBSP port stated above.

Thanks for your kind help.

Best Regards,
Albert Siu

--- 2008???7?7?? ????EUR??Jeff Brower ?????

????????: Jeff Brower
????: Re: [c6x] Switching speed og GPIO
????????: "Albert Siu"
????(CC): c...
???: 2008 7 7 ????EUR ??? 1:09

Albert-

> I am using the DSK6455 which includes two MCBSP port and these two
>
MCBSP port of 6455 can be use as a SPI interface. In my system I use
> both MCBSP port to interface with ADC/DAC so there is no free MCBSP
port..
>
> As I need another port to interface with a MCU which require a data
> rate at about 30Mb/s, so I decided to use the SPI interface. Since
> there is no free MCBSP port in my system, I use the GPIO to implement
> the SPI myself. After the implementation, I find that the clock speed
> of this GPIO type SPI interface is around 5Mb/s. My problem is as
below:
>
> 1. Is there any better solution that I can use to link the MCU and DSP
> together with a data rate of ~30Mb/s.
> 2. Do anyone have try this GPIO type SPI interface approach and have
> figure on the maximum data rate about it?

Regarding GPIO-based serial I/O, I'm surprised that you could obtain 5
Mbit/sec. I
would have thought it would be slower. GPIO is only
accessible on C64x devices
via
CPU instructions, i.e. 'brute force'. As there is no DMA or other
hardware circuitry
'dedicated' to GPIO data rate, GPIO is subject to CPU stalls due to
onchip
competition for internal memory busses. I've seen delays in the range of
150 nsec
when trying to toggle a GPIO pin.

Is there a requirement to use serial I/O for your MCU? Can you use
another
method,
for example HPI, to talk with the MCU?

Another option is to devise a way to use 1 McBSP for the audio I/O
interface.
I
think it's a waste of a McBSP for the "control" interface of an
audio I/O codec, as
is done on the DSK6455 and other DSK boards that use AIC23 series audio
codec
devices. Control and data communication is rarely, if ever needed at the
same
time.
A clever design using a bus switch or mux could be
implemented.

-Jeff

>
Dear Jeff,

Noted with thanks. I will sped some time to study the UTOPIA, HPI and EMIF and test it later.

Albert Siu

--- 2008年7月8日 星期二,Jeff Brower 寫道﹕
寄件人: Jeff Brower
主題: Re: [c6x] Switching speed of GPIO
收件人: "Albert Ciu"
副本(CC): c...
日期: 2008 7 8 星期二 上午 7:43

Albert-
If you expect 30 Mbit/sec for *processed* data output
to the MCU, then what is the total bandwidth of all the unprocessed codecs? 
It sounds to me like if you have enough codecs -- doubled on two separate
FPGAs -- then your serial data rate will be far higher than 25 to 35 Mbit/sec
on each McBSP, which is a "safe" rate for McBSP.
I might suggest you consider UTOPIA for the "third
pipe" (MCU or other).  Other than HPI and EMIF, there isn't going
to be an another peripheral alternative that gives you sustained, high
bandwidth if, at the same time, you have 2 McBSP ports pushed to the limit. 
Maybe the EMAC is an option, but I'm guessing you need the processed data
flow to be tightly synchronized with what's happening on the codec side,
not as easy to do with packet data.
-Jeff

 
 
Actually in my
experiment I just pump data to the GPIO to implement the SPI and do not
do any other task so I can get the 5Mbit/s. Which means that in real life
I cannot get this 5Mbit/s since I need to perform many other different
task.
In my current design, I connect a huge amount of audio
CODEC to a FPGA. All the CODEC will work in an almost real time continuously.
MCBSP channel switching seems not allowable due to the almost real time
continuously data sampling requirement. Those CODEC sample data will pass
to the DSP for processing form the FPGA via the MCBSP port. Since computering
power of DSP is quite large so I design to use both MCBSP channel of the
DSP to connect to two different FPGA for receiving more sampled data in
parallel.
The serial interface is just use to send the processed
data from the DSP to another FPGA / MCU ... for next stage of data processing.
Actually it is not limited to serial bus it can be a parallel bus but I
think the SPI serial bus is more easily to implement so use it as a trial.
The only limitation about this bus is the data rate and it is expect to
be ~30Mbit/s per each FPGA connected to the DSP via the MCBSP port stated
above.
Thanks for your kind help.
Best Regards,

Albert Siu
--- 2008年7�7�
��一�Jeff Brower
寫��
�件人:
Jeff Brower

主�: Re: [c6x] Switching
speed og GPIO

�件人:
"Albert Siu"

��(CC): c...

��: 2008 7 7 ��一
�� 1:09
Albert-

> I am using the DSK6455 which includes two MCBSP port and these two

>

 MCBSP port of 6455 can be use as a SPI interface. In my system I
use

> both MCBSP port to interface with ADC/DAC so there is no free MCBSP port...



> As I need another port to interface with a MCU which require a data

> rate at about 30Mb/s, so I decided to use the SPI interface. Since

> there is no free MCBSP port in my system, I use the GPIO to implement

> the SPI myself. After the implementation, I find that the clock speed

> of this GPIO type SPI interface is around 5Mb/s. My problem is as below:



> 1. Is there any better solution that I can use to link the MCU and DSP

> together with a data rate of ~30Mb/s.

> 2. Do anyone have try this GPIO type SPI interface approach and have

> figure on the maximum data rate about it?

Regarding GPIO-based serial I/O, I'm surprised that you could obtain 5

Mbit/sec.  I

would have thought it would be slower.  GPIO is only

 accessible on C64x devices

via

CPU instructions, i.e. 'brute force'.  As there is no DMA or other

hardware circuitry

'dedicated' to GPIO data rate, GPIO is subject to CPU stalls due to

onchip

competition for internal memory busses.  I've seen delays in the range
of

150 nsec

when trying to toggle a GPIO pin.

Is there a requirement to use serial I/O for your MCU?  Can you use
another

method,

for example HPI, to talk with the MCU?

Another option is to devise a way to use 1 McBSP for the audio I/O interface. 

I

think it's a waste of a McBSP for the "control" interface of an

audio I/O codec, as

is done on the DSK6455 and other DSK boards that use AIC23 series audio
codec

devices.  Control and data communication is rarely, if ever needed
at the same

time. 

A clever design using a bus switch or mux could be

 implemented.

-Jeff

_______________________________________
YM - 離線訊息
就算你沒有上網,你的朋友仍可以留下訊息給你,當你上網時就能立即看到,任何說話都冇走失。
http://messenger.yahoo.com.hk
SGVsbG8gQWxiZXJ0LAoKQWxvbmcgdGhlIGxpbmVzIG9mIEplZmYncyBzdWdnZXN0aW9ucy4u
LgpNYWtlIHN1cmUgdGhhdCB5b3UgYXJlIHRha2luZyBhIHN5c3RlbXMgYXBwcm9hY2ggdG8g
eW91ciBkZXNpZ24uIEkgZG8Kbm90IGtub3cgYWxsIG9mIHRoZSBjb25zdHJhaW50cyBvZiB5
b3VyIGRlc2lnbiwgYnV0IGhlcmUgYXJlIHNvbWUgb2YKbXkgdGhvdWdodHMgYmFzZWQgb24g
d2hhdCBJIGtub3cuCklmIDMwIE1iL3NlYy9GUEdBIGlzIHlvdXIgZGF0YSByYXRlIFt5b3Ug
c2hvdWxkIGJlIGFibGUgdG8gZGV0ZXJtaW5lCnRoZSByYXRlIGZhaXJseSBhY2N1cmF0ZWx5
IGlmIHlvdSBoYXZlbid0IGFscmVhZHldIGFuZCB5b3UgYXJlIHVzaW5nCkZQR0FzLCB5b3Ug
Y291bGQgY29uZmlndXJlIGVhY2ggd2l0aCBhbiA4IGJpdCBwYXJhbGxlbCBpbnRlcmZhY2Ug
YW5kCmNvbm5lY3QgZWFjaCBvbmUgdG8gOCBkaWZmZXJlbnQgRU1JRiBkYXRhIGJpdHMgZm9y
IGEgMy43NSBNaHogcmF0ZS4KWW91IGNvdWxkIGFsc28gaW1wbGVtZW50IGFuIDgvMTYgcGFy
YWxsZWwgaW50ZXJmYWNlIHRvIHRoZSBNQ1UgW2lmIGl0CnN1cHBvcnRzIGl0XSB3aXRoIGFu
IEZQR0EgW3lvdSBjb3VsZCBldmVuIHB1dCBpbiBhIEZJRk9dLiBBbGwgb2YgdGhpcwpjb3Vs
ZCBiZSBwdXQgb24gYSBzaW5nbGUgZGF1Z2h0ZXJjYXJkIHRvIGNyZWF0ZSBhIHByb3RvdHlw
ZS4gQWx0aG91Z2gKdGhlcmUgYXJlIG90aGVyIG9wdGlvbnMsIHVzaW5nIHBhcmFsbGVsIGlu
dGVyZmFjZXMgd2lsbCBzaW1wbGlmeSB0aGUKRlBHQSBsb2dpYyBhbmQgdGhlIERTUCBjb2Rl
LiAgVGhpcyB3aWxsIGFsbG93IHlvdSB0byBnZXQgYSBwcm90b3R5cGUKdXAgYW5kIHJ1bm5p
bmcgd2l0aCBsZXNzICd0aHJvdyBhd2F5JyBjb2RlLgoKbWlrZWR1bm4KCjIwMDgvNy84ICA8
aGthczIwMDgtYWxsQHlhaG9vLmNvbS5oaz46Cj4gRGVhciBKZWZmLAo+Cj4gTm90ZWQgd2l0
aCB0aGFua3MuIEkgd2lsbCBzcGVkIHNvbWUgdGltZSB0byBzdHVkeSB0aGUgVVRPUElBLCBI
UEkgYW5kIEVNSUYKPiBhbmQgdGVzdCBpdCBsYXRlci4KPgo+IEFsYmVydCBTaXUKPgo+IC0t
LSAyMDA45bm0N+aciDjml6Ug5pif5pyf5LqM77yMSmVmZiBCcm93ZXIgPGpicm93ZXJAc2ln
bmFsb2dpYy5jb20+IOWvq+mBk++5lQo+Cj4g5a+E5Lu25Lq6OiBKZWZmIEJyb3dlciA8amJy
b3dlckBzaWduYWxvZ2ljLmNvbT4KPiDkuLvpoYw6IFJlOiBbYzZ4XSBTd2l0Y2hpbmcgc3Bl
ZWQgb2YgR1BJTwo+IOaUtuS7tuS6ujogIkFsYmVydCBDaXUiIDxoa2FzMjAwOC1hbGxAeWFo
b28uY29tLmhrPgo+IOWJr+acrChDQyk6IGM2eEB5YWhvb2dyb3Vwcy5jb20KPiDml6XmnJ86
IDIwMDggNyA4IOaYn+acn+S6jCDkuIrljYggNzo0Mwo+Cj4gQWxiZXJ0LQo+Cj4gSWYgeW91
IGV4cGVjdCAzMCBNYml0L3NlYyBmb3IgKnByb2Nlc3NlZCogZGF0YSBvdXRwdXQgdG8gdGhl
IE1DVSwgdGhlbiB3aGF0Cj4gaXMgdGhlIHRvdGFsIGJhbmR3aWR0aCBvZiBhbGwgdGhlIHVu
cHJvY2Vzc2VkIGNvZGVjcz8gIEl0IHNvdW5kcyB0byBtZSBsaWtlCj4gaWYgeW91IGhhdmUg
ZW5vdWdoIGNvZGVjcyAtLSBkb3VibGVkIG9uIHR3byBzZXBhcmF0ZSBGUEdBcyAtLSB0aGVu
IHlvdXIKPiBzZXJpYWwgZGF0YSByYXRlIHdpbGwgYmUgZmFyIGhpZ2hlciB0aGFuIDI1IHRv
IDM1IE1iaXQvc2VjIG9uIGVhY2ggTWNCU1AsCj4gd2hpY2ggaXMgYSAic2FmZSIgcmF0ZSBm
b3IgTWNCU1AuCj4KPiBJIG1pZ2h0IHN1Z2dlc3QgeW91IGNvbnNpZGVyIFVUT1BJQSBmb3Ig
dGhlICJ0aGlyZCBwaXBlIiAoTUNVIG9yIG90aGVyKS4KPiBPdGhlciB0aGFuIEhQSSBhbmQg
RU1JRiwgdGhlcmUgaXNuJ3QgZ29pbmcgdG8gYmUgYW4gYW5vdGhlciBwZXJpcGhlcmFsCj4g
YWx0ZXJuYXRpdmUgdGhhdCBnaXZlcyB5b3Ugc3VzdGFpbmVkLCBoaWdoIGJhbmR3aWR0aCBp
ZiwgYXQgdGhlIHNhbWUgdGltZSwKPiB5b3UgaGF2ZSAyIE1jQlNQIHBvcnRzIHB1c2hlZCB0
byB0aGUgbGltaXQuICBNYXliZSB0aGUgRU1BQyBpcyBhbiBvcHRpb24sCj4gYnV0IEknbSBn
dWVzc2luZyB5b3UgbmVlZCB0aGUgcHJvY2Vzc2VkIGRhdGEgZmxvdyB0byBiZSB0aWdodGx5
IHN5bmNocm9uaXplZAo+IHdpdGggd2hhdCdzIGhhcHBlbmluZyBvbiB0aGUgY29kZWMgc2lk
ZSwgbm90IGFzIGVhc3kgdG8gZG8gd2l0aCBwYWNrZXQgZGF0YS4KPgo+IC1KZWZmCj4KPgo+
Cj4gQWN0dWFsbHkgaW4gbXkgZXhwZXJpbWVudCBJIGp1c3QgcHVtcCBkYXRhIHRvIHRoZSBH
UElPIHRvIGltcGxlbWVudCB0aGUgU1BJCj4gYW5kIGRvIG5vdCBkbyBhbnkgb3RoZXIgdGFz
ayBzbyBJIGNhbiBnZXQgdGhlIDVNYml0L3MuIFdoaWNoIG1lYW5zIHRoYXQgaW4KPiByZWFs
IGxpZmUgSSBjYW5ub3QgZ2V0IHRoaXMgNU1iaXQvcyBzaW5jZSBJIG5lZWQgdG8gcGVyZm9y
bSBtYW55IG90aGVyCj4gZGlmZmVyZW50IHRhc2suCj4KPiBJbiBteSBjdXJyZW50IGRlc2ln
biwgSSBjb25uZWN0IGEgaHVnZSBhbW91bnQgb2YgYXVkaW8gQ09ERUMgdG8gYSBGUEdBLiBB
bGwKPiB0aGUgQ09ERUMgd2lsbCB3b3JrIGluIGFuIGFsbW9zdCByZWFsIHRpbWUgY29udGlu
dW91c2x5LiBNQ0JTUCBjaGFubmVsCj4gc3dpdGNoaW5nIHNlZW1zIG5vdCBhbGxvd2FibGUg
ZHVlIHRvIHRoZSBhbG1vc3QgcmVhbCB0aW1lIGNvbnRpbnVvdXNseSBkYXRhCj4gc2FtcGxp
bmcgcmVxdWlyZW1lbnQuIFRob3NlIENPREVDIHNhbXBsZSBkYXRhIHdpbGwgcGFzcyB0byB0
aGUgRFNQIGZvcgo+IHByb2Nlc3NpbmcgZm9ybSB0aGUgRlBHQSB2aWEgdGhlIE1DQlNQIHBv
cnQuIFNpbmNlIGNvbXB1dGVyaW5nIHBvd2VyIG9mIERTUAo+IGlzIHF1aXRlIGxhcmdlIHNv
IEkgZGVzaWduIHRvIHVzZSBib3RoIE1DQlNQIGNoYW5uZWwgb2YgdGhlIERTUCB0byBjb25u
ZWN0Cj4gdG8gdHdvIGRpZmZlcmVudCBGUEdBIGZvciByZWNlaXZpbmcgbW9yZSBzYW1wbGVk
IGRhdGEgaW4gcGFyYWxsZWwuCj4KPiBUaGUgc2VyaWFsIGludGVyZmFjZSBpcyBqdXN0IHVz
ZSB0byBzZW5kIHRoZSBwcm9jZXNzZWQgZGF0YSBmcm9tIHRoZSBEU1AgdG8KPiBhbm90aGVy
IEZQR0EgLyBNQ1UgLi4uIGZvciBuZXh0IHN0YWdlIG9mIGRhdGEgcHJvY2Vzc2luZy4gQWN0
dWFsbHkgaXQgaXMgbm90Cj4gbGltaXRlZCB0byBzZXJpYWwgYnVzIGl0IGNhbiBiZSBhIHBh
cmFsbGVsIGJ1cyBidXQgSSB0aGluayB0aGUgU1BJIHNlcmlhbAo+IGJ1cyBpcyBtb3JlIGVh
c2lseSB0byBpbXBsZW1lbnQgc28gdXNlIGl0IGFzIGEgdHJpYWwuIFRoZSBvbmx5IGxpbWl0
YXRpb24KPiBhYm91dCB0aGlzIGJ1cyBpcyB0aGUgZGF0YSByYXRlIGFuZCBpdCBpcyBleHBl
Y3QgdG8gYmUgfjMwTWJpdC9zIHBlciBlYWNoCj4gRlBHQSBjb25uZWN0ZWQgdG8gdGhlIERT
UCB2aWEgdGhlIE1DQlNQIHBvcnQgc3RhdGVkIGFib3ZlLgo+Cj4gVGhhbmtzIGZvciB5b3Vy
IGtpbmQgaGVscC4KPgo+IEJlc3QgUmVnYXJkcywKPiBBbGJlcnQgU2l1Cj4KPiAtLS0gMjAw
OMOlwrnCtDfDpu+/ve+/vTfDpu+/vcKlIMOm77+977+9w6bvv73vv73DpMK44oKsw6/CvO+/
vUplZmYgQnJvd2VyIDxqYnJvd2VyQHNpZ25hbG9naWMuY29tPgo+IMOlwq/Cq8Op77+977+9
w6/Cue+/vQo+Cj4gw6XCr++/vcOkwrvCtsOkwrrCujogSmVmZiBCcm93ZXIgPGpicm93ZXJA
c2lnbmFsb2dpYy5jb20+Cj4gw6TCuMK7w6nCoe+/vTogUmU6IFtjNnhdIFN3aXRjaGluZyBz
cGVlZCBvZyBHUElPCj4gw6bvv73CtsOkwrvCtsOkwrrCujogIkFsYmVydCBTaXUiIDxoa2Fz
MjAwOC1hbGxAeWFob28uY29tLmhrPgo+IMOl77+9wq/Dpu+/vcKsKENDKTogYzZ4QHlhaG9v
Z3JvdXBzLmNvbQo+IMOm77+9wqXDpu+/ve+/vTogMjAwOCA3IDcgw6bvv73vv73Dpu+/ve+/
vcOkwrjigqwgw6TCuO+/vcOl77+977+9IDE6MDkKPgo+IEFsYmVydC0KPgo+PiBJIGFtIHVz
aW5nIHRoZSBEU0s2NDU1IHdoaWNoIGluY2x1ZGVzIHR3byBNQ0JTUCBwb3J0IGFuZCB0aGVz
ZSB0d28KPj4KPiAgTUNCU1AgcG9ydCBvZiA2NDU1IGNhbiBiZSB1c2UgYXMgYSBTUEkgaW50
ZXJmYWNlLiBJbiBteSBzeXN0ZW0gSSB1c2UKPj4gYm90aCBNQ0JTUCBwb3J0IHRvIGludGVy
ZmFjZSB3aXRoIEFEQy9EQUMgc28gdGhlcmUgaXMgbm8gZnJlZSBNQ0JTUCBwb3J0Li4KPj4K
Pj4gQXMgSSBuZWVkIGFub3RoZXIgcG9ydCB0byBpbnRlcmZhY2Ugd2l0aCBhIE1DVSB3aGlj
aCByZXF1aXJlIGEgZGF0YQo+PiByYXRlIGF0IGFib3V0IDMwTWIvcywgc28gSSBkZWNpZGVk
IHRvIHVzZSB0aGUgU1BJIGludGVyZmFjZS4gU2luY2UKPj4gdGhlcmUgaXMgbm8gZnJlZSBN
Q0JTUCBwb3J0IGluIG15IHN5c3RlbSwgSSB1c2UgdGhlIEdQSU8gdG8gaW1wbGVtZW50Cj4+
IHRoZSBTUEkgbXlzZWxmLiBBZnRlciB0aGUgaW1wbGVtZW50YXRpb24sIEkgZmluZCB0aGF0
IHRoZSBjbG9jayBzcGVlZAo+PiBvZiB0aGlzIEdQSU8gdHlwZSBTUEkgaW50ZXJmYWNlIGlz
IGFyb3VuZCA1TWIvcy4gTXkgcHJvYmxlbSBpcyBhcyBiZWxvdzoKPj4KPj4gMS4gSXMgdGhl
cmUgYW55IGJldHRlciBzb2x1dGlvbiB0aGF0IEkgY2FuIHVzZSB0byBsaW5rIHRoZSBNQ1Ug
YW5kIERTUAo+PiB0b2dldGhlciB3aXRoIGEgZGF0YSByYXRlIG9mIH4zME1iL3MuCj4+IDIu
IERvIGFueW9uZSBoYXZlIHRyeSB0aGlzIEdQSU8gdHlwZSBTUEkgaW50ZXJmYWNlIGFwcHJv
YWNoIGFuZCBoYXZlCj4+IGZpZ3VyZSBvbiB0aGUgbWF4aW11bSBkYXRhIHJhdGUgYWJvdXQg
aXQ/Cj4KPiBSZWdhcmRpbmcgR1BJTy1iYXNlZCBzZXJpYWwgSS9PLCBJJ20gc3VycHJpc2Vk
IHRoYXQgeW91IGNvdWxkIG9idGFpbiA1Cj4gTWJpdC9zZWMuICBJCj4gd291bGQgaGF2ZSB0
aG91Z2h0IGl0IHdvdWxkIGJlIHNsb3dlci4gIEdQSU8gaXMgb25seQo+ICBhY2Nlc3NpYmxl
IG9uIEM2NHggZGV2aWNlcwo+IHZpYQo+IENQVSBpbnN0cnVjdGlvbnMsIGkuZS4gJ2JydXRl
IGZvcmNlJy4gIEFzIHRoZXJlIGlzIG5vIERNQSBvciBvdGhlcgo+IGhhcmR3YXJlIGNpcmN1
aXRyeQo+ICdkZWRpY2F0ZWQnIHRvIEdQSU8gZGF0YSByYXRlLCBHUElPIGlzIHN1YmplY3Qg
dG8gQ1BVIHN0YWxscyBkdWUgdG8KPiBvbmNoaXAKPiBjb21wZXRpdGlvbiBmb3IgaW50ZXJu
YWwgbWVtb3J5IGJ1c3Nlcy4gIEkndmUgc2VlbiBkZWxheXMgaW4gdGhlIHJhbmdlIG9mCj4g
MTUwIG5zZWMKPiB3aGVuIHRyeWluZyB0byB0b2dnbGUgYSBHUElPIHBpbi4KPgo+IElzIHRo
ZXJlIGEgcmVxdWlyZW1lbnQgdG8gdXNlIHNlcmlhbCBJL08gZm9yIHlvdXIgTUNVPyAgQ2Fu
IHlvdSB1c2UgYW5vdGhlcgo+IG1ldGhvZCwKPiBmb3IgZXhhbXBsZSBIUEksIHRvIHRhbGsg
d2l0aCB0aGUgTUNVPwo+Cj4gQW5vdGhlciBvcHRpb24gaXMgdG8gZGV2aXNlIGEgd2F5IHRv
IHVzZSAxIE1jQlNQIGZvciB0aGUgYXVkaW8gSS9PCj4gaW50ZXJmYWNlLgo+IEkKPiB0aGlu
ayBpdCdzIGEgd2FzdGUgb2YgYSBNY0JTUCBmb3IgdGhlICJjb250cm9sIiBpbnRlcmZhY2Ug
b2YgYW4KPiBhdWRpbyBJL08gY29kZWMsIGFzCj4gaXMgZG9uZSBvbiB0aGUgRFNLNjQ1NSBh
bmQgb3RoZXIgRFNLIGJvYXJkcyB0aGF0IHVzZSBBSUMyMyBzZXJpZXMgYXVkaW8KPiBjb2Rl
Ywo+IGRldmljZXMuICBDb250cm9sIGFuZCBkYXRhIGNvbW11bmljYXRpb24gaXMgcmFyZWx5
LCBpZiBldmVyIG5lZWRlZCBhdCB0aGUKPiBzYW1lCj4gdGltZS4KPiBBIGNsZXZlciBkZXNp
Z24gdXNpbmcgYSBidXMgc3dpdGNoIG9yIG11eCBjb3VsZCBiZQo+ICBpbXBsZW1lbnRlZC4K
Pgo+IC1KZWZmCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
PiBZTSAtIOmboue3muioiuaBrwo+IOWwseeul+S9oOaykuacieS4iue2su+8jOS9oOeahOac
i+WPi+S7jeWPr+S7peeVmeS4i+ioiuaBr+e1puS9oO+8jOeVtuS9oOS4iue2suaZguWwseiD
veeri+WNs+eci+WIsO+8jOS7u+S9leiqquipsemDveWGh+i1sOWkseOAggo+IGh0dHA6Ly9t
ZXNzZW5nZXIueWFob28uY29tLmhrCj4gCgoKCi0tIAp3d3cuZHNwcmVsYXRlZC5jb20vYmxv
Z3MtMS9uZi9NaWtlX0R1bm4ucGhwCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0KCk9NQVAzNXggRVZNIGp1bXAtc3RhcnRzIGxvdy1wb3dlciBhcHBzCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpUaGUgbW9kdWxhciBhbmQgZXh0ZW5zaWJs
ZSBPTUFQMzV4IEV2YWx1YXRpb24gTW9kdWxlIChFVk0pIGVuYWJsZXMgZGV2ZWxvcGVycyB0
byBzdGFydCBidWlsZGluZyBhcHBsaWNhdGlvbnMgYmFzZWQgb24gdGhlIE9NQVAzNXggYXJj
aGl0ZWN0dXJlOiBodHRwOi8vd3d3LkRTUFJlbGF0ZWQuY29tL29tYXAzNXgKCk5FVyEgIFlv
dSBjYW4gbm93IHBvc3QgYSBtZXNzYWdlIG9yIGFjY2VzcyBhbmQgc2VhcmNoIHRoZSBhcmNo
aXZlcyBvZiB0aGlzIGdyb3VwIG9uIERTUFJlbGF0ZWQuY29tOgpodHRwOi8vd3d3LmRzcHJl
bGF0ZWQuY29tL2dyb3Vwcy9jNngvMS5waHAKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KTm90ZTogSWYgeW91IGRvIGEgc2ltcGxlICJyZXBseSIgd2l0aCB5b3Vy
IGVtYWlsIGNsaWVudCwgb25seSB0aGUgYXV0aG9yIG9mIHRoaXMgbWVzc2FnZSB3aWxsIHJl
Y2VpdmUgeW91ciBhbnN3ZXIuICBZb3UgbmVlZCB0byBkbyBhICJyZXBseSBhbGwiIGlmIHlv
dSB3YW50IHlvdXIgYW5zd2VyIHRvIGJlIGRpc3RyaWJ1dGVkIHRvIHRoZSBlbnRpcmUgZ3Jv
dXAuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkFib3V0IHRoaXMg
ZGlzY3Vzc2lvbiBncm91cDoKCkFyY2hpdmVzOiAgaHR0cDovL3d3dy5kc3ByZWxhdGVkLmNv
bS9ncm91cHMvYzZ4LzEucGhwCgpUbyBQb3N0OiAgU2VuZCBhbiBlbWFpbCB0byBjNnhAeWFo
b29ncm91cHMuY29tCgpPdGhlciBEU1AgUmVsYXRlZCBHcm91cHM6IGh0dHA6Ly93d3cuZHNw
cmVsYXRlZC5jb20vZ3JvdXBzLnBocFlhaG9vISBHcm91cHMgTGlua3MKCjwqPiBUbyB2aXNp
dCB5b3VyIGdyb3VwIG9uIHRoZSB3ZWIsIGdvIHRvOgogICAgaHR0cDovL2dyb3Vwcy55YWhv
by5jb20vZ3JvdXAvYzZ4LwoKPCo+IFlvdXIgZW1haWwgc2V0dGluZ3M6CiAgICBJbmRpdmlk
dWFsIEVtYWlsIHwgVHJhZGl0aW9uYWwKCjwqPiBUbyBjaGFuZ2Ugc2V0dGluZ3Mgb25saW5l
IGdvIHRvOgogICAgaHR0cDovL2dyb3Vwcy55YWhvby5jb20vZ3JvdXAvYzZ4L2pvaW4KICAg
IChZYWhvbyEgSUQgcmVxdWlyZWQpCgo8Kj4gVG8gY2hhbmdlIHNldHRpbmdzIHZpYSBlbWFp
bDoKICAgIG1haWx0bzpjNngtZGlnZXN0QHlhaG9vZ3JvdXBzLmNvbSAKICAgIG1haWx0bzpj
NngtZnVsbGZlYXR1cmVkQHlhaG9vZ3JvdXBzLmNvbQoKPCo+IFRvIHVuc3Vic2NyaWJlIGZy
b20gdGhpcyBncm91cCwgc2VuZCBhbiBlbWFpbCB0bzoKICAgIGM2eC11bnN1YnNjcmliZUB5
YWhvb2dyb3Vwcy5jb20KCjwqPiBZb3VyIHVzZSBvZiBZYWhvbyEgR3JvdXBzIGlzIHN1Ympl
Y3QgdG86CiAgICBodHRwOi8vZG9jcy55YWhvby5jb20vaW5mby90ZXJtcy8KCg=
Dear Michael,

Noted with thanks. Let me spend some time in studying those parallel interface first before continue the development.

Best Regards,
Albert Siu

--- 2008年7月8日 星期二,Michael Dunn 寫道﹕
寄件人: Michael Dunn
主題: Re: [c6x] Switching speed of GPIO
收件人: h...@yahoo.com.hk
副本(CC): "Jeff Brower" , c6x
日期: 2008 7 8 星期二 下午 10:22


Hello Albert,

Along the lines of Jeff's suggestions. ..

Make sure that you are taking a systems approach to your design. I do

not know all of the constraints of your design, but here are some of

my thoughts based on what I know.

If 30 Mb/sec/FPGA is your data rate [you should be able to determine

the rate fairly accurately if you haven't already] and you are using

FPGAs, you could configure each with an 8 bit parallel interface and

connect each one to 8 different EMIF data bits for a 3.75 Mhz rate.

You could also implement an 8/16 parallel interface to the MCU [if it

supports it] with an FPGA [you could even put in a FIFO]. All of this

could be put on a single daughtercard to create a prototype. Although

there are other options, using parallel interfaces will simplify the

FPGA logic and the DSP code. This will allow you to get a prototype

up and running with less 'throw away' code.

mikedunn

2008/7/8 :

> Dear Jeff,

>

> Noted with thanks. I will sped some time to study the UTOPIA, HPI and EMIF

> and test it later.

>

> Albert Siu

>

> --- 2008年7月8日 星期二,Jeff Brower 寫道﹕

>

> 寄件人: Jeff Brower

> 主題: Re: [c6x] Switching speed of GPIO

> 收件人: "Albert Ciu"

> 副本(CC): c6x@yahoogroups. com

> 日期: 2008 7 8 星期二 上午 7:43

>

> Albert-

>

> If you expect 30 Mbit/sec for *processed* data output to the MCU, then what

> is the total bandwidth of all the unprocessed codecs? It sounds to me like

> if you have enough codecs -- doubled on two separate FPGAs -- then your

> serial data rate will be far higher than 25 to 35 Mbit/sec on each McBSP,

> which is a "safe" rate for McBSP.

>

> I might suggest you consider UTOPIA for the "third pipe" (MCU or other).

> Other than HPI and EMIF, there isn't going to be an another peripheral

> alternative that gives you sustained, high bandwidth if, at the same time,

> you have 2 McBSP ports pushed to the limit. Maybe the EMAC is an option,

> but I'm guessing you need the processed data flow to be tightly synchronized

> with what's happening on the codec side, not as easy to do with packet data.

>

> -Jeff

>

>

>

> Actually in my experiment I just pump data to the GPIO to implement the SPI

> and do not do any other task so I can get the 5Mbit/s. Which means that in

> real life I cannot get this 5Mbit/s since I need to perform many other

> different task.

>

> In my current design, I connect a huge amount of audio CODEC to a FPGA. All

> the CODEC will work in an almost real time continuously. MCBSP channel

> switching seems not allowable due to the almost real time continuously data

> sampling requirement. Those CODEC sample data will pass to the DSP for

> processing form the FPGA via the MCBSP port. Since computering power of DSP

> is quite large so I design to use both MCBSP channel of the DSP to connect

> to two different FPGA for receiving more sampled data in parallel.

>

> The serial interface is just use to send the processed data from the DSP to

> another FPGA / MCU ... for next stage of data processing. Actually it is not

> limited to serial bus it can be a parallel bus but I think the SPI serial

> bus is more easily to implement so use it as a trial. The only limitation

> about this bus is the data rate and it is expect to be ~30Mbit/s per each

> FPGA connected to the DSP via the MCBSP port stated above.

>

> Thanks for your kind help.

>

> Best Regards,

> Albert Siu

>

> --- 2008年7�7� ��一�Jeff Brower

> 寫��

>

> �件人: Jeff Brower

> 主�: Re: [c6x] Switching speed og GPIO

> �件人: "Albert Siu"

> ��(CC): c6x@yahoogroups. com

> ��: 2008 7 7 ��一 �� 1:09

>

> Albert-

>

>> I am using the DSK6455 which includes two MCBSP port and these two

>>

> MCBSP port of 6455 can be use as a SPI interface. In my system I use

>> both MCBSP port to interface with ADC/DAC so there is no free MCBSP port...

>>

>> As I need another port to interface with a MCU which require a data

>> rate at about 30Mb/s, so I decided to use the SPI interface. Since

>> there is no free MCBSP port in my system, I use the GPIO to implement

>> the SPI myself. After the implementation, I find that the clock speed

>> of this GPIO type SPI interface is around 5Mb/s. My problem is as below:

>>

>> 1. Is there any better solution that I can use to link the MCU and DSP

>> together with a data rate of ~30Mb/s.

>> 2. Do anyone have try this GPIO type SPI interface approach and have

>> figure on the maximum data rate about it?

>

> Regarding GPIO-based serial I/O, I'm surprised that you could obtain 5

> Mbit/sec. I

> would have thought it would be slower. GPIO is only

> accessible on C64x devices

> via

> CPU instructions, i.e. 'brute force'. As there is no DMA or other

> hardware circuitry

> 'dedicated' to GPIO data rate, GPIO is subject to CPU stalls due to

> onchip

> competition for internal memory busses. I've seen delays in the range of

> 150 nsec

> when trying to toggle a GPIO pin.

>

> Is there a requirement to use serial I/O for your MCU? Can you use another

> method,

> for example HPI, to talk with the MCU?

>

> Another option is to devise a way to use 1 McBSP for the audio I/O

> interface.

> I

> think it's a waste of a McBSP for the "control" interface of an

> audio I/O codec, as

> is done on the DSK6455 and other DSK boards that use AIC23 series audio

> codec

> devices. Control and data communication is rarely, if ever needed at the

> same

> time.

> A clever design using a bus switch or mux could be

> implemented.

>

> -Jeff

--

www.dsprelated. com/blogs- 1/nf/Mike_ Dunn.php