Porting Between C6713 and C6745

Audio Dave said:

1. Is there any memory map issues between the platforms

The memory map is not the same, Please look at each datasheet to compare:

http://www.ti.com/lit/gpn/tms320c6713b

http://www.ti.com/lit/gpn/tms320c6745

Audio Dave said:

2. Is the any peripheral issues face in the new platform

Well, they are different parts, so yes, you will need to adapt your peripheral code. Please see datasheet for more details.

Also, most of the software offered for C6713 was CSL based (chip support library). For C6745/7 the software is PSP based. Please see:

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/41165/143421.aspx#143421

Audio Dave said:

3. My code is floating point. Any type precision loss face in the new platform..

No precision loss, please see:

http://processors.wiki.ti.com/index.php/-mv_option_to_use_with_the_C674x

Dear Mariana

Thanks for your valid answer. Few of your reference links are useful to me. Others are already visited.

I will note few difference in the memory architecture of C6713 and C6745. My doubt is the source is portable from C6713 to C6745

The important difference noted are

1. In C6713 the external memory map is as follows

EMIF CE0 256M

EMIF CE1 256M

EMIF CE2 256M

EMIF CE3 256M

but in C6745

There is two EMIF memory ie: EMIFA and EMIFB

according to the data sheet the EMIFA have a 16 bit SDRAM with 128MB address Space (C6747)

and EMIFB have 32 bit or 16 bit SDRAM with 256 MB address space(C6747)

16 bit SDRAM with 256 MB address space(C6745)

So following are my questions

1. EMIFA is not present in C6745?

2. I can map CE0 to CE3 memory to the 16 bit SDRAM of 256MB address space ?

The second question is due to the following

The memory spliting of EMIFA is as follows

CS0 to CS5

then there is no spliting of EMIFB SDRAM Data .

my question is in this architecture what is the difficulties generated.

I thought the C6745 is the superset of C6713. So a backward compactibility is exists in the DSP's

One more question about the periperals

The necessary periperals in  C6713 is present in the C6745 so we can avoid the extra features ?

Thanks !

Dave

Audio Dave said:

1. EMIFA is not present in C6745?

EMIFA is present, but given the C6745's reduced pin-count PTP package the interface does not support SDRAM.

Audio Dave said:

2. I can map CE0 to CE3 memory to the 16 bit SDRAM of 256MB address space ?

The second question is due to the following

The memory spliting of EMIFA is as follows

CS0 to CS5

then there is no spliting of EMIFB SDRAM Data .

my question is in this architecture what is the difficulties generated.

Is this more of a hardware or software question?  For software, the memories are accessed through the memory map so you just need to change program locations through the .cmd or BIOS configuration files.

Audio Dave said:

I thought the C6745 is the superset of C6713. So a backward compactibility is exists in the DSP's

One more question about the periperals

The necessary periperals in  C6713 is present in the C6745 so we can avoid the extra features ?

The C674x family is a completely different chip architecture from C671x so there is no guarantee of memory map or peripheral compatibility.  The DSP core should be able to run the same instructions, but the devices are quite different.

Hi tlee,

Yes your question is correct.

i am porting a video viewer software from C6713 to C6745

I want to clarify CE0-CE3(512 MBytes) memory map is exactly working with EMIFB SDRAM?

How i drive the extra periperals in the C6745 platform.

where i get the periparal drivers for C6745 platform ?

Is it necessary a performence turn for the existing software to use the extra DSP feature ?

Regards

Dave 

Audio Dave said:

i am porting a video viewer software from C6713 to C6745

I want to clarify CE0-CE3(512 MBytes) memory map is exactly working with EMIFB SDRAM?

The short answer is no, it is not the same.  As Mariana pointed out, the memory map is different so the mapped SDRAM address range is different (C6713 is 0x80000000-0xBFFFFFFF, and C6745 is 0xC0000000-0xCFFFFFFF).  Additionally, the C6745 is offered in the lower pin-count PTP package so the SDRAM memory space is smaller (256MB on EMIFB).

Audio Dave said:

How i drive the extra periperals in the C6745 platform.

where i get the periparal drivers for C6745 platform ?

BIOS drivers are supplied for C674x devices: http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSPSP/index.html

Audio Dave said:

