Local memory slots not considered in area estimation, causing DSE to fail

[sommerlukas]

If a PE has local memories (or more than one slave interface, for that matter), DSE will still try to build more instances than will fit in the current 128 slots limit. There are several possible solutions:

1. Have separate enumeration for memory slots (affects status core, platform_info and potentially requires a more sophisticated way to determine accessibility for each PE).
2. Fix the algorithms to account for each slave interface instead of just assuming one.

Need to think about it some more; I guess, each PE will always have exactly one control slave interface. We could require a naming convention to identify it if more than one candidate is present on a PE, e.g., S_AXI_CTRL or similar. All other slave interfaces could be assigned a base address from a different pool, e.g., using the upper 64 base addresses already reserved for platform addresses. But we'd have to come up with some O(k) or at least O(n) scheme to find the base addresses of all slaves on a PE. :thinking:

[sommerlukas]

@jahofmann, @cahz: Any ideas how to solve the problem brought up by Jens, i.e. how to know how many additional slave interfaces a PE has and how to map them into the address space?

[jahofmann]

The status core needs to be reworked anyway. The slots concept doesn't really help us in any way these days and we can rather have an "unlimited" number of PEs. I imagine that might be implemented as a list of tuples like (Type, Relationship, Offset, Length).

To solve this issue before we'll rework the status core in that way we could simply have DSE check for each PE how many slave ports it has and don't try to place more than the 128 available right now.

[sommerlukas]

Ok. How should we count the slave ports? Should we use some naming convention as suggested by Jens to identify AXI4 slaves?

[sommerlukas]

@cahz: I created branch issue-30-consider-slots-in-dse for you to puish the TCL extension.

[jahofmann]

Weren't we planning on using GitFlow for those branches and their names? Just to keep naming consistent and not all over the place...

[sommerlukas]

The only official [1] naming convention for feature branches I'm aware of is:

Branch naming convention: anything except master, develop, release-, or hotfix-

[1] https://nvie.com/posts/a-successful-git-branching-model/ What would you prefer?

[jahofmann]

Well, there is somewhat of a default as used git the git flow extension to keep things nicely separated and distinguishable. It's e.g. described at https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

[sommerlukas]

@cahz: The file, to which the number of slaves port should be written, is called REPORT_PORT (TCL needle @@REPORT_PORT@@).

@jahofmann, @cahz: Does somebody have an example core with more than one slave port that we could use for testing?

[cahz]

The evaluation template now writes the number of ports to the file. As an example, you can use the RISC-V PEs. They expose a second slave port for local memory.

[sommerlukas]

b758d4fc9e3a880ebb68cabf9336527b38582f86 fixes this issue, the number of slave ports is now considered for the calculation of feasible compositions in TaPaSCo DSE.