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