Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

https://github.com/AUCOHL/DFFRAM

Standard Cell Library based Memory Compiler using FF/Latch cells
https://github.com/AUCOHL/DFFRAM

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

Last synced: 2 months ago
JSON representation

Standard Cell Library based Memory Compiler using FF/Latch cells

Lists

README

        

DFFRAM Compiler



Open in Google Colab



License: Apache 2.0
CI Status
Invite to the Skywater PDK Slack
Code Style: Black

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

# ✨ Installation & Usage

See [this document](./docs/Usage.md).

You can try the
[Google Colaboratory](https://colab.research.google.com/github/Cloud-V/DFFRAM/blob/main/dffram.ipynb),
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](./docs/) for more info. The following shows how a
32x32 memory (DFF based) is constructed.

![](./docs/img/ram_ex.png)

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...
![GDS layout of a byte](./docs/img/1x8.png)

* Put four of those side by side, and you get a 32-bit word...
![GDS layout of a word](./docs/img/1x32.png)

* Stack eight of those for an 8 word bank of RAM...
![GDS layout of 8 words stacked vertically](./docs/img/8x32.png)

* And stack 4 of these 8 words for a kilobit of RAM!
![GDS layout of 4x8 words stacked vertically](./docs/img/32x32.png)

* We can keep going, but these images aren't getting any smaller. As a bonus
though, here is 64 kilobits: ![8kbytes](./docs/img/8kb_layout.png)

> 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/`](./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:
* `/`
* `/`
* `_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.


Size1
OpenRAM2
DFFRAM Compiler
DFFRAM/OpenLane
RTL/OpenLane


Dim WxH (μm) Bit Density (bits/mm2)
Dim WxH (μm) Bit Density (bits/mm2)
Dim WxH (μm) Bit Density (bits/mm2)
Dim WxH (μm) Bit Density (bits/mm2)


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

1 All support 32-bit word reads and 1, 2, and 4 bytes
writes.\
2 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

Copyright ©2020-2023 The American University in Cairo

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.