mpl2 algorithm and io constraints

[oharboe]

I'm looking forward to taking mpl2 for a spin on mock-array-big(there's an assert I've reported, that I'm sure will be fixed before long.)

Concerning the algorithm of mpl2: does it consider the IO pins and how they are connected to other macros?

In the case of mock-array-big, there can be no doubt that the best layout is a grid. There are quite a few macros in that design (8x8 in an array). It is easily possible to reduce or increase the datapath width of the mock-array-big as well as change the layout of the array to pretty much any M x N.

At the top level of another design I'm interested in, the situation is similar, even if it is not an array.

I don't expect there to be much doubt as to how the 4 large macros can be organized as macro io pin constraints have placed pins on edges. Afterwards there really is only one way the macros can be placed. If you get one macro placement wrong, you have an enormous amount of routing that needs to be done for all the pins.

The number of macros is 4 or so all that is needed is to have some sense of how much space is needed in the routing channel between the macros.

The advantage of automatic macro placement is to reduce the amount of brittle Tcl I have to write during architectural exploration. Writing Tcl to place macros is VERY time consuming at the top level, even with mock abstracts. Mock abstracts is where you skip CTS and routing to work only on higher level floorplanning and routing. To generate a mock abstract, run: make skip_cts skip_route generate_abstract

[oharboe]

I have tried mpl2 on mock-array-big, but it crashes.