Multicore Verification

Multicore Verification

Concerns

The Deos Kernel team has captured thoughts on design issues at Multicore Design Issues

• What items can be controlled with regards to safe operation of the system?
  • What mechanisms provide the control?
  • How can the mechanisms be reviewed, tested, or analyzed?

• What items cannot be controlled with regards to safe operation of the system?
  • How do uncontrollable items contribute to or detract from safe operation of the system?
  • How can items that contribute to safe operation of the system be reviewed, tested, or analyzed?
  • How can items that detract from safe operation of the system be mitigated?
  • How can any mitigation strategy be reviewed, tested, or analyzed?

• Where do we draw the line between multicore verification objectives we can meet and those that must be performed by the user?

Guidance

• CAST-32A
• DO-178C - Must be obtained locally through DDC-I access to RTCA documents. Talk with Greg Rose for access details, if needed.

Verification Philosophy

Given the complexity of the multicore environment, changes to our current software verification approach are likely. The three verification areas to consider are:

1. Reviews
   • How can our reviews support correct evaluation of requirements, code, and test with regards to Multicore Design Issues and CAST-32A?
2. Testing
   • How can our testing support correct evaluation of requirements and code with regards to Multicore Design Issues and CAST-32A?
   • More table based requirements and test cases? Karen and Gary started some of this effort on the recent fourpeaks verf effort. I believe this should be continued to get more fidelity in our testing.
   • Are there tools to support table based tests?
   • Can we leverage a partnership with LDRA for multicore analysis and testing needs?
3. Analysis
   • Good analysis tools tend to be expensive. Can we leverage our relationship with Honeywell for possible joint purchases and use?
   • More analysis is likely based on the complexity of multicore processing.
   • Additional analysis tools to support review and testing?
   • One tool I am intrigued with is CodeSonar by GrammaTech. I have contacted them by email regarding a full evaluation version of the tool.

Mulitcore Verification Learning Curve

• To support initial releases of the multicore kernel, I propose developing as many examples as possible exercising as many features as possible. This will serve two purposes.
  • Provide a set of acceptance tests for non-certified releases
  • Allow prospective testers to start up the multicore learning curve.

Possible Examples

• DDC-I Deos apps on core other than core 0
• IOI in multicore environment
• Serial port use in multicore environment
• CFFS in multicore environment
• A653 in multicore environment
• Cache partitioning in multicore environment
• Shared memory objects in multicore environment
• Platform resources in multicore environment
• Impact of TLB invalidation on other cores (primarily ARM issue).