data2/text/range/10001-15000/694849.txt

Ticket Name: TDA2: In Vision SDK different size of enumeration type among TDA2x heterogeneous cores cause XDAIS Algorithm Interface failed.

Query Text:
Part Number: TDA2 Dears, In TDA2x there are several heterogeneous cores: Cortex A15, Cortex M4, DSP C66x, EVE. Current we try to integrate TIDL (run in DSP and EVE) and H.264 codec (run in M4) in our program and each function will go crash. Either calling TIDL or calling H.264 codec will invoke XDIAS Algorithm Interface, and we observe that the size of enumeration type compiled by those corresponding compilers(A15, M4, C66x, EVE) with default enum size option is different and will cause XDAIS Algorithm Interface failed. The structure IALG_MemRec defined in ialg.h (XDIAS Algorithm Interface) is shown as the following: typedef struct IALG_MemRec { Uns size; /**< Size in MAU of allocation */ Int alignment; /**< Alignment requirement (MAU) */ IALG_MemSpace space; /**< Allocation space */ IALG_MemAttrs attrs; /**< Memory attributes */ Void *base; /**< Base address of allocated buf */ } IALG_MemRec; and the two enumeration types defined in ialg.h are also shown as the following: typedef enum IALG_MemSpace { IALG_EPROG = IALG_MPROG | IALG_MXTRN, /**< External program memory */ IALG_IPROG = IALG_MPROG, /**< Internal program memory */ IALG_ESDATA = IALG_MXTRN + 0, /**< Off-chip data memory (accessed sequentially) */ IALG_EXTERNAL = IALG_MXTRN + 1, /**< Off-chip data memory (accessed randomly) */ IALG_DARAM0 = 0, /**< Dual access on-chip data memory */ IALG_DARAM1 = 1, /**< Block 1, if independant blocks required */ IALG_SARAM = 2, /**< Single access on-chip data memory */ IALG_SARAM0 = 2, /**< Block 0, equivalent to IALG_SARAM */ IALG_SARAM1 = 3, /**< Block 1, if independant blocks required */ IALG_DARAM2 = 4, /**< Block 2, if a 3rd independent block required */ IALG_SARAM2 = 5 /**< Block 2, if a 3rd independent block required */ } IALG_MemSpace; typedef struct IALG_MemRec { Uns size; /**< Size in MAU of allocation */ Int alignment; /**< Alignment requirement (MAU) */ IALG_MemSpace space; /**< Allocation space */ IALG_MemAttrs attrs; /**< Memory attributes */ Void *base; /**< Base address of allocated buf */ } IALG_MemRec; We use the following test code to display the data size: printf("sizeof(IALG_MemSpace) = %d, sizeof(IALG_MemAttrs) = %d, sizeof(IALG_MemRec) = %d\r\n", sizeof(IALG_MemSpace) = %d, sizeof(IALG_MemAttrs) = %d, sizeof(IALG_MemRec) = %d); The data size displayed in different cores in TDA2x are: [M4 ]: sizeof(IALG_MemSpace) = 1, sizeof(IALG_MemAttrs) = 1, sizeof(IALG_MemRec) = 16 [A15]: sizeof(IALG_MemSpace) = 4, sizeof(IALG_MemAttrs) = 4, sizeof(IALG_MemRec) = 20 [DSP]: sizeof(IALG_MemSpace) = 4, sizeof(IALG_MemAttrs) = 4, sizeof(IALG_MemRec) = 20 [EVE]: sizeof(IALG_MemSpace) = 1, sizeof(IALG_MemAttrs) = 1, sizeof(IALG_MemRec) = 16 Mainly the above enum size in M4 and EVE is 8-bit (packed size, the smallest possible byte size) and the enum size in A15 and DSP is 32-bit. In Vision SDK we may use XDIAS Algorithm Interface among different cores, the above enum data defined in EVE and M4 is 8-bit and will be incorrectly accessed by A15 and DSP. Since there is no compiler option for EVE(arp32) compiler to generate the above enum data to be 32-bit, we choose to force A15 compiler with compiler option -fshort-enums and C66x compiler with option -small_enum to generate the above enum data to be packed size (8-bit) in our own code, but we still can not make XDIAS Algorithm Interface among cores work correctly. The main reason is that in Vision SDK there are many pre-built libraries (mainly located in ti_compoenents folder) which are built with default compiler option. Unless we have the source code of those pre-built libraries, we can't generate the same packed enum size for different cores. We wonder why TI does not provide consistent enum size in threir released library which uses XDAIS Algorithm Interface, since it may be accessed as the parameter accross different cores. We prefer 32-bit enum size for all cores. If there is any difficulty to generate 32-bit enum size for all cores, packed enum size is also acceptable for all cores. In anyway, can TI provide a consistent enum size among different cores in Vision SDK and all pre-built libraries? Sincerely. Mark Kang.

