SRAM Placement on Small Boom Config

[Jordan McGhee]

I am currently trying to place SRAM's by hand in hammer, but I was unsure in how I should be going about choosing  a location for each of the SRAM blocks. When I had allowed hammer to choose the location (using "floorplan_mode: auto") I noticed that it would sometimes overlap with the dimensions specified for the core, which had confused me a little.

If anybody has any input or a document for me to read I would definitely appreciate it.

-Jordan

[Harrison Liew]

Macro placement is one of the tedious optimization problems in physical design. As you noticed, Innovus' auto-placer can only give you a rough placement which you can use as a guide. Google's RL-based placer (https://github.com/google-research/circuit_training) claims to exceed the quality of those auto-placers, and we're excited to see if anyone is willing to try it out with Chipyard.

For manual placement in Chipyard-generated designs, here are some guidelines:

• The compiled SRAMs (via MacroCompiler) will be in generated-src/<config>/<config>.top.mems.v. There you will find the memory instances. For now, you will need to manually trace the path to each of those modules using this and the Top Verilog (.top.v file).
• Next, note the size of each compiled SRAM macro. To do this, look in the LEF file for each memory (path can be found in the generated sram_generator-output.json file).
• Next, cluster each memory instance in a bank according to their array index. Memory instances within a bank are named like mem_0_0, mem_1_0, etc. Use the 2 indices to place them into a 2D array. Then, calculate the placement of each macro given its dimensions, leaving sufficient routing channels between each macro. For certain SRAMs that have pins only on 1 edge, you can also mirror alternating ones along an axis to abut them on the sides that have no pins to save space.
• Finally, the placement of your memory banks should be clustered relative to the logic that uses them (this takes the most exploration). For example, caches (I$, D$) should be separated (we've had good results placing them on both sides of a core). Within each cache, data and tag arrays should be placed close-ish together.

Looking ahead into the future, we're working on using aspect-oriented Chisel to encode abstract floorplan constraints and compile them down into hard, legal Hammer placement constraints. You can see the WIP in the (semi-old) dev-floorplan-new branch of Chipyard, which relies on code in the floorplan_new branch of barstools. I have an undergrad working part-time for me to clean it up at the moment.

-Harrison