Is it necessary a performence turn for the existing software to use the extra DSP feature ?

I don't understand this question.

Thanks for your post

I have some doubts regarding the post .

I agree with the memory address range of EMIFB of C6745 and EMIF of C6713

The data sheets of C6745 told 16 bit SDRAM with 256 MB address space. So it means that 2 byte of 256 MB address space. So a total of 512 MB address space ?

My question, Is there any difference between 8 bit and 16 bit address ?

memory addressed as 0,1,2...2^8 - 1 or 2^16 - 1 as the upper range. So any difference imposed by this 8 bit or 16 Bit notation

Audio Dave said:

 

Is it necessary a performence turn for the existing software to use the extra DSP feature ?

By this question i want to clarify the following things

1. C6745 have 64 32 bit registers but C6713 have 32 32 bit registers

2. Additional power ful instruction for multiplication are available

3. Other DSP features like SPLOOP, Compact Instructions, Instruction set enhancement, Exception Handling, and  Privilege are available

will i give my C code in C6713 to the compiler of C6745 I get atleast the performence of C6713 or any type of code rework needed

In a video software usually the format conversion like RGB<-->YUV is time consuming so any types of rework necessary in the source ?

I want to know one more clarification.

1. How i create a memory section in memory and place my source code there.

Thanks

Dave

Audio Dave said:

I agree with the memory address range of EMIFB of C6745 and EMIF of C6713

The data sheets of C6745 told 16 bit SDRAM with 256 MB address space. So it means that 2 byte of 256 MB address space. So a total of 512 MB address space ?

The device architecture is byte-addressable so a 256MB address space means that it can only access 256MB.  Please see the "EMIFB Supported SDRAM Configurations" table in the datasheet for more details.

Audio Dave said:

My question, Is there any difference between 8 bit and 16 bit address ?

memory addressed as 0,1,2...2^8 - 1 or 2^16 - 1 as the upper range. So any difference imposed by this 8 bit or 16 Bit notation 

I'm not sure I understand this question.

Audio Dave said:

1. C6745 have 64 32 bit registers but C6713 have 32 32 bit registers

2. Additional power ful instruction for multiplication are available

3. Other DSP features like SPLOOP, Compact Instructions, Instruction set enhancement, Exception Handling, and  Privilege are available

If you are running ASM code, you will have to update the ASM to make use of the registers/instructions.  If you are programming in C, the compiler will take care of it.  Additional questions for this can be directed to the C/C++ Compiler Forum: http://e2e.ti.com/support/development_tools/compiler/f/343.aspx

Audio Dave said:

will i give my C code in C6713 to the compiler of C6745 I get atleast the performence of C6713 or any type of code rework needed

In a video software usually the format conversion like RGB<-->YUV is time consuming so any types of rework necessary in the source ?

The C674x core is ISA code-compatible with the C67x so you can port your code over without rework (unless there are references to physical addresses/features).  There may be performance differences that are attributed to deviations in device architecture.  For example, changes in data bus architecture.

Audio Dave said:

1. How i create a memory section in memory and place my source code there.

Search for "Command File" in http://www-s.ti.com/sc/techlit/SPRU187 for C, or http://www-s.ti.com/sc/techlit/SPRU303 for BIOS.  Additional questions for this topic can be directed to the C/C++ Compiler Forum (http://e2e.ti.com/support/development_tools/compiler/f/343.aspx), CCS Forum (http://e2e.ti.com/support/development_tools/code_composer_studio/f/81.aspx) or BIOS Forum (http://e2e.ti.com/support/embedded/f/355.aspx).

 Thanks for your replay.

So for a conclusion

C6713 have the following memory map.

EMIF CE0 256M 80000000 - 8FFFFFFF

EMIF CE1 256M 90000000 - 9FFFFFFF

EMIF CE2 256M A0000000 - AFFFFFFF

EMIF CE3 256M B0000000 - BFFFFFFF

for a total of 1G Memory

C6745 have following memory map

EMIFB     256M C0000000 - CFFFFFFF

So due to the size limitation the replacement is not feasible.

I again ask is it possible to replace C6713 by C6747?

Thanks,

Dave

Audio Dave said:

I again ask is it possible to replace C6713 by C6747?