Responses:
Mark Kang. I guess you are using Vision SDK, right? In VSDK I have used constant size data type for any interface file, where it need to run on heterogeneous cores: Cortex A15, Cortex M4, DSP C66x, EVE. for example, i will only use Int32 or UInt32 instead of int or uint, this way we can assure same size in all cores for any enums use as below, sample code below typedef enum { DEC_LINK_FIELDLEVELPROCESSCALL = 0, DEC_LINK_FRAMELEVELPROCESSCALL = 1, DEC_LINK_CAL_LEVEL_FORCE32BITS = 0x7FFFFFFF /**< To make sure enum is 32 bits */ } DecLink_ChProcessCallLevel; the last entry will make sure enum is 32 bits Hope i have answered your question? regards, Shiju

Hi Shiju, We already have tried the same method as you suggested (see below code), it doesn't work because we don't have all the source code of TI released libraries using XDIAS Algorithm Interface to rebuild. typedef enum IALG_MemSpace { IALG_EPROG = IALG_MPROG | IALG_MXTRN, /**< External program memory */ IALG_IPROG = IALG_MPROG, /**< Internal program memory */ IALG_ESDATA = IALG_MXTRN + 0, /**< Off-chip data memory (accessed sequentially) */ IALG_EXTERNAL = IALG_MXTRN + 1, /**< Off-chip data memory (accessed randomly) */ IALG_DARAM0 = 0, /**< Dual access on-chip data memory */ IALG_DARAM1 = 1, /**< Block 1, if independant blocks required */ IALG_SARAM = 2, /**< Single access on-chip data memory */ IALG_SARAM0 = 2, /**< Block 0, equivalent to IALG_SARAM */ IALG_SARAM1 = 3, /**< Block 1, if independant blocks required */ IALG_DARAM2 = 4, /**< Block 2, if a 3rd independent block required */ IALG_SARAM2 = 5 /**< Block 2, if a 3rd independent block required */ IALG_MEMSPACE_END = 0x7FFFFFFF **< To make sure enum is 32 bits */ } IALG_MemSpace; typedef enum IALG_MemAttrs { IALG_SCRATCH, /**< Scratch memory. */ IALG_PERSIST, /**< Persistent memory. */ IALG_WRITEONCE /**< Write-once persistent memory. */ IALG_MEMATTRS_END = 0x7FFFFFFF **< To make sure enum is 32 bits */ } IALG_MemAttrs; Although we have TIDL source and can modify ialg.h( XDIAS Algorithm Interface) as the above code, re-build the TIDL to make sure the above enum data is 32-bit in both DSP and EVE core. However, ialg.h is XDIAS Algorithm Interface which is also used in other library such as H.264 codec released by TI. Solely modifying our local ialg.h only guarantee the enum type is 32-bit in our own code for all heterogeneous cores (A5, M4, DSP, EVE), but not guarantee the enum data in TI released libraries is also 32-bit. Unless TI can release the all libraries using XDIAS Algorithm Interface by re-building them with the same 32-bit enum as you suggest. Best regards. Mark Kang.

Hi Mark I do not suggest you to modify and rebuild Codec and TIDL libs. Instead you can create a public header files which is almost a copy of these alg/codec header files and use the same in your integration/wrapper code. Define constant size data type in this new interface file and use the same across cores. The same approach I have followed for Vision SDK (TI SW development Kit for ADAS). If you have not looked into VSDK, please check if you can use VSDK, where we have addressed all these issues. BTW, can you please help me to understand your requirement a bit more, I mean what data flow/usecase you are tying to build etc.? regards, Shiju

Hi Shiju, I don't get your point. Adding wrapper code seems to be just another kind of temporarily workaround method, but it does not solve issue radically to me. Although XDIAS originally stands for "eXpressDSP Algorithm Interface Standard", later TI still uses it in libraries running on other cores such as m4(e.g. H.264) and EVE(e.g. TIDL). If TI extended the usage of XDIAS Algorithm Interface from DSP to other cores, the design of later version of XDIAS Algorithm Interface should be taken heterogeneous cores into consideration and make the size of data structure (e.g. enum size) in XDIAS Algorithm Interface be the same among different cores. From software perspective, XDIAS Algorithm Interface should be transparent to user. It means the data structure of XDIAS Algorithm Interface must be cross-core. It's weird and non-intuitive to add a warpper to handle heterogeneous-core-dependency data structure when calling libraries using XDIAS Algorithm Interface. Mark.

Hi Mark I am coping to our XDIAS Algorithm Interface expert. regards, Shiju

