search

forsyde / IDeSyDe

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

Only hardware implementations cannot be explored #32

Closed BeethovenKodar closed 6 months ago

BeethovenKodar commented 6 months ago

Only instrumenting hardware implementations do not identify the AperiodicAsynchronousDataflowToPartitionedMemoryMappableMulticoreAndPL used for exploration.

I suspect that the identification of the above fails due to InstrumentedMemoryRequirements and InstrumentedComputationTimes being absent (and the combined 'large' decision model).

I'm not sure how to solve the issue, as the decision models above that are absent must likely be optional in the 'large' decision model.

Output:

...
identified categories: SDFApplication, MM_MCoreAndPL, MemoryMappableMultiCore, HardwareImplementationArea,
RuntimesAndProcessors, SharedMemoryMultiCore, PartitionedCoresWithRuntimes, SDFApplicationWithFunctions, 
PartitionedSharedMemoryMultiCore, PartitionedMemoryMappableMulticore, PartitionedMemoryMappableMulticoreAndPL, 
AnalysedSDFApplication, SDFToPartitionedSharedMemory, AsynchronousAperiodicDataflow
...
Acquired 0 dominant bidding(s) out of 0 bidding(s)

Input files: evaluatorsdf.txt mpsoc.txt

Rojods commented 6 months ago

Holy crud. You are right. I will think a workaround for this. I think it wouldn't break much if I would always identify the instrumentation decision models as long as the "later' identification rules make sure that they are putting together valid larger decision models. I will see of doing this in the next days :)

Rojods commented 6 months ago

I think the issue has been fixed with commit #575b523dc347b61e24e3b55d6e90fdb3a3fb6b43 of develop! Try it out to see if it works :). All the other test that I have are still passing, so I suppose I have no broken any of my previous assumptions by simply producing the instrumentation decision models.

BeethovenKodar commented 6 months ago

I got the results now, thanks for the swift fix!

On a side note: the rust module crashes via minizinc if the area and/or bram constraints are violated but if both are satisfied it's fine. For my part, this is not a necessary fix, just a heads up if you think it's important for completeness.

Rojods commented 6 months ago

the crash has been continued in the issue #34