On 2004-06-03, Cyrus Yunker <cxxrusxxxunxker@nxsux.xdu> wrote:> I am trying to figure out if TI's 6713 DSP running at 225 MHz > is capable of performing the following tasks. I've little > experience with DSP system design. > > I am interested in capturing 4 signals (>=16bits) at 400ksps > or better each. > > I'd then like to either stream that data to a computer (via > a USB interface perhaps), or perform some processing or analysis. > > I'd then like to be able to generate analog output on 4 channels > (>=16bits) at 600ksps or so each. These outputs would be related > to the inputs and be mostly sine wave or PWM-type outputs, real > time. > > This figures out to be about 68 Mbits of I/O, not including overhead.> > On 2004-06-04, Brad Griffis <bradgriffis@hotmail.com> wrote: > > > How many data converters are there? What speed and bit > > > resolution? Do they provide a serial or parallel data stream? > > > What else is in your system? Host processor? FPGA? SDRAM? > > > DAC? > > > > 2 quad channel data converters. TI's ADS8361EVM and DAC8534EVM > > boards. 16bits, 500ksps per channel. Serial interfaces. No > > FPGA. Avnet USB daughtercard for moving data to the host machine. > > I think you should be fine. You can hook up the quad ADC to > McBSP0 and the DAC to McBSP1. That will give you about 32 Mbps > on each McBSP which it can do without a problem. I don't have > time to look up the interfaces on those EVMs, but as long as you > don't need to use separate McBSPs for configuration/control of > the codec and data you should be fine. > > > > I'm sure you can implement this one way or another. The > > > specifics of it would be determined by the rest of your system. > > > The most basic way would be to input the data through the > > > serial ports (McBSPs) and have the enhanced DMA (EDMA) set up > > > to buffer your data and then trigger an interrupt. In this > > > case you'd have used zero CPU to get your data onto the chip > > > and would have the full 225 MHz available for filtering. > > The EDMA thing will probably take you quite a while to set up. > However, it's a good learning experience. Make sure you > double-buffer your io so that the EDMA is filling one while you're > processing another. Also, you can do channel separation with the > EDMA. I can't remember if this is described in the user guide or > not, but you can always post another question later...I wonder if the DSP/BIOS kernel TI offers with the Code Composer Studio would be a good way to go? I am having trouble judging whether or not this aproach would consume too much overhead. Would using the kernel deny me needed performance or help make use of the pipelined nature of said DSP? Suggestions? Plan of attack for building this application? Much thanks! Cyrus
Questions regarding TI's DSP/BIOS on the 6713 Floating Point DSP
Started by ●September 1, 2004
Reply by ●September 3, 20042004-09-03
"Cyrus Yunker" <cyrus.yunker@gmail.com> wrote in message news:ch3e4d$tb@odbk17.prod.google.com...> On 2004-06-03, Cyrus Yunker <cxxrusxxxunxker@nxsux.xdu> wrote: >> I am trying to figure out if TI's 6713 DSP running at 225 MHz >> is capable of performing the following tasks. I've little >> experience with DSP system design. >> >> I am interested in capturing 4 signals (>=16bits) at 400ksps >> or better each. >> >> I'd then like to either stream that data to a computer (via >> a USB interface perhaps), or perform some processing or analysis. >> >> I'd then like to be able to generate analog output on 4 channels >> (>=16bits) at 600ksps or so each. These outputs would be related >> to the inputs and be mostly sine wave or PWM-type outputs, real >> time. >> >> This figures out to be about 68 Mbits of I/O, not including overhead. > >> > On 2004-06-04, Brad Griffis <bradgriffis@hotmail.com> wrote: >> > > How many data converters are there? What speed and bit >> > > resolution? Do they provide a serial or parallel data stream? >> > > What else is in your system? Host processor? FPGA? SDRAM? >> > > DAC? >> > >> > 2 quad channel data converters. TI's ADS8361EVM and DAC8534EVM >> > boards. 16bits, 500ksps per channel. Serial interfaces. No >> > FPGA. Avnet USB daughtercard for moving data to the host machine. >> >> I think you should be fine. You can hook up the quad ADC to >> McBSP0 and the DAC to McBSP1. That will give you about 32 Mbps >> on each McBSP which it can do without a problem. I don't have >> time to look up the interfaces on those EVMs, but as long as you >> don't need to use separate McBSPs for configuration/control of >> the codec and data you should be fine. >> >> > > I'm sure you can implement this one way or another. The >> > > specifics of it would be determined by the rest of your system. >> > > The most basic way would be to input the data through the >> > > serial ports (McBSPs) and have the enhanced DMA (EDMA) set up >> > > to buffer your data and then trigger an interrupt. In this >> > > case you'd have used zero CPU to get your data onto the chip >> > > and would have the full 225 MHz available for filtering. >> >> The EDMA thing will probably take you quite a while to set up. >> However, it's a good learning experience. Make sure you >> double-buffer your io so that the EDMA is filling one while you're >> processing another. Also, you can do channel separation with the >> EDMA. I can't remember if this is described in the user guide or >> not, but you can always post another question later... > > I wonder if the DSP/BIOS kernel TI offers with the Code Composer Studio > would be a good way to go? I am having trouble judging whether or not > this aproach would consume too much overhead. > > Would using the kernel deny me needed performance or help make use of > the pipelined nature of said DSP? > > Suggestions? Plan of attack for building this application? > Much thanks! > CyrusThe decision of whether or not to use BIOS won't come down to performance but rather to what you're looking to do. The BIOS kernel is rather efficient and will only take up a couple percent of your processing so you don't need to worry about it soaking up all your cycles. If you have a lot of different threads running that will require extensive prioritization and perhaps inter-module communication then you should definitely use BIOS. If this is going to be a simple, straight-forward project where data comes in through the serial port, gets processed, and then is sent back out the serial port then BIOS is not necessary. However, even for the latter ("simple") case many people still like to use BIOS. I guess it depends on whether you prefer to keep things as simple and low-level as possible or if you like more abstraction. Brad
