The object structure generator prototype

[AleksandrDanilovIntel]

Generates the internal object structure (objects, configuration attributes, input and output interfaces) in JSON format for later use in CLI commands and Blueprints.

attaching the output format
test-cmn-700-dml.json

It's easy to extend the number of JSON parameters by adding an optional object parameter in DML code.

template impl_connect {
    interface memory_space;
    interface signal {
        param required = false;
    }
    interface map_demap {
        param required = false;
    }
}

    if node.get_component('required') != None and param_defined(node, 'required'):
        d['required'] = param_bool(node, 'required')

  "connect": [
    {
      "name": "QWERTY",
      "desc": "BBB",
      "interfaces": [
        {
          "name": "map_demap_interface",
          "required": true
        }  
      ]
    },
    { 
      "name": "map_connected",
      "desc": "CCC",
      "interfaces": [
        {
          "name": "map_demap_interface",
          "required": false
        },
        { 
          "name": "memory_space_interface",
          "required": true
        },
        { 
          "name": "signal_interface",
          "required": false
        }
      ]
    }
  ],

[jhbaarnh]

You could tag this with the JIRAs SIMICS-22377 and/or SIMICS-22497

I think it is a good idea, not sure which data we need to store though.

[AleksandrDanilovIntel]

You could tag this with the JIRAs SIMICS-22377 and/or SIMICS-22497

I think it is a good idea, not sure which data we need to store though.

We can create a well known list of parameters and give a user list as an option.

[peternystrom-intel]

I see how this information can be useful but it is quite a gap from generating this file to having it accessible to a user or component/blueprint designer from cli.
If we should go down this route the C++ Api will probably need something similar.

[AleksandrDanilovIntel]

I see how this information can be useful but it is quite a gap from generating this file to having it accessible to a user or component/blueprint designer from cli. If we should go down this route the C++ Api will probably need something similar.

The next step is to generate module_load.py files and add extra info commands each registered class.
Which will be automatically piked up by framework. And user will be able to see the object structure in DML terms.
Henrik suggested adding cli_name to each object in the JSON file for easier matching. It also solves the problem of conversion of the DML types into the framework primitives.
It seems to me that the C++ types are different and it would be better to display it as is. And the cli_name approach works well with C++.

[AleksandrDanilovIntel]

I moved all parameter names into a config file. Now it's much more flexible.
Adding one more example
test-subdev-dml.json