Intern Team Project #1

VLE/Code Pruning

Obi Michael, Nicholas Gill, and Frank Oh

-- Cummins Confidential --2

Outline

I. VLE Project Introduction/ Background

II. VLE Steps

III. Conclusion

IV. Code Pruning Introduction/ Background

V. Code Pruning Steps

VI. Memory Reduction Analysis, Throughput Test Results & Conclusion

VII. Schedule

VIII. References/ Resources

-- Cummins Confidential --3

Outline

I. VLE Project Introduction/ Background

II. VLE Steps

III. Conclusion

IV. Code Pruning Introduction/ Background

V. Code Pruning Steps

VI. Memory Reduction Analysis, Throughput Test Results & Conclusion

VII. Schedule

VIII. References/ Resources

-- Cummins Confidential --4

VLE Project Introduction/ Background

Definition – Variable Length Encoding (VLE) is a form of machine instruction

compression. Instead of using a fixed number of bytes for each instruction, VLE uses a variable number of bytes depending on the instruction.

Goal – To test the implementation of VLE on Off-Highway Stage V

software build to provide flash memory reduction without comprising on quality.

Value – VLE provides additional flash memory for all Off-Highway

Industrial Builds.

– VLE helps to alleviate the difficulty of adding new feature functionalities that could be critical to the Off-Highway Market.

-- Cummins Confidential --5

Outline

I. VLE Project Introduction/ Background

II. VLE Steps

III. Conclusion

IV. Code Pruning Introduction/ Background

V. Code Pruning Steps

VI. Memory Reduction Analysis, Throughput Test Results & Conclusion

VII. Schedule

VIII. References/ Resources

-- Cummins Confidential --6

Overview of Steps Taken

Meetings – Angela explained in detail about VLE and we received guidelines

on how to proceed.

– VLE expert Christina Runge gave an insight view and the advantage/ disadvantage of VLE

– Received release report to analyze the VLE components that will be used in integration.

C2ST – Familiarized ourselves with C2ST through the process.

– Updated Stage V software build components with VLE components.

Buildforge – Compiled VLE components into the build.

– Inspected the errors using Clearcase and debugged.

-- Cummins Confidential --7

Procedure Outline

1. Copy an existing stage V software build in C2ST.

2. Update existing components with integrated VLE components.

3. Build in Buildforge to compile the updated components.

• Build Execution was running infinitely due to lack of constants in new data template.

4. Debug the errors.• Utilized Clearcase and Buildforge to inspect the errors.

• Met with Timothy Viola a Controls Engineer who had similar integration issues.

-- Cummins Confidential --8

Procedure Outline

1. Copy an existing stage V software build in C2ST.

2. Update existing components with integrated VLE components.

3. Build in Buildforge to compile the updated components.

• Build Execution was running infinitely due to lack of constants in new data template.

4. Debug the errors.• Utilized Clearcase and Buildforge to inspect the errors.

• Met with Timothy Viola a Controls Engineer who had similar integration issues.

-- Cummins Confidential --9

Copy an existing stage V software build in C2ST

• Stage V build to be used for VLE implementation

-- Cummins Confidential --10

Procedure Outline

1. Copy an existing stage V software build in C2ST.

2. Update existing components with integrated VLE components.

3. Build in Buildforge to compile the updated components.

4. Debug the errors.

-- Cummins Confidential --11

Update existing components with integrated VLE components

• Auto Build Component with VLE already built in

• Dependencies on 33.08.03.00 Version of Auto-Build• Components indicated are updated to versions in this box

-- Cummins Confidential --12

Procedure Outline

1. Copy an existing stage V software build in C2ST.

2. Update existing components with integrated VLE components.

3. Build in Buildforge to compile the updated components.

• Build Execution was running infinitely due to lack of constants in new data template.

4. Debug the errors.• Utilized Clearcase and Buildforge to inspect the errors.

• Met with Timothy Viola a Controls Engineer who had similar integration issues.

-- Cummins Confidential --13

Build in Buildforge to compile the updated components

• Initially, Build ran infinitely in step 18 (Clearmake) for more than 9 hours.

