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
Reply by Jeff Brower●July 8, 20082008-07-08
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.
> 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.