Hello All,
I have a weird problem with interfacing EMIF interface on my TMS320C6455 DSK
from Spectrum Digital to the parallel DAC. DAC has a 20-bit wide interface, with
the clock up to 40 MHz. My DAC is connected to the EMIF using only data lines
and AWE signal for the clock. I am setting period of the clock using
TA/Setup/Strobe/Hold settings. Recently I measured the clock on the oscilloscope
in the larger time frame and noticed periodic AWE pauses. The pause is 5 uS long
(200 kHz) and happens about every 10.25 kHz (97.5 uS). This pause is 60 cycles
of asynchronous memory writes long or 480 ECLKOUT cycles. I checked ECLKOUT
output and it's continuous, so clock is good. I disabled DDR2 controller,
as someone mentioned that it could be SDRAM refresh time, but that did not help
and DDR2 is also a different controller from EMIF anyway. Changing period of the
AWE signal did not help either. Did anyone ever have such a problem on this
board? Should I use something else for the DAC clock?
_____________________________________
TMS320C6455 EMIF to DAC interface glitch
Started by ●April 22, 2010
Reply by ●April 22, 20102010-04-22
Terrabith-
> I have a weird problem with interfacing EMIF interface on
> my TMS320C6455 DSK from Spectrum Digital to the parallel
> DAC. DAC has a 20-bit wide interface, with the clock up
> to 40 MHz. My DAC is connected to the EMIF using only data
> lines and AWE signal for the clock. I am setting period
> of the clock using TA/Setup/Strobe/Hold settings. Recently I
> measured the clock on the oscilloscope in the larger time
> frame and noticed periodic AWE pauses. The pause is 5 uS
> long (200 kHz) and happens about every 10.25 kHz (97.5 uS).
> This pause is 60 cycles of asynchronous memory writes long
> or 480 ECLKOUT cycles. I checked ECLKOUT output and it's
> continuous, so clock is good. I disabled DDR2 controller, as
> someone mentioned that it could be SDRAM refresh time, but
> that did not help and DDR2 is also a different controller
> from EMIF anyway. Changing period of the AWE signal did not
> help either. Did anyone ever have such a problem on this
> board? Should I use something else for the DAC clock?
A couple of general comments:
1) Maybe some software is running that periodically consumes the DSP's internal memory bus and temporarily stalls
external accesses. Are you running DSP/BIOS? What interrupts are going off and what code do they cause to run?
2) Suggest to consider using a FIFO between your DAC and the DSP. There are a number of reasons that the DSP might
not keep a 100% perfect 40 MHz access to async EMIF, including EDMA stalls as your code development becomes more
complex. There should be a FIFO to collect data on 100% reliable basis, and then your code moves data as "buffers"
from the FIFO to DSP mem. Buffer transfers don't have to be cycle-perfect.
3) Your high speed DAC doesn't have a built-in FIFO or include a companion chip in its reference design? What is the
part number?
-Jeff
_____________________________________
> I have a weird problem with interfacing EMIF interface on
> my TMS320C6455 DSK from Spectrum Digital to the parallel
> DAC. DAC has a 20-bit wide interface, with the clock up
> to 40 MHz. My DAC is connected to the EMIF using only data
> lines and AWE signal for the clock. I am setting period
> of the clock using TA/Setup/Strobe/Hold settings. Recently I
> measured the clock on the oscilloscope in the larger time
> frame and noticed periodic AWE pauses. The pause is 5 uS
> long (200 kHz) and happens about every 10.25 kHz (97.5 uS).
> This pause is 60 cycles of asynchronous memory writes long
> or 480 ECLKOUT cycles. I checked ECLKOUT output and it's
> continuous, so clock is good. I disabled DDR2 controller, as
> someone mentioned that it could be SDRAM refresh time, but
> that did not help and DDR2 is also a different controller
> from EMIF anyway. Changing period of the AWE signal did not
> help either. Did anyone ever have such a problem on this
> board? Should I use something else for the DAC clock?
A couple of general comments:
1) Maybe some software is running that periodically consumes the DSP's internal memory bus and temporarily stalls
external accesses. Are you running DSP/BIOS? What interrupts are going off and what code do they cause to run?
2) Suggest to consider using a FIFO between your DAC and the DSP. There are a number of reasons that the DSP might
not keep a 100% perfect 40 MHz access to async EMIF, including EDMA stalls as your code development becomes more
complex. There should be a FIFO to collect data on 100% reliable basis, and then your code moves data as "buffers"
from the FIFO to DSP mem. Buffer transfers don't have to be cycle-perfect.
3) Your high speed DAC doesn't have a built-in FIFO or include a companion chip in its reference design? What is the
part number?
-Jeff
_____________________________________
Reply by ●April 23, 20102010-04-23
Vladimir-
> --- In c..., "Jeff Brower" wrote:
> >
> > Terrabith-
> >
> > > I have a weird problem with interfacing EMIF interface on
> > > my TMS320C6455 DSK from Spectrum Digital to the parallel
> > > DAC. DAC has a 20-bit wide interface, with the clock up
> > > to 40 MHz. My DAC is connected to the EMIF using only data
> > > lines and AWE signal for the clock. I am setting period
> > > of the clock using TA/Setup/Strobe/Hold settings. Recently I
> > > measured the clock on the oscilloscope in the larger time
> > > frame and noticed periodic AWE pauses. The pause is 5 uS
> > > long (200 kHz) and happens about every 10.25 kHz (97.5 uS).
> > > This pause is 60 cycles of asynchronous memory writes long
> > > or 480 ECLKOUT cycles. I checked ECLKOUT output and it's
> > > continuous, so clock is good. I disabled DDR2 controller, as
> > > someone mentioned that it could be SDRAM refresh time, but
> > > that did not help and DDR2 is also a different controller
> > > from EMIF anyway. Changing period of the AWE signal did not
> > > help either. Did anyone ever have such a problem on this
> > > board? Should I use something else for the DAC clock?
> >
> > A couple of general comments:
> > Hello Jeff,
>
> Thanks for the reply.
>
> > 1) Maybe some software is running that periodically consumes the DSP's internal memory bus and temporarily stalls
> > external accesses. Are you running DSP/BIOS? What interrupts are going off and what code do they cause to run?
>
> There is nothing in the background, I have simplified the system
> down to EMIF only for the purposes of testing this problem. I am
> running it in the normal mode (non BIOS).
>
> > 2) Suggest to consider using a FIFO between your DAC and the DSP. There are a number of reasons that the DSP might
> > not keep a 100% perfect 40 MHz access to async EMIF, including EDMA stalls as your code development becomes more
> > complex. There should be a FIFO to collect data on 100% reliable basis, and then your code moves data as "buffers"
> > from the FIFO to DSP mem. Buffer transfers don't have to be cycle-perfect.
>
> I guess FIFO is a good idea in any project. Unfortunately I cannot
> really add it now, maybe I can use like DMA transfers or something.
> Add a software FIFO in the DSP that I fill and then call function
> to send it to DAC after some time?
>
> > 3) Your high speed DAC doesn't have a built-in FIFO or include a companion chip in its reference design? What is the
> > part number?
>
> I am using devices called ComBlocks. They are pre-made devices for
> rapid prottotyping. This one in particular is COM-2001, and it uses
> AD9760 DACs on it. If anything it means I will have to modify their
> board.
First, please post to the group not to me.
I assume these things connect directly to the DSK 6455 daughterboard site. Does it
have an FPGA on it between the DAC and the daughterboard connector?
> Also, would you suggest using Timer as a DAC clock and send data
> to EMIF every interrupt instead?
40 MHz is way too fast for individual interrupts. If the C6455 is running 1 GHz then
you have 25 nsec to process each sample. If you operate on buffer basis and you can
maximize your use of parallel instructions, then maybe you can do a bit of signal
processing. But for non-arithmetic work like interrupt handling, there's no way.
At this point, my suggestion is to experiment with much lower rates and find where
your system can become stable. Then add step-by-step EDMA access to async EMIF
(using buffers in DSP mem) and software layers that you need, carefully checking EMIF
reliability and access rate consistency at each step. By that I mean run tests where
you can tell whether you've missed 1 out of billions of samples. Very high rate
systems are not easy, you have to be methodical and make many measurements to be sure
of what is really happening.
-Jeff
_____________________________________
> --- In c..., "Jeff Brower" wrote:
> >
> > Terrabith-
> >
> > > I have a weird problem with interfacing EMIF interface on
> > > my TMS320C6455 DSK from Spectrum Digital to the parallel
> > > DAC. DAC has a 20-bit wide interface, with the clock up
> > > to 40 MHz. My DAC is connected to the EMIF using only data
> > > lines and AWE signal for the clock. I am setting period
> > > of the clock using TA/Setup/Strobe/Hold settings. Recently I
> > > measured the clock on the oscilloscope in the larger time
> > > frame and noticed periodic AWE pauses. The pause is 5 uS
> > > long (200 kHz) and happens about every 10.25 kHz (97.5 uS).
> > > This pause is 60 cycles of asynchronous memory writes long
> > > or 480 ECLKOUT cycles. I checked ECLKOUT output and it's
> > > continuous, so clock is good. I disabled DDR2 controller, as
> > > someone mentioned that it could be SDRAM refresh time, but
> > > that did not help and DDR2 is also a different controller
> > > from EMIF anyway. Changing period of the AWE signal did not
> > > help either. Did anyone ever have such a problem on this
> > > board? Should I use something else for the DAC clock?
> >
> > A couple of general comments:
> > Hello Jeff,
>
> Thanks for the reply.
>
> > 1) Maybe some software is running that periodically consumes the DSP's internal memory bus and temporarily stalls
> > external accesses. Are you running DSP/BIOS? What interrupts are going off and what code do they cause to run?
>
> There is nothing in the background, I have simplified the system
> down to EMIF only for the purposes of testing this problem. I am
> running it in the normal mode (non BIOS).
>
> > 2) Suggest to consider using a FIFO between your DAC and the DSP. There are a number of reasons that the DSP might
> > not keep a 100% perfect 40 MHz access to async EMIF, including EDMA stalls as your code development becomes more
> > complex. There should be a FIFO to collect data on 100% reliable basis, and then your code moves data as "buffers"
> > from the FIFO to DSP mem. Buffer transfers don't have to be cycle-perfect.
>
> I guess FIFO is a good idea in any project. Unfortunately I cannot
> really add it now, maybe I can use like DMA transfers or something.
> Add a software FIFO in the DSP that I fill and then call function
> to send it to DAC after some time?
>
> > 3) Your high speed DAC doesn't have a built-in FIFO or include a companion chip in its reference design? What is the
> > part number?
>
> I am using devices called ComBlocks. They are pre-made devices for
> rapid prottotyping. This one in particular is COM-2001, and it uses
> AD9760 DACs on it. If anything it means I will have to modify their
> board.
First, please post to the group not to me.
I assume these things connect directly to the DSK 6455 daughterboard site. Does it
have an FPGA on it between the DAC and the daughterboard connector?
> Also, would you suggest using Timer as a DAC clock and send data
> to EMIF every interrupt instead?
40 MHz is way too fast for individual interrupts. If the C6455 is running 1 GHz then
you have 25 nsec to process each sample. If you operate on buffer basis and you can
maximize your use of parallel instructions, then maybe you can do a bit of signal
processing. But for non-arithmetic work like interrupt handling, there's no way.
At this point, my suggestion is to experiment with much lower rates and find where
your system can become stable. Then add step-by-step EDMA access to async EMIF
(using buffers in DSP mem) and software layers that you need, carefully checking EMIF
reliability and access rate consistency at each step. By that I mean run tests where
you can tell whether you've missed 1 out of billions of samples. Very high rate
systems are not easy, you have to be methodical and make many measurements to be sure
of what is really happening.
-Jeff
_____________________________________
Reply by ●April 23, 20102010-04-23
> First, please post to the group not to me.
Sorry about this, I am new to the group, and learn with time. Just noticed how to do that.
> I assume these things connect directly to the DSK 6455 daughterboard site. Does
> it
> have an FPGA on it between the DAC and the daughterboard connector?
You assume correctly. I guess you can say I made my own daughtercard. There is an FPGA between ADC and DSP to do some processing rate reduction, but DAC is directly connected. Although it can handle up to 40 Msps, I run it at 12 Msps. For my future designs I will keep in mind that buffer is always a good idea. I never worked with DSP boards before, and expected DSP to have lots of I/O just like any microprocessor/microcontroller.... I guess I was kind of wrong.
> Also, would you suggest using Timer as a DAC clock and send data
> to EMIF every interrupt instead?
> 40 MHz is way too fast for individual interrupts. If the C6455 is running 1 GHz
> then
> you have 25 nsec to process each sample. If you operate on buffer basis and you
> can
> maximize your use of parallel instructions, then maybe you can do a > bit of
> signal
> processing. But for non-arithmetic work like interrupt handling, there's no
> way.
> At this point, my suggestion is to experiment with much lower rates > and find
> where
> your system can become stable. Then add step-by-step EDMA access to > async EMIF
> (using buffers in DSP mem) and software layers that you need, carefully checking
> EMIF
> reliability and access rate consistency at each step. By that I mean run tests
> where
> you can tell whether you've missed 1 out of billions of samples. Very high rate
> systems are not easy, you have to be methodical and make many measurements to be
> sure
> of what is really happening.
I will follow your suggestion and introduce DMA. The rate is already slower, so I will see what I can do. Thanks for all suggestions. I will keep working on solving this problem, and post here if I find solution for future visitors.
_____________________________________
Sorry about this, I am new to the group, and learn with time. Just noticed how to do that.
> I assume these things connect directly to the DSK 6455 daughterboard site. Does
> it
> have an FPGA on it between the DAC and the daughterboard connector?
You assume correctly. I guess you can say I made my own daughtercard. There is an FPGA between ADC and DSP to do some processing rate reduction, but DAC is directly connected. Although it can handle up to 40 Msps, I run it at 12 Msps. For my future designs I will keep in mind that buffer is always a good idea. I never worked with DSP boards before, and expected DSP to have lots of I/O just like any microprocessor/microcontroller.... I guess I was kind of wrong.
> Also, would you suggest using Timer as a DAC clock and send data
> to EMIF every interrupt instead?
> 40 MHz is way too fast for individual interrupts. If the C6455 is running 1 GHz
> then
> you have 25 nsec to process each sample. If you operate on buffer basis and you
> can
> maximize your use of parallel instructions, then maybe you can do a > bit of
> signal
> processing. But for non-arithmetic work like interrupt handling, there's no
> way.
> At this point, my suggestion is to experiment with much lower rates > and find
> where
> your system can become stable. Then add step-by-step EDMA access to > async EMIF
> (using buffers in DSP mem) and software layers that you need, carefully checking
> EMIF
> reliability and access rate consistency at each step. By that I mean run tests
> where
> you can tell whether you've missed 1 out of billions of samples. Very high rate
> systems are not easy, you have to be methodical and make many measurements to be
> sure
> of what is really happening.
I will follow your suggestion and introduce DMA. The rate is already slower, so I will see what I can do. Thanks for all suggestions. I will keep working on solving this problem, and post here if I find solution for future visitors.
_____________________________________
Reply by ●April 24, 20102010-04-24
Vladimir-
>> First, please post to the group not to me.
>
> Sorry about this, I am new to the group, and learn with time.
> Just noticed how to do that.
>
>> I assume these things connect directly to the DSK 6455 daughterboard site. Does
>> it
>> have an FPGA on it between the DAC and the daughterboard connector?
>
> You assume correctly. I guess you can say I made my own
> daughtercard. There is an FPGA between ADC and DSP to do some
> processing rate reduction, but DAC is directly connected.
> Although it can handle up to 40 Msps, I run it at 12 Msps.
> For my future designs I will keep in mind that buffer is
> always a good idea. I never worked with DSP boards before,
> and expected DSP to have lots of I/O just like any
> microprocessor/microcontroller.... I guess I was kind of
> wrong.
I think your basic thinking was Ok. DSPs do have a lot of I/O options. But a 40 MHz gap-free I/O rate is fast for
any type of CPU. Even if you were using a synchronous interface, there still might be the occasional stall or
internal memory bus conflict.
I think the only 'design flaw' (pardon me for saying) is the DAC should connect via FPGA also. Then if you do need a
FIFO or other "re-timing" it's relatively easy to implement.
>> Also, would you suggest using Timer as a DAC clock and send data
>> to EMIF every interrupt instead?
>
>> 40 MHz is way too fast for individual interrupts. If the C6455 is running 1 GHz
>> then
>> you have 25 nsec to process each sample. If you operate on buffer basis and you
>> can
>> maximize your use of parallel instructions, then maybe you can do a > bit of
>> signal
>> processing. But for non-arithmetic work like interrupt handling, there's no
>> way.
>
>> At this point, my suggestion is to experiment with much lower rates > and find
>> where
>> your system can become stable. Then add step-by-step EDMA access to > async EMIF
>> (using buffers in DSP mem) and software layers that you need, carefully checking
>> EMIF
>> reliability and access rate consistency at each step. By that I mean run tests
>> where
>> you can tell whether you've missed 1 out of billions of samples. Very high rate
>> systems are not easy, you have to be methodical and make many measurements to be
>> sure
>> of what is really happening.
>
> I will follow your suggestion and introduce DMA. The rate is already
> slower, so I will see what I can do. Thanks for
> all suggestions. I will keep working on solving this problem, and
> post here if I find solution for future visitors.
Yep sounds good. It seems to me that you're likely to get this to work.
-Jeff
_____________________________________
>> First, please post to the group not to me.
>
> Sorry about this, I am new to the group, and learn with time.
> Just noticed how to do that.
>
>> I assume these things connect directly to the DSK 6455 daughterboard site. Does
>> it
>> have an FPGA on it between the DAC and the daughterboard connector?
>
> You assume correctly. I guess you can say I made my own
> daughtercard. There is an FPGA between ADC and DSP to do some
> processing rate reduction, but DAC is directly connected.
> Although it can handle up to 40 Msps, I run it at 12 Msps.
> For my future designs I will keep in mind that buffer is
> always a good idea. I never worked with DSP boards before,
> and expected DSP to have lots of I/O just like any
> microprocessor/microcontroller.... I guess I was kind of
> wrong.
I think your basic thinking was Ok. DSPs do have a lot of I/O options. But a 40 MHz gap-free I/O rate is fast for
any type of CPU. Even if you were using a synchronous interface, there still might be the occasional stall or
internal memory bus conflict.
I think the only 'design flaw' (pardon me for saying) is the DAC should connect via FPGA also. Then if you do need a
FIFO or other "re-timing" it's relatively easy to implement.
>> Also, would you suggest using Timer as a DAC clock and send data
>> to EMIF every interrupt instead?
>
>> 40 MHz is way too fast for individual interrupts. If the C6455 is running 1 GHz
>> then
>> you have 25 nsec to process each sample. If you operate on buffer basis and you
>> can
>> maximize your use of parallel instructions, then maybe you can do a > bit of
>> signal
>> processing. But for non-arithmetic work like interrupt handling, there's no
>> way.
>
>> At this point, my suggestion is to experiment with much lower rates > and find
>> where
>> your system can become stable. Then add step-by-step EDMA access to > async EMIF
>> (using buffers in DSP mem) and software layers that you need, carefully checking
>> EMIF
>> reliability and access rate consistency at each step. By that I mean run tests
>> where
>> you can tell whether you've missed 1 out of billions of samples. Very high rate
>> systems are not easy, you have to be methodical and make many measurements to be
>> sure
>> of what is really happening.
>
> I will follow your suggestion and introduce DMA. The rate is already
> slower, so I will see what I can do. Thanks for
> all suggestions. I will keep working on solving this problem, and
> post here if I find solution for future visitors.
Yep sounds good. It seems to me that you're likely to get this to work.
-Jeff
_____________________________________