• Discovered some missing Software Constants related to four functions as cause of the issue.

• Angela added the constants to the data template of the new version

• Able to fix the running issue but kept failing.

-- Cummins Confidential --14

Procedure Outline

1. Copy an existing stage V software build in C2ST.

2. Update existing components with integrated VLE components.

3. Build in Buildforge to compile the updated components.

4. Debug the errors.

-- Cummins Confidential --15

Missing Software Constants

• These constants were being used by some functions/services in the build that ran infinitely. • Adding these constants fixed the infinite looping.

-- Cummins Confidential --16

Build in Buildforge to compile the updated components (Failed)

• Failed Clearmake (Step 18)

-- Cummins Confidential --17

Debugging Errors

Buildforge

• More than 340 Errors related to missing identifiers, missing/undeclared functions, missing parameters, and illegal type errors.

• Errors were read from buildforge because clearcase error file was not very detailed.

-- Cummins Confidential --18

Outline

I. VLE Project Introduction/ Background

II. VLE Steps

III. Conclusion

IV. Code Pruning Introduction/ Background

V. Code Pruning Steps

VI. Memory Reduction Analysis, Throughput Test Results & Conclusion

VII. Schedule

VIII. References/ Resources

-- Cummins Confidential --19

Conclusion A successful build could not be achieved.

– Integration of the group of OS and Infrastructure components in Stage V build results in errors.

– A few disadvantages of VLE are that the process is complex and that some Stage V components might not be compatible with VLE.

– Because we couldn’t get a successful build we, of course, could not show any memory reduction.

– Talked to Timothy Viola who has a similar issue, hopefully he will find the issue and this project can be continued at a later date.

Lack of time and access – Took approximately a week to request and attain required

software/ accesses for VLE project.

– Unfortunately, we only had builder access in C2ST• Had to ask Angela Niu to add constants whenever we needed to.

– Difficult to get hold of those who can help us.

-- Cummins Confidential --20

Outline

I. VLE Project Introduction/ Background

II. VLE Steps

III. Conclusion

IV. Code Pruning Introduction/ Background

V. Code Pruning Steps

VI. Memory Reduction Analysis/ Assumption

VII. Throughput Test Results

VIII. Schedule

IX. References/ Resources

-- Cummins Confidential --21

Code Pruning Project Introduction/ Background

Definition – Web Definition: Code pruning is the process of restructuring

existing code without modifying its external behavior.

– Cummins Definition: Code pruning is a term for taking advantage of optimizations in the compiler.

Goal – To test the method of Code Pruning on Off-Highway Tier4F

software build to provide flash memory reduction without comprising on quality.

Value – To remove code that will never be executed at runtime such as

parameters that are not useful in Off-Highway Tier4F software build.

– To improve loading time, performance, and reduce flash memory.

-- Cummins Confidential --22

Outline

I. VLE Project Introduction/ Background

II. VLE Steps

III. Conclusion

IV. Code Pruning Introduction/ Background

V. Code Pruning Steps

VI. Memory Reduction Analysis, Throughput Test Results & Conclusion

VII. Schedule

VIII. References/ Resources

-- Cummins Confidential --23

Overview of Steps Taken

Meetings – Angela Niu and Oscar Flores explained in detail about code

pruning.

– Met with Mark Zimmer a tools integator and received a list of parameters linked to _TIS.

– Discussed and finalized parameters to code prune with Calibration Team.

C2ST – Imported filtered parameters into a template created by Nick.

Buildforge– Built without any error using Nick’s template.

Reduction Analysis and Throughput Test– Used Clearcase to review the memory reduction.

– Ran the throughput test.

-- Cummins Confidential --24

Procedure Outline

1. Copy an existing Tier4F software build in C2ST.

2. Create a new template for Code Pruning.

3. Import the parameters into the template.

– Set the values of parameters to 0 with valid units.

4. Build through Buildforge and debug if necessary.

-- Cummins Confidential --25

Procedure Outline

1. Copy an existing Tier4F software build in C2ST.

2. Create a new template for Code Pruning.

3. Import the parameters into the template.

– Set the values of parameters to 0 with valid units.

