DSPKOGNA.out Silicon Version -mv6740

[griffinboyle]

Hello,

I am currently using a Kogna to control my custom 3D printer, and for the past few months now have been compiling and linking my firmware external to the KMotion.exe application - mainly for scalability and portability of the source code, as well as for customizability of the build process, external libraries, optimizations, etc.

Thus far, when compiling my source code with the TI C6000 7.4.21 compiler, I have been using the -mv6710 compilation flag, just as is done in the KMotionDLL.cpp source code:

Code: Select all

cmd.Format(L" %ls -k -q -as --diag_suppress=163 --mem_model:data=far "
	"-i \"" + IncSrcPath1 + "\" -i \"" + IncSrcPath2 + "\" -i \"" + IncSrcPath3 + "\" -mu -ml3 -mv6710 -o%d", FileType, Opt);

I did think it was a bit odd that the silicon version used was -mv6710 despite the Kogna using a C6748 processor - but had no real reason to poke and prod this flag it since my firmware was compiling and running as expected already.

Recently, however, I've been developing a portable space-efficient messaging protocol to be used over RS485 which uses packed structs to remove excess padding from the message structure and reduce packet size, but began encountering build errors as a result. According to the TMS320C6000 Optimizing Compiler v 7.4 User's Guide:

Section 6.15.3 Variable Attributes

The packed attribute for structure and union types is available only when there is hardware support for
unaligned accesses. For C6000 this means C6400+, C6400, C6740, and C6600.

2.13 Linking C6400 Code With C6200/C6700/Older C6400 Object Code

If you are linking C6400/C6400+/C6740/C6600 with C6200/C6700 code or older C6400 code, you may
need to take steps to ensure compatibility. The following lists the potential alignment conflicts and possible
solutions.
Potential alignment conflicts occur when:
• Linking new C6400/C6400+/C6740/C6600 code with any C6400 code already compiled with the 4.0
tools.
• Linking new C6400/C6400+/C6740/C6600 code with code already compiled with any version of the
tools for the C6200 or C6700 family.
Solutions (pick one):
• Recompile the entire application with the --silicon_version=6400 switch. This solution, if possible, is
recommended because it can lead to better performance.
• Compile the new code with the --target_compatibility_6200 option. When using this option, link with the
6200 RTS library to ensure proper compatibility. The --target_compatibility_6200 option changes the
alignment of top-level arrays to 4 bytes when the --silicon_version=6400 or --silicon_version=6400+
option is used.

As such, I began by changing my silicon version from -mv6710 to -mv6740 - this got rid of the Invalid attribute for "struct rs485_pkt_hdr_v1" compiler error, but resulted in a new error error: file "lib/KMotionSDK/KMotion5.3.3/DSP_KOGNA/user_boot.obj" aligns arrays to 4 bytes, but previous files expect arrays to be aligned to 8 bytes.

Following the recommendations from TI shown above, I added the --target_compatibility_6200 compiler flag, and my code compiled successfully! That being said, I have some uneducated/untested concerns/suspicions about the potential implications that this mixed-target compilation scheme may have on the performance and stability of the code once it's running on the Kogna. Do you have any ideas regarding how severe these implications would be, if present in the first place?

Lastly, if it isn't too much to ask and is even possible, I would really appreciate it if you could provide me with a version of the DSPKOGNA.out and user_boot.obj (and DSPKOGNA.sym if that would be necessary) files which have been compiled with the silicon version -mv6740 - or better yet a copy of the actual source code which I can compile myself (I assume this is not a possibility considering it is your proprietary firmware, but I figured I might as well ask) - so that I can build my firmware with code which has all been compiled for the same target, maximizing potential performance advances and removing any possibility of undefined behavior resulting from the mixed-target compilation.

Many thanks in advance,
Griffin Boyle

[TomKerekes]

Hi Griffin,

I think the main issue with specifying the 6740 silicon is it opens up Software pipelined loops. The SPLOOP instruction. Which is not interruptible. Kogna never disables interrupts to avoid other issues.

So I believe your solution of:

-mv6740
-target_compatibility_6200

Should be ok if you also include.
--disable_software_pipelining

Here is a lengthy ChatGTP I had regarding this.

Let us know if that works for you.

[griffinboyle]

Hi Tom,

Thanks for getting back to me! As you suggested I've added the --disable_software_pipeline compiler flag, thus far I haven't noticed any unexpected or erroneous behavior - do you have any ideas on what kind of issues I should be keeping an eye out for? Any way that I could "stress-test" it in some way to try to provoke an error?

Will keep you posted if anything comes up but at the moment it appears to be operational!

Thanks again,
Griffin Boyle

[TomKerekes]

Hi Griffin,

With those options I wouldn't expect any issues, but we might not be considering something.

In general with something not executing correctly, or some context not being preserved between time slices, the results would be indeterminate possibly causing a crash or error.

The only real way to test I know of is to run complicated code for a long period of time (days - millions of context switches) without any issues.