aucohl / dffram Goto Github PK

View Code? Open in Web Editor NEW

123.0 14.0 33.0 48.08 MB

Standard Cell Library based Memory Compiler using FF/Latch cells

License: Apache License 2.0

Verilog 95.63% Makefile 0.07% Python 3.91% Tcl 0.03% Jupyter Notebook 0.33% Nix 0.03%

verilog vlsi vlsi-physical-design vlsi-circuits electronics-design asic-design

dffram's Introduction

DFFRAM Compiler

Standard Cell Library based Memory Compiler using DFF/Latch cells.

✨ Installation & Usage

See this document.

You can try the Google Colaboratory, but it is a bit out-of-date at this point.

Platform Support Status

Configured Platform	Working	Silicon-proven*
`sky130A`	Yes	Yes
`sky130B`	Yes	No
`gf180mcuD`	No* (Hold violations in the Netlist)	No

* Silicon proven does not imply that you should use it without whole-system, timing-annotated simulation to make sure that it works for your circuit.

There may be design-specific complications that may render DFFRAM (and indeed the entire chip) unusable. Proceed with caution.

Overview

The objective of this project is to develop a DFF/Latch-based RAM, Register File and Cache custom compilation flow that utilizes standard cell libraries following a standard ASIC (Application Specific Integrated Circuit) implementation approach. Different views (HDL netlist, HDL functional models, LEF, GDS, Timing, …) are all generated for a given size configuration.

The layout targets highly compact designs (85%+) as the cells are placed on the floor plan using a custom placer. Moreover, the custom placer ensures that the routing will be relatively simple. Currently, the compiler uses OpenROAD routers to route the macros with great success.

The Compiler relies on basic building blocks to construct the layout of different RAM/RF/Cache configurations. Check the compiler documentation for more info. The following shows how a 32x32 memory (DFF based) is constructed.

The generated layouts by the DFFRAM compilers for RAM32 as well as its building blocks are as follows:

First, a byte, which is just 8 bits placed together...
Put four of those side by side, and you get a 32-bit word...
Stack eight of those for an 8 word bank of RAM...
And stack 4 of these 8 words for a kilobit of RAM!
We can keep going, but these images aren't getting any smaller. As a bonus though, here is 64 kilobits:

That stuff you see on the right of each image? It's clock gates, decoders and the like. Don't worry about it.

Currently, the can compiler generate the layout of the following configurations:

1RW1R variants are temporarily disabled due to a bug.

RAM
- 32 words with byte write enable (1RW and 1RW1R).
- 128 words with byte write enable (1RW and 1RW1R).
- 256 words with byte write enable (1RW and 1RW1R).
- 512 words with byte write enable (1RW and 1RW1R).
- 1024 words with byte write enable (1RW and 1RW1R).
- 2048 words with byte write enable (1RW and 1RW1R).
Register File
- 32 x 32-bit words (2R1W)

The OpenLane/ folder will contain good known OpenLane configurations to build DFFRAM different macros.

File Structure

.github contains files for GitHub actions.
docs/ contains documentation (😮)
rtl/ contains RTL RAM file generators for benchmarking and comparison purposes.
platforms/ contains PDK-specific files:
- <pdk-name>/
  - <scl-name>/
    - _building_blocks/ contains a hierarchy of building blocks supported by the compiler.
placeram/ is the custom placer Python module.
scripts/ has assisting scripts used by the flow.
dffram.py is the compilation flow going from building blocks to LVS.

Comparisons

The following table compares the areas and bit densities of RAM macros generated using different means.

Size¹	OpenRAM²		DFFRAM Compiler		DFFRAM/OpenLane		RTL/OpenLane
Size¹	Dim WxH (μm)	Bit Density (bits/mm²)	Dim WxH (μm)	Bit Density (bits/mm²)	Dim WxH (μm)	Bit Density (bits/mm²)	Dim WxH (μm)	Bit Density (bits/mm²)
512 bytes	N/A	N/A	396.52 x 388.96	26,557	527.46 x 527.46	14,722	680.25 x 690.97	8,714
1 kbytes	386 x 456	46,541	792.58 x 397.12	26,027	975.01 x 985.73	8,523	1,050 x 1,060	7,360
2 kbytes	659.98 x 398.18	62,372	792.58 x 786.08	26,297	1374.46 x 1385.18	8,605	1,439.615 x 1,450.335	7,847
4 kbytes	670.86 x 651.14	75,014	1,584.24 x 788.8	26,196	1940.45 x 1951.17	8,654	2,074 x 2,085	7,578
8 kbytes	N/A	N/A	1,589 x 1,572	26,229	TBD	TBD	2,686.610 x 2,697.330	9,043

¹ All support 32-bit word reads and 1, 2, and 4 bytes writes.
² Values are based on the original layout produced by the compiler. OpenRAM macros are typically wrapped to be useful w/ automated PnR ASIC flows.

⚖️ Copyright and Licensing

Licensed under the Apache License, Version 2.0 (the "Open Source License"); you may not use this file except in compliance with the Open Source License. You may obtain a copy of the Open Source License at the root of this repository (see the file 'License') or at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the Open Source License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the Open Source License for the specific language governing permissions and limitations under the Open Source License.

dffram's People

Stargazers

Watchers

dffram's Issues

Address Antenna Issues

STA >= 256 fails

Example workflow image in README.md is broken

Investigate Empty Space In Designs

>=128 words not working with current RAM, only legacy

No dual porting either.

DFFRAM Behavioral Model

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.

Tracks on met5

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 ) ;

update lvs using magic due to magic netlist extraction update

Generate and Characterize Lib Files

DFFRAM dual ported prflow > 32 support

Fix CI in `dir_restructure`

Use Olof's prebuilt PDK or whatever

insert diodes before each flip flop (dffram) for antenna violations

Verify the newly added RAM modules as well as the parameterized RFile

Cache Support

GDS Output?

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?

Specify clock period statically for each design variant

Technology Porting Instructions

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

Move `pdk/` somewhere under `sky130A`

Dual ported and single ported should have separate pin order config files.

row.py placing a tap cell does not correctly reset self.since_last_tap attribute

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.

Add missing sizes to dual-ported RAM

Blocked by #50.

Update Technical Documentation

Refactor/Normalize Building Blocks + Model BB dependency

(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.)

depend on magic drc check instead of TritonRoute

A good starting point would be this script

Rename Handcrafted -> Openlane

Handcrafted is a bit of a misnomer.

String error in dffram.py

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

Introduce synthesis and STA to CI testing.

Synthesis and STA reports must be checked for potential issues.

Use consistent naming for README files

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

Handcrafted Readme is Out-of-date

Everything below Simulating the Memory is out of date.

Add linting using google's verible

Move /pdk to Verification directory

@ahmednofal

Register File Not Working

Add Verification for 1024x, 2048x

Move Building Blocks Outside the Compiler

Call it HDL in Root

Move as much of the flow as possible to OpenLane

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.

Global routing hits "Invalid 2D tree" error

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

Pin mismatch between LEF and Spice/GLNL

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: