This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Integrating AER with Codec Engine



Hi,

  While integrating  AER  with the codec engine in EZSDK  I encountered the follwoing problem with building.

  ======== all [.] ========
configuring bin/ti_platforms_evmTI816X/all_DSP.pe674 from package/cfg/bin/ti_platforms_evmTI816X/all_DSP_pe674.cfg ...
platformName = 'ti.platforms.evmTI816X:DSP'
js: "./all_syslink.cfg", line 238: XDC runtime error: ti.sdo.ce.Server/algs/1: incompatible assignment to mod :xdc.services.intern.xsr.Value$Obj@79ed7f::ti.mas.aer.Version

I  obtained the ti/mas/ folder from TI.  Then I  'mkdir  mas'  in codec_engine_3_21_00_19/ti  directory.  Add  the ti/mas folder to /usr/local/ezsdk/component-sources/codec_engine_3_21_00_19/examples/ti/. 

Then I modify /usr/local/ezsdk/component-sources/codec_engine_3_21_00_19/examples/ti/sdo/ce/examples/servers/all_codecs/all_syslink.cfg.                                                

var  Version=xdc.useModule('ti.mas.aer.Version');  

and

 {name: "aer", mod: Version, threadAttrs: {
        stackMemId: 0, priority: Server.MINPRI + 1}
 },

I am attaching the screen shot of the directory structure.

The aer directory includes:

 

The aer/package.xdc content:

requires ti.mas.types[5,0,7,0];
requires ti.mas.fract[2,0,7,0];
requires ti.mas.util[4,0,8,0];
requires ti.mas.vpe[2,0,6,0];
requires internal ti.mas.swtools[2,0,4,0];

package ti.mas.aer[4.2, 0, 2, 0] {
   module Version;
}

I compare AER with other codes  package. I found that AER package is very diffrent  from  other codec packages.

(1)Other codec packages  locate in ti.sdo.ce.example.codecs;but AER must locate in ti.mas as "package ti.mas.aer[4.2, 0, 2, 0]" in package.xdc.

(2)I  can't understand  the types,fract,util,vpe,swtools folders in mas directory. 

(3)Other codecs blong to one of VISA,but I don't know  whether  AER blong to  VISA. 

(4)Other  codecs module name is similar to package name,but AER module is “Version”.

(5)The module.xdc of  other codecs  is diffrent from  Version.xdc of  AER.  For example  G711ENC.xdc:

     *  ======== G711ENC ========
 *  G711 Encoder specification
 *
 *  This file specifies information necessary to integrate with the Codec
 *  Engine.

 *
 *  By inheriting ti.sdo.ce.speech.ISPHENC, G711ENC declares that it "is a"
 *  speech encoder algorithm
. This allows the codec engine to automatically
 *  supply simple stubs and skeletons for transparent execution of DSP
 *  codecs by the GPP.
 *
 *  In addition to declaring the type of the G711 algorithm, we declare
 *  the external symbol required by xDAIS that identifies the algorithms
 *  implementation functions.
 */
metaonly module G711ENC inherits ti.sdo.ce.speech1.ISPHENC1
{
    /*!
     *  ======== ialgFxns ========
     *  name of this algorithm's xDAIS alg fxn table
     */
    override readonly config String ialgFxns = "G711ENC_SUN_IG711ENC";
}

I  doubt  that  AER  can't  use same integrating way with other codecs

Can  AER use by codec engine?   If  yes, then how  should  AER  integrate with codec engine?  If not, then how should AER  integrate  with EZSDK?

The CPU  is CA8168.

 

