• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 32 subscribers
  • Views 329 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

SAFETI_CQKIT: How do I correctly select a validated and compliant compiler configuration for qualification?

Nicolas J.
Prodigy 20 points
Part Number: SAFETI_CQKIT


Tool/software:

Sorry to post this in the ARM MCU forum, even though I'm using C2000. If I select SAEFTI_CQKIT as part number, it automatically selects this forum and I can't change it to something else.

I'm following the TI Qualification Kit user guide to better understand what is required to get a TI C2000 MCU certified. Currently, I'm stuck on the Tool Qualification Plan (TQP.docm), specifically the part about configuration selection. As far as I understand, I need to choose a tested and supported configuration, i.e. compiler flags/options, to build my software. These compiler options can be chosen according to the Tool Definition, Chapter 6. Multiple aspects of this are confusing to me.

Let me show you my current situation so you can follow along. So far I have isolated these flags used during C++ build in code composer studio (excluding include / object directories):

-v28 -ml -mt --cla_support=cla2 --float_support=fpu64 --idiv_support=idiv0 --tmu_support=tmu0 --vcu_support=vcrc -O0 --advice:performance=all --define=_FLASH --define=DEBUG --define=CPU1 -g --diag_warning=225 --diag_wrap=off --display_error_number --gen_func_subsections=on --abi=eabi

Looking at the Tool Definition Table 6.1, the options that influence code generation the most are the following:

-v28 -O0 -g --gen_func_subsections=on

Additionally, these compiler options impact code generation to a lesser extent according to Table 6.2:

--abi=eabi --cla_support=cla2 --float_support=fpu64 --idiv_support=idiv0 --vcu_support=vcrc --tmu_support=tmu0

All other options should not affect code generation at all, so they're not relevant for certification.

Now, the questions that I have about this:

  1. Tool Definition Table 6.2 lists --idiv_support=idiv0 as the default, but the compiler user's guide (spru514z) says 'none' is the default. Which one is correct?
  2. What is the idea behind splitting compiler options into the categories of "impacts code generation" and "impacts code generation to a lesser extent"? Can I somehow treat them differently when it comes to certification?
  3. Many of the options I currently use to enable additional hardware acceleration (fast integer division, 64 bit float support, VCU support, TMU support) are not present in Tool Definition Table 6.3.1, especially not with low optimization levels. Does this mean I need to turn them off / set to default to be compliant?
  4. The --gen_func_subsections is only tested in 7 validation test cases according to Table 6.3.1, and likely none of these will match my configuration exactly. Does this mean I can't use this option at all?
  5. The compiler user's guide indicates that the --vcu_support option is ignored for C/C++ code. If I don't use assembly code (only through TI libraries), do I still need to disable this to comply?
  6. I have enabled CLA support (--cla_support=cla2) for the whole project, even though this is only used for a subset of files. I assume this is the same situation as the question above, just with CLA code, right?
  7. Most of the configurations in Table 6.3.1 list the "-mt -ml" options. Should I use these too? I can't even find "-ml" in the compiler's user guide.
  • 0
    TI__Expert 5365 points

    Nicolas,

    What safety standard and safety compliance level are you using?  ASIL-D or ASIL-B, or a SIL level?

    1. If you specify --idiv_support without any argument then the compiler users value idiv0. To disable idiv0 support, do not include the option at all, or explicitly set --idiv_support=none).
    2. The main distinction between options in table 6.1 and 6.2 is 6.1 lists options that are varied across test suites, while table 6.2 options are mostly tested with unit testing. 
    3. These are tested with unit testing.
    4. All TI compiler options are tested and can be used in functional safety development. 
    5. If your device supports vcu then you should configure the option to match your device's vcu and use for all compilations. 
    6. There's no need to set cla_support differently for .C an .CLA files. Just set it to what is needed for your device.
    7. -ml (--large_memory_model) is now the default. -mt (--unified_memory) has description details in spru514 user guide pdf.

    Regardless of your functional safety level, you can perform the coverage compare check which will ensure that all portions of the TI compiler used when compiling your application are also exercised when performing release validations.

    It's not possible to test every option permutation which is why TI provides above coverage compare check. 

    Please let me know if you have any additional questions.

    Kind Regards,
    Greg

  • 0 in reply to GregM
    Prodigy 20 points

    Greg,

    Thanks a lot for the detailed response(s).

    Currently, I need to comply with UL1998 and likely IEC60730-1 in the near future. Both standards are less strict than most ASIL/SIL levels as far as I can tell. Neither the process-based nor the validation-based qualification completely match what I read in the standards, but I think validation-based with maybe a few additions/tweaks (description of mitigations for relevant known bugs) should be sufficient (correct me if I'm wrong). At least the qualification kit user guide mentions validation-based qualification for IEC 61508 which is what IEC60730 often references in Annex H.

    About the coverage compare check:

    - I assume the check needs to be done for every release that changes safety-relevant parts of the software to ensure it's still up-to-date. How long does it usually take to process such a request on TI's side? A ballpark number is perfectly fine for me, like is it a matter of hours, days or weeks?

    Best,

    Nicolas

  • +1 in reply to Nicolas J.
    TI__Expert 5365 points

    I recommend just applying the QKIT in validation mode and doing the coverage compare.  The review from TI should take less than a week and many times it's same day.  However, to avoid delays at project end, feel free to send an initial compare earlier. Then any subsequent compares will definitely be quicker.