Dynamic memory segment configuration for `simple_mem_system`

[wysiwyng]

This adds dynamic configuration to simple_mem_system, allowing specification of up to 99 memory segments via .ini files or command line parameters. The following options are used (XX being a number from 00 to 99, must be double digits):

• simple_mem_system.memseg_origin_XX: (int) Lowest address of the segment
• simple_mem_system.memseg_length_XX: (int) Length of the address
• simple_mem_system.memseg_mode_XX: (string) Access mode of the segment, can be any combination of R, W, X (execute)
• simple_mem_system.memseg_image_XX: (string) A binary image from which the segment is to be initialized

If mode is omitted, RWX is assumed. If image is omitted, the segment will be initialized to zero. If either origin or length is missing, the segment will be ignored regardless of other present parameters.

Access modes R and W are checked within simple_mem_system and warnings are thrown when they are violated. Throwing exceptions or simply ignoring the violating call is an open discussion point, please provide ideas. The X access mode is provided for completeness's sake, it currently has no use within ETISS.

If vp.elf_file is present in the configuration, segments in the specified ELF file will be matched against configured segments. If an ELF segment matches a configured segment, this segment's image and access mode is then updated from the ELF file, overwriting values specified by mode or image options.

If a segment is present in the ELF-File which was not specified in the configuration, depending on the configuration option simple_mem_system.error_on_seg_mismatch two things can happen:

• If true: an error is thrown stating that memory segments don't match, and ETISS terminates.
• If false: the memory segment is created from the information contained in the ELF file, and a warning is thrown informing about possible issues with creating a segment directly from the ELF file.

edit The configuration parameter arch.cpu determines the target CPU architecture used. If an ELF file is in use, ETISS tries to find a matching target architecture for the ELF file. If no built-in architecture matches, a fatal error is thrown and ETISS terminates. The target architecture can be overridden by specifying arch.cpu in a configuration file, in this case the target architecture is not read from the ELF file. This feature is useful for implementing architectures other than RISC-V or OpenRISC in ETISS without changing ETISS internals. /edit

edit 2 The start address of the target code is extracted from the ELF file, if one is present. Alternatively it can be forced by the configuration parameter vp.entry_point. /edit 2

Further changes:

• Changed the generated binary files of the example programs to end in .elf
• Removed the linker file "hack" from example programs which expanded the RAM segment to its maximum size to facilitate for stack
• Removed the generation of separate binary files for ROM and RAM segments from example programs
• Greatly simplified read and write implementations in simple_mem_system
• Updated bare_etiss_processor to make use of the aforementioned changes
• Updated run_helper.sh to add fitting options to its launch configuration
• Better error messages in simple_mem_system, largely copied from the previous effort on configurable memory segments

[JoGei]

While you are refining the startup behavior. I've found that the architecture specific reset signaling is still fixed to 0x80 for all architectures. Since you introduced this setting we could also use it for the reset handling there:

• RISCV: https://github.com/tum-ei-eda/etiss/blob/05d346d37073263fe1afe8fb5491ab4c4c0dbcf5/ArchImpl/RISCV/RISCVArchSpecificImp.h#L226-L228
• RISCV64: https://github.com/tum-ei-eda/etiss/blob/05d346d37073263fe1afe8fb5491ab4c4c0dbcf5/ArchImpl/RISCV64/RISCV64ArchSpecificImp.h#L245-L247