Open ElaHobby opened 3 years ago
Hi Ela,
There might be an issue here. The theory behind it is that if a block does not have many valid locations for placement, it should not be considered during the simulated annealing phase. Therefore, if a block can only be placed in a single location, it should be placed in that location and not moved. No other blocks should occupy its footprint. If you are seeing that other blocks are being placed on top of it, that is a bug. If you could, perhaps you could share an example of where this is happening and we can investigate further.
Thanks,
Chris
Hi Chris,
thanks for your answer! Below a more detailed description:
-> some modules are big and do not satisfy condition: if(hm.getValidPlacements().size() > 2). I will denote these bellow as "modules X". -> hardMacros does not contain "modules X", as they were removed after the initialPlacement. -> after Simulated Annealing completes, the algorithm goes through the elements of hardMacros in order to conduct the final placement. Module instances X are not included. -> a hashSet containing the already used tiles is created: usedTiles. Of course, in the beginning it is empty. -> each time a module instance is placed, the algorithm verifies whether its position is valid: isValidPlacement -> isValidPlacement verifies if other modules have already been placed on certain tiles by checking usedTiles. -> if the placement is valid, the corresponding tiles are inserted into usedTiles. Problem: usedTiles can never contain tiles of Modules X Problem: Modules X were already placed in the initialPlacement (I think its the line if(!hm.place(site)){, however I didn't have a closer look, I just noticed that such modules are actually placed in the final placement)
Attached is a snipped from a placed design where I observed this behavior. Some modules are overlapped.
Thanks, Ela
Hi Ela,
Sorry for the delayed response. Let me know if you have a design that exhibits this behavior that you can share with me and I can take a look.
Thanks!
Chris
@jakobwenzel - I recall you mentioning that perhaps you might have fixed this. Do you recall?
If not, let me know, I will look into my local fix. I remember I changed initialPlacement() in BlockPlacer2. I will try it out next week.
Thanks!
I think the issue is still present in the current code, exactly as Ela described:
https://github.com/Xilinx/RapidWright/blob/672e1347ec2f2985931362fddda3bb1566dbcadc/src/com/xilinx/rapidwright/placer/blockplacer/BlockPlacer2.java#L234-L241
Here, we discard all some specific modules. When doing the final placement, we only check against this hardMacros
list, not taking those other modules into account:
https://github.com/Xilinx/RapidWright/blob/master/src/com/xilinx/rapidwright/placer/blockplacer/BlockPlacer2Module.java#L163-L202
Now that I'm reading the code that prunes the list again, I'm wondering if there is another issue: I think this code is supposed to filter out modules that only have a single valid placement. Right now, it also filters out modules with exactly two valid placements. I think we do want to try and move those?
Hi!
I am not sure if my observations are correct. In my opinion lines 220-224 in BlockPlacer2.java could lead to overlapped modules. Scenario:
Consequences:
Many thanks, Ela