4. Build through Buildforge and debug if necessary.

-- Cummins Confidential --26

Copy an existing Tier4F software build in C2ST

• A build in which code pruning would be implemented in. • Tier4 Final Blazer

-- Cummins Confidential --27

Procedure Outline

1. Copy an existing Tier4F software build in C2ST.

2. Create a new template for Code Pruning.

3. Import the parameters into the template.

– Set the values of parameters to 0 with valid units.

4. Build through Buildforge and debug if necessary.

-- Cummins Confidential --28

Create a new template for Code Pruning

• Template with parameters to be code pruned. • Code pruning tool (“Data Override”) is found in “configuration info” tab and “Memory Reduction” sub-tab in C2ST

-- Cummins Confidential --29

Procedure Outline

1. Copy an existing Tier4F software build in C2ST.

2. Create a new template for Code Pruning.

3. Import the parameters into the template.

– Set the values of parameters to 0 with valid units.

4. Build through Buildforge and debug if necessary.

-- Cummins Confidential --30

Import the parameters into the template

• Parameters to be code pruned added to the template.

• Original Parameters: 1408• Disabled Parameters: 906• Reduced Parameters: 96• Code Pruned: 63

-- Cummins Confidential --31

Procedure Outline

1. Copy an existing Tier4F software build in C2ST.

2. Create a new template for Code Pruning.

3. Import the parameters into the template.

– Set the values of parameters to 0 with valid units.

4. Build through Buildforge and debug if necessary.

-- Cummins Confidential --32

Debugging

Not all 93 parameters could be added to code pruning

template in C2ST.– Some parameters could not be found.

BCST_ENABLE parameters were removed because they

were crucial to some components in build.– Build originally failed because BCST_ENABLE parameters were

still in a template.

-- Cummins Confidential --33

Outline

I. VLE Project Introduction/ Background

II. VLE Steps

III. Conclusion

IV. Code Pruning Introduction/ Background

V. Code Pruning Steps

VI. Memory Reduction Analysis, Throughput Test Results & Conclusion

VII. Schedule

VIII. References/ Resources

-- Cummins Confidential --34

Memory Reduction Analysis

1.81% Reduction 0.4% Reduction

-- Cummins Confidential --35

Throughput Test Results (1)

Code Pruned Build Data

DIG Build Data

-- Cummins Confidential --36

Throughput Results (2)

0.72% Reduction

• Code Pruning Calibration is just like the DIG build but with some enables turned into constants.

• Throughput Result correlates to Memory Reduction.

-- Cummins Confidential --37

Conclusion

Application Ram Reduction Percentage: 0.4% Flash Memory Reduction Percentage: 1.81%

The Execution Time Frame was under ESW 5000 μs Code Pruning calibration file had 0.72% Throughput

reduction Adding code pruned parameters back into a calibration

later will cause issues with overlays. Code pruning is not as effective as VLE. But according

to Christina Runge VLE is more risky.

-- Cummins Confidential --38

Outline

I. VLE Project Introduction/ Background

II. VLE Steps

III. Conclusion

IV. Code Pruning Introduction/ Background

V. Code Pruning Steps

VI. Memory Reduction Analysis, Throughput Test Results & Conclusion

VII. Schedule

VIII. References/ Resources

-- Cummins Confidential --39

Schedule

-- Cummins Confidential --40

Outline

I. VLE Project Introduction/ Background

II. VLE Steps

III. Conclusion

IV. Code Pruning Introduction/ Background

V. Code Pruning Steps

VI. Memory Reduction Analysis, Throughput Test Results & Conclusion

VII. Schedule

VIII. References/ Resources

-- Cummins Confidential --41

References/ Resources

Angela Niu – Controls CPS Engineer Christian Runge – Architect and System Enginer Timothy Viola – Controls Engineer Oscar Flores – Controls CPS Engineer Paul Pulkowski – Electronics Technical Engineer Mark Zimmer – Off Highway Tools Integrator

-- Cummins Confidential --42

Next Steps

Submit the Technical Report, Cummins Report #00059811

Start working on 2nd Project: CM2350 Lead Free TransparencySponsor: Shwetha Prasad