Hello,
A few opinions if you will.
Using a 6713DSK, I wish to read a clocked pipeline ADC at its top speed of 20MHz
on a prototype daughtercard I have made.
I am clocking the ADC from ECLKOUT, which is from SYS3CLK, and want to setup to
run at about 20Mhz ie: ECLKOUT Mhz
What will be the minimum read strobe time I can achieve ? Can it be reduced to
say 4 ECLKOUT cycles ? or less ? via EMIF config.(That would give back to back
samples at 5 MHz or less)
Its a shame to not be able to read ADC at full 20Msps...or is it possible doing
things this way ?
I havent any experience yet at reconfiguring EMIF or setting the PLL
divisors.
Can anyone point me to examples, perhaps in CCS for 6713, or other references I
can study and amend to suit ?
Thanks,
Carlo
6713 emif to adc timing question
Started by ●June 5, 2008
Reply by ●June 5, 20082008-06-05
Carlo-
> A few opinions if you will.
>
> Using a 6713DSK, I wish to read a clocked pipeline ADC at its top speed
> of 20MHz on a prototype daughtercard I have made.
>
> I am clocking the ADC from ECLKOUT, which is from SYS3CLK, and want to
> setup to run at about 20Mhz ie: ECLKOUT Mhz
>
> What will be the minimum read strobe time I can achieve ? Can it be
> reduced to say 4 ECLKOUT cycles ? or less ? via EMIF config.(That would
> give back to back samples at 5 MHz or less)
>
> Its a shame to not be able to read ADC at full 20Msps...or is it
> possible doing things this way ?
ECLKOUT is intended for use with a synchronous EMIF interface (e.g. SDRAM), which is
not what you have. You can get 20 MHz from one of the CLKOUTn pins.
For an async EMIF interface (e.g. ADC), sustained 20 MHz read rate is not a problem
-- you can set the EMIF registers for async timing as needed. But if you use DSP
code to directly access the ADC, then one problem can be initial CPU stalls, not the
overall, or "average" rate. Typically, DSP code may wait up to 90 to 150 nsec before
it can "touch" the ADC value and use it in subsequent calculations.
The first way to try and beat this is to use DMA, in which case it matters less what
the CPU is doing. In this case you can use some type of "sample ready" signal from
the ADC, or possibly a derivative of the CLKOUTn signal (may have to be somewhat
delayed) as a DMA initiate.
In general, a very efficient method is to use some type of intermediate FIFO or other
circuitry that collects and stores samples directly from the ADC, say from 8 to 256
samples. Then the DSP reads the FIFO when full, using DMA. A typical method is to
implement the FIFO in an FPGA, which makes it flexible and easy to modify or even do
some preliminary processing before data reaches the DSP. In your case the FPGA would
be on the DSK daughtercard. If you look at some of the high speed ADC daughtercards
available out there for DSK boards, this is the architecture that is often used.
-Jeff
> I havent any experience yet at reconfiguring EMIF or setting the PLL divisors.
>
> Can anyone point me to examples, perhaps in CCS for 6713, or other references I can study and amend to suit ?
> A few opinions if you will.
>
> Using a 6713DSK, I wish to read a clocked pipeline ADC at its top speed
> of 20MHz on a prototype daughtercard I have made.
>
> I am clocking the ADC from ECLKOUT, which is from SYS3CLK, and want to
> setup to run at about 20Mhz ie: ECLKOUT Mhz
>
> What will be the minimum read strobe time I can achieve ? Can it be
> reduced to say 4 ECLKOUT cycles ? or less ? via EMIF config.(That would
> give back to back samples at 5 MHz or less)
>
> Its a shame to not be able to read ADC at full 20Msps...or is it
> possible doing things this way ?
ECLKOUT is intended for use with a synchronous EMIF interface (e.g. SDRAM), which is
not what you have. You can get 20 MHz from one of the CLKOUTn pins.
For an async EMIF interface (e.g. ADC), sustained 20 MHz read rate is not a problem
-- you can set the EMIF registers for async timing as needed. But if you use DSP
code to directly access the ADC, then one problem can be initial CPU stalls, not the
overall, or "average" rate. Typically, DSP code may wait up to 90 to 150 nsec before
it can "touch" the ADC value and use it in subsequent calculations.
The first way to try and beat this is to use DMA, in which case it matters less what
the CPU is doing. In this case you can use some type of "sample ready" signal from
the ADC, or possibly a derivative of the CLKOUTn signal (may have to be somewhat
delayed) as a DMA initiate.
In general, a very efficient method is to use some type of intermediate FIFO or other
circuitry that collects and stores samples directly from the ADC, say from 8 to 256
samples. Then the DSP reads the FIFO when full, using DMA. A typical method is to
implement the FIFO in an FPGA, which makes it flexible and easy to modify or even do
some preliminary processing before data reaches the DSP. In your case the FPGA would
be on the DSK daughtercard. If you look at some of the high speed ADC daughtercards
available out there for DSK boards, this is the architecture that is often used.
-Jeff
> I havent any experience yet at reconfiguring EMIF or setting the PLL divisors.
>
> Can anyone point me to examples, perhaps in CCS for 6713, or other references I can study and amend to suit ?
Reply by ●June 6, 20082008-06-06
Hi Jeff,
Thanks for your detailed reply.
For my application I believe I can use the EMIF to do asynchronous reads from the ADC by the DSP code. This will result in some jitter which I think my appl. can tolerate. (will find out later down the track no doubt)
Today I implemented use of the RDY signal (via some CPLD logic) to delay the completion of the /ARE strobe until the ADC data is stable. The RDY signal out of CPLD works as expected when not actually connected to the DSK DC connector RDY terminal. I start the read, with 2-10-2 timing (defaults I believe), and the RDY adds a few ECLKOUT cycles of extention to the strobe part of the /ARE when needed.
HOWEVER, when I connect my RDY signal to DSK, once it goes low, (after the /ARE goes low) it never returns HI.
This problem sounds like one posted by Adolf Klemenz " HPI lockup problem" back in June 2007...to which the solution seemed to be 'try various delay values'.
My code though is trivial...as follows.
My ECLKOUT is 90Mhz (default). Using the 225Mhz 6713 DSK. EMIF setup for CE2 is 32 bit ASRAM (default).
I do 1 READ from 0xA0100000, then WRITE that result to 0xB0000000 (where I have a DAC), then another WRITE to same DAC, then loop back.
It seems so basic...a very simple example of an Async. read with RDY (as per Fig 36 of processor databook.)
Can you or anyone else think of what I need to check, or test, to get some more ideas about this problem ?
Thanks,
Carlo
Thanks for your detailed reply.
For my application I believe I can use the EMIF to do asynchronous reads from the ADC by the DSP code. This will result in some jitter which I think my appl. can tolerate. (will find out later down the track no doubt)
Today I implemented use of the RDY signal (via some CPLD logic) to delay the completion of the /ARE strobe until the ADC data is stable. The RDY signal out of CPLD works as expected when not actually connected to the DSK DC connector RDY terminal. I start the read, with 2-10-2 timing (defaults I believe), and the RDY adds a few ECLKOUT cycles of extention to the strobe part of the /ARE when needed.
HOWEVER, when I connect my RDY signal to DSK, once it goes low, (after the /ARE goes low) it never returns HI.
This problem sounds like one posted by Adolf Klemenz " HPI lockup problem" back in June 2007...to which the solution seemed to be 'try various delay values'.
My code though is trivial...as follows.
My ECLKOUT is 90Mhz (default). Using the 225Mhz 6713 DSK. EMIF setup for CE2 is 32 bit ASRAM (default).
I do 1 READ from 0xA0100000, then WRITE that result to 0xB0000000 (where I have a DAC), then another WRITE to same DAC, then loop back.
It seems so basic...a very simple example of an Async. read with RDY (as per Fig 36 of processor databook.)
Can you or anyone else think of what I need to check, or test, to get some more ideas about this problem ?
Thanks,
Carlo
Reply by ●June 6, 20082008-06-06
Carlo-
> Thanks for your detailed reply.
>
> For my application I believe I can use the EMIF to do asynchronous reads
> from the ADC by the DSP code. This will result in some jitter which I
> think my appl. can tolerate. (will find out later down the track no doubt)
>
> Today I implemented use of the RDY signal (via some CPLD logic) to delay
> the completion of the /ARE strobe until the ADC data is stable. The RDY
> signal out of CPLD works as expected when not actually connected to the
> DSK DC connector RDY terminal. I start the read, with 2-10-2 timing
> (defaults I believe), and the RDY adds a few ECLKOUT cycles of extention
> to the strobe part of the /ARE when needed.
This sounds to me like you are a bit confused. The /ARE strobe should go straight
through to your ADC. The ADC should respond with some type of "sample ready to read"
signal -- that's like the Ready signal on Flash or other async device -- and your
CPLD logic should, in turn, drive that signal to the RDY pin on the daughterboard
connector. Alternatively, if the ADC doesn't have a suitable Ready signal (or you
didn't wire it), then your CPLD logic can use a small state-machine that is initiated
by /ARE, takes RDY low, then counts a few clocks before re-asserting RDY.
> HOWEVER, when I connect my RDY signal to DSK, once it goes low, (after the
> /ARE goes low) it never returns HI.
>
> This problem sounds like one posted by Adolf Klemenz " HPI lockup problem"
> back in June 2007...to which the solution seemed to be 'try various delay
> values'.
>
> My code though is trivial...as follows.
>
> My ECLKOUT is 90Mhz (default). Using the 225Mhz 6713 DSK. EMIF setup for
> CE2 is 32 bit ASRAM (default).
>
> I do 1 READ from 0xA0100000, then WRITE that result to 0xB0000000 (where
> I have a DAC), then another WRITE to same DAC, then loop back.
>
> It seems so basic...a very simple example of an Async. read with RDY (as
> per Fig 36 of processor databook.)
>
> Can you or anyone else think of what I need to check, or test, to get
> some more ideas about this problem ?
The DSP (and any other onboard DSK circuitry) doesn't drive RDY to the daughtercard
connector, so it's up to your daughtercard to drive this signal. If your ADC and
CPLD are not doing it, then you need to fix that.
-Jeff
> Thanks for your detailed reply.
>
> For my application I believe I can use the EMIF to do asynchronous reads
> from the ADC by the DSP code. This will result in some jitter which I
> think my appl. can tolerate. (will find out later down the track no doubt)
>
> Today I implemented use of the RDY signal (via some CPLD logic) to delay
> the completion of the /ARE strobe until the ADC data is stable. The RDY
> signal out of CPLD works as expected when not actually connected to the
> DSK DC connector RDY terminal. I start the read, with 2-10-2 timing
> (defaults I believe), and the RDY adds a few ECLKOUT cycles of extention
> to the strobe part of the /ARE when needed.
This sounds to me like you are a bit confused. The /ARE strobe should go straight
through to your ADC. The ADC should respond with some type of "sample ready to read"
signal -- that's like the Ready signal on Flash or other async device -- and your
CPLD logic should, in turn, drive that signal to the RDY pin on the daughterboard
connector. Alternatively, if the ADC doesn't have a suitable Ready signal (or you
didn't wire it), then your CPLD logic can use a small state-machine that is initiated
by /ARE, takes RDY low, then counts a few clocks before re-asserting RDY.
> HOWEVER, when I connect my RDY signal to DSK, once it goes low, (after the
> /ARE goes low) it never returns HI.
>
> This problem sounds like one posted by Adolf Klemenz " HPI lockup problem"
> back in June 2007...to which the solution seemed to be 'try various delay
> values'.
>
> My code though is trivial...as follows.
>
> My ECLKOUT is 90Mhz (default). Using the 225Mhz 6713 DSK. EMIF setup for
> CE2 is 32 bit ASRAM (default).
>
> I do 1 READ from 0xA0100000, then WRITE that result to 0xB0000000 (where
> I have a DAC), then another WRITE to same DAC, then loop back.
>
> It seems so basic...a very simple example of an Async. read with RDY (as
> per Fig 36 of processor databook.)
>
> Can you or anyone else think of what I need to check, or test, to get
> some more ideas about this problem ?
The DSP (and any other onboard DSK circuitry) doesn't drive RDY to the daughtercard
connector, so it's up to your daughtercard to drive this signal. If your ADC and
CPLD are not doing it, then you need to fix that.
-Jeff
Reply by ●June 6, 20082008-06-06
Hi Carlo,
the HPI problem was a bit different: We had two 6713 DSPs, one operating
as the host, accessing the slave DSP via HPI. The slave /HRDY output was
connected to the host ARDY input via an inverter. If the slave DSP was too
busy (lots of EDMA and short code loops), it sometimes did not release the
/HRDY line, which in turn locked the host DSP. The problem was clearly
caused by the slave DSP. By slowing down the HPI access and modifying the
slave software (among others compiling with -mi option to avoid
non-breakable loops), we could solve this issue.
In your case it must be the CPLD which holds ARDY low. I assume you have
implemented a state machine to generate ARDY. Please make sure the DSP
signals are poperly synchronized to this FSM, otherwise internal register
setup violations may occur which cause metastability and malfunction of the
FSM.
Hope this helps,
Best Regards,
Adolf Klemenz, D.SignT
At 08:17 06.06.2008 -0400, c...@emona.com.au wrote:
>Hi Jeff,
>
>Thanks for your detailed reply.
>
>For my application I believe I can use the EMIF to do asynchronous reads
>from the ADC by the DSP code. This will result in some jitter which I
>think my appl. can tolerate. (will find out later down the track no doubt)
>
>Today I implemented use of the RDY signal (via some CPLD logic) to delay
>the completion of the /ARE strobe until the ADC data is stable. The RDY
>signal out of CPLD works as expected when not actually connected to the
>DSK DC connector RDY terminal. I start the read, with 2-10-2 timing
>(defaults I believe), and the RDY adds a few ECLKOUT cycles of extention
>to the strobe part of the /ARE when needed.
>
>HOWEVER, when I connect my RDY signal to DSK, once it goes low, (after the
>/ARE goes low) it never returns HI.
>
>This problem sounds like one posted by Adolf Klemenz " HPI lockup problem"
>back in June 2007...to which the solution seemed to be 'try various delay
>values'.
>
>My code though is trivial...as follows.
>
>My ECLKOUT is 90Mhz (default). Using the 225Mhz 6713 DSK. EMIF setup for
>CE2 is 32 bit ASRAM (default).
>
>I do 1 READ from 0xA0100000, then WRITE that result to 0xB0000000 (where I
>have a DAC), then another WRITE to same DAC, then loop back.
>
>It seems so basic...a very simple example of an Async. read with RDY (as
>per Fig 36 of processor databook.)
>
>Can you or anyone else think of what I need to check, or test, to get some
>more ideas about this problem ?
>
>Thanks,
>
>Carlo
-------------------------------
D.SignT - Digital Signalprocessing Technology GmbH & Co. KG
Adolf Klemenz
Marktstr. 10
D-47647 Kerken
phone (+49)(0)2833/570-976
fax (+49)(0)2833/3328
email mailto:a...@dsignt.de
web http://www.dsignt.de
-------------------------------
the HPI problem was a bit different: We had two 6713 DSPs, one operating
as the host, accessing the slave DSP via HPI. The slave /HRDY output was
connected to the host ARDY input via an inverter. If the slave DSP was too
busy (lots of EDMA and short code loops), it sometimes did not release the
/HRDY line, which in turn locked the host DSP. The problem was clearly
caused by the slave DSP. By slowing down the HPI access and modifying the
slave software (among others compiling with -mi option to avoid
non-breakable loops), we could solve this issue.
In your case it must be the CPLD which holds ARDY low. I assume you have
implemented a state machine to generate ARDY. Please make sure the DSP
signals are poperly synchronized to this FSM, otherwise internal register
setup violations may occur which cause metastability and malfunction of the
FSM.
Hope this helps,
Best Regards,
Adolf Klemenz, D.SignT
At 08:17 06.06.2008 -0400, c...@emona.com.au wrote:
>Hi Jeff,
>
>Thanks for your detailed reply.
>
>For my application I believe I can use the EMIF to do asynchronous reads
>from the ADC by the DSP code. This will result in some jitter which I
>think my appl. can tolerate. (will find out later down the track no doubt)
>
>Today I implemented use of the RDY signal (via some CPLD logic) to delay
>the completion of the /ARE strobe until the ADC data is stable. The RDY
>signal out of CPLD works as expected when not actually connected to the
>DSK DC connector RDY terminal. I start the read, with 2-10-2 timing
>(defaults I believe), and the RDY adds a few ECLKOUT cycles of extention
>to the strobe part of the /ARE when needed.
>
>HOWEVER, when I connect my RDY signal to DSK, once it goes low, (after the
>/ARE goes low) it never returns HI.
>
>This problem sounds like one posted by Adolf Klemenz " HPI lockup problem"
>back in June 2007...to which the solution seemed to be 'try various delay
>values'.
>
>My code though is trivial...as follows.
>
>My ECLKOUT is 90Mhz (default). Using the 225Mhz 6713 DSK. EMIF setup for
>CE2 is 32 bit ASRAM (default).
>
>I do 1 READ from 0xA0100000, then WRITE that result to 0xB0000000 (where I
>have a DAC), then another WRITE to same DAC, then loop back.
>
>It seems so basic...a very simple example of an Async. read with RDY (as
>per Fig 36 of processor databook.)
>
>Can you or anyone else think of what I need to check, or test, to get some
>more ideas about this problem ?
>
>Thanks,
>
>Carlo
-------------------------------
D.SignT - Digital Signalprocessing Technology GmbH & Co. KG
Adolf Klemenz
Marktstr. 10
D-47647 Kerken
phone (+49)(0)2833/570-976
fax (+49)(0)2833/3328
email mailto:a...@dsignt.de
web http://www.dsignt.de
-------------------------------
Reply by ●June 10, 20082008-06-10
Hello,
Thanks for the suggestions.
My CPLD logic is driving the ARDY signal, and I found an error in my logic which was causing the non-return from RD strobe.
As well, I have been able to vary strobes times and clock rates etc. So some progress has been made.
Regards,
Carlo
Thanks for the suggestions.
My CPLD logic is driving the ARDY signal, and I found an error in my logic which was causing the non-return from RD strobe.
As well, I have been able to vary strobes times and clock rates etc. So some progress has been made.
Regards,
Carlo
Reply by ●June 10, 20082008-06-10
Carlo,
Thank you for the feedback. It helps others to learn the actual solution
instead of "just wondering what happened".
mikedunn
On 6/10/08, c...@emona.com.au wrote:
>
> Hello,
>
> Thanks for the suggestions.
> My CPLD logic is driving the ARDY signal, and I found an error in my logic
> which was causing the non-return from RD strobe.
>
> As well, I have been able to vary strobes times and clock rates etc. So
> some progress has been made.
>
> Regards,
> Carlo
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Thank you for the feedback. It helps others to learn the actual solution
instead of "just wondering what happened".
mikedunn
On 6/10/08, c...@emona.com.au wrote:
>
> Hello,
>
> Thanks for the suggestions.
> My CPLD logic is driving the ARDY signal, and I found an error in my logic
> which was causing the non-return from RD strobe.
>
> As well, I have been able to vary strobes times and clock rates etc. So
> some progress has been made.
>
> Regards,
> Carlo
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●June 10, 20082008-06-10
Carlo-
> Thanks for the suggestions.
> My CPLD logic is driving the ARDY signal, and I found an error in my logic which was causing the non-return from RD
> strobe.
>
> As well, I have been able to vary strobes times and clock rates etc. So some progress has been made.
Good to hear that. Hopefully things continue to go well and you can achieve your 20 MHz rate.
I agree wholeheartedly with Mike's comment that "how it turned out" feedback is helpful to others. I would add that,
if you could reply using the original thread and retain the original text, it would be helpful to people searching
this type of issue in the future.
-Jeff
> Thanks for the suggestions.
> My CPLD logic is driving the ARDY signal, and I found an error in my logic which was causing the non-return from RD
> strobe.
>
> As well, I have been able to vary strobes times and clock rates etc. So some progress has been made.
Good to hear that. Hopefully things continue to go well and you can achieve your 20 MHz rate.
I agree wholeheartedly with Mike's comment that "how it turned out" feedback is helpful to others. I would add that,
if you could reply using the original thread and retain the original text, it would be helpful to people searching
this type of issue in the future.
-Jeff
Reply by ●June 16, 20082008-06-16
Hello,
In terms of the progress I have made, I now have a situation where ECLKOUT is approx 20Mhz( which drives the pipeline ADC at full speed), and total ce-rd-ce strobe time is 3 ECLKOUT cycles (150ns).
The DSP is able to read the ADC correctly at this rate, though this is not full speed but about 5 Msps.
My question is:
Is it correct that during the external mem read to the ADC (of 150ns) the processor is not able to execute other code, and is thus held up by this slow read time ?
Is there some better way of doing this without resorting to DMA or external FIFO, that would reduce the processor overheads ?
Are there any program examples of external mem access in assembler that I can refer to, to reduce some overheads (other than Chassaings book)?
Or is this approach basically doomed to be slow ?
Thanks for any help,
Carlo
Hello,
>
>A few opinions if you will.
>
>Using a 6713DSK, I wish to read a clocked pipeline ADC at its top speed of 20MHz on a prototype daughtercard I have made.
>
>I am clocking the ADC from ECLKOUT, which is from SYS3CLK, and want to setup to run at about 20Mhz ie: ECLKOUT Mhz
>
>What will be the minimum read strobe time I can achieve ? Can it be reduced to say 4 ECLKOUT cycles ? or less ? via EMIF config.(That would give back to back samples at 5 MHz or less)
>
>Its a shame to not be able to read ADC at full 20Msps...or is it possible doing things this way ?
>
>I havent any experience yet at reconfiguring EMIF or setting the PLL divisors.
>
>Can anyone point me to examples, perhaps in CCS for 6713, or other references I can study and amend to suit ?
>
>Thanks,
>Carlo
>
In terms of the progress I have made, I now have a situation where ECLKOUT is approx 20Mhz( which drives the pipeline ADC at full speed), and total ce-rd-ce strobe time is 3 ECLKOUT cycles (150ns).
The DSP is able to read the ADC correctly at this rate, though this is not full speed but about 5 Msps.
My question is:
Is it correct that during the external mem read to the ADC (of 150ns) the processor is not able to execute other code, and is thus held up by this slow read time ?
Is there some better way of doing this without resorting to DMA or external FIFO, that would reduce the processor overheads ?
Are there any program examples of external mem access in assembler that I can refer to, to reduce some overheads (other than Chassaings book)?
Or is this approach basically doomed to be slow ?
Thanks for any help,
Carlo
Hello,
>
>A few opinions if you will.
>
>Using a 6713DSK, I wish to read a clocked pipeline ADC at its top speed of 20MHz on a prototype daughtercard I have made.
>
>I am clocking the ADC from ECLKOUT, which is from SYS3CLK, and want to setup to run at about 20Mhz ie: ECLKOUT Mhz
>
>What will be the minimum read strobe time I can achieve ? Can it be reduced to say 4 ECLKOUT cycles ? or less ? via EMIF config.(That would give back to back samples at 5 MHz or less)
>
>Its a shame to not be able to read ADC at full 20Msps...or is it possible doing things this way ?
>
>I havent any experience yet at reconfiguring EMIF or setting the PLL divisors.
>
>Can anyone point me to examples, perhaps in CCS for 6713, or other references I can study and amend to suit ?
>
>Thanks,
>Carlo
>
Reply by ●June 16, 20082008-06-16
Carlo-
> In terms of the progress I have made, I now have a situation where
> ECLKOUT is approx 20Mhz( which drives the pipeline
> ADC at full speed), and total ce-rd-ce strobe time is 3 ECLKOUT
> cycles (150ns).
>
> The DSP is able to read the ADC correctly at this rate, though this
> is not full speed but about 5 Msps.
>
> My question is:
>
> Is it correct that during the external mem read to the ADC (of
> 150ns) the processor is not able to execute other code,
> and is thus held up by this slow read time ?
If your code executes a "read mem" asm lang instruction, and it takes 4 cycles for the result to be valid, then some
other code may execute in those 4 cycles. But, if for some "onchip circuitry" reason there is additional delay (for
example, there is some competition by a non-CPU entity for an internal mem bus), then the CPU will "stall" before it
executes the next instruction.
> Is there some better way of doing this without resorting to DMA
> or external FIFO, that would reduce the processor
> overheads ?
>
> Are there any program examples of external mem access in
> assembler that I can refer to, to reduce some overheads
> (other than Chassaings book)?
>
> Or is this approach basically doomed to be slow ?
As I mentioned before, strongly urge that you try DMA. It should get you faster read performance and avoid CPU stalls
that tend to appear when using DSP code (either C or asm) to make "brute force" mem access. Obviously with a C6713
device capable of 300 MHz CPU performance and 133 MHz (at least) EMIF performance, you should be able to read memory
faster than 5 MHz.
-Jeff
> Hello,
>>
>>A few opinions if you will.
>>
>>Using a 6713DSK, I wish to read a clocked pipeline ADC at its top speed of 20MHz on a prototype daughtercard I have
>> made.
>>
>>I am clocking the ADC from ECLKOUT, which is from SYS3CLK, and want to setup to run at about 20Mhz ie: ECLKOUT Mhz
>>
>>What will be the minimum read strobe time I can achieve ? Can it be reduced to say 4 ECLKOUT cycles ? or less ? via
>> EMIF config.(That would give back to back samples at 5 MHz or less)
>>
>>Its a shame to not be able to read ADC at full 20Msps...or is it possible doing things this way ?
>>
>>I havent any experience yet at reconfiguring EMIF or setting the PLL divisors.
>>
>>Can anyone point me to examples, perhaps in CCS for 6713, or other references I can study and amend to suit ?
>>
>>Thanks,
>>Carlo
> In terms of the progress I have made, I now have a situation where
> ECLKOUT is approx 20Mhz( which drives the pipeline
> ADC at full speed), and total ce-rd-ce strobe time is 3 ECLKOUT
> cycles (150ns).
>
> The DSP is able to read the ADC correctly at this rate, though this
> is not full speed but about 5 Msps.
>
> My question is:
>
> Is it correct that during the external mem read to the ADC (of
> 150ns) the processor is not able to execute other code,
> and is thus held up by this slow read time ?
If your code executes a "read mem" asm lang instruction, and it takes 4 cycles for the result to be valid, then some
other code may execute in those 4 cycles. But, if for some "onchip circuitry" reason there is additional delay (for
example, there is some competition by a non-CPU entity for an internal mem bus), then the CPU will "stall" before it
executes the next instruction.
> Is there some better way of doing this without resorting to DMA
> or external FIFO, that would reduce the processor
> overheads ?
>
> Are there any program examples of external mem access in
> assembler that I can refer to, to reduce some overheads
> (other than Chassaings book)?
>
> Or is this approach basically doomed to be slow ?
As I mentioned before, strongly urge that you try DMA. It should get you faster read performance and avoid CPU stalls
that tend to appear when using DSP code (either C or asm) to make "brute force" mem access. Obviously with a C6713
device capable of 300 MHz CPU performance and 133 MHz (at least) EMIF performance, you should be able to read memory
faster than 5 MHz.
-Jeff
> Hello,
>>
>>A few opinions if you will.
>>
>>Using a 6713DSK, I wish to read a clocked pipeline ADC at its top speed of 20MHz on a prototype daughtercard I have
>> made.
>>
>>I am clocking the ADC from ECLKOUT, which is from SYS3CLK, and want to setup to run at about 20Mhz ie: ECLKOUT Mhz
>>
>>What will be the minimum read strobe time I can achieve ? Can it be reduced to say 4 ECLKOUT cycles ? or less ? via
>> EMIF config.(That would give back to back samples at 5 MHz or less)
>>
>>Its a shame to not be able to read ADC at full 20Msps...or is it possible doing things this way ?
>>
>>I havent any experience yet at reconfiguring EMIF or setting the PLL divisors.
>>
>>Can anyone point me to examples, perhaps in CCS for 6713, or other references I can study and amend to suit ?
>>
>>Thanks,
>>Carlo
