Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Technology Porting Instructions #103

Open
leochand101 opened this issue Aug 1, 2021 · 3 comments
Open

Technology Porting Instructions #103

leochand101 opened this issue Aug 1, 2021 · 3 comments
Labels
documentation Improvements or additions to documentation

Comments

@leochand101
Copy link

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

@donn
Copy link
Member

donn commented Aug 4, 2021

Hey Leo,

With the merging of #104, we've enabled this.

The general idea is, you'd want to replicate the file structure in platforms/sky130A for your PDK.

We only have two hard requirements:

Everything else is either configurable or of no consequence: we don't care about the ports of the cells, for example, and the names of the modules can be defined in https://github.com/Cloud-V/DFFRAM/blob/main/platforms/sky130A/sky130_fd_sc_hd/_building_blocks/ram/config.yml.

If you want to use dffram.py, your PDK must be supported by Open_PDKs, otherwise, you'd have to do some steps manually.

This info should be enough to start but we're planning to provide more thorough documentation in the very near future, god-willing.

@leochand101
Copy link
Author

Thanks I will look into these instructions and give it a try.

@mwongrivai
Copy link

I was wondering if you have any experience with porting to a technology without 1:1 logic mapping. I'm in the process of doing so, and it's mostly just things like not having a particular AND gate with the exact amount of inverted inputs. It's simple enough to manually add in an inverter and write extra code for placeram, but I'm encountering a bigger issue in that yosys is deciding to optimize logic away, resulting in things like entire decoders going away.

For my case, I'm running the 32x32 regfile_2R1W and am only seeing a single DEC5x32 in my synthesized netlist:

UDBLVT20_BUF_S_2 \DEC2.D1.ABUF[0]  (
UDBLVT20_BUF_S_2 \DEC2.D1.ABUF[1]  (
UDBLVT20_BUF_S_2 \DEC2.D1.ABUF[2]  (
UDBLVT20_NR4B_2 \DEC2.D1.AND0  (

So no DEC1 or DEC0 instances. This causes problems later with the d2a function and also placeram accesses the returned array with hardcoded index elements since it expects an array of [2:0].

Do you have any experience with Yosys optimizing logic out? I've tried expanding out the synth command in the yosys script as shown in the documentation:

http://www.clifford.at/yosys/cmd_synth.html

and removing all the opt_* steps, but am running into an issue when it tries to use proc because that's a namespace collision with a tcl command.

@donn donn added the documentation Improvements or additions to documentation label Feb 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

3 participants