aucohl / dffram Goto Github PK

By a user on slack:

We are at LVS for our full chip and running into issues:
The generated spice file for all the RAMs are missing pins for VPWR and VGND. according to LEF, we have VPWR, several VPWR.extra*, VGND, and several VGND.extra*. The spice file only lists a single VPWR.extra and VGND.extra. Similarly, the powered gate level netlist only lists VPWR and VGND.

Digest:

• .spice files are missing pins that are in the LEF
• powered glnl are missing pins that are in the LEF
• the pins are different

While we can build up 64 bit RAMs with 2 32 bit building blocks, it would be nice to have native 64 bit macros.

Looking at the output of dffram.py -s 512x32, I see one track on met5. We have a blockage on met5:

BLOCKAGES 1 ;
    - LAYER met5 RECT ( 0 0 ) ( 835820 786080 ) ;
END BLOCKAGES

But it appears to be too small, because we have a met5 track here:

      NEW met5 ( 148580 790500 ) ( 199180 * )

Shouldn't the met5 blockage match DIEAREA?

DIEAREA ( 0 0 ) ( 841340 791520 ) ;

I am trying to use the DFFRAM with my verilog design but it uses sky130_pdk cells. so my first question is how can we use sky130_pdk cells in our design simulation using verilator or Vivado.
Secondly there is no timing diagram available for DFFRAM. so, how we can know that the working of memory in terms of timing. will you please provide the behavioral model of DFFRAM.

(Allow building blocks to have dependencies on other building blocks, i.e. sky130A:ram -> sky130A:common and ensure that prflow and placeram both handle these.)

A good starting point would be this script

The idea is, it detects if antenna violations surpass an acceptable threshold.

Minor antenna violations are considered an acceptable risk and are to be ignored.

Everything below Simulating the Memory is out of date.

Blocked by #50.

Synthesis and STA reports must be checked for potential issues.

The table in https://github.com/Cloud-V/DFFRAM/tree/main/Handcrafted#hardening-the-memory is hard to understand.

I was expecting to see a table which has the DFFRAM and automatic PnR results side by side.

IE;

• 1kb ram in automatic PnR is 60% density, with DFFRAM it is 85% density.
• 1kb ram in automatic PnR is XXXum2, with DFFRAM it is YYYum2.

@ahmednofal

Currently you seem to have README.md, Readme.md and ReadMe.md - pick one form and use it consistently everywhere.

We require GDS generation among other things. Currently dffram.py replicates too much functionality that is present in OpenLane already. Beyond placement, there is no reason not to just use OL (or underlying scripts) with a specific configuration.

No dual porting either.

I'm still trying to build native 64 bit RAMs, but in the meantime I thought I'd try doubling up 32 bit RAMs. I get the following error when building a 1024x32 RAM:

dffram.py -s 1024x32
...
[INFO GRT-0101] Running extra iterations to remove overflow.
[INFO GRT-0103] Extra Run for hard benchmark.
[WARNING GRT-0164] Initial grid wrong y1 x1 [114 13], net start [114 14] routelen 15.
[ERROR GRT-0167] Invalid 2D tree for net BANK512\[0\].RAM512.BANK128\[0\].RAM128.Do0\[18\].
Error: route.tcl, 21 GRT-0167

Use Generic Building Blocks and use SCL-specific mapping files.

Are there directions for adding a new technology to the flow ?

Handcrafted is a bit of a misnomer.

While the script appears to be freely available, there's no license attached. This is a problem.

Goes to https://github.com/Cloud-V/DFFRAM/blob/main/Handcrafted/Readme.md

Call it HDL in Root

While testing out placeram in a different technology with much larger tap cell spacing than sky130, I've found that tap cells are being placed much more frequently than I was expecting. I believe it's because of this code in row.py in the place() method:

 if re.match(Row.tap_rx, instance.getName()):
            self.since_last_tap = 0

Row.tap_rx is a regexp pattern for a cell MASTER, which is then compared to the instance's name. This will never match, and self.since_last_tap will never be reset even though a tap cell gets placed. I changed it to:

 if re.match(Row.tap_rx, instance.getMaster().getName()):
            self.since_last_tap = 0

and now tap cells seem to be placed with the frequency I expect.

A few months ago I built a handcrafted 128x64 3R1W DFFRAM based register file for Microwatt. Coming back to the project now, I see a lot of work on the compiler, which is great.

Has there been any work on alternate register file formats with the compiler, or is it just 32x32 2R1W at the moment?

Use Olof's prebuilt PDK or whatever

When running dffram.py, getting TypeError with string path for pdk_root:

File "./dffram.py", line 692, in flow
prep(build_folder, pdk_root)
File "./dffram.py", line 117, in prep
pdk_root = os.path.abspath(os.path.realpath(local_pdk_root))
File "/usr/lib/python3.8/posixpath.py", line 390, in realpath
filename = os.fspath(filename)
TypeError: expected str, bytes or os.PathLike object, not NoneType

I see that the DFFRAM Overview:
https://github.com/Cloud-V/DFFRAM#overview

Says:

Different views (HDL netlist, HDL functional models, LEF, GDS, Timing, …) are all generated for a given size configuration.

After running the compiler, I don't see any GDS.

Is that the idea?
Is there some follow-up step which should be generating one?
Or is this an indication that something went wrong?