Hi Mark, I understood your point and very valid point. We avoid the usage of enum in our public interface files like itidl.h and any other algorithm for that say. But we base our interface on this ialg.h so the problem got carried in these components also. So let me start with acknowledging the problem but let me also understand how can we help now given this issue. So few questions 1. Are you creating any instance of such object which has IALG_MemRec and sharing across cores? If so which one is that? I think this can be avoided so I want to understand your need for such usage if any For example if you create a TIDL object, it can be shared across cores because the final created object doesn't have size difference across cores I need to check Codec interface file also but I think the core interface of codec also doesn't use any enum. So after object creation it should be shareable across cores. And the object creation sequence is most likely local to core and if so the impact of different size for the IALG_MemRec shouldn't cause the issue 2. So please help me understand your object creation sequencing which involves these multiple cores and create the hang issue you mentioned. Thanks, With Regards, Pramod

Hi Pramod, 1. We share an TIDL-related object containing IALG_MemRec across DSP and EVE. The TIDL-related object is created in DSP first, then this object is passed to EVE and EVE calls TIDL library. Finally DSP gets the output of TIDL from EVE and performs some post-processing. At our first time of integration, we noticed that the enum size issue causing the size of TIDL-related object is different between DSP and EVE and and we tried to fix it by ourselves. We tried two cases(see below) to fix the issue, one failed and the other worked. [case A, fail] We used DSP compiler option -small_enum to force IALG_MemRec size be 16-byte, the same size as the one generated by EVE (ARP32) compile i.e, sizeof(IALG_MemSpace) = 1, sizeof(IALG_MemAttrs) = 1, sizeof(IALG_MemRec) = 16. However, the option -small_enum also applied to all our code(including Vision SDK code) and the built program went crash immediately after booting. Perhaps only limiting the option -small_enum to to our TIDL-related object code but not all other Vision SDK code can avoid system crash. We didn't try this proposal because it made the build configuration inconsistent between our own development code and Vision SDK code. [Case B, work] We force the enum be 32-bit by adding an 0x7FFFFFFF value at the end of enum decalartion like the following: typedef enum IALG_MemAttrs { IALG_SCRATCH, /**< Scratch memory. */ IALG_PERSIST, /**< Persistent memory. */ IALG_WRITEONCE /**< Write-once persistent memory. */ IALG_MEMATTRS_END = 0x7FFFFFFF **< To make sure enum is 32 bits */ } IALG_MemAttrs; Since we got TIDL source from TI, we can generated the IALG_MemRec size be 20-byte for both DSP and EVE. i.e., sizeof(IALG_MemSpace) = 4, sizeof(IALG_MemAttrs) = 4, sizeof(IALG_MemRec) = 20. So our TIDL-related object works between DSP and EVE. 2. After our "successful" integration of using case B, we tried to integrate H.264 codec library into our program. But H.264 codec failed to run in our built program. We guessed part of H.264 related code containg IALG_MemRec containing 32-bit enum and the pre-built H.264 codec library containing 8-bit enum. However, If we didn't fix TIDL-related object between DSP and EVE and also integrate H.264 code library, our program can run H.264 codec successfully. So we face the dilemma, only one of TIDL and H.264 can work in our program but not both. Of course currently we have some workaround method to make both TIDL and H.264 working in our program, but it requires to re-build TIDL source code. We are afraid that sooner or later we may integrate other XDIAS Algorithm Interface library and without rebuilding its source code by our workaround method, the same issue will happen again. So we need TI to make the data structure size in XDIAS Algorithm Interface be the same among heterogeneous cores. Best regards. Mark.

Hi Mark, Thanks for detailed explanation... We shall fix this issue in next TIDL release and that should fix your current issue. we shall also inform the changes to you soon so you can apply locally in your code base and gets unblocked without waiting for release. Now one thing which I want to understand on your usage and suggest As such if your usage is that few set of layers on EVE and few set of layers on DSP - you can create 2 instance one on each core (EVE and DSP) with proper setting of currLayersGroupId and coreId. You can refer SSD based object detection example for such usage. Thanks, With Regards, Pramod

Hi Mark, As mentioned about quick fix, you can do below change 1. File tidl_alg_int.h : Define one local structure IALG_MemRecLocLoc by reusing the IALG_MemRec and chnage both space and attrs parameter as Int instead of enumerated parameters 2. File tidl_alg.c Line 2429, there is one memcpy to algHandle->memRec, you can replace this in a loop with individual structure element assignments (total 5 assignments in a loop iterating for algHandle->numMemRecs times) Thanks, With Regards Pramod

Hi Pramod, Thanks for the quick fix. We can do the similar modification to resolve the issue Instead of change "space" and "attrs" parameter from enum to Int (32-bit), we prefer change it to char(8-bit). Since "space" and "attrs" parameter in H.264 pre-built library for M4 core is 8-bit and we want to make all of their size be the same. Mark.

Hi Mark, With this change, the dependency of TIDL object goes away on enumerated data type, so it doesn't matter if H.264 pre-built library has 8-bit or 32-bit. However there is no issue in keeping it char (8-bit) instead of int (32-bit) Thanks, With Regards, Pramod