|
|
|
# Evaluating the generation of an ILP using RACR
|
|
|
|
|
|
|
|
## Setup
|
|
|
|
|
|
|
|
- the initial system state is a generated system using the following parameters
|
|
|
|
- `num-pe` – total number of hardware resources
|
|
|
|
- `num-pe-subs` – number of subresources per resource (i.e. breadth of the HW-tree)
|
|
|
|
- `num-comp` – number of SW components
|
|
|
|
- `impl-per-comp` – number of implementations per component
|
|
|
|
- `mode-per-impl` – number of modes per implementation
|
|
|
|
- possible other, not implemented possibilities to describe the system include
|
|
|
|
- randomness for number of Impls and Modes
|
|
|
|
- minima and maxima for properties
|
|
|
|
|
|
|
|
## Test
|
|
|
|
|
|
|
|
1. create the initial system state, i.e. the example ast `ea`
|
|
|
|
2. `(att-value 'to-ilp ea)` – generate the ILP, and measure the time for generation
|
|
|
|
3. optional: solve the ILP and measure the time for solving
|
|
|
|
4. change some hardware resources, i.e. do a rewrite of some terminales representing the values inside
|
|
|
|
the provision clauses of the respective resources
|
|
|
|
5. GOTO 2.
|
|
|
|
|
|
|
|
Instead of changing the hardware, changing the software is also feasible, e.g. to simulate
|
|
|
|
new components or contract runtime feedback. The latter example means, that a contract is
|
|
|
|
re-calculated after the (monitored) execution of a component and its values are updated. |
