% Technical Report ***New xml output*** **Author:** *Jérôme Legrand* # Introduction CheddarKernel is a special version of cheddar without the aadl parser and the gui. It is used mainly by ellidiss technologies through AADLInspector or the taste toolchain. CheddarKernel uses the cheddar framework but needs specific framework modifications. These packages are copied to the ellidiss directory and, thanks to the gpr capabilities, overload the original ones. These modifications mainly consist in adding a new xml output but it can be used to make framework modifications (an attempt to optimize the simulation engine was also done) without interfering with the cheddar source code. The main problem with this approach is that each time a modification is done in the original framework packages, a manual difference merging has to be done to the copied ones. This operation can take a couple hours and is prone to mistakes. After meeting with the main cheddar's developers, it has been decided to replace the previous xml output, which is not used and not maintained, by the one from cheddarKernel. Furthermore, some package from the ellidiss directory were obsolete. They were used by the optimization of the simulation engine. # Work done and reflection In this section, the work done is presented as well as some though about its current state and possible future modifications. ## xml validation : It is not related to the xml output but by default the xml projects must be validate. For cheddarKernel, it was needed to remove this verification. The option was there in the concerned functions of the framework but always set to true. A parameter has been added to allow the validation to be set to false. ## Replace the current xml output * remove the old one : all the switches referencing xml_output has been removed (generally the set_tag function was called) as well as all tags from the xml_tag package. * add the ellidiss xml output : The xml formatting from the cheddarKernel packages is far from perfect and only partial. It consists in a switch between the textual/raw and the xml output for the services used by cheddarKernel. A better way to make a new xml output would be to design what a service result should be and, if possible, based on that design, automatically generate the output functions. This work could be hugh, time consuming and should involved all cheddar developers, so we (ellidiss) decided to stay on the simple version for now. ## Remove the obsolete packages and references to the simulator engine optimization : The objective was to add some heuristics for jumping to the next relevant event. Due to the fact that the cheddar simulator engine is based on next event calculation and is not dynamic, the optimization was useless. There were also a preliminary work on a socket based communication with the simulator engine in order to add more dynamic behavior. Therefor, the *heuristics*, *marzhin_utils* and *sockets_overlay* packages were archived. ## Regression tests : After modifying the code, tests must be conducted. For Cheddar, an automatic regression tests process exists. The main objective, for this work, is to check if the textual output is still the same. For cheddarKernel, no automatic test exists for checking the xml output, so a manual verification is done. Tests can be added in the Cheddar regression test process : * add an output argument to "call_unit_test" (which can be set to xml_output) and pass to "sequential_framework_request" * add a command line to the "unittest" program to set the output to xml. * and, of course, add the tests in the "regression_tests" one. ### Cheddar/unittest In order to check if there is no regression with all these modifications, the regression tests have been done. * ./test_memory_footprint1.xmlv3 and ./test_memory_footprint2.xmlv3.R3.4 There is a problem in the file loading, the parser complains about the missing period of the task A2s. * ./basic_scheduling_simulation/multiprocessor/test_run2.xmlv3 The main result is identical but, in the current version, the event table is added. * ./basic_scheduling_simulation/uniprocessor/test_resource_wait_post.xmlv3 The results are identical except for the line of the "constraint error". * ./basic_scheduling_simulation/user_defined_schedulers/test_parametric6.xmlv3 There is a lot differences in the end of the simulation. This is probably due to the random numbers found in the "task_activation_section" section in the activations.sc file. * ./basic_scheduling_simulation/user_defined_schedulers/test_parametric15.xmlv3 There is a lot of differences in the beginning of the files, in the "Line" part. This is probably due to the random numbers found in the "priority_section" section in the laplace_gauss.sc file. * ./test_memory_footprint1.xmlv3 There is no result for this test in the current version. I do not know why. There is also a missing reference file for the 3,3 reference version : "./basic_scheduling_simulation/uniprocessor/test_ppcp_tasks_sems.xmlv3.R3.3". I've compiled a unittest version with the previous version of the source and here is the result with the problematic tests : * ./test_memory_footprint1.xmlv3 and ./test_memory_footprint2.xmlv3.R3.4: same error * ./basic_scheduling_simulation/multiprocessor/test_run2.xmlv3 : same differences. The 2 results from the previous unittest and the new one are identical. * ./basic_scheduling_simulation/uniprocessor/test_resource_wait_post.xmlv3 : same differences. The 2 results from the previous unittest and the new one are identical. * ./basic_scheduling_simulation/user_defined_schedulers/test_parametric6.xmlv3 : the 3 results (reference 3.3, previous modification and after modification) are different. * ./basic_scheduling_simulation/user_defined_schedulers/test_parametric15.xmlv3 : the 3 results (reference 3.3, previous modification and after modification) are different. So the added source code does not seem to change the results than the previous one and the only difference in the tests seems to be coming from the random generation numbers from the 2 parametric tests. ### CheddarKernel For cheddarKernel, only the xmloutput has been checked through the AADLInspector prototype and seems to be ok. ## facade Services ### used by cheddar Kernel * scheduling_simulation_time_line * scheduling_simulation_response_time * scheduling_feasibility_general_task * scheduling_feasibility_first_fit * scheduling_feasibility_next_fit * scheduling_feasibility_best_fit * scheduling_feasibility_small_task * scheduling_feasibility_basics * scheduling_set_priorities_according_to_deadline_monotonic * scheduling_set_priorities_according_to_rate_monotonic ### not used The following services could be interested : * scheduling_simulation_basics * scheduling_simulation_run_event_handler * scheduling_simulation_priority_inversion * scheduling_simulation_deadlock * scheduling_simulation_context_switch_number * scheduling_simulation_preemption_number * scheduling_simulation_blocking_time * scheduling_simulation_all_response_times (Implemented but no return) * scheduling_feasibility_periodic_task_worst_case_response_time * scheduling_feasibility_cpu_utilization * scheduling_feasibility_demand_bound_function * scheduling_feasibility_interval * scheduling_feasibility_compute_and_set_worst_case_blocking_time * scheduling_feasibility_compute_worst_case_blocking_time * scheduling_feasibility_compute_resource_ceiling_priority * scheduling_feasibility_compute_and_set_resource_ceiling_priority * scheduling_feasibility_tests_compositional * scheduling_feasibility_transaction_worst_case_response_time_audsley * scheduling_feasibility_transaction_worst_case_response_time_tindell * scheduling_feasibility_transaction_worst_case_response_time_palencia * scheduling_feasibility_transaction_worst_case_response_time_wcdops_plus * scheduling_feasibility_transaction_worst_case_response_time_wcdops_plus_nim * scheduling_set_priorities_according_to_audsley_opa * scheduling_set_priorities_according_to_opa_crpd_pt_simplified * scheduling_set_priorities_according_to_opa_crpd_pt * scheduling_set_priorities_according_to_opa_crpd_tree The following services could also be interesting but i m not sure how to use the results or what the service does exactly : * select_feasibility_test_by_name * select_feasibility_tests_simple * dependency_compute_chetto_blazewicz_priority * dependency_set_chetto_blazewicz_priority * dependency_compute_end_to_end_response_time_one_step * dependency_set_end_to_end_response_time_one_step * dependency_compute_end_to_end_response_time_all_steps * dependency_set_end_to_end_response_time_all_steps * scheduling_compute_scheduling_anomalies * buffer_feasibility_tests * buffer_scheduling_simulation * memory_compute_footprint_analysis * memory_set_footprint_analysis * memory_analysis_interferences_delays * random_response_time_density * cache_analysis_compute_cache_access_profile * cache_analysis_import_cfg_and_compute_cache_access_profile * network_noc_compute_communication_delay * network_noc_compute_path_delay * network_noc_compute_direct_interference_delay * network_noc_compute_indirect_interference_delay * network_compute_noc_transformation_ectm_saf * network_set_noc_transformation_ectm_saf * network_compute_noc_transformation_ectm_wormhole * network_set_noc_transformation_ectm_wormhole * network_compute_noc_transformation_wcctm_saf * network_set_noc_transformation_wcctm_saf * network_compute_noc_transformation_wcctm_wormhole * network_set_noc_transformation_wcctm_wormhole * network_compute_spacewire_transformation_scm * network_set_spacewire_transformation_scm * mils_compute_security_chinese_wall * mils_compute_security_warshall * mils_compute_security_bell_lapadula * mils_compute_security_biba ## cleaning up the facade for cheddarKernel This work is interesting for 2 things : * only embark what is necessary for cheddarKernel : for security reasons (less chance to have bugs, ...) and control over the features we have. * speeding up the compilation time At first i have made dummy package of the unwanted facade : * call_cache_framework * call_dependency_framework * call_design_pattern_framework * call_memory_framework * call_network_framework * call_random_framework * call_security_framework I also notice that an unused and not needed reference in the call_design_pattern_framework cause to add a lot of packages from the architecture generator. This first step has lower the number to compile from around 320 to around 270. In a second step, i search for a tool or a compilation option to detect unused packages. I found an option for the gnat compiler/builder (-gnatwu) to achieve this. If added in the KCompiler_Switches variable in the kernel.gpr file, a warning will be raised if an unused element is found.