search

forsyde / IDeSyDe

Design space identification and exploration
https://forsyde.github.io/IDeSyDe
4 stars 4 forks source link

Adds hw impl area DM to large app+plat DM #30

Closed BeethovenKodar closed 5 months ago

BeethovenKodar commented 5 months ago

Adds new field in large decision model and new decision model in rust to represent the HardwareImplementationAreas DM from java-common.

BeethovenKodar commented 5 months ago

Before we merge, I removed the @JsonProperty since I did not make sense of it and it had to be reflected elsewhere in the code base. I'm not trying to say that it's not needed as I fully trust you and all that but for the time being the identification at the top level works now with the addition of processes, just that @JsonProperty("programmable_areas") is not in use. Would this be the platform's available area, or what did you think of and the nested Map<Map<String, ...>> I did not catch either so it's Map<String, Long> until I fully got this.

I converted this PR to draft until we sort it out :)

Rojods commented 5 months ago

Guided by our email conversations (@BeethovenKodar) and the previous issues + PR, I have added the relevant code in the decision model and identification rule following this exact through process.

The most correct way, i.e. general way, is that we have a Map<String, Map<String, Long>> final property available which is conceptually equivalent to having a table of putting every HW-synthesizable process into a programmable logic area. The latest proglogic commit 3c6531c follows the necessary changes to achieve this.

HOWEVER....

It is true that currently there is no difference between programmable logic areas given how it comes from the design model, i.e. ForSyDe IO. This we can resolve later and leave this PR open for the moment to remind us to dicuss it.

BeethovenKodar commented 5 months ago

I did actually provide support for multiple FPGAs so the idea of this two-level map might not be so bad after all. Also, would this nested map help with reverse identification? I was wondering about matching actor instructions to PU instructions to know if the actor had mapped to an FPGA, but if there's some neat thing we could do with the map then it would be super useful and "robust" rather than string matching.

Rojods commented 5 months ago

@BeethovenKodar the best way to go about this is to simply have a property in the "large" decision model that tracks which process was mapped to the programmable logic areas, if any. This is done for the general-programmable elements with the properties like processes_to_runtime_scheduling.

Rojods commented 5 months ago

Now we might also judge if this pull request is still relevant.

The latest commit on proglogic (beeca02a) has been merged on develop (beeca02a), which means that most (likely all) of the proposed extensions are already incorporated into the develop branch. I did this in order to free again the proglogic branch for further extensions while focusing in the exploration part at develop.

BeethovenKodar commented 5 months ago

Sounds great to me. I'll close this PR.