AUCOHL/DFFRAM

Placement optimisations

antonblanchard opened this issue · 2 comments

antonblanchard commented

I was looking at the results of dffram.py -s 1024x32. Firstly the default positioning of pins looks pretty bad (somewhat random):

baseline

I found the USE_IOPLACE environment variable, which does a much better job of laying out the pins, including placing the data in and out bits in the right spot:

USE_IOPLACE

Another interesting thing is the layout is quite congested towards the left and (somewhat less so) towards the top. Looking at met4:

met4

I haven't worked out why yet.

antonblanchard commented

Another observation. If I understand it correctly *.BYTE\[0\].B.BIT\[0\] is the first bit of 32 and should be grouped together at the left of the macro. Why is it in 2 separate chunks:

    - BANK128\[0\].RAM128.BLOCK\[0\].RAM32.SLICE\[0\].RAM8.WORD\[1\].W.BYTE\[0\].B.BIT\[0\].genblk1.STORAGE sky130_fd_sc_hd__dlxtp_1 + PLACED ( 2760 13600 ) N ;
    - BANK128\[0\].RAM128.BLOCK\[0\].RAM32.SLICE\[0\].RAM8.WORD\[3\].W.BYTE\[0\].B.BIT\[0\].genblk1.STORAGE sky130_fd_sc_hd__dlxtp_1 + PLACED ( 2760 19040 ) N ;
    - BANK128\[0\].RAM128.BLOCK\[0\].RAM32.SLICE\[0\].RAM8.WORD\[5\].W.BYTE\[0\].B.BIT\[0\].genblk1.STORAGE sky130_fd_sc_hd__dlxtp_1 + PLACED ( 2760 24480 ) N ;
    - BANK128\[0\].RAM128.BLOCK\[0\].RAM32.SLICE\[0\].RAM8.WORD\[7\].W.BYTE\[0\].B.BIT\[0\].genblk1.STORAGE sky130_fd_sc_hd__dlxtp_1 + PLACED ( 2760 29920 ) N ;

...

    - BANK128\[2\].RAM128.BLOCK\[2\].RAM32.SLICE\[0\].RAM8.WORD\[0\].W.BYTE\[0\].B.BIT\[0\].genblk1.STORAGE sky130_fd_sc_hd__dlxtp_1 + PLACED ( 314180 198560 ) N ;
    - BANK128\[3\].RAM128.BLOCK\[1\].RAM32.SLICE\[0\].RAM8.WORD\[0\].W.BYTE\[0\].B.BIT\[0\].genblk1.STORAGE sky130_fd_sc_hd__dlxtp_1 + PLACED ( 314180 492320 ) N ;
    - BANK128\[3\].RAM128.BLOCK\[3\].RAM32.SLICE\[0\].RAM8.WORD\[0\].W.BYTE\[0\].B.BIT\[0\].genblk1.STORAGE sky130_fd_sc_hd__dlxtp_1 + PLACED ( 314180 682720 ) N ;
    - BANK128\[2\].RAM128.BLOCK\[1\].RAM32.SLICE\[0\].RAM8.WORD\[0\].W.BYTE\[0\].B.BIT\[0\].genblk1.STORAGE sky130_fd_sc_hd__dlxtp_1 + PLACED ( 314640 103360 ) FS ;
donn commented

The placement thing was due to an OpenLane regression that required us to fall back to OpenROAD random pin placement, so I’ll update the default. The layout is congested towards the left because we start left to right, so the right side is typically padded with fills, taps, etc to fill the rest of the Core Area.

As for your other observation, the four banks are laid out in a 2x2 fashion, not 4x1. 4x1 would not route— we try to keep the aspect ratio within reasonable distance of 1:1.