|
Hi all, I'm getting some unexpected results from the following setup, and perhaps someone has an idea why. I am simulating a 65L program. The simulator uses SPORTs streaming to read data from a file. The DMA reads a block of data (say 80 32bit words), then an interrupt occrus. In the meantime, DMA chain loading occurs and to initialize another DMA, which again reads 80 values, this time into a second buffer. The two buffers are continuously filled by alternating DMAs. There is no other DMA activity. I have set the SPORT input divisor to read a value every 1248 processor cycles (RDVI = 0x26). This works most of the time. However, for some transfers, I'm seeing a much larger cycle count between reading two consecutive values from the SPORT (up to about 2000 cycles). This is odd: since I have an internal SPORT clock, this shouldn't happen. The data should be read at a constant rate. I'm seeing the prolonged cycle counts especially when heavy usage is made with simultaneous PM and DM reads, as well as during 16bit internal memory accesses. Has somebody experienced similar behaviour or can explain why I'm having irregular cycle counts between internally clocked SPORT DMA accesses? Regards, Andor |
|
|
Simulating SPORT DMA on 65L
Started by ●January 19, 2004
Reply by ●January 22, 20042004-01-22
|
Hi, Andor, --- andor_bariska <> wrote: > Hi all, > > I'm getting some unexpected results from the > following setup, and > perhaps someone has an idea why. > > I am simulating a 65L program. The simulator uses > SPORTs streaming to > read data from a file. The DMA reads a block of data > (say 80 32bit > words), then an interrupt occrus. In the meantime, > DMA chain loading > occurs and to initialize another DMA, which again > reads 80 values, > this time into a second buffer. The two buffers are > continuously > filled by alternating DMAs. There is no other DMA > activity. > > I have set the SPORT input divisor to read a value > every 1248 > processor cycles (RDVI = 0x26). > > This works most of the time. > > However, for some transfers, I'm seeing a much > larger cycle count > between reading two consecutive values from the > SPORT (up to about > 2000 cycles). This is odd: since I have an internal > SPORT clock, this > shouldn't happen. The data should be read at a > constant rate. > > I'm seeing the prolonged cycle counts especially > when heavy usage is > made with simultaneous PM and DM reads, as well as > during 16bit > internal memory accesses. Have you checked that the PM and DM, and 16 bit internal memory accesses are being executed in parallel with other operations, when coded to do so? I mean, is there any possibility that for some instructions the processor is not executing in a single cycle? JaaC > > Has somebody experienced similar behaviour or can > explain why I'm > having irregular cycle counts between internally > clocked SPORT DMA > accesses? > > Regards, > Andor > > _____________________________________ > Note: If you do a simple "reply" with your email > client, only the author of this message will receive > your answer. You need to do a "reply all" if you > want your answer to be distributed to the entire > group. > > _____________________________________ > About this discussion group: > > To Join: Send an email to > To Post: Send an email to > > To Leave: Send an email to > Archives: http://groups.yahoo.com/group/adsp > > Other Groups: http://www.dsprelated.com/groups.php3 __________________________________ |
|
|
Reply by ●January 23, 20042004-01-23
|
Jaime wrote: ... > Have you checked that the PM and DM, and 16 bit > internal memory accesses are being executed in > parallel with other operations, when coded to do so? I > mean, is there any possibility that for some > instructions the processor is not executing in a > single cycle? Hi Jaime, thanks for your answer. The problem I'm having is not that a piece of code does not perform as expected. It is the simulation of the SPORT DMA which is not performing as expected - it takes too long (you can count the clock cycles for one DMA transfer by looking at the DMA counter register (CPxx), which decrements for each DMA transfer). I suspect that DMA simulation is influenced by 16bit memory access. I haven't verified it yet with a test project, but when I do so I will let the group know. Thanks, Andor |
|
|
Reply by ●January 23, 20042004-01-23
|
Hi Andor, In your original post you wrote: "I'm seeing the prolonged cycle counts especially when heavy usage is made with simultaneous PM and DM reads, as well as during 16bit internal memory accesses." That's where my suggestion came from. Could you test with an emulator, too? That could give you some insights on what's actually happending, and check whether it is an issue with the simulation of the DMA + 16 bit accesses, or with the DSp itself, or the program. I don't recall at the moment: does the '065L have cache? Could that influence your scenario? Regards, JaaC --- andor_bariska <> wrote: > I suspect that DMA simulation is influenced by 16bit > memory access. I > haven't verified it yet with a test project, but > when I do so I will > let the group know. ===== Jaime Andr Aranguren Cardona __________________________________ |
