Hello,
Our group has got Altera DSP Development Kit, Cyclone II. The whole purpose is
to have co-processing with TI DSP via EMIF.
The development kit includes "Fast Fourier transform (FFT) coprocessor reference
design for Texas Instruments' TMS320C6416 DSK"
(http://www.altera.com/products/devkits/altera/kit-dsp-2C70.html), but the
problem is that we dont have 320C6416 DSK, but rather have 2 other models: C6455
and C6713 DSKs.
The problem is that none of us had much experience with either FPGA or DSP, and
cannot adapt the code part of C6416 to any of the two DSKs we have.
In the past few days I was left to try to do something with the .gel files, and
config files, but got really stuck, and instead of getting one build error, I
was getting another.
Cannot find any resource that would explain how to do so.
It would be great if someone could tell me where to read this material from, or
if "there is a number of steps that I need to follow and then it will be VOILA",
or a link to where this have been done. Anything that you think could help us
with this task.
Thank you very much.
Waiting for replies.
Nik
co processor design problem
Started by ●August 4, 2008
Reply by ●August 4, 20082008-08-04
Hello Nik,
On Mon, Aug 4, 2008 at 12:03 PM, wrote:
> Hello,
>
> Our group has got Altera DSP Development Kit, Cyclone II. The whole purpose
> is to have co-processing with TI DSP via EMIF.
> The development kit includes "Fast Fourier transform (FFT) coprocessor
> reference design for Texas Instruments' TMS320C6416 DSK"
> (http://www.altera.com/products/devkits/altera/kit-dsp-2C70.html), but the
> problem is that we dont have 320C6416 DSK, but rather have 2 other models:
> C6455 and C6713 DSKs.
1. Does your development card have 2 parallel 80 pin connectors
[a.k.a. TI Daughtercard Interface] that match the 6713DSK??
2. I would guess [I have never seen the kit] that the interface to the
host is via some memory locations. If so, [and #1 is true] this will
probably work on the 6713DSK or the 6455DSK. I would use the 6713DSK
to at least 'learn the interface' - the 6713 memory interface [EMIF]
more closely resembles the 6416. I would expect it to work like:
A. call a 'typical looking FFTfuction'.
B. range check params for fit; subdivide if needed
C. write params to FPGA 'input addresses'
D. get int, read FPGA 'output addresses'
E. do more 'sub functions' if needed
F. assemble the solution and return
NOTE: Daughtercard addresses in some header file
6416DSK CE2 base address = 0x68000000
6416DSK CE3 base address = 0x6C000000
6713DSK CE2 base address = 0xA0000000
6713DSK CE3 base address = 0xB0000000
3. Is the 6416 code in assembly or C?? If it is C, it should adapt
fairly easily. Assembly might not be very hard either, depending on
the complexity of the code, and the number of c64x specific
instructions.
> The problem is that none of us had much experience with either FPGA or DSP,
> and cannot adapt the code part of C6416 to any of the two DSKs we have.
> In the past few days I was left to try to do something with the .gel files,
4. GEL files [IMO] are only used during development to facilitate
hardware initialization [like allowing 'hello world' type stuff
without having to initialize a bunch of HW regs].
> and config files,
not sure what you mean by 'config files'
5. Are you referring to '.cmd' files?? Or BIOS config files??
> but got really stuck, and instead of getting one build
> error, I was getting another.
> Cannot find any resource that would explain how to do so.
>
> It would be great if someone could tell me where to read this material from,
> or if "there is a number of steps that I need to follow and then it will be
> VOILA", or a link to where this have been done. Anything that you think
> could help us with this task.
I don't have enough info to make specific suggestions [other than
'read a few dozen docs'].
6. Do you have a sample program?? [if #1 is not yes, I will need more HW info]
7. Does the sample program use DSP/BIOS??
8. Is the sample program written in C??
9. Have you tried to open a mem window at 0xA000xxxx [or whatever
address the FPGA lives at] and poke around some to see if the status
regs look valid??
mikedunn
>
> Thank you very much.
> Waiting for replies.
> Nik
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On Mon, Aug 4, 2008 at 12:03 PM, wrote:
> Hello,
>
> Our group has got Altera DSP Development Kit, Cyclone II. The whole purpose
> is to have co-processing with TI DSP via EMIF.
> The development kit includes "Fast Fourier transform (FFT) coprocessor
> reference design for Texas Instruments' TMS320C6416 DSK"
> (http://www.altera.com/products/devkits/altera/kit-dsp-2C70.html), but the
> problem is that we dont have 320C6416 DSK, but rather have 2 other models:
> C6455 and C6713 DSKs.
1. Does your development card have 2 parallel 80 pin connectors
[a.k.a. TI Daughtercard Interface] that match the 6713DSK??
2. I would guess [I have never seen the kit] that the interface to the
host is via some memory locations. If so, [and #1 is true] this will
probably work on the 6713DSK or the 6455DSK. I would use the 6713DSK
to at least 'learn the interface' - the 6713 memory interface [EMIF]
more closely resembles the 6416. I would expect it to work like:
A. call a 'typical looking FFTfuction'.
B. range check params for fit; subdivide if needed
C. write params to FPGA 'input addresses'
D. get int, read FPGA 'output addresses'
E. do more 'sub functions' if needed
F. assemble the solution and return
NOTE: Daughtercard addresses in some header file
6416DSK CE2 base address = 0x68000000
6416DSK CE3 base address = 0x6C000000
6713DSK CE2 base address = 0xA0000000
6713DSK CE3 base address = 0xB0000000
3. Is the 6416 code in assembly or C?? If it is C, it should adapt
fairly easily. Assembly might not be very hard either, depending on
the complexity of the code, and the number of c64x specific
instructions.
> The problem is that none of us had much experience with either FPGA or DSP,
> and cannot adapt the code part of C6416 to any of the two DSKs we have.
> In the past few days I was left to try to do something with the .gel files,
4. GEL files [IMO] are only used during development to facilitate
hardware initialization [like allowing 'hello world' type stuff
without having to initialize a bunch of HW regs].
> and config files,
not sure what you mean by 'config files'
5. Are you referring to '.cmd' files?? Or BIOS config files??
> but got really stuck, and instead of getting one build
> error, I was getting another.
> Cannot find any resource that would explain how to do so.
>
> It would be great if someone could tell me where to read this material from,
> or if "there is a number of steps that I need to follow and then it will be
> VOILA", or a link to where this have been done. Anything that you think
> could help us with this task.
I don't have enough info to make specific suggestions [other than
'read a few dozen docs'].
6. Do you have a sample program?? [if #1 is not yes, I will need more HW info]
7. Does the sample program use DSP/BIOS??
8. Is the sample program written in C??
9. Have you tried to open a mem window at 0xA000xxxx [or whatever
address the FPGA lives at] and poke around some to see if the status
regs look valid??
mikedunn
>
> Thank you very much.
> Waiting for replies.
> Nik
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●August 4, 20082008-08-04
Hello.
1. Yes, both of the DSK boards have 2 parallel 80 pin connectors.
(Both of them are from Spectrum Digital, and this is exactly one of the boards that we are using, C6713: http://www.spectrumdigital.com/product_info.php?cPath1_75&products_id3&osCsidc594beb254d12b4b5f08a8a5a2a4f)
2. Ok, I will be trying to implement it on C6713 rather than on C6455.
The steps are approximately as you stated. I do not clearly understand them myself at the point when it comes to writing the data to one of those parallel ports for transmission to Altera board, as well as I cannot see how the data is received at those parallel ports after being processed by the Altera board.
This page ( http://www.altera.com/products/devkits/altera/kit-dsp-2C70.html#documentation ) provides a .zip file "Cyclone II EP2C70 DSP Development Board Design Files" and inside that folder there is a folder ...\TI6455_Quartus_documents\emif_ref_design_FFT. One part for Altera board, which seems to be working fine for me, and the other folder is for TI board. (Oh and the code for TI board is in C language.)
Concerning the daughtercard addresses that you have mentioned. Though the file is meant to be for C6416, all i could find in all the files are the following two lines in the file that also contains the main() function:
reset_hw(0xB0000000);
reset_hw(0xA0000000);
While the reset_hw() is defined as follows:
void reset_hw(UINT32 base)
{
emif_base = (volatile UINT32 *)base;
// Give hardware a soft reset
emif_base[0x80/4] = 1;
}
Where, emif_base is defined as:
volatile UINT32 * emif_base;
and emif_base doesn't seem to be passed to any function anywhere else in the file. Confusing.
>3. Is the 6416 code in assembly or C?? If it is C, it should adapt
fairly easily. Assembly might not be very hard either, depending on
the complexity of the code, and the number of c64x specific
instructions.
3. Yes, the code is in C.
>4. GEL files [IMO] are only used during development to facilitate
hardware initialization [like allowing 'hello world' type stuff
without having to initialize a bunch of HW regs].
4. Since .gel files are used as you say, then I will not be messing around with it anymore. I was actually trying to somehow "modify" DSK6455.gel, and it didn't really work out well. So, I decided to leave DSK6455.gel as it is and the program was building again. (Yeah, the program is building. I should have mentioned it earlier. The problem is that it doesnt work fully. I have put some printfs and GEL_TextOut's and it seems that the problem occurs due to transmission not taking place, since there should be a counter increased with every packet sent to Altera, but it never does increase.)
>5. Are you referring to '.cmd' files?? Or BIOS config files??
5. Yes, DSP/BIOS config (originally in .cmd, but I have converted it to .tcf with the provided tool by TI or Altera. Newer versions of CCS require .tcf. In any case, I have tried running it on the older version of CCS with the .cmd file, and was still getting the same results. So, config file is not the source of the error independently of the format it is in.)
>6. Do you have a sample program?? [if #1 is not yes, I will need more HW info]
6. The sample program, actually the exact program, is provided in that file I have mentioned above. It seems to be too much to post it in here. Please let me know if you would rather prefer me to post it right here in the next post.
>7. Does the sample program use DSP/BIOS??
7. I do not really know/understand. There is a dsp/bios config file as I have said, but I do not really understand what you mean.
>8. Is the sample program written in C??
8. Yes, in C.
>9. Have you tried to open a mem window at 0xA000xxxx [or whatever
address the FPGA lives at] and poke around some to see if the status
regs look valid??
9. No, I have not tried, and do not really know how to do so.
Thank you very much for detailed approach and your time. Helps very much.
Really looking forward to hear from you.
Nik
1. Yes, both of the DSK boards have 2 parallel 80 pin connectors.
(Both of them are from Spectrum Digital, and this is exactly one of the boards that we are using, C6713: http://www.spectrumdigital.com/product_info.php?cPath1_75&products_id3&osCsidc594beb254d12b4b5f08a8a5a2a4f)
2. Ok, I will be trying to implement it on C6713 rather than on C6455.
The steps are approximately as you stated. I do not clearly understand them myself at the point when it comes to writing the data to one of those parallel ports for transmission to Altera board, as well as I cannot see how the data is received at those parallel ports after being processed by the Altera board.
This page ( http://www.altera.com/products/devkits/altera/kit-dsp-2C70.html#documentation ) provides a .zip file "Cyclone II EP2C70 DSP Development Board Design Files" and inside that folder there is a folder ...\TI6455_Quartus_documents\emif_ref_design_FFT. One part for Altera board, which seems to be working fine for me, and the other folder is for TI board. (Oh and the code for TI board is in C language.)
Concerning the daughtercard addresses that you have mentioned. Though the file is meant to be for C6416, all i could find in all the files are the following two lines in the file that also contains the main() function:
reset_hw(0xB0000000);
reset_hw(0xA0000000);
While the reset_hw() is defined as follows:
void reset_hw(UINT32 base)
{
emif_base = (volatile UINT32 *)base;
// Give hardware a soft reset
emif_base[0x80/4] = 1;
}
Where, emif_base is defined as:
volatile UINT32 * emif_base;
and emif_base doesn't seem to be passed to any function anywhere else in the file. Confusing.
>3. Is the 6416 code in assembly or C?? If it is C, it should adapt
fairly easily. Assembly might not be very hard either, depending on
the complexity of the code, and the number of c64x specific
instructions.
3. Yes, the code is in C.
>4. GEL files [IMO] are only used during development to facilitate
hardware initialization [like allowing 'hello world' type stuff
without having to initialize a bunch of HW regs].
4. Since .gel files are used as you say, then I will not be messing around with it anymore. I was actually trying to somehow "modify" DSK6455.gel, and it didn't really work out well. So, I decided to leave DSK6455.gel as it is and the program was building again. (Yeah, the program is building. I should have mentioned it earlier. The problem is that it doesnt work fully. I have put some printfs and GEL_TextOut's and it seems that the problem occurs due to transmission not taking place, since there should be a counter increased with every packet sent to Altera, but it never does increase.)
>5. Are you referring to '.cmd' files?? Or BIOS config files??
5. Yes, DSP/BIOS config (originally in .cmd, but I have converted it to .tcf with the provided tool by TI or Altera. Newer versions of CCS require .tcf. In any case, I have tried running it on the older version of CCS with the .cmd file, and was still getting the same results. So, config file is not the source of the error independently of the format it is in.)
>6. Do you have a sample program?? [if #1 is not yes, I will need more HW info]
6. The sample program, actually the exact program, is provided in that file I have mentioned above. It seems to be too much to post it in here. Please let me know if you would rather prefer me to post it right here in the next post.
>7. Does the sample program use DSP/BIOS??
7. I do not really know/understand. There is a dsp/bios config file as I have said, but I do not really understand what you mean.
>8. Is the sample program written in C??
8. Yes, in C.
>9. Have you tried to open a mem window at 0xA000xxxx [or whatever
address the FPGA lives at] and poke around some to see if the status
regs look valid??
9. No, I have not tried, and do not really know how to do so.
Thank you very much for detailed approach and your time. Helps very much.
Really looking forward to hear from you.
Nik
Reply by ●August 5, 20082008-08-05
Nik,
Please retain the original text. I do some multi-tasking and I have a
very small stack and sometimes I cannot remember what I said last
time.
:-)
On Mon, Aug 4, 2008 at 4:41 PM, wrote:
> Hello.
>
> 1. Yes, both of the DSK boards have 2 parallel 80 pin connectors.
> (Both of them are from Spectrum Digital, and this is exactly one of the
> boards that we are using, C6713:
> http://www.spectrumdigital.com/product_info.php?cPath1_75&products_id3&osCsidc594beb254d12b4b5f08a8a5a2a4f)
Actually I meant to ask if your Altera board had the connectors,
but I see that it does. I was just trying to make sure that the
Altera/DSK connection was what I was expecting.
>
> 2. Ok, I will be trying to implement it on C6713 rather than on C6455.
> The steps are approximately as you stated. I do not clearly understand them
> myself at the point when it comes to writing the data to one of those
> parallel ports for transmission to Altera board, as well as I cannot see how
> the data is received at those parallel ports after being processed by the
> Altera board.
> This page (
> http://www.altera.com/products/devkits/altera/kit-dsp-2C70.html#documentation
> ) provides a .zip file "Cyclone II EP2C70 DSP Development Board Design
> Files" and inside that folder there is a folder
> ...\TI6455_Quartus_documents\emif_ref_design_FFT.
I don't know what is up. I went there -
ftp://ftp.altera.com/outgoing/devkit/CycloneII_DSP-v1.0.1_CD.zip
and didn't find any *6455* files or directories. The only thing under
'altera/kits/' was 'CycloneII_DSP_Kit-v1.0.1'.
Under 'C:\altera\kits\CycloneII_DSP_Kit-v1.0.1\Examples\HW\ReferenceDesigns\emif_ref_design_FFT\TI6416'
I used
'grep -ni 0x[ab]00..... *.[ch]' and found the following:
edma.c:122: EDMA_SRC_OF(0xb0000080), // src address
edma.c:161: EDMA_DST_OF(0xB0000000), // dest address
edma.c:246: tx_credit_inc(0xB0000000);
edma.c:283: tx_credit_inc(0xb0000000);
fft_ping_pong.c:52:// actual emif is at 0xb0000000
fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
fft_ping_pong.c:134: reset_hw(0xB0000000);
fft_ping_pong.c:136: reset_hw(0xA0000000);
fft_ping_pong.c:146: tx_credit_inc(0xA0000000);
fft_ping_pong.c:154: tx_credit_inc(0xB0000000);
FYI - ping and pong are used to reference the double buffers in many
TI double buffer designs.
Some of the 'artifact files' [and 2004/2005 dates] indicate that the
included examples were built under CCS 2.x.
Check your project for 'csl6416.lib' - you will have to replace it
with 6713 version. You will probably have to search for it. The
project has a preprocessor def [-d"CHIP_6416"] that needs to be
changed to 6713. The 'processor build type' will also have to be
changed.
I assume that the problem is that 'the project will not build' - once
you do this stuff, let us know where you are.
> One part for Altera board,
> which seems to be working fine for me, and the other folder is for TI board.
> (Oh and the code for TI board is in C language.)
>
> Concerning the daughtercard addresses that you have mentioned. Though the
> file is meant to be for C6416, all i could find in all the files are the
> following two lines in the file that also contains the main() function:
>
RE:
NOTE: Daughtercard addresses in some header file
6416DSK CE2 base address = 0x68000000 <<-------------------wrong s/be 0xA0000000
6416DSK CE3 base address = 0x6C000000 <<-------------------wrong s/be 0xB0000000
The above are incorrect. For some reason my memory failed me and I
remembered [incorrectly] that the daughtercard was on EMIF B. Itis on
EMIF A at the same addresses as the 6713.
Sorry 'bout that.
mikedunn
6713DSK CE2 base address = 0xA0000000
6713DSK CE3 base address = 0xB0000000
> reset_hw(0xB0000000);
>
> reset_hw(0xA0000000);
>
> While the reset_hw() is defined as follows:
>
> void reset_hw(UINT32 base)
> {
> emif_base = (volatile UINT32 *)base;
> // Give hardware a soft reset
> emif_base[0x80/4] = 1;
> }
> Where, emif_base is defined as:
>
> volatile UINT32 * emif_base;
>
> and emif_base doesn't seem to be passed to any function anywhere else in the
> file. Confusing.
>
>>3. Is the 6416 code in assembly or C?? If it is C, it should adapt
> fairly easily. Assembly might not be very hard either, depending on
> the complexity of the code, and the number of c64x specific
> instructions.
>
> 3. Yes, the code is in C.
>
>>4. GEL files [IMO] are only used during development to facilitate
> hardware initialization [like allowing 'hello world' type stuff
> without having to initialize a bunch of HW regs].
>
> 4. Since .gel files are used as you say, then I will not be messing around
> with it anymore. I was actually trying to somehow "modify" DSK6455.gel, and
> it didn't really work out well. So, I decided to leave DSK6455.gel as it is
> and the program was building again. (Yeah, the program is building. I should
> have mentioned it earlier. The problem is that it doesnt work fully. I have
> put some printfs and GEL_TextOut's and it seems that the problem occurs due
> to transmission not taking place, since there should be a counter increased
> with every packet sent to Altera, but it never does increase.)
>
>>5. Are you referring to '.cmd' files?? Or BIOS config files??
>
> 5. Yes, DSP/BIOS config (originally in .cmd, but I have converted it to .tcf
> with the provided tool by TI or Altera. Newer versions of CCS require .tcf.
> In any case, I have tried running it on the older version of CCS with the
> .cmd file, and was still getting the same results. So, config file is not
> the source of the error independently of the format it is in.)
>
>>6. Do you have a sample program?? [if #1 is not yes, I will need more HW
>> info]
>
> 6. The sample program, actually the exact program, is provided in that file
> I have mentioned above. It seems to be too much to post it in here. Please
> let me know if you would rather prefer me to post it right here in the next
> post.
>
>>7. Does the sample program use DSP/BIOS??
>
> 7. I do not really know/understand. There is a dsp/bios config file as I
> have said, but I do not really understand what you mean.
>
>>8. Is the sample program written in C??
>
> 8. Yes, in C.
>
>>9. Have you tried to open a mem window at 0xA000xxxx [or whatever
> address the FPGA lives at] and poke around some to see if the status
> regs look valid??
>
> 9. No, I have not tried, and do not really know how to do so.
>
> Thank you very much for detailed approach and your time. Helps very much.
> Really looking forward to hear from you.
> Nik
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Please retain the original text. I do some multi-tasking and I have a
very small stack and sometimes I cannot remember what I said last
time.
:-)
On Mon, Aug 4, 2008 at 4:41 PM, wrote:
> Hello.
>
> 1. Yes, both of the DSK boards have 2 parallel 80 pin connectors.
> (Both of them are from Spectrum Digital, and this is exactly one of the
> boards that we are using, C6713:
> http://www.spectrumdigital.com/product_info.php?cPath1_75&products_id3&osCsidc594beb254d12b4b5f08a8a5a2a4f)
Actually I meant to ask if your Altera board had the connectors,
but I see that it does. I was just trying to make sure that the
Altera/DSK connection was what I was expecting.
>
> 2. Ok, I will be trying to implement it on C6713 rather than on C6455.
> The steps are approximately as you stated. I do not clearly understand them
> myself at the point when it comes to writing the data to one of those
> parallel ports for transmission to Altera board, as well as I cannot see how
> the data is received at those parallel ports after being processed by the
> Altera board.
> This page (
> http://www.altera.com/products/devkits/altera/kit-dsp-2C70.html#documentation
> ) provides a .zip file "Cyclone II EP2C70 DSP Development Board Design
> Files" and inside that folder there is a folder
> ...\TI6455_Quartus_documents\emif_ref_design_FFT.
I don't know what is up. I went there -
ftp://ftp.altera.com/outgoing/devkit/CycloneII_DSP-v1.0.1_CD.zip
and didn't find any *6455* files or directories. The only thing under
'altera/kits/' was 'CycloneII_DSP_Kit-v1.0.1'.
Under 'C:\altera\kits\CycloneII_DSP_Kit-v1.0.1\Examples\HW\ReferenceDesigns\emif_ref_design_FFT\TI6416'
I used
'grep -ni 0x[ab]00..... *.[ch]' and found the following:
edma.c:122: EDMA_SRC_OF(0xb0000080), // src address
edma.c:161: EDMA_DST_OF(0xB0000000), // dest address
edma.c:246: tx_credit_inc(0xB0000000);
edma.c:283: tx_credit_inc(0xb0000000);
fft_ping_pong.c:52:// actual emif is at 0xb0000000
fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
fft_ping_pong.c:134: reset_hw(0xB0000000);
fft_ping_pong.c:136: reset_hw(0xA0000000);
fft_ping_pong.c:146: tx_credit_inc(0xA0000000);
fft_ping_pong.c:154: tx_credit_inc(0xB0000000);
FYI - ping and pong are used to reference the double buffers in many
TI double buffer designs.
Some of the 'artifact files' [and 2004/2005 dates] indicate that the
included examples were built under CCS 2.x.
Check your project for 'csl6416.lib' - you will have to replace it
with 6713 version. You will probably have to search for it. The
project has a preprocessor def [-d"CHIP_6416"] that needs to be
changed to 6713. The 'processor build type' will also have to be
changed.
I assume that the problem is that 'the project will not build' - once
you do this stuff, let us know where you are.
> One part for Altera board,
> which seems to be working fine for me, and the other folder is for TI board.
> (Oh and the code for TI board is in C language.)
>
> Concerning the daughtercard addresses that you have mentioned. Though the
> file is meant to be for C6416, all i could find in all the files are the
> following two lines in the file that also contains the main() function:
>
RE:
NOTE: Daughtercard addresses in some header file
6416DSK CE2 base address = 0x68000000 <<-------------------wrong s/be 0xA0000000
6416DSK CE3 base address = 0x6C000000 <<-------------------wrong s/be 0xB0000000
The above are incorrect. For some reason my memory failed me and I
remembered [incorrectly] that the daughtercard was on EMIF B. Itis on
EMIF A at the same addresses as the 6713.
Sorry 'bout that.
mikedunn
6713DSK CE2 base address = 0xA0000000
6713DSK CE3 base address = 0xB0000000
> reset_hw(0xB0000000);
>
> reset_hw(0xA0000000);
>
> While the reset_hw() is defined as follows:
>
> void reset_hw(UINT32 base)
> {
> emif_base = (volatile UINT32 *)base;
> // Give hardware a soft reset
> emif_base[0x80/4] = 1;
> }
> Where, emif_base is defined as:
>
> volatile UINT32 * emif_base;
>
> and emif_base doesn't seem to be passed to any function anywhere else in the
> file. Confusing.
>
>>3. Is the 6416 code in assembly or C?? If it is C, it should adapt
> fairly easily. Assembly might not be very hard either, depending on
> the complexity of the code, and the number of c64x specific
> instructions.
>
> 3. Yes, the code is in C.
>
>>4. GEL files [IMO] are only used during development to facilitate
> hardware initialization [like allowing 'hello world' type stuff
> without having to initialize a bunch of HW regs].
>
> 4. Since .gel files are used as you say, then I will not be messing around
> with it anymore. I was actually trying to somehow "modify" DSK6455.gel, and
> it didn't really work out well. So, I decided to leave DSK6455.gel as it is
> and the program was building again. (Yeah, the program is building. I should
> have mentioned it earlier. The problem is that it doesnt work fully. I have
> put some printfs and GEL_TextOut's and it seems that the problem occurs due
> to transmission not taking place, since there should be a counter increased
> with every packet sent to Altera, but it never does increase.)
>
>>5. Are you referring to '.cmd' files?? Or BIOS config files??
>
> 5. Yes, DSP/BIOS config (originally in .cmd, but I have converted it to .tcf
> with the provided tool by TI or Altera. Newer versions of CCS require .tcf.
> In any case, I have tried running it on the older version of CCS with the
> .cmd file, and was still getting the same results. So, config file is not
> the source of the error independently of the format it is in.)
>
>>6. Do you have a sample program?? [if #1 is not yes, I will need more HW
>> info]
>
> 6. The sample program, actually the exact program, is provided in that file
> I have mentioned above. It seems to be too much to post it in here. Please
> let me know if you would rather prefer me to post it right here in the next
> post.
>
>>7. Does the sample program use DSP/BIOS??
>
> 7. I do not really know/understand. There is a dsp/bios config file as I
> have said, but I do not really understand what you mean.
>
>>8. Is the sample program written in C??
>
> 8. Yes, in C.
>
>>9. Have you tried to open a mem window at 0xA000xxxx [or whatever
> address the FPGA lives at] and poke around some to see if the status
> regs look valid??
>
> 9. No, I have not tried, and do not really know how to do so.
>
> Thank you very much for detailed approach and your time. Helps very much.
> Really looking forward to hear from you.
> Nik
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●August 5, 20082008-08-05
Nik,
Please retain the original text. I do some multi-tasking and I have a
very small stack and sometimes I cannot remember what I said last
time.
:-)
Sorry for not referring to the original text.
I don't know what is up. I went there -
ftp://ftp.altera.com/outgoing/devkit/CycloneII_DSP-v1.0.1_CD.zip
and didn't find any *6455* files or directories. The only thing under
'altera/kits/' was 'CycloneII_DSP_Kit-v1.0.1'.
Again, my fault, but I have given you the wrong directory, since this is how
I renamed it on my laptop. And you have gone exactly to the location that I
meant.
I am confised concerning this daughtercard(these two 80-pin ports as I
understand), namely - is it the EMIF that takes care for the data
transmission from the TI to Altera? Or is it EDMA? Sorry if it might seem
too newbie for a question. It seems that both are resposible and has their
own tasks to do in the whole process.
Under
'C:\altera\kits\CycloneII_DSP_Kit-v1.0.1\Examples\HW\ReferenceDesigns\emif_ref_design_FFT\TI6416'
I used
'grep -ni 0x[ab]00..... *.[ch]' and found the following:
edma.c:122: EDMA_SRC_OF(0xb0000080), // src
address
edma.c:161: EDMA_DST_OF(0xB0000000), // dest
address
edma.c:246: tx_credit_inc(0xB0000000);
edma.c:283: tx_credit_inc(0xb0000000);
fft_ping_pong.c:52:// actual emif is at 0xb0000000
fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
fft_ping_pong.c:134: reset_hw(0xB0000000);
fft_ping_pong.c:136: reset_hw(0xA0000000);
fft_ping_pong.c:146: tx_credit_inc(0xA0000000);
fft_ping_pong.c:154: tx_credit_inc(0xB0000000);
FYI - ping and pong are used to reference the double buffers in many
TI double buffer designs.
Some of the 'artifact files' [and 2004/2005 dates] indicate that the
included examples were built under CCS 2.x.
So, is this the line that "turns the transmission on" so to say? I mean that
address in the brackets
edma.c:246: tx_credit_inc(0xB0000000);
If so, then what is the line that would be doing something about receiving?
Check your project for 'csl6416.lib' - you will have to replace it
with 6713 version. You will probably have to search for it. The
project has a preprocessor def [-d"CHIP_6416"] that needs to be
changed to 6713. The 'processor build type' will also have to be
changed.
I assume that the problem is that 'the project will not build' - once
you do this stuff, let us know where you are.
Yes, IO have changed the processor build type, and the preprocessor. The
thing with preprocessor is that there is no CHIP_6713 predefined in the
csl.h or some other csl_*.h file, but there is a CHIP_6711, so I have tried
with this one and it worked fine(at least i think that it did). It did build
and I loaded it onto the board.
After running it though, it does not run all the way. It stops(not in a gets
frozen way, or some other, so to say "bad" way ) at a certain point. What
happens is that there is a counter that (I think) is supposed to be
incremented up to a certain value with every package/packet that is being
transmitted(or rather sent to some port), but this is exactly the problem,
it seems that this EMIF port is not being accessed by the data, and the
counter is not incremented, and I cannot figure out what to do here.
The code that you have downloaded is exactly the one I am using, and here is
the output I am getting:
FFT core test program
CLOCK_DIVIDE: 37
Starting signal generation
Done signal generation
Testing with 1024 word blocks
Writing to LEDs
Increment Tx credit
But the increment is not taking place. I have tried adding this value of
rxcount that is supposed to be incremented into the watch window and doing
step by step procedure, but it keeps staying 0...
RE:
NOTE: Daughtercard addresses in some header file
6416DSK CE2 base address = 0x68000000 <<-------------------wrong s/be
0xA0000000
6416DSK CE3 base address = 0x6C000000 <<-------------------wrong s/be
0xB0000000
The above are incorrect. For some reason my memory failed me and I
remembered [incorrectly] that the daughtercard was on EMIF B. Itis on
EMIF A at the same addresses as the 6713.
6713DSK CE2 base address = 0xA0000000
6713DSK CE3 base address = 0xB0000000
I see from the help manual that these CE's are the chip enablers for
particular type of memory, and I have to tell you that I am using IRAM type
and not SDRAM. I do not fully understan what is happening here either.
Eagerly wsiting (and meanwhile trying out)
Nik
Please retain the original text. I do some multi-tasking and I have a
very small stack and sometimes I cannot remember what I said last
time.
:-)
Sorry for not referring to the original text.
I don't know what is up. I went there -
ftp://ftp.altera.com/outgoing/devkit/CycloneII_DSP-v1.0.1_CD.zip
and didn't find any *6455* files or directories. The only thing under
'altera/kits/' was 'CycloneII_DSP_Kit-v1.0.1'.
Again, my fault, but I have given you the wrong directory, since this is how
I renamed it on my laptop. And you have gone exactly to the location that I
meant.
I am confised concerning this daughtercard(these two 80-pin ports as I
understand), namely - is it the EMIF that takes care for the data
transmission from the TI to Altera? Or is it EDMA? Sorry if it might seem
too newbie for a question. It seems that both are resposible and has their
own tasks to do in the whole process.
Under
'C:\altera\kits\CycloneII_DSP_Kit-v1.0.1\Examples\HW\ReferenceDesigns\emif_ref_design_FFT\TI6416'
I used
'grep -ni 0x[ab]00..... *.[ch]' and found the following:
edma.c:122: EDMA_SRC_OF(0xb0000080), // src
address
edma.c:161: EDMA_DST_OF(0xB0000000), // dest
address
edma.c:246: tx_credit_inc(0xB0000000);
edma.c:283: tx_credit_inc(0xb0000000);
fft_ping_pong.c:52:// actual emif is at 0xb0000000
fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
fft_ping_pong.c:134: reset_hw(0xB0000000);
fft_ping_pong.c:136: reset_hw(0xA0000000);
fft_ping_pong.c:146: tx_credit_inc(0xA0000000);
fft_ping_pong.c:154: tx_credit_inc(0xB0000000);
FYI - ping and pong are used to reference the double buffers in many
TI double buffer designs.
Some of the 'artifact files' [and 2004/2005 dates] indicate that the
included examples were built under CCS 2.x.
So, is this the line that "turns the transmission on" so to say? I mean that
address in the brackets
edma.c:246: tx_credit_inc(0xB0000000);
If so, then what is the line that would be doing something about receiving?
Check your project for 'csl6416.lib' - you will have to replace it
with 6713 version. You will probably have to search for it. The
project has a preprocessor def [-d"CHIP_6416"] that needs to be
changed to 6713. The 'processor build type' will also have to be
changed.
I assume that the problem is that 'the project will not build' - once
you do this stuff, let us know where you are.
Yes, IO have changed the processor build type, and the preprocessor. The
thing with preprocessor is that there is no CHIP_6713 predefined in the
csl.h or some other csl_*.h file, but there is a CHIP_6711, so I have tried
with this one and it worked fine(at least i think that it did). It did build
and I loaded it onto the board.
After running it though, it does not run all the way. It stops(not in a gets
frozen way, or some other, so to say "bad" way ) at a certain point. What
happens is that there is a counter that (I think) is supposed to be
incremented up to a certain value with every package/packet that is being
transmitted(or rather sent to some port), but this is exactly the problem,
it seems that this EMIF port is not being accessed by the data, and the
counter is not incremented, and I cannot figure out what to do here.
The code that you have downloaded is exactly the one I am using, and here is
the output I am getting:
FFT core test program
CLOCK_DIVIDE: 37
Starting signal generation
Done signal generation
Testing with 1024 word blocks
Writing to LEDs
Increment Tx credit
But the increment is not taking place. I have tried adding this value of
rxcount that is supposed to be incremented into the watch window and doing
step by step procedure, but it keeps staying 0...
RE:
NOTE: Daughtercard addresses in some header file
6416DSK CE2 base address = 0x68000000 <<-------------------wrong s/be
0xA0000000
6416DSK CE3 base address = 0x6C000000 <<-------------------wrong s/be
0xB0000000
The above are incorrect. For some reason my memory failed me and I
remembered [incorrectly] that the daughtercard was on EMIF B. Itis on
EMIF A at the same addresses as the 6713.
6713DSK CE2 base address = 0xA0000000
6713DSK CE3 base address = 0xB0000000
I see from the help manual that these CE's are the chip enablers for
particular type of memory, and I have to tell you that I am using IRAM type
and not SDRAM. I do not fully understan what is happening here either.
Eagerly wsiting (and meanwhile trying out)
Nik
Reply by ●August 5, 20082008-08-05
Nik,
On Tue, Aug 5, 2008 at 11:03 AM, Nikolay Melnikov
wrote:
> Nik,
>
> Please retain the original text. I do some multi-tasking and I have a
> very small stack and sometimes I cannot remember what I said last
> time.
> :-)
>
> Sorry for not referring to the original text.
> I don't know what is up. I went there -
> ftp://ftp.altera.com/outgoing/devkit/CycloneII_DSP-v1.0.1_CD.zip
> and didn't find any *6455* files or directories. The only thing under
> 'altera/kits/' was 'CycloneII_DSP_Kit-v1.0.1'.
>
> Again, my fault, but I have given you the wrong directory, since this is how
> I renamed it on my laptop. And you have gone exactly to the location that I
> meant.
> I am confised concerning this daughtercard(these two 80-pin ports as I
> understand), namely - is it the EMIF that takes care for the data
> transmission from the TI to Altera? Or is it EDMA? Sorry if it might seem
> too newbie for a question. It seems that both are resposible and has their
> own tasks to do in the whole process.
EMIF= External Memory InterFace = memory bus - add, data, control
EDMA = Enhanced DMA = the DMA mechanism to xfer data via the EMIF
TI I/O is memory mapped I/O
>
> Under
> 'C:\altera\kits\CycloneII_DSP_Kit-v1.0.1\Examples\HW\ReferenceDesigns\emif_ref_design_FFT\TI6416'
> I used
> 'grep -ni 0x[ab]00..... *.[ch]' and found the following:
> edma.c:122: EDMA_SRC_OF(0xb0000080), // src
> address
> edma.c:161: EDMA_DST_OF(0xB0000000), // dest
> address
> edma.c:246: tx_credit_inc(0xB0000000);
> edma.c:283: tx_credit_inc(0xb0000000);
> fft_ping_pong.c:52:// actual emif is at 0xb0000000
> fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
> fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
> fft_ping_pong.c:134: reset_hw(0xB0000000);
> fft_ping_pong.c:136: reset_hw(0xA0000000);
> fft_ping_pong.c:146: tx_credit_inc(0xA0000000);
> fft_ping_pong.c:154: tx_credit_inc(0xB0000000);
>
> FYI - ping and pong are used to reference the double buffers in many
> TI double buffer designs.
>
> Some of the 'artifact files' [and 2004/2005 dates] indicate that the
> included examples were built under CCS 2.x.
>
> So, is this the line that "turns the transmission on" so to say? I mean that
> address in the brackets
> edma.c:246: tx_credit_inc(0xB0000000);
> If so, then what is the line that would be doing something about receiving?
BTW, your mail reader has put my reply and your reply at the same
'level' of '>'.
These 2 lines
fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
probably are the base address of 2 dual port memories in the FPGA -
one for wr[tx] and 1 for rd[rx].
I don't know if they are split for real/complex numbers. that would be
in the FPGA VHDL/HDL code.
>
> Check your project for 'csl6416.lib' - you will have to replace it
> with 6713 version. You will probably have to search for it. The
> project has a preprocessor def [-d"CHIP_6416"] that needs to be
> changed to 6713. The 'processor build type' will also have to be
> changed.
>
> I assume that the problem is that 'the project will not build' - once
> you do this stuff, let us know where you are.
>
> Yes, IO have changed the processor build type, and the preprocessor. The
> thing with preprocessor is that there is no CHIP_6713 predefined in the
> csl.h or some other csl_*.h file, but there is a CHIP_6711, so I have tried
> with this one and it worked fine(at least i think that it did). It did build
> and I loaded it onto the board.
I suspect that the CSL that you have is a bit old - pre-6713.
You really need 6713 support - it has a slightly different
initialization that 6711.
Do you know what version of DSP/BIOS that you have??
> After running it though, it does not run all the way. It stops(not in a gets
> frozen way, or some other, so to say "bad" way ) at a certain point. What
> happens is that there is a counter that (I think) is supposed to be
> incremented up to a certain value with every package/packet that is being
> transmitted(or rather sent to some port), but this is exactly the problem,
> it seems that this EMIF port is not being accessed by the data, and the
> counter is not incremented, and I cannot figure out what to do here.
You can monitor access to the Altera board by checking CE3 and ARE
[reads] and AWE [writes].
>
> The code that you have downloaded is exactly the one I am using, and here is
> the output I am getting:
>
> FFT core test program
>
> CLOCK_DIVIDE: 37
> Starting signal generation
> Done signal generation
> Testing with 1024 word blocks
> Writing to LEDs
> Increment Tx credit
>
> But the increment is not taking place. I have tried adding this value of
> rxcount that is supposed to be incremented into the watch window and doing
> step by step procedure, but it keeps staying 0...
>
You are working with a lot of unknowns.
If you can figure out how the FPGA is supposed to work [at a block
diagram level], I would suggest the following:
1. Put the original project aside [use it for some reference.
2. write a simple program that stuffs some values [they need to be
valid] to emif_ce3_tx_base[n]. Check to see if it expects ints or
shorts.
3. poll for an interrupt status [I suspect that it generates an
interrupt when finished] - this is probably one of your problems.
4. read from emif_ce3_rx_base[n].
Another step would be to replace the hardware functionality with a
software routine to be sure that you DSK sw is working correctly.
I like to start small, get something working as opposed to trying to
troubleshoot a complex system with multiple unknowns [crawl, walk,
jog, run].
>
> RE:
> NOTE: Daughtercard addresses in some header file
> 6416DSK CE2 base address = 0x68000000 <<-------------------wrong s/be
> 0xA0000000
> 6416DSK CE3 base address = 0x6C000000 <<-------------------wrong s/be
> 0xB0000000
> The above are incorrect. For some reason my memory failed me and I
> remembered [incorrectly] that the daughtercard was on EMIF B. Itis on
> EMIF A at the same addresses as the 6713.
> 6713DSK CE2 base address = 0xA0000000
> 6713DSK CE3 base address = 0xB0000000
> I see from the help manual that these CE's are the chip enablers for
> particular type of memory, and I have to tell you that I am using IRAM type
> and not SDRAM. I do not fully understan what is happening here either.
If all of your code fits into internal RAM that it great - it is one
less thing to worry about.
mikedunn
>
> Eagerly wsiting (and meanwhile trying out)
> Nik
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On Tue, Aug 5, 2008 at 11:03 AM, Nikolay Melnikov
wrote:
> Nik,
>
> Please retain the original text. I do some multi-tasking and I have a
> very small stack and sometimes I cannot remember what I said last
> time.
> :-)
>
> Sorry for not referring to the original text.
> I don't know what is up. I went there -
> ftp://ftp.altera.com/outgoing/devkit/CycloneII_DSP-v1.0.1_CD.zip
> and didn't find any *6455* files or directories. The only thing under
> 'altera/kits/' was 'CycloneII_DSP_Kit-v1.0.1'.
>
> Again, my fault, but I have given you the wrong directory, since this is how
> I renamed it on my laptop. And you have gone exactly to the location that I
> meant.
> I am confised concerning this daughtercard(these two 80-pin ports as I
> understand), namely - is it the EMIF that takes care for the data
> transmission from the TI to Altera? Or is it EDMA? Sorry if it might seem
> too newbie for a question. It seems that both are resposible and has their
> own tasks to do in the whole process.
EMIF= External Memory InterFace = memory bus - add, data, control
EDMA = Enhanced DMA = the DMA mechanism to xfer data via the EMIF
TI I/O is memory mapped I/O
>
> Under
> 'C:\altera\kits\CycloneII_DSP_Kit-v1.0.1\Examples\HW\ReferenceDesigns\emif_ref_design_FFT\TI6416'
> I used
> 'grep -ni 0x[ab]00..... *.[ch]' and found the following:
> edma.c:122: EDMA_SRC_OF(0xb0000080), // src
> address
> edma.c:161: EDMA_DST_OF(0xB0000000), // dest
> address
> edma.c:246: tx_credit_inc(0xB0000000);
> edma.c:283: tx_credit_inc(0xb0000000);
> fft_ping_pong.c:52:// actual emif is at 0xb0000000
> fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
> fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
> fft_ping_pong.c:134: reset_hw(0xB0000000);
> fft_ping_pong.c:136: reset_hw(0xA0000000);
> fft_ping_pong.c:146: tx_credit_inc(0xA0000000);
> fft_ping_pong.c:154: tx_credit_inc(0xB0000000);
>
> FYI - ping and pong are used to reference the double buffers in many
> TI double buffer designs.
>
> Some of the 'artifact files' [and 2004/2005 dates] indicate that the
> included examples were built under CCS 2.x.
>
> So, is this the line that "turns the transmission on" so to say? I mean that
> address in the brackets
> edma.c:246: tx_credit_inc(0xB0000000);
> If so, then what is the line that would be doing something about receiving?
BTW, your mail reader has put my reply and your reply at the same
'level' of '>'.
These 2 lines
fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
probably are the base address of 2 dual port memories in the FPGA -
one for wr[tx] and 1 for rd[rx].
I don't know if they are split for real/complex numbers. that would be
in the FPGA VHDL/HDL code.
>
> Check your project for 'csl6416.lib' - you will have to replace it
> with 6713 version. You will probably have to search for it. The
> project has a preprocessor def [-d"CHIP_6416"] that needs to be
> changed to 6713. The 'processor build type' will also have to be
> changed.
>
> I assume that the problem is that 'the project will not build' - once
> you do this stuff, let us know where you are.
>
> Yes, IO have changed the processor build type, and the preprocessor. The
> thing with preprocessor is that there is no CHIP_6713 predefined in the
> csl.h or some other csl_*.h file, but there is a CHIP_6711, so I have tried
> with this one and it worked fine(at least i think that it did). It did build
> and I loaded it onto the board.
I suspect that the CSL that you have is a bit old - pre-6713.
You really need 6713 support - it has a slightly different
initialization that 6711.
Do you know what version of DSP/BIOS that you have??
> After running it though, it does not run all the way. It stops(not in a gets
> frozen way, or some other, so to say "bad" way ) at a certain point. What
> happens is that there is a counter that (I think) is supposed to be
> incremented up to a certain value with every package/packet that is being
> transmitted(or rather sent to some port), but this is exactly the problem,
> it seems that this EMIF port is not being accessed by the data, and the
> counter is not incremented, and I cannot figure out what to do here.
You can monitor access to the Altera board by checking CE3 and ARE
[reads] and AWE [writes].
>
> The code that you have downloaded is exactly the one I am using, and here is
> the output I am getting:
>
> FFT core test program
>
> CLOCK_DIVIDE: 37
> Starting signal generation
> Done signal generation
> Testing with 1024 word blocks
> Writing to LEDs
> Increment Tx credit
>
> But the increment is not taking place. I have tried adding this value of
> rxcount that is supposed to be incremented into the watch window and doing
> step by step procedure, but it keeps staying 0...
>
You are working with a lot of unknowns.
If you can figure out how the FPGA is supposed to work [at a block
diagram level], I would suggest the following:
1. Put the original project aside [use it for some reference.
2. write a simple program that stuffs some values [they need to be
valid] to emif_ce3_tx_base[n]. Check to see if it expects ints or
shorts.
3. poll for an interrupt status [I suspect that it generates an
interrupt when finished] - this is probably one of your problems.
4. read from emif_ce3_rx_base[n].
Another step would be to replace the hardware functionality with a
software routine to be sure that you DSK sw is working correctly.
I like to start small, get something working as opposed to trying to
troubleshoot a complex system with multiple unknowns [crawl, walk,
jog, run].
>
> RE:
> NOTE: Daughtercard addresses in some header file
> 6416DSK CE2 base address = 0x68000000 <<-------------------wrong s/be
> 0xA0000000
> 6416DSK CE3 base address = 0x6C000000 <<-------------------wrong s/be
> 0xB0000000
> The above are incorrect. For some reason my memory failed me and I
> remembered [incorrectly] that the daughtercard was on EMIF B. Itis on
> EMIF A at the same addresses as the 6713.
> 6713DSK CE2 base address = 0xA0000000
> 6713DSK CE3 base address = 0xB0000000
> I see from the help manual that these CE's are the chip enablers for
> particular type of memory, and I have to tell you that I am using IRAM type
> and not SDRAM. I do not fully understan what is happening here either.
If all of your code fits into internal RAM that it great - it is one
less thing to worry about.
mikedunn
>
> Eagerly wsiting (and meanwhile trying out)
> Nik
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●August 5, 20082008-08-05
> TI I/O is memory mapped I/O
> >
> > Under
> >
> 'C:\altera\kits\CycloneII_DSP_Kit-v1.0.1\Examples\HW\ReferenceDesigns\emif_ref_design_FFT\TI6416'
> > I used
> > 'grep -ni 0x[ab]00..... *.[ch]' and found the following:
> > edma.c:122: EDMA_SRC_OF(0xb0000080), // src
> > address
> > edma.c:161: EDMA_DST_OF(0xB0000000), // dest
> > address
> > edma.c:246: tx_credit_inc(0xB0000000);
> > edma.c:283: tx_credit_inc(0xb0000000);
> > fft_ping_pong.c:52:// actual emif is at 0xb0000000
> > fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
> > fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
> > fft_ping_pong.c:134: reset_hw(0xB0000000);
> > fft_ping_pong.c:136: reset_hw(0xA0000000);
> > fft_ping_pong.c:146: tx_credit_inc(0xA0000000);
> > fft_ping_pong.c:154: tx_credit_inc(0xB0000000);
> >
> > FYI - ping and pong are used to reference the double buffers in many
> > TI double buffer designs.
> >
> > Some of the 'artifact files' [and 2004/2005 dates] indicate that the
> > included examples were built under CCS 2.x.
> >
> > So, is this the line that "turns the transmission on" so to say? I mean
> that
> > address in the brackets
> > edma.c:246: tx_credit_inc(0xB0000000);
> > If so, then what is the line that would be doing something about
> receiving?
>
>
> BTW, your mail reader has put my reply and your reply at the same
> 'level' of '>'.
> These 2 lines
> fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
> fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
> probably are the base address of 2 dual port memories in the FPGA -
> one for wr[tx] and 1 for rd[rx].
> I don't know if they are split for real/complex numbers. that would be
> in the FPGA VHDL/HDL code.
getting a bit frustrated with all the unknown to me information...
>
> >
> > Check your project for 'csl6416.lib' - you will have to replace it
> > with 6713 version. You will probably have to search for it. The
> > project has a preprocessor def [-d"CHIP_6416"] that needs to be
> > changed to 6713. The 'processor build type' will also have to be
> > changed.
> >
> > I assume that the problem is that 'the project will not build' - once
> > you do this stuff, let us know where you are.
> >
> > Yes, IO have changed the processor build type, and the preprocessor. The
> > thing with preprocessor is that there is no CHIP_6713 predefined in the
> > csl.h or some other csl_*.h file, but there is a CHIP_6711, so I have
> tried
> > with this one and it worked fine(at least i think that it did). It did
> build
> > and I loaded it onto the board.
>
> I suspect that the CSL that you have is a bit old - pre-6713.
> You really need 6713 support - it has a slightly different
> initialization that 6711.
> Do you know what version of DSP/BIOS that you have??
I have figured out this problem, and it is okay now. I was misinterpreting
something concerned with the files and the pre-processor command. It is okay
now.
> > After running it though, it does not run all the way. It stops(not in a
> gets
> > frozen way, or some other, so to say "bad" way ) at a certain point. What
> > happens is that there is a counter that (I think) is supposed to be
> > incremented up to a certain value with every package/packet that is being
> > transmitted(or rather sent to some port), but this is exactly the
> problem,
> > it seems that this EMIF port is not being accessed by the data, and the
> > counter is not incremented, and I cannot figure out what to do here.
>
>
> You can monitor access to the Altera board by checking CE3 and ARE
> [reads] and AWE [writes].
This is again something that I do not know fully understand from what I have
read in the help manual of CCS.
>
> >
> > The code that you have downloaded is exactly the one I am using, and here
> is
> > the output I am getting:
> >
> > FFT core test program
> >
> > CLOCK_DIVIDE: 37
> > Starting signal generation
> > Done signal generation
> > Testing with 1024 word blocks
> > Writing to LEDs
> > Increment Tx credit
> >
> > But the increment is not taking place. I have tried adding this value of
> > rxcount that is supposed to be incremented into the watch window and
> doing
> > step by step procedure, but it keeps staying 0...
> >
> You are working with a lot of unknowns.
> If you can figure out how the FPGA is supposed to work [at a block
> diagram level], I would suggest the following:
>
> 1. Put the original project aside [use it for some reference.
> 2. write a simple program that stuffs some values [they need to be
> valid] to emif_ce3_tx_base[n]. Check to see if it expects ints or
> shorts.
> 3. poll for an interrupt status [I suspect that it generates an
> interrupt when finished] - this is probably one of your problems.
> 4. read from emif_ce3_rx_base[n].
>
> Another step would be to replace the hardware functionality with a
> software routine to be sure that you DSK sw is working correctly.
>
> I like to start small, get something working as opposed to trying to
> troubleshoot a complex system with multiple unknowns [crawl, walk,
> jog, run].
I agree that as a whole, this is too complicated. And starting from
something small is good, except that I do not have enough knowledge of how
to do these 4 steps that you listed, and I was trying to find something on
Google for "c6713 EMIF" program/sample code or a tutorial or an explanation
but wasnt able to.
Do you by any chance have anything similar or know where I can look at?
> >
> > RE:
> > NOTE: Daughtercard addresses in some header file
> > 6416DSK CE2 base address = 0x68000000 <<-------------------wrong s/be
> > 0xA0000000
> > 6416DSK CE3 base address = 0x6C000000 <<-------------------wrong s/be
> > 0xB0000000
> > The above are incorrect. For some reason my memory failed me and I
> > remembered [incorrectly] that the daughtercard was on EMIF B. Itis on
> > EMIF A at the same addresses as the 6713.
> >
> >
> > 6713DSK CE2 base address = 0xA0000000
> > 6713DSK CE3 base address = 0xB0000000
> > I see from the help manual that these CE's are the chip enablers for
> > particular type of memory, and I have to tell you that I am using IRAM
> type
> > and not SDRAM. I do not fully understan what is happening here either.
>
>
> If all of your code fits into internal RAM that it great - it is one
> less thing to worry about.
>
> mikedunn
> >
> > Eagerly wsiting (and meanwhile trying out)
> > Nik
>
Thanks for keeping supporting me.
Very much appreciate it.
Nik
Nikolay Melnikov
School of Engineering and Science
Jacobs University Bremen
> >
> > Under
> >
> 'C:\altera\kits\CycloneII_DSP_Kit-v1.0.1\Examples\HW\ReferenceDesigns\emif_ref_design_FFT\TI6416'
> > I used
> > 'grep -ni 0x[ab]00..... *.[ch]' and found the following:
> > edma.c:122: EDMA_SRC_OF(0xb0000080), // src
> > address
> > edma.c:161: EDMA_DST_OF(0xB0000000), // dest
> > address
> > edma.c:246: tx_credit_inc(0xB0000000);
> > edma.c:283: tx_credit_inc(0xb0000000);
> > fft_ping_pong.c:52:// actual emif is at 0xb0000000
> > fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
> > fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
> > fft_ping_pong.c:134: reset_hw(0xB0000000);
> > fft_ping_pong.c:136: reset_hw(0xA0000000);
> > fft_ping_pong.c:146: tx_credit_inc(0xA0000000);
> > fft_ping_pong.c:154: tx_credit_inc(0xB0000000);
> >
> > FYI - ping and pong are used to reference the double buffers in many
> > TI double buffer designs.
> >
> > Some of the 'artifact files' [and 2004/2005 dates] indicate that the
> > included examples were built under CCS 2.x.
> >
> > So, is this the line that "turns the transmission on" so to say? I mean
> that
> > address in the brackets
> > edma.c:246: tx_credit_inc(0xB0000000);
> > If so, then what is the line that would be doing something about
> receiving?
>
>
> BTW, your mail reader has put my reply and your reply at the same
> 'level' of '>'.
> These 2 lines
> fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
> fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
> probably are the base address of 2 dual port memories in the FPGA -
> one for wr[tx] and 1 for rd[rx].
> I don't know if they are split for real/complex numbers. that would be
> in the FPGA VHDL/HDL code.
getting a bit frustrated with all the unknown to me information...
>
> >
> > Check your project for 'csl6416.lib' - you will have to replace it
> > with 6713 version. You will probably have to search for it. The
> > project has a preprocessor def [-d"CHIP_6416"] that needs to be
> > changed to 6713. The 'processor build type' will also have to be
> > changed.
> >
> > I assume that the problem is that 'the project will not build' - once
> > you do this stuff, let us know where you are.
> >
> > Yes, IO have changed the processor build type, and the preprocessor. The
> > thing with preprocessor is that there is no CHIP_6713 predefined in the
> > csl.h or some other csl_*.h file, but there is a CHIP_6711, so I have
> tried
> > with this one and it worked fine(at least i think that it did). It did
> build
> > and I loaded it onto the board.
>
> I suspect that the CSL that you have is a bit old - pre-6713.
> You really need 6713 support - it has a slightly different
> initialization that 6711.
> Do you know what version of DSP/BIOS that you have??
I have figured out this problem, and it is okay now. I was misinterpreting
something concerned with the files and the pre-processor command. It is okay
now.
> > After running it though, it does not run all the way. It stops(not in a
> gets
> > frozen way, or some other, so to say "bad" way ) at a certain point. What
> > happens is that there is a counter that (I think) is supposed to be
> > incremented up to a certain value with every package/packet that is being
> > transmitted(or rather sent to some port), but this is exactly the
> problem,
> > it seems that this EMIF port is not being accessed by the data, and the
> > counter is not incremented, and I cannot figure out what to do here.
>
>
> You can monitor access to the Altera board by checking CE3 and ARE
> [reads] and AWE [writes].
This is again something that I do not know fully understand from what I have
read in the help manual of CCS.
>
> >
> > The code that you have downloaded is exactly the one I am using, and here
> is
> > the output I am getting:
> >
> > FFT core test program
> >
> > CLOCK_DIVIDE: 37
> > Starting signal generation
> > Done signal generation
> > Testing with 1024 word blocks
> > Writing to LEDs
> > Increment Tx credit
> >
> > But the increment is not taking place. I have tried adding this value of
> > rxcount that is supposed to be incremented into the watch window and
> doing
> > step by step procedure, but it keeps staying 0...
> >
> You are working with a lot of unknowns.
> If you can figure out how the FPGA is supposed to work [at a block
> diagram level], I would suggest the following:
>
> 1. Put the original project aside [use it for some reference.
> 2. write a simple program that stuffs some values [they need to be
> valid] to emif_ce3_tx_base[n]. Check to see if it expects ints or
> shorts.
> 3. poll for an interrupt status [I suspect that it generates an
> interrupt when finished] - this is probably one of your problems.
> 4. read from emif_ce3_rx_base[n].
>
> Another step would be to replace the hardware functionality with a
> software routine to be sure that you DSK sw is working correctly.
>
> I like to start small, get something working as opposed to trying to
> troubleshoot a complex system with multiple unknowns [crawl, walk,
> jog, run].
I agree that as a whole, this is too complicated. And starting from
something small is good, except that I do not have enough knowledge of how
to do these 4 steps that you listed, and I was trying to find something on
Google for "c6713 EMIF" program/sample code or a tutorial or an explanation
but wasnt able to.
Do you by any chance have anything similar or know where I can look at?
> >
> > RE:
> > NOTE: Daughtercard addresses in some header file
> > 6416DSK CE2 base address = 0x68000000 <<-------------------wrong s/be
> > 0xA0000000
> > 6416DSK CE3 base address = 0x6C000000 <<-------------------wrong s/be
> > 0xB0000000
> > The above are incorrect. For some reason my memory failed me and I
> > remembered [incorrectly] that the daughtercard was on EMIF B. Itis on
> > EMIF A at the same addresses as the 6713.
> >
> >
> > 6713DSK CE2 base address = 0xA0000000
> > 6713DSK CE3 base address = 0xB0000000
> > I see from the help manual that these CE's are the chip enablers for
> > particular type of memory, and I have to tell you that I am using IRAM
> type
> > and not SDRAM. I do not fully understan what is happening here either.
>
>
> If all of your code fits into internal RAM that it great - it is one
> less thing to worry about.
>
> mikedunn
> >
> > Eagerly wsiting (and meanwhile trying out)
> > Nik
>
Thanks for keeping supporting me.
Very much appreciate it.
Nik
Nikolay Melnikov
School of Engineering and Science
Jacobs University Bremen
Reply by ●August 6, 20082008-08-06
Nik,
On Tue, Aug 5, 2008 at 3:47 PM, Nikolay Melnikov
wrote:
>
>> TI I/O is memory mapped I/O
>> >
>> > Under
>> >
>> > 'C:\altera\kits\CycloneII_DSP_Kit-v1.0.1\Examples\HW\ReferenceDesigns\emif_ref_design_FFT\TI6416'
>> > I used
>> > 'grep -ni 0x[ab]00..... *.[ch]' and found the following:
>> > edma.c:122: EDMA_SRC_OF(0xb0000080), // src
>> > address
>> > edma.c:161: EDMA_DST_OF(0xB0000000), // dest
>> > address
>> > edma.c:246: tx_credit_inc(0xB0000000);
>> > edma.c:283: tx_credit_inc(0xb0000000);
>> > fft_ping_pong.c:52:// actual emif is at 0xb0000000
>> > fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
>> > fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
>> > fft_ping_pong.c:134: reset_hw(0xB0000000);
>> > fft_ping_pong.c:136: reset_hw(0xA0000000);
>> > fft_ping_pong.c:146: tx_credit_inc(0xA0000000);
>> > fft_ping_pong.c:154: tx_credit_inc(0xB0000000);
>> >
>> > FYI - ping and pong are used to reference the double buffers in many
>> > TI double buffer designs.
>> >
>> > Some of the 'artifact files' [and 2004/2005 dates] indicate that the
>> > included examples were built under CCS 2.x.
>> >
>> > So, is this the line that "turns the transmission on" so to say? I mean
>> > that
>> > address in the brackets
>> > edma.c:246: tx_credit_inc(0xB0000000);
>> > If so, then what is the line that would be doing something about
>> > receiving?
>>
>>
>> BTW, your mail reader has put my reply and your reply at the same
>> 'level' of '>'.
>> These 2 lines
>> fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
>> fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
>> probably are the base address of 2 dual port memories in the FPGA -
>> one for wr[tx] and 1 for rd[rx].
>> I don't know if they are split for real/complex numbers. that would be
>> in the FPGA VHDL/HDL code.
>
> getting a bit frustrated with all the unknown to me information...
>
>>
>> >
>> > Check your project for 'csl6416.lib' - you will have to replace it
>> > with 6713 version. You will probably have to search for it. The
>> > project has a preprocessor def [-d"CHIP_6416"] that needs to be
>> > changed to 6713. The 'processor build type' will also have to be
>> > changed.
>> >
>> > I assume that the problem is that 'the project will not build' - once
>> > you do this stuff, let us know where you are.
>> >
>> > Yes, IO have changed the processor build type, and the preprocessor. The
>> > thing with preprocessor is that there is no CHIP_6713 predefined in the
>> > csl.h or some other csl_*.h file, but there is a CHIP_6711, so I have
>> > tried
>> > with this one and it worked fine(at least i think that it did). It did
>> > build
>> > and I loaded it onto the board.
>>
>> I suspect that the CSL that you have is a bit old - pre-6713.
>> You really need 6713 support - it has a slightly different
>> initialization that 6711.
>> Do you know what version of DSP/BIOS that you have??
>
> I have figured out this problem, and it is okay now. I was misinterpreting
> something concerned with the files and the pre-processor command. It is okay
> now.
>> > After running it though, it does not run all the way. It stops(not in a
>> > gets
>> > frozen way, or some other, so to say "bad" way ) at a certain point.
>> > What
>> > happens is that there is a counter that (I think) is supposed to be
>> > incremented up to a certain value with every package/packet that is
>> > being
>> > transmitted(or rather sent to some port), but this is exactly the
>> > problem,
>> > it seems that this EMIF port is not being accessed by the data, and the
>> > counter is not incremented, and I cannot figure out what to do here.
>>
>>
>> You can monitor access to the Altera board by checking CE3 and ARE
>> [reads] and AWE [writes].
>
> This is again something that I do not know fully understand from what I have
> read in the help manual of CCS.
You can use CCS memory->view to access the 0xB000xxxx addresses [check
your GEL file to make sure that the addresses are included in the
memory map if it is enabled].
For a beginning sample program, all you need to do is think about C.
There is nothing special about CCS, DSP, or any 'TI stuff' that you
need to know.
1. To start with, write some 'canned data' [an initialized array would
be easy] to 'myWrAdd' + offset [for test, myWrAdd= 0x00020000 in
internal memory an offset increments from 0 to 0x1f]. The read from
'myRdAdd' + offset [fro test myRdAdd = 0x00020000 with increment].
2. Once this works, redefine myWrAdd to 0xB0000000 and myRdAdd to
0xB0000080 and you will be ready to access the hw.
3. The catch here is that you will need to put meaningful data into
your preinitialized array. You will also need to figure out if the HW
is expecting ints or shorts.
mikedunn
>>
>> >
>> > The code that you have downloaded is exactly the one I am using, and
>> > here is
>> > the output I am getting:
>> >
>> > FFT core test program
>> >
>> > CLOCK_DIVIDE: 37
>> > Starting signal generation
>> > Done signal generation
>> > Testing with 1024 word blocks
>> > Writing to LEDs
>> > Increment Tx credit
>> >
>> > But the increment is not taking place. I have tried adding this value of
>> > rxcount that is supposed to be incremented into the watch window and
>> > doing
>> > step by step procedure, but it keeps staying 0...
>> >
>> You are working with a lot of unknowns.
>> If you can figure out how the FPGA is supposed to work [at a block
>> diagram level], I would suggest the following:
>>
>> 1. Put the original project aside [use it for some reference.
>> 2. write a simple program that stuffs some values [they need to be
>> valid] to emif_ce3_tx_base[n]. Check to see if it expects ints or
>> shorts.
>> 3. poll for an interrupt status [I suspect that it generates an
>> interrupt when finished] - this is probably one of your problems.
>> 4. read from emif_ce3_rx_base[n].
>>
>> Another step would be to replace the hardware functionality with a
>> software routine to be sure that you DSK sw is working correctly.
>>
>> I like to start small, get something working as opposed to trying to
>> troubleshoot a complex system with multiple unknowns [crawl, walk,
>> jog, run].
>
> I agree that as a whole, this is too complicated. And starting from
> something small is good, except that I do not have enough knowledge of how
> to do these 4 steps that you listed, and I was trying to find something on
> Google for "c6713 EMIF" program/sample code or a tutorial or an explanation
> but wasnt able to.
>
> Do you by any chance have anything similar or know where I can look at?
>> >
>> > RE:
>> > NOTE: Daughtercard addresses in some header file
>> > 6416DSK CE2 base address = 0x68000000 <<-------------------wrong s/be
>> > 0xA0000000
>> > 6416DSK CE3 base address = 0x6C000000 <<-------------------wrong s/be
>> > 0xB0000000
>> > The above are incorrect. For some reason my memory failed me and I
>> > remembered [incorrectly] that the daughtercard was on EMIF B. Itis on
>> > EMIF A at the same addresses as the 6713.
>> >
>> >
>> > 6713DSK CE2 base address = 0xA0000000
>> > 6713DSK CE3 base address = 0xB0000000
>> > I see from the help manual that these CE's are the chip enablers for
>> > particular type of memory, and I have to tell you that I am using IRAM
>> > type
>> > and not SDRAM. I do not fully understan what is happening here either.
>>
>>
>> If all of your code fits into internal RAM that it great - it is one
>> less thing to worry about.
>>
>> mikedunn
>> >
>> > Eagerly wsiting (and meanwhile trying out)
>> > Nik
>> > Thanks for keeping supporting me.
> Very much appreciate it.
> Nik
> Nikolay Melnikov
> School of Engineering and Science
> Jacobs University Bremen
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On Tue, Aug 5, 2008 at 3:47 PM, Nikolay Melnikov
wrote:
>
>> TI I/O is memory mapped I/O
>> >
>> > Under
>> >
>> > 'C:\altera\kits\CycloneII_DSP_Kit-v1.0.1\Examples\HW\ReferenceDesigns\emif_ref_design_FFT\TI6416'
>> > I used
>> > 'grep -ni 0x[ab]00..... *.[ch]' and found the following:
>> > edma.c:122: EDMA_SRC_OF(0xb0000080), // src
>> > address
>> > edma.c:161: EDMA_DST_OF(0xB0000000), // dest
>> > address
>> > edma.c:246: tx_credit_inc(0xB0000000);
>> > edma.c:283: tx_credit_inc(0xb0000000);
>> > fft_ping_pong.c:52:// actual emif is at 0xb0000000
>> > fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
>> > fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
>> > fft_ping_pong.c:134: reset_hw(0xB0000000);
>> > fft_ping_pong.c:136: reset_hw(0xA0000000);
>> > fft_ping_pong.c:146: tx_credit_inc(0xA0000000);
>> > fft_ping_pong.c:154: tx_credit_inc(0xB0000000);
>> >
>> > FYI - ping and pong are used to reference the double buffers in many
>> > TI double buffer designs.
>> >
>> > Some of the 'artifact files' [and 2004/2005 dates] indicate that the
>> > included examples were built under CCS 2.x.
>> >
>> > So, is this the line that "turns the transmission on" so to say? I mean
>> > that
>> > address in the brackets
>> > edma.c:246: tx_credit_inc(0xB0000000);
>> > If so, then what is the line that would be doing something about
>> > receiving?
>>
>>
>> BTW, your mail reader has put my reply and your reply at the same
>> 'level' of '>'.
>> These 2 lines
>> fft_ping_pong.c:58:const unsigned int emif_ce3_tx_base = 0xb0000000;
>> fft_ping_pong.c:59:const unsigned int emif_ce3_rx_base = 0xb0000080;
>> probably are the base address of 2 dual port memories in the FPGA -
>> one for wr[tx] and 1 for rd[rx].
>> I don't know if they are split for real/complex numbers. that would be
>> in the FPGA VHDL/HDL code.
>
> getting a bit frustrated with all the unknown to me information...
>
>>
>> >
>> > Check your project for 'csl6416.lib' - you will have to replace it
>> > with 6713 version. You will probably have to search for it. The
>> > project has a preprocessor def [-d"CHIP_6416"] that needs to be
>> > changed to 6713. The 'processor build type' will also have to be
>> > changed.
>> >
>> > I assume that the problem is that 'the project will not build' - once
>> > you do this stuff, let us know where you are.
>> >
>> > Yes, IO have changed the processor build type, and the preprocessor. The
>> > thing with preprocessor is that there is no CHIP_6713 predefined in the
>> > csl.h or some other csl_*.h file, but there is a CHIP_6711, so I have
>> > tried
>> > with this one and it worked fine(at least i think that it did). It did
>> > build
>> > and I loaded it onto the board.
>>
>> I suspect that the CSL that you have is a bit old - pre-6713.
>> You really need 6713 support - it has a slightly different
>> initialization that 6711.
>> Do you know what version of DSP/BIOS that you have??
>
> I have figured out this problem, and it is okay now. I was misinterpreting
> something concerned with the files and the pre-processor command. It is okay
> now.
>> > After running it though, it does not run all the way. It stops(not in a
>> > gets
>> > frozen way, or some other, so to say "bad" way ) at a certain point.
>> > What
>> > happens is that there is a counter that (I think) is supposed to be
>> > incremented up to a certain value with every package/packet that is
>> > being
>> > transmitted(or rather sent to some port), but this is exactly the
>> > problem,
>> > it seems that this EMIF port is not being accessed by the data, and the
>> > counter is not incremented, and I cannot figure out what to do here.
>>
>>
>> You can monitor access to the Altera board by checking CE3 and ARE
>> [reads] and AWE [writes].
>
> This is again something that I do not know fully understand from what I have
> read in the help manual of CCS.
You can use CCS memory->view to access the 0xB000xxxx addresses [check
your GEL file to make sure that the addresses are included in the
memory map if it is enabled].
For a beginning sample program, all you need to do is think about C.
There is nothing special about CCS, DSP, or any 'TI stuff' that you
need to know.
1. To start with, write some 'canned data' [an initialized array would
be easy] to 'myWrAdd' + offset [for test, myWrAdd= 0x00020000 in
internal memory an offset increments from 0 to 0x1f]. The read from
'myRdAdd' + offset [fro test myRdAdd = 0x00020000 with increment].
2. Once this works, redefine myWrAdd to 0xB0000000 and myRdAdd to
0xB0000080 and you will be ready to access the hw.
3. The catch here is that you will need to put meaningful data into
your preinitialized array. You will also need to figure out if the HW
is expecting ints or shorts.
mikedunn
>>
>> >
>> > The code that you have downloaded is exactly the one I am using, and
>> > here is
>> > the output I am getting:
>> >
>> > FFT core test program
>> >
>> > CLOCK_DIVIDE: 37
>> > Starting signal generation
>> > Done signal generation
>> > Testing with 1024 word blocks
>> > Writing to LEDs
>> > Increment Tx credit
>> >
>> > But the increment is not taking place. I have tried adding this value of
>> > rxcount that is supposed to be incremented into the watch window and
>> > doing
>> > step by step procedure, but it keeps staying 0...
>> >
>> You are working with a lot of unknowns.
>> If you can figure out how the FPGA is supposed to work [at a block
>> diagram level], I would suggest the following:
>>
>> 1. Put the original project aside [use it for some reference.
>> 2. write a simple program that stuffs some values [they need to be
>> valid] to emif_ce3_tx_base[n]. Check to see if it expects ints or
>> shorts.
>> 3. poll for an interrupt status [I suspect that it generates an
>> interrupt when finished] - this is probably one of your problems.
>> 4. read from emif_ce3_rx_base[n].
>>
>> Another step would be to replace the hardware functionality with a
>> software routine to be sure that you DSK sw is working correctly.
>>
>> I like to start small, get something working as opposed to trying to
>> troubleshoot a complex system with multiple unknowns [crawl, walk,
>> jog, run].
>
> I agree that as a whole, this is too complicated. And starting from
> something small is good, except that I do not have enough knowledge of how
> to do these 4 steps that you listed, and I was trying to find something on
> Google for "c6713 EMIF" program/sample code or a tutorial or an explanation
> but wasnt able to.
>
> Do you by any chance have anything similar or know where I can look at?
>> >
>> > RE:
>> > NOTE: Daughtercard addresses in some header file
>> > 6416DSK CE2 base address = 0x68000000 <<-------------------wrong s/be
>> > 0xA0000000
>> > 6416DSK CE3 base address = 0x6C000000 <<-------------------wrong s/be
>> > 0xB0000000
>> > The above are incorrect. For some reason my memory failed me and I
>> > remembered [incorrectly] that the daughtercard was on EMIF B. Itis on
>> > EMIF A at the same addresses as the 6713.
>> >
>> >
>> > 6713DSK CE2 base address = 0xA0000000
>> > 6713DSK CE3 base address = 0xB0000000
>> > I see from the help manual that these CE's are the chip enablers for
>> > particular type of memory, and I have to tell you that I am using IRAM
>> > type
>> > and not SDRAM. I do not fully understan what is happening here either.
>>
>>
>> If all of your code fits into internal RAM that it great - it is one
>> less thing to worry about.
>>
>> mikedunn
>> >
>> > Eagerly wsiting (and meanwhile trying out)
>> > Nik
>> > Thanks for keeping supporting me.
> Very much appreciate it.
> Nik
> Nikolay Melnikov
> School of Engineering and Science
> Jacobs University Bremen
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●August 8, 20082008-08-08
Hi,
Does anybody already had problem with NMI interrupt.
We've got a signal connected to NMI on C6713 and linked an interrupt that does nothing except a B NRP with 5 nop after.
But we've got problems, sometimes (application gets corrupted and finally the watchdog reset) and I suspect it is linked to the NMI interrupt.
Did anybody experienced that?
Does anybody already had problem with NMI interrupt.
We've got a signal connected to NMI on C6713 and linked an interrupt that does nothing except a B NRP with 5 nop after.
But we've got problems, sometimes (application gets corrupted and finally the watchdog reset) and I suspect it is linked to the NMI interrupt.
Did anybody experienced that?