Golden

  • It would be helpful to see the Version.xdc file, however...

    The element assigned to "mod:" needs to be of type ICodec.Module.  This is from Engine.xdc:
        struct AlgDesc {
            String          name;       /*! Alg nick-name */
            ICodec.Module   mod;        /*! The alg implementation */
            Bool            local;      /*! Run algorithm locally */
            Int             groupId;    /*! Alg group ID for sharing resources */
        };
    This is the definition of the structure that you're assigning in all_syslink.cfg.

    All the codecs are declared to be of this ICodec type.  This is from IIMGDEC1.xdc:
        metaonly interface IIMGDEC1 inherits ti.sdo.ce.ICodec
    So, you can only assign modules of type ICodec to the AlgDesc.mod element.  What is the definition of the Version module (contents of Version.xdc)?

    Regards,

    - Rob

     

  • Version.xdc:

    /*
     *  DO NOT MODIFY THIS FILE
     *  This file is generated by this package's build script (package.bld).
     */
    /*!
     *  ======== Version ========
     *  Version for the ti.mas.aer package
     */
    metaonly module Version inherits ti.mas.swtools.IVersion2 {

        /*
         *  ======== MAJOR ========
         *  Major version number of ti.mas.aer
         */
        override const UInt16 MAJOR = 15;

        /*
         *  ======== MINOR ========
         *  Minor version number of ti.mas.aer
         */
        override const UInt16 MINOR = 1;

        /*
         *  ======== PATCH ========
         *  Patch level of ti.mas.aer
         */
        override const UInt16 PATCH = 10;
       
        /*
         *  ======== BUILD ========
         *  Build Number of ti.mas.aer
         */
        const UInt16 BUILD = 3;
       
        /*
         *  ======== QUALITY ========
         *  Quality level of ti.mas.aer
         */
        override const UInt16 QUALITY = 3;

        /*
         *  ======== BTYPE ========
         *  Built type of ti.mas.aer
         */
        override const UInt16 BTYPE = 0;

      /*
         *  ======== WIDTH ========
         *  Minimum print width for ti.mas.aer
         */
        override const UInt16 WIDTH = 0;

      /*
         *  ======== PACKAGING STD COMPLIANCE ========
         *  Packaging Standard Compliance field
         */
        const UInt16 PKGSTD = 2;   
       
    }

    mas/swtools/IVersion2.xdc:

    /*!
     *  ======== IVersion ========
     *  Standard package version number interface
     *
     *  This interface is part of the SDO Package Standard.  Each conformant
     *  package that supplies a version number contains a module named
     *  `Version` that implements this interface.  In other words,
     *  @p(blist)
     *      - the package's `package.xdc` file declares `Version` as one of it's
     *        modules
     *      - the package contains a spec for the `Version` module (named
     *        `Version.xdc`) and a header generated from this spec (named
     *        `Version.h`)
     *      - the `Version.xdc` file may optionally be generated from the
     *        `ti/sdoarch/standards/pkg/Version.xdt` template when the package's
     *        build script runs.
     *  @p
     *
     *  This interface defines a set of values that are used to
     *  @p(nlist)
     *      - informally communicate the "degree" of change between successive
     *        releases of a package,
     *      - provide a "key" that enables the producer to unambigeously identify
     *        the sources (and tools) used to produce the package, and
     *      - enable consumers to easily communicate to producers the version(s)
     *        of the package(s) they are using.
     *  @p
     */
    metaonly interface IVersion2 {
        /*!
         *  ======== MAJOR ========
         *  Major version number
         *
         *  This number should be changed when major changes in the package
         *  occur. Examples include adding new modules, adding substantial new
         *  features to the algorithm(s).
         */
        const UInt16 MAJOR;

        /*!
         *  ======== MINOR ========
         *  Minor version number
         *
         *  This number should be changed when minor changes in the package
         *  occur. Examples include minor changes to the existing APIs,
         *  adding minor features to the algorithms(s) including expanding the
         *  configuration options.
         */
        const UInt16 MINOR;

        /*!
         *  ======== PATCH ========
         *  Patch level
         *
         *  This number should be changed when bug fixes or performance
         *  improvements are introduced. There should be no changes in the APIs
         *  in this case.
         */
        const UInt16 PATCH;

        /* Constants for the QUALITY config param.  Should these be enums? */
        const UInt16 QUALITY_PREALPHA = 0;
        const UInt16 QUALITY_ALPHA = 1;
        const UInt16 QUALITY_BETA = 2;
        const UInt16 QUALITY_GA = 3;

        /*!
         *  ======== QUALITY ========
         *  Quality
         *
         * Value   | String   | Description
         *  0      | prealpha | Pre-alpha, under development. Cannot be delivered
         *                      to customers. (default)
         *  1      | alpha    | Substantial features included. Not fully tested.
         *  2      | beta     | All features included. Not fully tested.
         *  3      | <empty>  | All features included. Fully tested. General
         *                      availability.
         * 4-31    | reserved | Reserved for future expansion of the packaging
         *                      standard.
         * 32-127  | user defined | Site/group specific extensions.
         */
        const UInt16 QUALITY;

        /* Constants for the BTYPE config param.  Should these be enums? */
        const UInt16 BTYPE_STANDARD = 0;
        const UInt16 BTYPE_ENGINEERING = 1;
        const UInt16 BTYPE_DEBUG = 2;

        /*!
         *  ======== BTYPE ========
         *  Build Type
         *
         * Value   | String   | Description
         *   0     |  empty   | Regular build as described by the QUALITY field.
         *                      (default)
         *   1     |  eng     | Engineering build provided prior to moving to next
         *                      quality stage. Not fully tested.
         *   2     |  dbg     | Debug build provided prior to moving to next quality
         *                      stage. Not fully tested. May contain temporary code
         *                      and traces that will be removed in the next regular
         *                      or engineering build.
         *  3-31   | reserved | Reserved for future expansion of the packaging
         *                      standard.
         *  32-127 | user defined | Site/group specific extensions.
         */
        const UInt16 BTYPE;

        /*!
         *  ======== WIDTH ========
         *  Minimum width of print fields
         *
         *  When denoting version numbers using '.' to separate fields
         *  there is a danger of confusing version "6.1" and version "6.10";
         *  because, in decimal notation 6.1 == 6.10.  To avoid
         *  this confusion, it is common practice to adopt a fixed minimum field
         *  width that's when printing version dimensions (other than MAJOR);
         *  e.g., rather than printing "6.1", if WIDTH == 2 then the version would
         *  be displayed as "6.01".
         */
        const UInt16 WIDTH;

        /*!
         *  ======== getString ========
         *  Returns a string representation of the version
         *
         *  This method return a string of the form:
         *  @p(code)
         *      MAJOR<sep>MINOR<sep>PATCH
         *  @p
         *  where `MAJOR`, `MINOR`, and `PATCH` are
         *  the values sepcified in this interface and `<sep>` is the (optional)
         *  argument to this method.  If `separator` is not supplied (or is
         *  `null`), `<sep>` defaults to `'.'`.
         */
        function getString(separator);
    }

    ==========================================end======================================================

    question:

    The  module AER  don't  inherits  Icodec.It means that AER can't integrate with Codec Engine?

    How  should  utilize AER ?

     

     

  • The ti.mas.aer.Version Module is clearly not a codec.  There may be a codec module in that AER product, but someone from the AER product (or release notes?) will need to provide details on how to integrate with Codec Engine.

    Chris

  •  I  don't   get  the  details on  how to integrate  with Codec Engine  from  Codec  Engine and AER package.  I  have asked  about  the  detailed  integating  way  from  Ti  Field Application  Engineer,but  no documentation  is supplied.

  • Assuming that AER is not one of the VISA class of algorithms, you may need to consider some additional work to integrate it into a Codec Engine framework using the IUNIVERSALinterface. Take a look at the following links to have some idea about the work involved.

    One solution is to create adaptors - to make your algorithm look like one of the existing VISA classes:

    But a preferable and potential simpler approach is to adapt your algorithm to use IUNIVERSAL, instead of one of the VISA interfaces, since IUNIVERSALinterface is supported by Codec Engine, in addition to the VISA classes, and some examples and references as a starting point can be found here:

     

    http://processors.wiki.ti.com/index.php/Getting_started_with_IUNIVERSAL

    Best regards,

    Murat

    http://www.ti.com/lit/an/spraae7b/spraae7b.pdf