unable to generate fakeram for sky130

[vijayank88]

I'm using following test130.cfg to generate fakeram.

{
  # The process node. This is used to tell cacti what technology to use when
  # estimating power, performance and area numbers.
  "tech_nm": 130,

  # The operating voltage.
  "voltage": 1.8,

  # String to add in front of every metal layer number for the layer name.
  "metalPrefix": "met",

  # The pin width for signal pins.
  "pinWidth_nm": 800,

  # The minimum pin pitch for signal pins (all pins will have a pitch that is a
  # multuple of this pitch. The first pin will be a multiple of this pitch from
  # the bottom edge of the macro too.
  "pinPitch_nm": 1700,

  # Optional: snap the width and height of the sram to a multiple value.
  "snapWidth_nm":  190,
  "snapHeight_nm": 1400,

  # Flips the pin orientations. Non-fliped assumes metal1 is vertical therefore
  # supply pins on metal4 will be horizontal and signal pins will also be on
  # metal4. If set to true, supply pins on metal4 will be vertical and signal
  # pins will be on metal3.
  "flipPins": true,

  # List of SRAM configurations (name, width, depth, and banks)
  "srams": [
    {"name": "fakeram130_80x64", "width": 80, "depth":  64, "banks": 1},
    {"name": "fakeram130_128x256", "width":  128, "depth": 256, "banks": 1},
    {"name": "fakeram130_44x64", "width":  44, "depth": 64, "banks": 1},
    {"name": "fakeram130_64x256", "width":  64, "depth": 256, "banks": 1}
  ]
}

command used:

make run CONFIG=example_cfgs/test130.cfg

Stopped with below error

Error: not enough tracks (num pins: 249, available tracks: 130).
make: *** [Makefile:8: run] Error 1

Expected behavior: Generate fakeram for test130.cfg

[csamudra]

Hello, I am seeing a similar issue when using the following settings in SKY130

pinPitch_nm: 920, name": "fakeram130_256x64", "width": 64, "depth": 256, "banks": 1

I understand that the height is not enough to fit all the tracks required by the pin pitch. It works when the pin pitch is reduced but we want it to be set to 920 (==2Xmetal pitch)

Is there a way around this ?

[taylor-bsg]

@derekcom17 @stdavids

[derekcom17]

One work around would be to use the "snapHeight_nm" setting to force the sram to be tall enough to hold all the pins. But this is kind of a hack, and would also force all other srams to snap to this height. (Since it is a global setting within a config file.) I tested this, and got it to work with these settings:

  "pinPitch_nm": 920,
  "snapHeight_nm": 210000,
  "srams": [
    {"name": "fakeram130_256x64", "width": 64, "depth": 256, "banks": 1}
  ]

It's reasonable that instead, we add a new boolean setting that allows the sram to become taller to accommodate all pins at the requested pitch. I should have time to work on that in the next few days if you all think that is a good fix!

[taylor-bsg]

In that example what is the calculated height and width of the sram? How are the address and data pins arranged?

On Fri, Jul 8, 2022 at 1:38 PM derekcom17 @.***> wrote:

One work around would be to use the "snapHeight_nm" setting to force the sram to be tall enough to hold all the pins. But this is kind of a hack, and would also force all other srams to snap to this height. (Since it is a global setting within a config file.) I tested this, and got it to work with these settings:

"pinPitch_nm": 920, "snapHeight_nm": 210000, "srams": [ {"name": "fakeram130_256x64", "width": 64, "depth": 256, "banks": 1} ]

It's reasonable that instead, we have a boolean setting that allows the sram to become taller to accommodate all pins at the requested pitch. I should have time to work on that in the next few days if you all think that is a good fix!

— Reply to this email directly, view it on GitHub https://github.com/bespoke-silicon-group/bsg_fakeram/issues/13#issuecomment-1179343718, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFG5AEJEVT4IKB7LXJT64DVTCGWDANCNFSM5K7IUM2A . You are receiving this because you commented.Message ID: @.***>

[derekcom17]

Looks like the original height was 161um. So the ram area grew by 1.3x to fit all the pins.

I believe the pins are always arranged as they are in this image. With all pins on the left.

We could work on a more efficient pin layout as well.

Or, we could add the option to disable the write mask so there are fewer pins if we don't need them.

[mithro]

FYI - I have a doc @ https://docs.google.com/spreadsheets/d/1TJrGuujPSOE9CAxwnf8IQg4X_veLV4QahXvGOfsVLK4/edit#gid=0 which tracks the actual sizes achieved on SKY130.

[derekcom17]

Sorry no update for a while on this one...

Now that we got a chance to take a closer look at this, we realized that the example sky130 parameters in sky130.cfg were kind of wrong. In the most recent commit set more realistic values for that file. (We also added a fix so that the pin width can be reduced to 300nm without violating DRC.)

If you use the new config, then I believe the 4 SRAMs from the original issue post can now be built!

As far as the 920nm pin pitch goes, I don't think there is an elegant way to do that. The pins just don't fit if they are spaced so far apart. My understanding is, in typical SRAM generators (I mean non-fake ones) that you don't get to set the pin pitch or width or position at all. If you absolutely need that pitch because you have some interface you need it to align with, then you could still do the "super-snap" hack from above. But you will be wasting area in your design.

[csamudra]

Thanks a lot @derekcom17 and others.

//then you could still do the "super-snap" hack from above Got that. Just a follow up then, if we use the hack, we get a very fat macro with dimensions: SIZE 1010.160 BY 210.000.

Does that make sense or are we doing something wrong ? If it does make sense, then is there any way around that ?

Apologies if this is a trivial question. Thanks again.

[derekcom17]

That size lines up with what I see. The original ram size (before any snapping) is 1009.78um wide by 159.937um deep.

That size (and all the other sram properties) are generated by the cacti program. I am not familiar with the inner workings of cacti, so I am not sure exactly how it calculated these SRAM dimensions.

I guess you also may have the option to instantiate 2 SRAMS parallel (each with half the data width). Looks like a w32_d256 sram is only 294x348 um. So if you instantiate 2, there will still be some extra area needed, but all the pins will fit correctly in that case.