I use the Local Installer

[donnie-j]

Prompt

As per the installer log message: [ALERT] The local installer is deprecated and will be removed in a future version of OpenLane.
If you're still using it, please file an issue at https://github.com/The-OpenROAD-Project/OpenLane/issues.

Proposal

We use a set of simple scripts to create Devuan (Debian) installs. We intend to publish .deb packages and recipes shortly (lack of time is all). This works very well, and is a part of our production workflow.

[donn]

I see. Thank you for the info- this is exactly why I added that warning, to gauge whether anybody was actually using the local installer in any capacity.

I want a more unified way of running OpenLane in the future- currently, there are way too many hacks, environment variables, or what have you to enable both Docker and the local installer to work. This isn't in the immediate future, but when I do start, I would appreciate input from your team on said "new way" of running OpenLane.

[donnie-j]

Thanks for that, happy to engage. We try to track mainline development, and I did notice that something has gone wrong with environment variables between our last known good OpenLane 30f87f5 and tip of tree.

No one has had time to look into if it's our locally carried (mostly VHDL, but also use of locally installed tools instead of OpenLane built versions) patches. I'll try and have a look and maybe bisect over the next few days.

[monibahmed]

Hi, I’m looking to use the local installer, however in this environment it may not be possible to sudo. Can we point to local install via a Conda Prefix of the tools? Ideally I would just use the flow part of OpenLane and not the tool installers.

Thanks

[donnie-j]

Hi, I’m looking to use the local installer, however in this environment it may not be possible to sudo. Can we point to local install via a Conda Prefix of the tools? Ideally I would just use the flow part of OpenLane and not the tool installers.

This is essentially what we do, patching out the need for sudo and disabling it installing (almost) any tools. We have a layered build, some developers doesn't need the whole flow that the engineers do.

It still does the Conda dance, but that's sorta ok, and from what I've seen version sensitive. OpenLane installer basically 'installs' itself in place, so our scripts clone OpenLane into a share directory, and then make a (few) symlinks to the tool flow install bin etc. This has worked well for our use, including for DFFRAM (which makes less assumptions than we feared).

The scripts, driven by flow.tcl, are the real magic here from our perspective... Our patches really reflect a different philosophy and requirement set, they don't change the operation of OpenLane (much).

[monibahmed]

Sorry, maybe I misread somewhere about .deb package installs (these don’t require sudo?) Is there a branch I can beta test the proposed local install with?

[donnie-j]

Installing locally as root system wide doesn't require sudo, so it's the same as local to the user. That lets us patch out the need for sudo generally in the OpenLane installer.

I should probably publish our (very very simple, or should I say straight forward) from minimal clean Debian system install shell scripts ahead of making a Debian repo for apt. Give me a day or two...

[monibahmed]

Hi, any update on this?

[proppy]

@donnie-j @monibahmed also interested about this discussion in the context of hdl/conda-eda#244 hdl/conda-eda#245 and streamlining installation of OpenLane in jupyter notebook, see https://github.com/chipsalliance/silicon-notebooks.

We got most of the dependencies of OpenLane packages in https://github.com/hdl/conda-eda/ (openroad, yosys, netgen, magic, open_pdks) and we can run flow.tcl assuming the following is set:

RUN_KLAYOUT=0 # because klayout is not yet packaged
RUN_CVC=0 # because cvc is not yet packaged
PDK_ROOT=$CONDA_PREFIX/share/pdk # to point to conda installed pdks
PDK=sky130A
STD_CELL_LIBRARY=sky130_fd_sc_hd
STD_CELL_LIBRARY_OPT=sky130_fd_sc_hd

And pass -ignore_mismatches to flow.tcl since the versions currently don't match.

[monibahmed]

@proppy, Thanks for this. I'll check out Conda-EDA. Most of the tools are also in litex-hub that can be installed using Conda, so it gives a really nice encapsulation of all the tools and versions using environments. It would be ideal to use Conda environments, since we don't have sudo access in our production Linux environments.

[proppy]

It would be ideal to use Conda environments, since we don't have sudo access in our production Linux environments.

@monibahmed I'm experimenting with creating a custom conda installer (using https://github.com/conda/constructor/), that bundle openlane + dependencies + sky130 pdk:

curl -L -O https://github.com/proppy/conda-eda/releases/download/v0.0-1358-g4ea08b3/openlane-sky130a-0-Linux-x86_64.sh
bash openlane-sky130a-0-Linux-x86_64.sh -b -p silicon-env/
source silicon-env/bin/activate 
flow.tcl -design inverter

Feel free to comment on the PR hdl/conda-eda#247 if you have any feedback.

[donnie-j]

Sorry for the long delay. Here is a link to the scripts, now forward ported to the latest OpenLane and Open PDKs, that we use to build installs of all the tools for (J-Core CPU/SoC) chip design.

https://github.com/j-core/openlane-vhdl-build

Notes:

• Builds J-Core (SuperH 'plus') compilers and Linux development environment also

• Assumes either a clean, nothing added, minimal Debian install. Either debootstrap or bare metal

• Integrates GHDL for VHDL into the OpenLane flow with as few changes as necessary

• Builds and installs tools itself, turning off as much Volare machinery as possible

• That is because we use the tools outside of an OpenLane context as well

• iCE40 FPGA tools are also installed, to allow hardware testing of designs on low cost platforms

• Just straight forward shell scripts, a good way to see what is actually needed

• 00 installs pre-requisites for all the tools assuming a clean devuan (Debian) machine install

• 01 - 03 also work on MacOS, with small tweaking (e.g. MacOS uses clang instead of gcc)

• We have native OpenROAD OpenLane on Mac OS X also, but it's about 9mo old.

There is little error checking, but we have been using versions of these scripts to install tools for quite some time. Some of our folks just use compilers, some just simulate... you don't need to run all the install scripts if you don't need the tools they install.