FedorSmirnov89
commented
5 years ago 1) Please provide more details on the evaluators. What objective do they evaluate? What parts of the implementation do they access? How is the objective generated?
2) For me, there is an important issue here: Do we want the users to run explorations directly from within the opendse project? For me, the answer is no. OpenDse should be used as a dependency providing the modules for the explorations. While this has the downside that the user has to know the structure of openDse, which modules she needs, and how to connect them, this design allows us to keep the openDse project generic and cohesive.
3) A proposition of a solution for a timing evaluator. What the evaluator does (sequentially): a) go through the application, calculate the timing of each message, and annotate it into the application graph. b) Calculate the appliation end2end timing and annotate it into the application graph. c) Read the end2end timings from the graph, summarize them (sum, max, min, whatever...) and add the generated value to the objectives.
Steps a) and b) are in fact just transformers that take an implementation and annotate it. Do we have a class like that? If not, we can create a generic transformer and put it into the model-project. In your many-core project, you then can have classes which implement the generic transformer for the concrete purposes of calculating timing.
Step c) can also be implemented in a generic way. In fact, e.g., the sum evaluator that is currently in the optimization project does just that. It gets the name of an attribute and calculates the sum as an objective. On a high level, we can add evaluators that do other stuff like min, max, average, ...
For the exploration, you then create a separated project, which depends on the whole opendse (you can , of course exclude things). There, you can create modules that do the appropriate binding and enable an actual exploration. Yet, as stated above, from my perspective, this should not be part of opendse.
P.S. : It is perfectly okay to have an extra project on GitHub that depends on openDse and offers actual, out-of-the-box many-core evaluators. I just think we shouldn't stuff everything into one project
I have an issue with the integration of the opendse-manycore sub-project: As far as I can tell, opendse-optimization requires dependencies to all sub-projects that are in some way used during optimization (model, io, visualization). Since I have classes like ImplementationTransformers for manycores or NoC-based routing Encodings and Interpreters that I would like to move to the manycore subproject, opendse-optimization would also need a dependency to opendse-manycore. However, I also require opendse-optimization as a dependency of opendse-manycore, so that, e.g., my manycore-specific evaluators (that I want to move to opendse-manycore as well) can inherit from ImplementationEvaluator in opendse-optimization. This would result in a circular dependency, which is obviously not possible. So should I keep classes in inheritance hierarchies like the evaluators in opendse-optimization (maybe in a package optimization.evaluator.manycore), or can we somehow restructure the project so that I can move anything manycore-related to the sub-project to clearly separate it?