I don't think that I am in a position to provide a simple yes/no answer to your roadmap question over the forum.  I recommend that you contact your local TI support office for a more thorough evaluation of your options.

Hi,

I used DMA/QDMA on C6713 before moving onto C6745. I tried same similar code with C6745 after going through SPRUFK4 and SPRU966b EDMA3 guide but it didnt work. Then I resorted to simple external data trnasfer code as follows;

#define   AD    *(volatile short *)  (0xC0000000)

#define   DA    *(volatile short *)  (0xC0000004)

main() {

int x = 0x5555; int y;

DA = x;  // works, data appears on bus and write strobe is generated

y = AD;  // Does Not Work! no signal present on Read Strobe.

}

The write to external memory works as it writes 0x5555 to the EMIFB port ad generates the write strobe. However the read command (x = AD) doesnt work as I cant see any singnal at EMB_RAS or EMB_CAS. I am using CCS4 and when I compile above code it says as a warning  'variable y was set but never used ' when compiled...

Any help is much appreciated. 

 Imran

Imran,

Do you have any compiler optimizations enabled?  I wonder if the compiler saw that variable "y" was not used before the end of the program so it just dropped the memory read.

-Tommy

Tommy,

Thanks for your prompt reply. I am using free version of CCS 4.0.1.01001, downloaded from TI website. I did not enable any complier optimization, so the complier has its default settings. Clicking 'build all' under project menue two or three times does however get rid of the warning 'variable 'y'  was set but never used'. But the read still doesnt work.

I start with a code with just DA = x;  (and without y = AD;) and the write works fine. When I add  y = AD; to the code, build and run, write stops working too along with the read(even after trying build all couple of time and getting rid of the warning).

Now if I take the read operation  y= AD; out of the code, build and run, the write operation doesnt work. To get the write to work again one has to reset the DSP, reload the GEL and rebuild and reload  reload the program ( without the read part y = AD; of course).

I am using GEL file for OMAPL137/C6747 DSK from Spectrum digital, however I am using my own custom hardware board with C6745. When I load GEL and before loading program i can see 35KHz read strobes that are produced by initialization of EMIFB in GEL.  If I disable EMIFB initialization in GEL then the write stops working too. It seeems as though that EMIFB engages read strobe in such a way that CPU cannot reset it. The GEL file is called 'evmomapl137_dsp.gel' and can be viewed at  http://support.spectrumdigital.com/boards/evmomapl137/revg/files/evmomapl137_dsp.gel

Any thoughts? 

(N.B. I have tried setting up EDMA3 regsiters and writing and reading using both DMA and QDMA method, but to no avail. Can send you the code in next post).

Imran

Imran,

Did you update the GEL file to operate with your C6745 memory instead of the EVM memory?  Note that the L137/C6747 devices have 32 EMIFB data lines, but the C6745 only has 16 EMIFB data lines.  The configuration settings will not be compatible.

-Tommy

^Tommy,

^{I changed the NM bit in  SDRAM configuration register SDCFG to 1 for 16 bit interface, however the problem with the read still persists. Whereas write operation is fine. I am wondering if it has something to do with memory protection. Simplified code is as follows:}

^{*(int *) 0x0184A200 = 0x0000FF3F;   // L2 Memory Protection Regsiter 0}

 ^{*(int *) 0xC0000000 = *(int *) 0x00800000;}    

^{0x0080000 is L2 start adress and 0xC0000000 is EMIFB Start adrdress    The write operation Wroks fine as stobes can be seen  on   EMB_CAS pin or EMB_WE_DQM  and EMB_WE pins '}

^{*(int *) 0x00800000 = *(int *) 0xC0000000;     // The read operation doesnt work at all; i.e. nothing at EMB_CAS pin or EMB_WE_DQM pins.}

^{Are the memory protection settings correct? could there be anything else killing the read command but allowing the write access?}

^Imran

Imran,

You should be able to access the EMIF and L2 memory space with the default protection settings.

Can you try to poke the 0xC0000000 memory space through the CCS memory view?  It would be good to make sure that your EMIF settings are correct before we dig into the C-code.

When poking at the memory addresses make sure the written data appears as expected and also perform multiple view refreshes to make sure the memory contents appear to be stable from the DSP perspective.  If the values are stuck or look like they are changing on their own, the EMIF settings will need to be modified.

-Tommy