|
Hi all, I'm have some trivial doubts about programming the 6205. Imagine this situation: The system consists of a PCI board with a 6205 and works with 32 voice channels. The DSP is simply supposed to receive samples from the Host (PC) and pass them to the codecs, and to receive samples from the codecs and pass them to the Host (all this in real-time, of course...). We are planning to work with 20ms (160 samples) frames. My questions... How is this communication? I mean, How the data flows to/from de PC and DSP? What should I do on the Host side? Will the PC be "interrupted" at every frame? The PC will send samples writing directly to the DSP memory? What should I do on the DSP side? Should I write a DSP/BIOS driver to implement this communication? Do I need to bufferize the incomming data from the PC? As you can see, I'm totaly lost in here... HELP! |
|
|
DSP-Host Communication
Started by ●October 9, 2003
Reply by ●October 9, 20032003-10-09
|
--- Lucas Barbosa <> wrote: > I'm have some trivial doubts about programming the > 6205. > Imagine this situation: > > The system consists of a PCI board with a 6205 and > works with 32 > voice channels. The DSP is simply supposed to > receive samples from > the Host (PC) and pass them to the codecs, and to > receive samples > from the codecs and pass them to the Host (all this > in real-time, of > course...). We are planning to work with 20ms (160 > samples) frames. > > My questions... > > How is this communication? I mean, How the data > flows to/from de PC > and DSP? > > What should I do on the Host side? Will the PC be > "interrupted" at > every frame? The PC will send samples writing > directly to the DSP > memory? > > What should I do on the DSP side? Should I write a > DSP/BIOS driver > to implement this communication? Do I need to > bufferize the incomming > data from the PC? > > As you can see, I'm totaly lost in here... HELP! yeah... we can clearly see that you're lost ;-) however - all those questions that you asked - you should direct them to the person who designed your hardware... you're talking about some PCI card - somebody has designed it... right? ask him (her? ;-) and by the way - you asked very good questions... and have you read the PCI documentation from spru190? that could give you some theoretical knowledge about PCI operation - but then - again - I don't know anything about the architecture of your system - it all depends on your system... __________________________________ |
Reply by ●October 9, 20032003-10-09
|
At 02:55 PM 10/9/2003, Lucas Barbosa wrote: >Hi all, > >I'm have some trivial doubts about programming the 6205. >Imagine this situation: > >The system consists of a PCI board with a 6205 and works with 32 >voice channels. The DSP is simply supposed to receive samples from >the Host (PC) and pass them to the codecs, and to receive samples >from the codecs and pass them to the Host (all this in real-time, of >course...). We are planning to work with 20ms (160 samples) frames. > >My questions... > >How is this communication? I mean, How the data flows to/from de PC >and DSP? > >What should I do on the Host side? Will the PC be "interrupted" at >every frame? The PC will send samples writing directly to the DSP >memory? > >What should I do on the DSP side? Should I write a DSP/BIOS driver >to implement this communication? Do I need to bufferize the incomming >data from the PC? > >As you can see, I'm totaly lost in here... HELP! If you really don't need the DSP to do anything other than to pass data to the codecs, then why use a DSP? A very simple logic design can do the same thing with a lot less work. A CPLD or a small FPGA will cost less and you can use free development tools. If you are using an off the shelf DSP board from a vendor, then you need to contact them for code that controls the PCI interface to the host. There should be library routines for both the host and the DSP. If you want to make things simple, I would use the library code to transfer a block of 5,120 samples in one large transfer. The PCI bus will break this up automatically to prevent monopolizing the bus. This will provide the shortest latency for your board. Establish double or even triple buffers on your DSP for the input and the output side. Then you just provide the code to read data from the buffers and send to the codecs and read from the codecs and send to the buffers. You can pack the samples into your 5,120 sample buffers either as one sample from each channel in succession repeating 5,120 times, or you can block out 160 samples for each channel. Check out how it will work best for talking to the codecs. You may be able to set up one DMA transfer to process all 32 channels if they are mapped to adjacent memory locations or if they are on a single TDM bus. Rick Collins Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX |
|
|
Reply by ●October 13, 20032003-10-13
|
Lucas Barbosa- > I'm have some trivial doubts about programming the 6205. > Imagine this situation: > > The system consists of a PCI board with a 6205 and works with 32 > voice channels. The DSP is simply supposed to receive samples from > the Host (PC) and pass them to the codecs, and to receive samples > from the codecs and pass them to the Host (all this in real-time, of > course...). We are planning to work with 20ms (160 samples) frames. > > My questions... > > How is this communication? I mean, How the data flows to/from de PC > and DSP? > > What should I do on the Host side? Will the PC be "interrupted" at > every frame? The PC will send samples writing directly to the DSP > memory? Definitely would not suggest the PC handling every frame. Your host program should have a buffer size of 32k or more to accommodate temporary slowdowns and critical section grabs due to the OS. For example, a buffer size of 40960 would be 8 frames of 32 channels and would require servicing the board every 160 msec. That still might be too often, depending on what's going on with host software. -Jeff > What should I do on the DSP side? Should I write a DSP/BIOS driver > to implement this communication? Do I need to bufferize the incomming > data from the PC? > > As you can see, I'm totaly lost in here... HELP! |
|
|
Reply by ●October 13, 20032003-10-13
|
Jeff,
I think that your suggestions are very valid for some apps - but not this
one. I am sure sure that the system spec calls for a max latency [if the
implementation has a prayer]. Keep in mind that this is a bidirectional
voice app where large buffers cause problems...
Lucas,
Are your samples 8 bits each?? If so, can you access 4 separate codecs in
one memory cycle [or 4 bytes from one codec]??
mikedunn
Jeff Brower <j...@signalogic.com> wrote: Lucas Barbosa- |
Reply by ●October 13, 20032003-10-13
|
Mike- > I think that your suggestions are very valid for some apps > - but not this one. I am sure sure that the system spec calls > for a max latency [if the implementation has a prayer]. > Keep in mind that this is a bidirectional voice app where large > buffers cause problems... Sure if it's actually speech and people are listening, then delay is a huge issue. But I didn't get that out of the original post -- if that were the case where's the PSTN or IP interface? Not on this board -- maybe somewhere else in the system I guess. If he hits the board every 20 msec or even 80 msec he's going to have some issues if the data is not compressed -- that's 2560 bytes min, enough for the PCI bus to start automatically breaking up the transfer to avoid monopolizing the bus. Actually, 640 32-bit transfers is almost 20 msec at 33 MHz, so that means the PCI bus would be constantly busy. I don't think that's going to work. -Jeff |
|
|
Reply by ●October 14, 20032003-10-14
|
Fisrt of all, I would like to thank Wojciech, Rick, Jeff and Mike for the answers, they helped a lot. I've studied your answers and some app. notes, and I think that Im going to try the following approach: There will be two low level buffers on the Host side (input and output), each having 10240 bytes (160 16-bit samples for each channel). Every 20ms the DSP will: 1. perform a master write to fill the Host input buffer 2. perform a master read to get the Host output buffer 3. interrupt the host (to communicate that the buffers have been filled/read ) Some new questions... 1. Do you think it will work? 2. Will the PC really be able to handle every frame? Its a P3 800MHz running windows XP... Maybe I can do it by setting the app. with the highest priority. 3. Would you implement this communication using the DSP/BIOS framework? 4. What about the communication with the codecs? Do you use to implement it using the DSP/BIOS framework (a stackable DEV including the McBSP and the codec)? Whats the advantage of that?? Thanks! Lucas |
|
|
Reply by ●October 15, 20032003-10-15
|
Hello Lucas,
As you can see, there is usually several ways to solve a problem. My
two cents on implementation...
If your present and future requirements are known AND they can be solved by
a simple deterministic state machine [I do not believe that they can] then
bypass the DSP/BIOS.
The DSP-BIOS/reference framework solution has the advantage of being able
to develop a prototype fairly quickly. Once you do that, you can always
throw away any or all of it if you need to eliminate bottle necks.
I suggest that you follow the steps that Jeff alluded to in some of his
email to get an idea of the required performance - you have a start in your
response below. Here is some info to get you started:
Tn ms timeslot 1-9
RBn= read buffer 1-3 WBn= write buffer 1-3 DF=DSP fill, HF=host fill, R=ready DR=DSP read, HR=host read T1 T2
T3 T4 T5 T6 T7 T8 T9
rb1 DF R HR DF R HR DF R HR rb2 E DF R HR DF R HR DF R rb3 E E DF R HR DF R HR DF wb1 HF R DW HF R DW HF R DW wb2 E HF R DW HF R DW HF R wb3 E E HF R DW HF R DW HF DF and DR each have 125us deadlines
HF and HR each have 80wd transfer deadlines each 20 ms mikedunn
Lucas Barbosa <l...@secrel.com.br> wrote: Fisrt of all, I would like to thank Wojciech, Rick, Jeff and Mike for |
Reply by ●October 16, 20032003-10-16
|
Lucas- > There will be two low level buffers on the Host side (input and > output), each having 10240 bytes (160 16-bit samples for each > channel). > Every 20ms the DSP will: > 1. perform a master write to fill the Host input buffer > 2. perform a master read to get the Host output buffer > 3. interrupt the host (to communicate that the buffers have been > filled/read ) > > Some new questions... > 1. Do you think it will work? > 2. Will the PC really be able to handle every frame? Its a P3 800MHz > running windows XP... Maybe I can do it by setting the app. with the > highest priority. > 3. Would you implement this communication using the DSP/BIOS > framework? > 4. What about the communication with the codecs? Do you use to > implement it using the DSP/BIOS framework (a stackable DEV including > the McBSP and the codec)? Whats the advantage of that?? I think you might get it to work. DSP/BIOS probably is not a problem as 32 channels of 16-bit PCM or G.711 is not tough for the DSP. Of course, that changes in a hurry if you start running speech codecs and other algorithms. Definitely make sure all channels are in the same data structure in DSP memory, including any other info you want to read/write (statistics, measurements, etc). You just want to do *one* PCI read/write per frame and not invoke any additional driver overhead. -Jeff |
Reply by ●October 16, 20032003-10-16
|
Lucas- > There will be two low level buffers on the Host side (input and > output), each having 10240 bytes (160 16-bit samples for each > channel). > Every 20ms the DSP will: > 1. perform a master write to fill the Host input buffer > 2. perform a master read to get the Host output buffer > 3. interrupt the host (to communicate that the buffers have been > filled/read ) > > Some new questions... > 1. Do you think it will work? > 2. Will the PC really be able to handle every frame? Its a P3 800MHz > running windows XP... Maybe I can do it by setting the app. with the > highest priority. > 3. Would you implement this communication using the DSP/BIOS > framework? > 4. What about the communication with the codecs? Do you use to > implement it using the DSP/BIOS framework (a stackable DEV including > the McBSP and the codec)? Whats the advantage of that?? I think you might get it to work. DSP/BIOS probably is not a problem as 32 channels of 16-bit PCM or G.711 is not tough for the DSP. Of course, that changes in a hurry if you start running speech codecs and other algorithms. Definitely make sure all channels are in the same data structure in DSP memory, including any other info you want to read/write (statistics, measurements, etc). You just want to do *one* PCI read/write per frame and not invoke any additional driver overhead. -Jeff |
