How to build the *.l64 to pass QualiTI checking?

JuliannH,

which XDAIS version you are using ?

if you  are a codec developer better to be on your development platform using CCS in Windows side.

Hi Katie & sujit,

I'm playing the role of codec developer now, and will need to play the other roles later.
So far, there's no problem to generate the *.l64P (omap3530 c64x+ dsp) on CCSv3.3 as an
input of QualiTI per Katie's instructions. However, my current issue is the generated
*.l64P library violates the two XDAIS rules when check it by QualiTI:
  
   Rule 20: must declare worst-case stack requirements
   Rule 26: All static/global data must be far on c6x
  
This looks like a linker command file is needed. So I have a linker command file as follows,
but CCS will say:
  Error, Don't know how to build file
     "C:\Project_CCSv3.3\amr_c64x\codec\amr_lib_xdm\lnk64xp_ialg.cmd"

I've tried to build by two ways, both caused the same error message about *.cmd file:
(1) source files of IALG + codec library 
(2) source files of both IALG and codec

Need your help with this.

Juliann

***** lnk64xp_ialg.cmd *****
-c
-heap   0x2000
-stack  0x2000

/*-m spdec_64x.map*/      /* create a map file */
/*-l rts64plus.lib*/      /* Runtime-support library */

MEMORY
{   
    DDR2        : origin = 0x85000000,  length = 0x00200000  
}

SECTIONS
{
    .text       >    DDR2   /* IRAM_L2 executable code and constant */   
    .bss        >    DDR2   /* global and static variables */
    .stack      >    DDR2
    .cinit      >    DDR2   /* tables */
    .cio        >    DDR2
    .const      >    DDR2
    .data       >    DDR2   /* global and static non-const variables that are explicitly initialized */
    .switch     >    DDR2   /* switch statement tables */
    .sysmem     >    DDR2   /* memory for malloc functions */
    .far        >    DDR2   /* global and static variables declared far */   
}  
  
--------------------------------------------------------------------------------
P.S.
Below are information that would be also helpful for generating the *.l64P library:
1. XDAIS  (I'm using XDAIS_6_24)
    There are no separated packages for Linux and Windows at download site, so I just
    make a copy of the one I previously installed on Linux to CCS.
2. XDCtools
    I downloaded the Windows version from here:
    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/rtsc/3_16_03_36/index_FDS.html
3. Set up environment variables in Windows XP:
    (1) Start -> Control Panel -> System -> Advance (tab)  
          At the bottom, click on Environment Variables.
          At "System variables" click "New". Put the values:
              Variable name: XDAIS_INSTALL_DIR
              Variable Value: C:\CCStudio_v3.3\xdais_6_24
          need to restart CCS to take effect.
    (2) CCS project ->Build Option -> Compiler (tab) ->Preprocessor ->Include Search Path (-i )
          $(Proj_dir)\inc;%XDAIS_INSTALL_DIR%\packages;%XDCROOT%\packages
4. This is the article explains why should use    #include <xdc/std.h>
     http://processors.wiki.ti.com/index.php/StdDotH
5. check "CCS help" to add "-D compiler option".

Rule 20: must declare worst-case stack requirements

This error is related to your linker command file if you have taken care of scaratch memory .

if yes , then it needs some modification. currently i am not able to recall. i will inform you shortly.

but by the time i will check, please verify that all local variables are moved to scaratch memory crated by you.

because from the linker command file i am not finding any memyro section allocation of scaratch memory.

Rule 26: All static/global data must be far on c6x

please check wether any static or global variables still present in your application.

an easy way to verify is just create a test project in VC and add all your files.

in VC you can check what all global and static variables left.

one more thing i want to conform where is you persistant memory section ?

in your linker command file there is no section you are allocation for persistant memory which must have been created by you

by removing all static and global variables of your standard code.

My further question is: do we need a linker command file when making
an archive (.lib) from CCS project?  I thought the linker command file
is used for an executable (.out) project.

Also, I must admit I don't quite understand sujit's answer. TI's document
spru352e has explained the rules, but still I have no clue to solve
the issue.

- Juliann 

My further question is: do we need a linker command file when making an archive (.lib) from CCS project? I thought the linker command file is used for an executable (.out) project.

Yes you need a separate linker command file while creating the lib but its not the same linker command file which you are using for executable file purpose.

Also, I must admit I don't quite understand sujit's answer. TI's document spru352e has explained the rules, but still I have no clue to solve the issue.

any XDAIS-XDM compliant algorithm must not have any static and global variables. Once you have taken any standard code and ported to you target, it will have all static, global vaiables. you need to remove these variables. you need to put all thse global variable in to your persistent memory.

also you need to take care of the local variables. for that you need to implement Scratch.

Hi sujit,

This is the article discussing how to solve the rule-violation issue.
http://processors.wiki.ti.com/index.php?title=QualiTI_XDAIS_Compliance_Tool

The *.l64P archive built in CCS as an input of QualiTI seems not necessary to have a
"main" function embedded, and I think the "main" function (application function) is
to compile with *.l64P later to generate a test program (*.out).
   
The Scratch and Persistent memory assignment probably should be considered at next
code-generation stage (I don't know what it is) rather than at making code xDM-compliant
stage.

Well, good news is I stubbornly chose not to use a linker command file when building
an archive project in CCS, and I moved a static function from IALG interface to interior
codec, then I built the project with --mem_model:data=far, got the *.l64P and tested it
by QualiTI tool, Test passed.   :-D

Thank you for every effort. This is just a small step for me, there would be more
difficulties coming and will need your help as usual. 

- Juliann