Cleanup example INI config files

[PhilippvK]

I realized, that multiple configuration options found in examples/bare_etiss_processor/base.ini do not have an effect right now.

I.e. arch.cpu_cycle_time_ps=10000 is only used by OR1KArch while RISCVArch has the value 31250 hardcoded.

For this propertie and a probably a few other we should decide to either:

• Remove the unsupported option from the example configuration file to reduce teh confusion for new users
• or properly implement the options for all supported architectures.

[PhilippvK]

I checked which of the options in base.ini and ETISS.ini are actually used in the project and found the following "leftovers":

testing = false
ETISS::CPU_quantum_ps=100000
ETISS::write_pc_trace_from_time_us=0
ETISS::write_pc_trace_until_time_us=3000000
ETISS::sim_mode=0
vp::simulation_time_us=20000000

Does anyone know which ones might still be used in the future or are used by external projects?

CC @DanMueGri @rafzi @JoGei @wysiwyng @uzleosharif

[DanMueGri]

testing = false
No clue

ETISS::CPU_quantum_ps=100000
I think this refers to co-simulation with SystemC. Here usually temporal decoupling is used, and this value tells you how far etiss may run ahead of the SystemC simulation.

ETISS::write_pc_trace_from_time_us=0
ETISS::write_pc_trace_until_time_us=3000000
This is from fault injection. I think a trace is written to see in which pc positions faults can be injected.

ETISS::sim_mode=0
No clue

vp::simulation_time_us=20000000
Again for SystemC simulation, after this time the SystemC simulation exits.

[PhilippvK]

@DanMueGri Thanks for your input.

Do we want to have the SystemC-related options in the ETISS-repo? For the bare_etiss_processor where there are currently mentioned, the will not have an effect and every other VP will probably have its own ini-files.

[uzleosharif]

i agree we can move application specific settings to other ini files..lets keep base.ini as simple as possible

[rafzi]

At the moment the configurations cannot easily be decoupled like that. The command line options are a whitelist and there is currently no mechanism to extend the configuration by user programs and plugins.

It would be a great addition to the Plugin interface where a function reports the options exposed by a plugin. However I think the command line processing would need an overhaul to support this. We would first have to load plugins given via command line while ignoring all other options, the query their options interface, then process the command line again and pass the correct options to all plugins for initialization.

The ini files can of course still be cleaned up either way.