X-HEEP Generator - Adding peripherals to the mcu-gen flow

[Pacsort17]

/!\ Currently not finished, but the overall structure is here /!\

Final goal : Being able to add and remove peripherals from python config() function

Overall structure for peripherals.

• One main class, Peripheral, describing a peripheral with only a memory field (offset + length). Two subclasses (AOPeripherals and OnOffPeripherals) extend form it, to describe two different type of peripherals (mandatory ones and not mandatory).
• Another class, DataConfiguration, acts as an interface (in Java) to add the possibility of linking a configuration .hjson file to a peripheral.
• When creating a peripheral, only the offset should be configured by the user.
• X_Heep object works with dictionaries of periph_name -> Periph_Object() | None, then converts it to a json-like string (compatibility reasons with hjson's comnfiguration)

Big changes :

• Adding peripheral.py (one class per peripheral + a bunch of util functions)
• Editing mcu_gen.py and system.py -> adding a way to add peripherals from python config() file, and checks that user's configuration is legal (everything is then cast to the same format as hjson's configuration, thus kwargs at the end of mcu_gen.py should be coherent between python configuration and hjson configuration)
• Editingt structs_periph_gen.py (and makefile) -> creates an x_heep object to take peripheral config from python config

Current issues :

• dma_ch_count is et to 256 instead of 100 (translates 100 to it's decimal reprensentation)
• Peripheral memory domains are not hard-coded (should be set to a specific value and don't move)
• auto_peripheral argument should be added to overide argument
• Check that peripheral domains don't overlap with other domains (not currently useful if peripherals memory domains are hard-coded)
• Opentitan should be used for configuration
• No test (add, for different configurations, a test that checks if kwargs are the same for either hjson's configuration and python configuration)

[davidmallasen]

@Pacsort17 remember to update the description of the PR and add the corresponding documentation to the docs folder too. There you can also describe the automation and checks that you are adding to the system to ease the user's work. This will bring more value and visibility to your work

[davidmallasen]

Remove the parenthesis

[davidmallasen]

Wouldn't it be easier to do everything from here down in a python script? That way we could reuse this in a local way instead of only having it in the CI

[davidmallasen]

Here and in the util/x_heep_gen I don't understand why there is both the add peripheral and configure peripheral functions. I feel that having a specific configure for each peripheral is a huge redundancy. The information of the peripheral and its configuration should be in its own object instance. If not, you see here that you're only configuring the peripherals when in fact you are adding them. Obtaining or creating the peripheral should not be done inside the config peripheral of each peripheral but here explicitly and then using the add function.

For example, the system can have by default the base peripheral domain with some default values for the peripherals. It would also have the user peripheral domain completely empty. Then the user can add the peripherals that they want here. We can discuss this further if you see that there is a better way of doing this or if you see a usecase that I'm missing.

[davidmallasen]

This file is getting a bit out of hand in size. Let's create a peripherals folder and have separate files for the different classes

[davidmallasen]

I do not understand why you would want to do this, also with the deep copies. You don't use them in the python configuration scripts that you wrote. Let's keep things as simple as they have to be, no need to overengineer these classes