Giter Club home page Giter Club logo

iic-jku / iic-osic-tools Goto Github PK

View Code? Open in Web Editor NEW

This project forked from efabless/foss-asic-tools

240.0 7.0 40.0 108.17 MB

IIC-OSIC-TOOLS is an all-in-one Docker image for SKY130/GF180/IHP130-based analog and digital chip design. AMD64 and ARM64 are natively supported.

License: Apache License 2.0

Shell 6.68% Python 65.90% Dockerfile 0.35% Awk 0.06% Ruby 1.71% Tcl 0.18% Scheme 0.17% Batchfile 0.29% Makefile 0.22% C 15.80% MATLAB 0.23% HTML 1.36% Gnuplot 0.04% CMake 0.38% C++ 1.61% CSS 0.05% JavaScript 0.06% Cython 4.87% Verilog 0.03%
analog-design circuits digital-design ic microelectronics mixed-signal-chips

iic-osic-tools's Introduction

IIC-OSIC-TOOLS

This environment is based on the efabless.com FOSS-ASIC-TOOLS.

IIC-OSIC-TOOLS is an all-in-one Docker container for open-source-based integrated circuit designs for analog and digital circuit flows. The CPU architectures x86_64/amd64 and aarch64/arm64 are natively supported based on Ubuntu 22.04LTS (since release 2022.12). This collection of tools is curated by the Institute for Integrated Circuits (IIC), Johannes Kepler University (JKU).

Table of Contents

1. How to Use These Open-Source (and Free) IC Design Tools

It supports two modes of operation:

  1. Using a complete desktop environment (XFCE) in Xvnc (a VNC server), either directly accessing it with a VNC client of your choice or the integrated noVNC server that runs in your browser.
  2. Using a local X11 server and directly showing the application windows on your desktop.

1.1 Step 1: Clone/download this GitHub repository onto your computer

Use the green Code button, and either download the zip file or do a git clone --depth=1 https://github.com/iic-jku/iic-osic-tools.git.

1.2 Step 2: Install Docker on your computer

See instructions on how to do this in the section Quick Launch for Designers further down in this README.

1.3 Step 3: Start and Use a Docker Container based on our IIC-OSIC-TOOLS Image

Enter the directory of this repository on your computer, and use one of the methods described in the section Quick Launch for Designers to start up and run a Docker container based on our image. The easiest way is probably to use the VNC mode.

If you do this the first time, or we have pushed an updated image to DockerHub, this can take a while since the image is pulled (loaded) automatically from DockerHub. Since this image is ca. 4GB, this takes time, depending on your internet speed. Please note that this compressed image will be extracted on your drive, so please provide at least 20GB of free drive space. If, after a while, the consumed space gets larger, this may be due to unused images piling up. In this case, delete old ones; please consult the internet for instructions on operating Docker.

If you know what you are doing and want full root access without a graphical interface, please use ./start_shell.sh.

2. Installed PDKs

As of the 2022.12 tag, the following open-source process-development kits (PDKs) are pre-installed, and the table shows how to switch by setting environment variables (you can do this per project by putting this into .designinit as explained below):

SkyWater Technologies sky130A
export PDK=sky130A
export PDKPATH=$PDK_ROOT/$PDK
export STD_CELL_LIBRARY=sky130_fd_sc_hd
Global Foundries gf180mcuC
export PDK=gf180mcuC
export PDKPATH=$PDK_ROOT/$PDK
export STD_CELL_LIBRARY=gf180mcu_fd_sc_mcu7t5v0
IHP Microelectronics sg13g2
Not yet ready to use

More options for selecting digital standard cell libraries are available; please check the PDK directories.

3. Installed Tools

Below is a list of the current tools already installed and ready to use (note there are some adaptions in our container vs. efabless.com):

  • amaranth a Python-based HDL toolchain
  • cace a Python-based circuit automatic characterization engine
  • cocotb simulation library for writing VHDL and Verilog test benches in Python
  • covered Verilog code coverage
  • cvc circuit validity checker (ERC)
  • edalize Python abstraction library for EDA tools
  • fusesoc package manager and build tools for SoC
  • gaw3-xschem waveform plot tool for xschem
  • gdsfactory Python library for GDS generation
  • gdspy Python module for the creation and manipulation of GDS files
  • gds3d a 3D viewer for GDS files
  • gf180mcu GlobalFoundries 180nm CMOS PDK
  • ghdl VHDL simulator
  • gtkwave waveform plot tool for digital simulation
  • sg13g2 IHP Microelectronics 130nm SiGe:C BiCMOS PDK (partial PDK, not fully supported yet; xschem and ngspice simulation works incl. PSP MOSFET model)
  • irsim switch-level digital simulator
  • iverilog Verilog simulator
  • hdl21 analog hardware description library
  • klayout layout viewer and editor for GDS and OASIS
  • libman design library manager to manage cells and views
  • magic layout editor with DRC and PEX
  • netlistsvg draws an SVG netlist from a yosys JSON netlist
  • netgen netlist comparison (LVS)
  • ngspice SPICE analog and mixed-signal simulator, with OSDI support
  • ngspyce Python bindings for ngspice
  • nvc VHDL simulator and compiler
  • open_pdks PDK setup scripts
  • openlane2 rewrite of OpenLane in Python, 2nd generation
  • openram OpenRAM Python library
  • openroad RTL2GDS engine used by openlane2
  • osic-multitool collection of useful scripts and documentation
  • padring padring generation tool
  • pyopus simulation runner and optimization tool for analog circuits
  • pyrtl collection of classes for pythonic RTL design
  • pyspice interface ngspice and xyce from Python
  • pyverilog Python toolkit for Verilog
  • RF toolkit with FastHenry2, FasterCap, openEMS, and scikit-rf.
  • qucs-s simulation environment with RF emphasis
  • rggen code generation tool for configuration and status registers
  • schemdraw Python package for drawing electrical schematics
  • spyci analyze/plot ngspice/xyce output data with Python
  • slang SystemVerilog parsing and translation (e.g. to Verilog)
  • synlig SystemVerilog plugin for yosys
  • vlog2verilog Verilog file conversion
  • volare version manager (and builder) for open-source PDKs
  • siliconcompiler modular build system for hardware
  • sky130 SkyWater Technologies 130nm CMOS PDK
  • verilator fast Verilog simulator
  • vlsirtools interchange formats for chip design.
  • xschem schematic editor
  • xyce fast parallel SPICE simulator (incl. xdm netlist conversion tool)
  • yosys Verilog synthesis tool (with GHDL plugin for VHDL synthesis), incl. eqy (equivalence checker), sby (formal verification), and mcy (mutation coverage)

The tool versions used for OpenLane2 (and other tools) are documented in tool_metadata.yml. In addition to the EDA tools above, further valuable tools (like git) and editors (like gvim) are installed. If something useful is missing, please let us know!

4. Quick Launch for Designers

Download and install Docker for your operating system:

Note for Linux: Do not run docker commands or the start scripts as root (sudo)! Follow the instructions in Post-installation steps for Linux

The following start scripts are intended as helper scripts for local or small-scale (single instance) deployment. Consider starting the containers with a custom start script if you need to run many instances.

4.1 Customizing Environment

All user data is persistently placed in the directory pointed to by the environment variable DESIGNS (the default is $HOME/eda/designs for Linux/macOS and %USERPROFILE%\eda\designs for Windows, respectively).

If a file .designinit is put in this directory, it is sourced last when starting the Docker environment. In this way, users can adapt settings to their needs.

4.2 Using VNC and noVNC

This mode is recommended for remote operation on a separate server or if you prefer the convenience of a full desktop environment. To start it up, you can use (in a Bash/Unix shell):

./start_vnc.sh

On Windows, you can use the equivalent batch script (if the defaults are acceptable, it can also be started by double-clicking in Explorer):

.\start_vnc.bat

You can now access the Desktop Environment through your browser (http://localhost). The default password is abc123.

4.2.1 Variables for VNC

Both scripts will use default settings, which you can tweak by settings shell variables (VARIABLE=default is shown):

  • DRY_RUN (unset by default); if set to any value (also 0, false, etc.), the start scripts print all executed commands instead of running. Useful for debugging/testing or just creating "template commands" for unique setups.
  • DESIGNS=$HOME/eda/designs (DESIGNS=%USERPROFILE%\eda\designs for .bat) sets the directory that holds your design files. This directory is mounted into the container on /foss/designs.
  • WEBSERVER_PORT=80 sets the port on which the Docker daemon will map the webserver port of the container to be reachable from localhost and the outside world. 0 disables the mapping.
  • VNC_PORT=5901 sets the port on which the Docker daemon will map the VNC server port of the container to be reachable from localhost and the outside world. This is only required to access the UI with a different VNC client. 0 disabled the mapping.
  • DOCKER_USER="hpretl" username for the Docker Hub repository from which the images are pulled. Usually, no change is required.
  • DOCKER_IMAGE="iic-osic-tools" Docker Hub image name to pull. Usually, no change is required.
  • DOCKER_TAG="latest" Docker Hub image tag. By default, it pulls the latest version; this might be handy to change if you want to match a specific version set.
  • CONTAINER_USER=$(id -u) (the current user's ID, CONTAINER_USER=1000 for .bat) The user ID (and also group ID) is especially important on Linux and macOS because those are the IDs used to write files in the DESIGNS directory. For debugging/testing, the user and group ID can be set to 0 to gain root access inside the container.
  • CONTAINER_GROUP=$(id -g) (the current user's group ID, CONTAINER_GROUP=1000 for .bat)
  • CONTAINER_NAME="iic-osic-tools_xvnc_uid_"$(id -u) (attaches the executing user's id to the name on Unix, or only CONTAINER_NAME="iic-osic-tools_xvnc for .bat) is the name that is assigned to the container for easy identification. It is used to identify if a container exists and is running.

To overwrite the default settings, see Overwriting Shell Variables

4.3 Using a Local X-Server

This mode is recommended if the container is run on the local machine. It is significantly faster than VNC (as it renders the graphics locally), is more lightweight (no complete desktop environment is running), and integrates with the desktop (copy-paste, etc.). To start the container, run the following:

./start_x.sh

or

.\start_x.bat

Attention Windows and macOS users: The X-server connection is automatically killed if there is a too-long idle period in the terminal (when this happens, it looks like a crash of the system). A workaround is to start a second terminal from the initial terminal that pops up when executing the start scripts ./start_x.sh or .\start_x.bat and then start htop in the initial terminal. In this way, there is an ongoing display activity in the initial terminal, and as a positive side-effect, the usage of the machine can be monitored. We are looking for a better long-term solution.

Attention macOS users: Please disable the Enable VirtioFS accelerated directory sharing setting available as "Beta Setting," as this will cause issues accessing the mounted drives! However, enabling the VirtioFS general setting works in Docker >v4.15.0!

4.3.1 Variables for X11

The following environment variables are used for configuration:

  • DRY_RUN (unset by default), if set to any value (also 0, false, etc.), makes the start scripts print all executed commands instead of running. Useful for debugging/testing or just creating "template commands" for unique setups.
  • DESIGNS=$HOME/eda/designs (DESIGNS=%USERPROFILE%\eda\designs for .bat) sets the directory that holds your design files. This directory is mounted into the container on /foss/designs.
  • DOCKER_USER="hpretl" username for the Docker Hub repository from which the images are pulled. Usually, no change is required.
  • DOCKER_IMAGE="iic-osic-tools" Docker Hub image name to pull. Usually, no change is required.
  • DOCKER_TAG="latest" Docker Hub image tag. By default, it pulls the latest version; this might be handy to change if you want to match a specific Version set.
  • CONTAINER_USER=$(id -u) (the current user's ID, CONTAINER_USER=1000 for .bat) The user ID (and also group ID) is especially important on Linux and macOS because those are the IDs used to write files in the DESIGNS directory.
  • CONTAINER_GROUP=$(id -g) (the current user's group ID, CONTAINER_GROUP=1000 for .bat)
  • CONTAINER_NAME="iic-osic-tools_xserver_uid_"$(id -u) (attaches the executing user's id to the name on Unix, or only CONTAINER_NAME="iic-osic-tools_xserver for .bat) is the name that is assigned to the container for easy identification. It is used to identify if a container exists and is running.

4.3.2 macOS and Windows-specific Variables

For Mac and Windows, the X11 server is accessed through TCP (:0, aka port 6000). To control the server's address, you can set the following variable:

  • DISP=host.docker.internal:0 is the environment variable that is copied into the DISPLAY variable of the container. host.docker.internal resolves to the host's IP address inside the docker containers, :0 corresponds to display 0 which corresponds to TCP port 6000.

If the executable xauth is in PATH, the startup script automatically disables access control for localhost, so the X11 server is open for connections from the container. A warning will be shown if not, and you must disable access control.

4.3.3 Linux-specific Variables

For Linux, the local X11 server is accessed through a Unix socket. There are multiple variables to control:

  • XSOCK=/tmp/.X11-unix is typically the default location for the Unix sockets. The script will probe if it exists and, if yes, mount it into the container.
  • DISP has the same function as macOS and Windows. It is copied to the container's DISPLAY variable. If it is not set, the value of DISPLAY from the host is copied.
  • XAUTH defines the file that holds the cookies for authentication through the socket. If it is unset, the host's XAUTHORITY contents are used. If those are unset too, it will use $HOME/.Xauthority.

The defaults for these variables are tested on native X11 servers, X2Go sessions, and Wayland. The script copies and modifies the cookie from the.Xauthority file into a separate, temporary file. This file is then mounted into the container.

4.3.4 Installing X11-Server

Everything should be ready on Linux with a desktop environment / UI (this setup has been tested on X11 and XWayland). For Windows and macOS, the installation of an X11 server is typically required. Due to the common protocol, every X11-server should work, although the following are tested:

  • For Windows: VcXsrc
  • For macOS: XQuartz Important: Please enable "Allow connections from network clients" in the XQuartz preferences [CMD+","], tab "Security"

For both X-Servers, it is strongly recommended to enable OpenGL:

  • The start_x.sh script will take care of that on macOS and set it according to configuration values. Only a manual restart of XQuartz is required after the script is run once (observe the output!).

  • On Windows with VcXsrv, we recommend using the utility "XLaunch" (installed with VcXsrv):

    • Multiple windows mode
    • Set the Display Number to 0
    • Start no client
    • Tick all Extra settings: Clipboard, Primary selection, Native opengl, and Disable access control

4.4 Overwriting Shell Variables

4.4.1 For the Linux/macOS Bash Scripts

There are multiple ways to configure the start scripts using Bash. Two of them are shown here. First, the variables can be set directly for each run of the script; they are not saved in the active session:

DESIGNS=/my/design/directory DOCKER_USERNAME=another_user ./start_x.sh

The second variant is to set the variables in the current shell session (not persistent between shell restarts or shared between sessions):

export DESIGNS=/my/design/directory
export DOCKER_USERNAME=another_user
./start_x.sh

As those variables are stored in your current shell session, you only have to set them once. After setting, you can directly run the scripts.

4.4.2 For the Windows Batch Scripts

In CMD you can't set the variables directly when running the script. So for the .bat scripts, it is like the second variant for Bash scripts:

SET DESIGNS=\my\design\directory
SET DOCKER_USERNAME=another_user
.\start_x.bat

5. Support with Issues/Problems/Bugs

We are open to your questions about this container and are very thankful for your input! If you run into a problem and you are sure it is a bug, please let us know by following this routine:

  • Take a look at the KNOWN_ISSUES and the RELEASE_NOTES. Both these files can include problems that we are already aware of and maybe include a workaround.
  • Check the existing Issues on GitHub and see if the problem has been reported already. If yes, please participate in the discussion and help by further collecting information.
  • Is the problem in connection with the container, or rather a problem with a specific tool? If it is the second, please also check out the sources of the tool and further contact the maintainer!
  • To help us fix the problem, please open an issue on Github and report the error. Please give us as much information as possible without being unneedingly verbose, so filter accordingly. It is also fine to open an issue with very little information, we will help you to narrow down the source of the error.
  • Finally, if you can exactly know how to fix the reported error, we are also happy if you open a pull request with a fix!

Thank you for your cooperation!

iic-osic-tools's People

Contributors

adankvitschal avatar akiles-esta-usado avatar danielgerlicher avatar daquintero avatar hpretl avatar jakobrat avatar kareefardi avatar martinjankoehler avatar mixkrip avatar mkkassem avatar mrhighvoltage avatar taichi-ishitani avatar w32agobot avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

iic-osic-tools's Issues

Appending to XSCHEM_LIBRARY_PATH

Is your feature request related to a problem? Please describe.

There's currently no easy way to add to the XSCHEM_LIBRARY_PATH. The user may want to add part of their repo or workspace to it to let xschem know where to look for schematics and symbols.

The xschem documentation suggests 2 methods of adding symbol and schematic libraries]. Both of them require updating the XSCHEM_LIBRARY_PATH.

The container's .bashrc file defines an alias wrapper for the xschem command which passes the xschemrc file as an environment variable. When the xschemrc is supplied this way, it is the only initialization file read-in according to the
install instructions.

alias xschem='xschem -b --rcfile $PDKPATH/libs.tech/xschem/xschemrc'
alias xschemtcl='xschem --rcfile $PDKPATH/libs.tech/xschem/xschemrc'

image

Describe the solution you'd like

Each PDK should have the following TCL code appended to its xschemrc to allow the user to specify paths to include on $XSCHEM_USER_LIBRARIES using the $XSCHEM_USER_LIBRARY_PATH environment variable. If the environment variable is not defined, then $XSCHEM_LIBRARY_PATH remains unchanged.

if { [info exists ::env(XSCHEM_USER_LIBRARY_PATH) ] } {
        append XSCHEM_LIBRARY_PATH :$env(XSCHEM_USER_LIBRARY_PATH)
}

Describe alternatives you've considered

  • The xschem documentation assumes the user can update the xschemrc in their user home which will be loaded as part of the startup sequence. Finding a way to load other a user xschemrc would make the xschem setup more flexible but also more prone to setup issues.

Additional context

None

Release a smaller "iic-osic-tools-analog" image

Is your feature request related to a problem? Please describe.

TL;DR: For analog-only designs, the large image size is using a lot more GitHub codespaces credits than necessary for digital design tools that are unused.

The size of the full image with both the analog and digital design tools takes around 40GB of size when running. (the compresses image is ~5GB and the image on disk ~20GB.

I've been using the image as part of a devcontainer that is used by Github codespaces. A design project repo can then be started in a complete analog design environment in the cloud with just a couple of clicks from the GitHub repo webpage.
However the size of this image is causing me to have to use a codespace with a lot of hardware resources. (currently using the largest with 16 cores / 32GB ram / 128GB disk space). GitHub limits the number of codespace credits based on the hardware size used. So it will end up costing me more for a bunch of digital tools that I don't use in a pure analog design.

Describe the solution you'd like

I'd like to have a second smaller image, "iic-osic-tools-analog" with only the tools necessary for analog design.

Hopefully the build wouldn't take much longer since the analog tool layers could be cached and reused between the 2 images.
The builds of the common tools can be cached in Docker image layers so they can be reused between both images.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

  • Create a separate repo for the analog image. But this would make it harder to maintain and keep in sync with updated to the full image. It also wouldn't take advantage of the caching between the 2 images.

Additional context

Starting my bandgaps repo in a Codespaces cloud analog development environment from its GitHub repo page.

Starting the Codespace

Step 39: gdsii-klayout failed

Sorry, it is me again :-( Maybe this is also because of the apptainer image, but maybe you find also a nice solution ;-)

The following command failed:
Executing "{python3 /foss/tools/openlane/2024.01/scripts/klayout/stream_out.py --output /home/user/designs/regfile_2r1w/runs/full_guide/results/signoff/regfile_2r1w.klayout.gds --lyt /foss/pdks/sky130A/libs.tech/klayout/tech/sky130A.lyt --lym /foss/pdks/sky130A/libs.tech/klayout/tech/sky130A.map --lyp /foss/pdks/sky130A/libs.tech/klayout/tech/sky130A.lyp --top regfile_2r1w --with-gds-file /foss/pdks/sky130A/libs.ref/sky130_fd_sc_hd/gds/sky130_fd_sc_hd.gds --with-gds-file /home/user/designs/mem_1r1w/runs/full_guide/results/final/gds/mem_1r1w.gds --input-lef /home/user/designs/regfile_2r1w/runs/full_guide/tmp/merged.nom.lef /home/user/designs/regfile_2r1w/runs/full_guide/results/routing/regfile_2r1w.def |& tee /dev/null /home/user/designs/regfile_2r1w/runs/full_guide/logs/signoff/39-gdsii-klayout.log}"

This I get in 39-gdsii-klayout.log:

Usage: exe [OPTIONS] INPUT
Try 'exe --help' for help.

Error: Missing argument 'INPUT'.

Sorry if I bother you too much.

Running the Octagon OpenEMS example from IHP fails with ImportError

Describe the bug
When trying to execute the example below, there is a python3 ImportError...

/foss/pdks/ihp-sg13g2/libs.tech/openems/testcase/SG13_Octagon_L2n0/OpenEMS_Python > python3 SG13_L2n0_mesh1um_v2.py

Traceback (most recent call last):
  File "/foss/pdks/ihp-sg13g2/libs.tech/openems/testcase/SG13_Octagon_L2n0/OpenEMS_Python/SG13_L2n0_mesh1um_v2.py", line 16, in <module>
    from pylab import *
  File "/usr/local/lib/python3.10/dist-packages/pylab.py", line 1, in <module>
    from matplotlib.pylab import *
  File "/usr/local/lib/python3.10/dist-packages/matplotlib/pylab.py", line 44, in <module>
    from matplotlib import cbook, mlab, pyplot as plt
  File "/usr/local/lib/python3.10/dist-packages/matplotlib/pyplot.py", line 66, in <module>
    from matplotlib.figure import Figure, FigureBase, figaspect
  File "/usr/local/lib/python3.10/dist-packages/matplotlib/figure.py", line 43, in <module>
    from matplotlib import _blocking_input, backend_bases, _docstring, projections
  File "/usr/local/lib/python3.10/dist-packages/matplotlib/projections/__init__.py", line 58, in <module>
    from mpl_toolkits.mplot3d import Axes3D
  File "/usr/lib/python3/dist-packages/mpl_toolkits/mplot3d/__init__.py", line 1, in <module>
    from .axes3d import Axes3D
  File "/usr/lib/python3/dist-packages/mpl_toolkits/mplot3d/axes3d.py", line 23, in <module>
    from matplotlib import _api, cbook, docstring, _preprocess_data
ImportError: cannot import name 'docstring' from 'matplotlib' (/usr/local/lib/python3.10/dist-packages/matplotlib/__init__.py)

Maybe this is related to https://stackoverflow.com/q/77235006

To Reproduce
Steps to reproduce the behavior:

  1. Go to '/foss/pdks/ihp-sg13g2/libs.tech/openems/testcase/SG13_Octagon_L2n0/OpenEMS_Python'
  2. Run 'python3 SG13_L2n0_mesh1um_v2.py'
  3. See error

Expected behavior
The testcase should run

Environment:

  • OS: Linux
  • Operating mode: VNC
  • Version tag: hpretl/iic-osic-tools:latest (441fc2b128b4)

Docker image version number environment variable

Is your feature request related to a problem? Please describe.

It can be hard to tell which version of the container is used. Especially if you are just using it as a base image in another docker file or devcontainer.

Describe the solution you'd like

There should be an environment variable, IIC_OSIC_TOOLS_VERSION, defining the image version used for that container. This will allow users to easily see what image version was used from within the running container.

From this issue:

Is there a way to check the version number from within it?

Unfortunately not, but I guess this would be a good idea going forward. I am thinking of an env var like IIC-OSIC-TOOLS giving the Docker like 2023.04.

Describe alternatives you've considered

None yet

Additional context

I couldn't tell what version I was using for the bug report in issue #9

Error on image start in `next_release`

When starting the latest build next_release, the following error message is shown:

ERROR: 'klayout' has version (but version must be > 'KLayout 0.28.8')

Further we try to consistently use [ERROR], [WARN] and [INFO] throughout the image, this should be adapted.

Container build fails with 'podman/buildah'

Describe the bug
buildah build fails with:
error resolving mountpoints for container "0bdf5cc5f4ace21d6868f64e9058d08398037cfab83836bb6d4678b55ee71894": invalid mount type "bind"
See GoogleContainerTools/kaniko#1568
This might actually be fixed in a new version of podman/buildah, but the one in Ubuntu 22.04 still has it..

To Reproduce
Steps to reproduce the behavior:
git clone https://github.com/iic-jku/IIC-OSIC-TOOLS
cd IIC-OSIC-TOOLS/_build

Expected behavior

  • build completes as it does on Docker -

Screenshots
buildah build
[1/38] STEP 1/4: FROM ubuntu:jammy AS base
[1/38] STEP 2/4: ARG CONTAINER_TAG=unknown
[1/38] STEP 3/4: ENV IIC_OSIC_TOOLS_VERSION=${CONTAINER_TAG} DEBIAN_FRONTEND=noninteractive TZ=Europe/Vienna LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 TOOLS=/foss/tools PDK_ROOT=/foss/pdks DESIGNS=/foss/designs EXAMPLES=/foss/examples
[1/38] STEP 4/4: RUN --mount=type=bind,source=images/base,target=/images/base bash /images/base/scripts/00_base_install.sh && bash /images/base/scripts/01_base_setup.sh && bash /images/base/scripts/30_install_boost.sh && bash /images/base/scripts/31_install_or-tools.sh && bash /images/base/scripts/70_install_from_pip.sh
error building at STEP "RUN --mount=type=bind,source=images/base,target=/images/base bash /images/base/scripts/00_base_install.sh && bash /images/base/scripts/01_base_setup.sh && bash /images/base/scripts/30_install_boost.sh && bash /images/base/scripts/31_install_or-tools.sh && bash /images/base/scripts/70_install_from_pip.sh": error resolving mountpoints for container "0bdf5cc5f4ace21d6868f64e9058d08398037cfab83836bb6d4678b55ee71894": invalid mount type "bind"
ERRO[0001] exit status 125

Environment:

  • Ubuntu 22.04, amd64

HTTP/s proxy regression

Describe the bug

In branch next_release, since f0da759 gpg is used to retrieve the keyring.
However, behind a proxy (see PR #26), the gpg invocation will run into a timeout, as gpg does not handle proxy settings by default.

image

The solution is, in case of a proxy, to add --keyserver-options http-proxy=$http_proxy.
image

[Image Build Phase] Boost download issue

Describe the bug

What happens

  • dependencies.sh script uses wget to fetch boost_1_82_0.tar.gz
    • which boils down to wget --no-verbose https://boostorg.jfrog.io/artifactory/main/release/1.82.0/source/boost_1_82_0.tar.gz
    • ERROR: the server delivered web content (HTML) for this URL, this causes the next step to fail
  • dependencies.sh script then tries to use tar xvfz fails to extract this file

Expected behavior
Build to succeed.

Screenshots

image

image

openlane --smoke-test fails with: No module named 'pya'

If I run openlane --smoke-test, I get the following error:

───────── GDSII Stream Out (KLayout) ─────────
Traceback (most recent call last): File "/usr/local/lib/python3.10/dist-packages/openlane/scripts/klayout/stream_out.py", line 49, in <module> import pya ModuleNotFoundError: No module named 'pya'

If I install pya with pip3 install pya the error changed to:

───────── GDSII Stream Out (KLayout) ─────────
/usr/local/lib/python3.10/dist-packages/matplotlib/projections/__init__.py:63: UserWarning: Unable to import Axes3D. This may be due to multiple versions of Matplotlib being installed (e.g. as a system package and as a pip package). As a result, the 3D projection is not available. warnings.warn("Unable to import Axes3D. This may be due to multiple versions of " module 'pya' has no attribute 'Technology'

What do I wrong?

Any help is appreciated.

Thanks for this nice image anyway :-)

Markus

Environment:

  • OS: Debian Linux with apptainer (docker image to sandbox)
  • Operating mode: shell
  • Version tag: latest

Additional context
I have build a sandbox with apptainer from the docker image. Btw docker hub overview mentions RockyLinux 8.5. as base.

Docker build fails: OpenVAF deadlink (in install_ihp.sh)

Describe the bug

 => ERROR [open_pdks 4/4] RUN bash install_ihp.sh                                                                                                                                                                                                    29.5s
------
 > [open_pdks 4/4] RUN bash install_ihp.sh:
0.842 Cloning into 'ihp'...
Updating files: 100% (3664/3664), done.
28.52 Switched to a new branch 'dev'
28.52 Branch 'dev' set up to track remote branch 'dev' from 'origin'.
28.53 --2023-11-30 21:49:20--  https://github.com/iic-jku/osic-multitool/raw/main/openvaf/openvaf.aarch64.gz
28.53 Resolving github.com (github.com)... 140.82.121.4
28.55 Connecting to github.com (github.com)|140.82.121.4|:443... connected.
28.63 HTTP request sent, awaiting response... 404 Not Found
29.00 2023-11-30 21:49:20 ERROR 404: Not Found.
29.00
29.06 install_ihp.sh: line 38: ./openvaf: No such file or directory
------
Dockerfile:56
--------------------
  54 |     RUN bash install_volare.sh
  55 |     COPY images/open_pdks/scripts/install_ihp.sh install_ihp.sh
  56 | >>> RUN bash install_ihp.sh
  57 |
  58 |     #######################################################################
--------------------
ERROR: failed to solve: process "/bin/sh -c bash install_ihp.sh" did not complete successfully: exit code: 127

To Reproduce
Steps to reproduce the behavior:

  1. docker build .

Expected behavior
Build to succeed.

Environment:

  • OS: macOS Apple Silicon
  • Operating mode: VNC
  • Version tag: main branch c7ee2e4

Build failed due to unsufficient disk space: how do I clean up?

While tryind to build the docker image, my VM ran out of memory.
I am therefore left with ~20 GB of "intermediate" files which are not listed be docker image ls, how can I get rid of these?
Also, what is a good estimate of how much memory the final build will occupy? I think this would be good information to put in the read me :)

Thanks for your work!
Andrea

Support for Chisel

Is your feature request related to a problem? Please describe.
This feature request is not related to a real problem but a nice to have.

To support Chisel for design entry we need a JVM, e.g., OpenJDK and sbt.
The rest (Scala, Chisel) will be downloaded automatically on the first run of sbt.

[Image Build Phase] install_ihp.sh can't find openvaf

Describe the bug

  • Tried to build the docker image
  • using next_release 726e509
[6/39] STEP 7/8: COPY images/open_pdks/scripts/install_ihp.sh install_ihp.sh
--> 9ac5b689a82a
[6/39] STEP 8/8: RUN bash install_ihp.sh 
Cloning into 'ihp'...
Updating files: 100% (3664/3664), done.
Branch 'dev' set up to track remote branch 'dev' from 'origin'.
Switched to a new branch 'dev'
install_ihp.sh: line 40: /foss/tools//openvaf
osic-multitool/bin/openvaf: No such file or directory
Error: building at STEP "RUN bash install_ihp.sh": while running runtime: exit status 127

Expected behavior
Build to succeed.

alias xschem as "xschem -b" prevent the other alias xschemtcl to enter tcl cmd mode

Describe the bug
the original xschem cmd from stefan when used, will return a TCL cmd. The default setting in iic-osic is to alias xschem as "xschem -b" in ~/.bashrc file. This setting results in the other alias "xschemtcl", which is supposed to behave like original, output TCL cmd, doesn't work and behave the same as "xschem -b".

To Reproduce
Steps to reproduce the behavior:

  1. I use icc-osic-tool-xserver in windows OS
  2. after start it, the cmd shows up, type "xschemtcl"
  3. the return doesn't have TCL cmd and hence I must have & to send it to the background.
    image

Expected behavior
The below results are obtained via the tricks in the Additional context.
image

Screenshots
If applicable, add screenshots to help explain your problem.

Environment:

  • OS: Windows
  • Operating mode: both mode, X11 and xvnc (http://localhost)
  • Version tag : where to find this info? I download from github last month on Dec/2023

Additional context
One workaround is to define "xschem -b" as something else, like xschem_b, but not replace the app name "xschem". What I show below in .bashrc is a possible work around. The line of "unalias xschem" is needed for de-link the existing xschem from 'xschem -b'
image

It looks like even xschemtcl will call the "xschem -b" if alias xschem is renmaed as 'xschem -b' no matter I put the xschemtcl alias definition before or after the 'xschem -b' alias. I have tried to code in the below two ways but xschemtcl still doesn't function properly.
image
or
image

I don't plan to file a Pull request because I think it's kind of personal preference to overwrite 'xschem' as 'xschem -b' and not using xschem_b or something like that. It's just unfortunately that somehow the defined "xschemtcl" doesn't work anymore. A more fundamental solution should fix this issue somewhere else, maybe in xschem or BASH. It sounds to me maybe this work previously but not now.

gf180mcuC Xschem Setup Bugs

Describe the bug
We're seeing issues with running Xschem with the gf180mcuC process. It doesn't seem to be working correctly. It doesn't have the models or PDK setup correctly within xschem. The $XSCHEM_LIBRARY_PATH is also not setup correctly. My teammates are also reporting simulation issues.

I start by sourcing the following .designinit file in a fresh terminal.

#!/bin/bash
export PDK=gf180mcuC
export PDKPATH=$PDK_ROOT/$PDK
export STD_CELL_LIBRARY=gf180mcu_fd_sc_mcu7t5v0

Then I start xschem, but it gives me the following incorrect pdk information in the terminal and it can't find the default process schematic as shown in the following error message pop-up.

pdk installation: using /foss/pdks
180MCU_MODELS: /foss/pdks/ngspice/models

image

This shows that the PDK models and the $XSCHEM_LIBRARY_PATH is not setup correctly.

Doing a diff of the xschemrc from SKY130 and gf180mcuC shows the following as the most significant difference. I also know several other differences before that which were mostly commented out values but seemed to show the gf180mcuC xschemrc is based off an older version of the xschemrc compared to SKY130.

image

I'm going to continue debug by updating to the latest version of the container.

To Reproduce
Steps to reproduce the behavior:

  1. Source the .designinit for gf180mcuC as given above
  2. run xschem command
  3. See the errors listed above

Expected behavior
I would expect the correct xschem "starter" schematic for the gf180mcuC process to open.
I would also expect the

Screenshots
See above

Environment:

  • OS: Windows running the container using Docker desktop which uses the WSL2 kernel
  • Operating mode: X11 using the X410 X-windows server.
  • Version tag: Not sure. I am using a devcontainer based on some version of it.
    Is there a way to check the version number from within it?
    I tried checking within Docker and it just shows the layers it used from iic-osic-tools and not the version of the image those came from.

Additional context
Add any other context about the problem here.

Getting a Permission Denied error while running the openlane flow

Describe the bug
When running the opnelane flow, it creates a bunch of directories and files. The permission to create them is denied.

To Reproduce
Steps to reproduce the behavior:

  1. run start_x.sh script
  2. Go to the openlane directory.
  3. Run "make mount"
  4. Run "./flow.tcl -design spm -overwrite"

Expected behavior
The entire openlane flow should run.

Environment:

  • OS: Linux - Ubuntu 22.04
  • Operating mode: X11
  • Version tag: latest

Additional context
When running a container with "start_shell.sh", the default user is root. But while running a container with "start_x.sh", the default user is Inside the container is "designer". The openlane flow doesn't run inside the container started by 'start_x.sh' script, but for the other one it runs. I need to use the GUI of klayout, so I need to run the container with "start_x.sh".

Bash Interface to automatise the tasks in Xschem NGSpice

Hello,

I am using Xschem with NGSpice at the backend through the Docker station provided by Efabless.com for circuit simulation. I have 100 different trials of the input signal, each saved in a separate text file (.txt). Manually loading timestamps and voltage values for each trial in the piecewise linear function, and modifying the output file path (as it's different for every trial) is time-consuming for 100 trials.

I'm looking to automate this task of loading different input files, simulating, and saving as different output files through a bash script. Has anyone implemented a bash interface to automatically load input data and save it as different output files through a loop? If so, is it possible to implement it inside the Docker container? If not, I'd be happy to contribute in this direction.

Thanks and Regards,
Shavika Rastogi
PhD Candidate
International Centre for Neuromorphic Systems
Western Sydney University, Australia
and
Biocomputation Research Group
University of Hertfordshire, UK

GDS files empty in magic when edited with klayout

Describe the bug
GDS files can not be viewed with magic if they were edited with klayout

To Reproduce
Preparation:

  • Start container
  • Open terminal in /foss/designs
  • cp -r /foss/tools/openlane/2023.01/designs/spm /foss/designs/spm
  • flow.tcl -design spm -tag foo
  • cd spm/runs/foo/results/final/gds/

Check if gds can be opened with magic

  • magic spm.gds
  • Everything's okay, close magic

Force issue:

  • ke spm.gds
  • Warning: Initialization of layers failed: Unable to open file: /headless/.klayout/tech/sky130/sky130.lyp (errno=2)
  • File - Save
  • close klayout

Check again if gds can be opened with magic

  • magic spm.gds
  • magic view is empty

Expected behavior
Magic can open the modified gds file

Environment:

  • OS: Windows
  • Operating mode: VNC
  • Version tag 2023.01

Additional context

  • My workaround is using version tag 2022.12
  • Also happens in tag next with 2023.02

find in the start_x.bat cannot work

Describe the bug
when run the start_x.bat with a cotainner running, the find function is not working in the command prompt.

docker container inspect %CONTAINER_NAME% 2>&1 | find "Status" | find /i "running"
find: '/i': No such file or directory
find:find :'Status' : 'running'No such file or directory:
No such file or directory

Replacing the find by findstr, everything is OK

To Reproduce
Let the docker image running, type start_x.bat in the command prompt.

Expected behavior
The batch file is supposed to find the running status correctly.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment:

  • OS: Win10
  • Operating mode: X11
  • Version tag: latest

Additional context
Add any other context about the problem here.

[Image Build Phase] Modularize dependencies.sh for faster builds

Is your feature request related to a problem? Please describe.

During stage base, the script _build/images/base/scripts/dependencies.sh gets executed with a single RUN statement.
This means that if the script fails at some point, the whole script has to be re-executed without any partial result caching.

In the current state, the script is quite long running, containing tasks like:

  1. Basic APT setup
  2. Adding Firefox PPA
  3. Preparations for VSCode (add APT repo)
  4. Install additional APT Packages (add APT repo)
  5. APT Update/Upgrade
  6. Git Proxy Setup
  7. Download/build/install Boost from source
  8. Download/build/install OpenROAD
  9. Install PIP packages
  10. Cleanup to minimize image size

Describe the solution you'd like

By modularizing the dependencies.sh script into multiple RUN invocations, build and debugging times can be drastically sped up.

Directory _build/images/base/scripts/dependencies contains:

  1. apt_base_install.sh
  2. apt_add_firefox_repository.sh
  3. apt_add_vscode_repository.sh
  4. apt_update_upgrade.sh
  5. apt_additional_pkg_install.sh
  6. git_proxy_setup.sh
  7. boost_install.sh
  8. openroad_install.sh
  9. pip_pkg_install.sh
  10. cleanup_image.sh

If this is of interest and a go, I'd suggest we schedule this refactoring after the pending commits or PRs are merged, to avoid conflicts.

Current repository configuration `main` branch not building

Describe the bug
I've just cloned the repo and tried to build it in my local Docker to make some edits, and the latest main branch is not building.

To Reproduce
Steps to reproduce the behavior:

11:10:26 dq16394@iqt iic-osic-tools ±|main|→ ls
build-all.sh      Dockerfile             eda_server_start.sh  LICENSE           start_jupyter.bat  start_vnc.bat  start_x.sh             tools
builder-clear.sh  eda_server_conf.sh     eda_server_stop.sh   README.md         start_jupyter.sh   start_vnc.sh   tool_metadata_add.yml
buildkitd.toml    eda_server_restart.sh  images               RELEASE_NOTES.md  start_shell.sh     start_x.bat    tool_metadata.yml
11:10:37 dq16394@iqt iic-osic-tools ±|main|→ docker build . -t daquintero/iic
[+] Building 1690.5s (57/129)                                                                                                                                                 docker:default
 => [internal] load build definition from Dockerfile                                                                                                                                    0.1s
 => => transferring dockerfile: 20.03kB                                                                                                                                                 0.0s
 => [internal] load .dockerignore                                                                                                                                                       0.1s
 => => transferring context: 2B                                                                                                                                                         0.0s
 => [internal] load metadata for docker.io/library/ubuntu:jammy                                                                                                                         1.6s
 => [internal] load build context                                                                                                                                                       0.9s
 => => transferring context: 27.81MB                                                                                                                                                    0.7s
 => [base 1/3] FROM docker.io/library/ubuntu:jammy@sha256:ec050c32e4a6085b423d36ecd025c0d3ff00c38ab93a3d71a460ff1c44fa6d77                                                              4.9s
 => => resolve docker.io/library/ubuntu:jammy@sha256:ec050c32e4a6085b423d36ecd025c0d3ff00c38ab93a3d71a460ff1c44fa6d77                                                                   0.0s
 => => sha256:56887c5194fddd8db7e36ced1c16b3569d89f74c801dc8a5adbf48236fb34564 424B / 424B                                                                                              0.0s
 => => sha256:01f29b872827fa6f9aed0ea0b2ede53aea4ad9d66c7920e81a8db6d1fd9ab7f9 2.30kB / 2.30kB                                                                                          0.0s
 => => sha256:b237fe92c4173e4dfb3ba82e76e5fed4b16186a6161e07af15814cb40eb9069d 29.54MB / 29.54MB                                                                                        1.0s
 => => sha256:ec050c32e4a6085b423d36ecd025c0d3ff00c38ab93a3d71a460ff1c44fa6d77 1.13kB / 1.13kB                                                                                          0.0s
 => => extracting sha256:b237fe92c4173e4dfb3ba82e76e5fed4b16186a6161e07af15814cb40eb9069d                                                                                               3.5s
 => [base 2/3] COPY images/base/scripts/dependencies.sh dependencies.sh                                                                                                                 4.1s
 => [base 3/3] RUN bash dependencies.sh                                                                                                                                              1469.5s
 => [padring 1/2] COPY images/padring/scripts/install.sh install.sh                                                                                                                     0.3s
 => [align-pdk-sky130 1/2] COPY images/align-pdk-sky130/scripts/install.sh install.sh                                                                                                   0.6s
 => [yosys 1/2] COPY images/yosys/scripts/install.sh install.sh                                                                                                                         0.3s
 => [xyce 1/4] COPY images/xyce/scripts/trilinos.reconfigure.sh /trilinos.reconfigure.sh                                                                                                0.5s
 => [nvc 1/2] COPY images/nvc/scripts/install.sh install.sh                                                                                                                             0.6s
 => [openroad_app 1/2] COPY images/openroad/scripts/install.sh install.sh                                                                                                               0.5s
 => [gtkwave 1/2] COPY images/gtkwave/scripts/install.sh install.sh                                                                                                                     0.7s
 => [covered 1/2] COPY images/covered/scripts/install.sh install.sh                                                                                                                     1.5s
 => [gaw3-xschem 1/2] COPY images/gaw3-xschem/scripts/install.sh install.sh                                                                                                             0.8s
 => [xschem 1/2] COPY images/xschem/scripts/install.sh install.sh                                                                                                                       0.9s
 => [rftoolkit 1/2] COPY images/rftoolkit/scripts/install.sh install.sh                                                                                                                 0.9s
 => [ngspice 1/2] COPY images/ngspice/scripts/install.sh install.sh                                                                                                                     1.2s
 => [iverilog 1/2] COPY images/iverilog/scripts/install.sh install.sh                                                                                                                   1.0s
 => [netgen 1/2] COPY images/netgen/scripts/install.sh install.sh                                                                                                                       0.7s
 => [riscv-gnu-toolchain-rv32i 1/2] COPY images/riscv-gnu-toolchain-rv32i/scripts/install.sh install.sh                                                                                 1.0s
 => [qucs-s 1/2] COPY images/qucs-s/scripts/install.sh install.sh                                                                                                                       1.3s
 => [fault 1/4] COPY images/fault/scripts/dependencies.sh dependencies.sh                                                                                                               1.5s
 => [irsim 1/2] COPY images/irsim/scripts/install.sh install.sh                                                                                                                         1.3s
 => [verilator 1/2] COPY images/verilator/scripts/install.sh install.sh                                                                                                                 1.3s
 => [qflow 1/2] COPY images/qflow/scripts/install.sh install.sh                                                                                                                         1.1s
 => [cvc_rv 1/2] COPY images/cvc_rv/scripts/install.sh install.sh                                                                                                                       1.1s
 => [basepkg 1/2] COPY images/base/scripts/install.sh install.sh                                                                                                                        1.1s
 => [slang 1/2] COPY images/slang/scripts/install.sh install.sh                                                                                                                         1.4s
 => [ghdl 1/2] COPY images/ghdl/scripts/install.sh install.sh                                                                                                                           1.4s
 => CANCELED [yosys 2/2] RUN bash install.sh                                                                                                                                          207.6s
 => [padring 2/2] RUN bash install.sh                                                                                                                                                 168.8s
 => [xyce 2/4] COPY images/xyce/scripts/xyce.reconfigure.sh /xyce.reconfigure.sh                                                                                                        1.3s
 => CANCELED [openroad_app 2/2] RUN bash install.sh                                                                                                                                   187.0s
 => CANCELED [nvc 2/2] RUN bash install.sh                                                                                                                                            178.9s
 => [align-pdk-sky130 2/2] RUN bash install.sh                                                                                                                                          2.9s
 => [netgen 2/2] RUN bash install.sh                                                                                                                                                  169.6s
 => CANCELED [gtkwave 2/2] RUN bash install.sh                                                                                                                                        179.6s
 => [gaw3-xschem 2/2] RUN bash install.sh                                                                                                                                             170.4s
 => [xschem 2/2] RUN bash install.sh                                                                                                                                                  170.4s
 => [rftoolkit 2/2] RUN bash install.sh                                                                                                                                               170.4s
 => CANCELED [iverilog 2/2] RUN bash install.sh                                                                                                                                       181.6s
 => CANCELED [riscv-gnu-toolchain-rv32i 2/2] RUN bash install.sh                                                                                                                      194.9s
 => [qflow 2/2] RUN bash install.sh                                                                                                                                                    61.1s
 => [cvc_rv 2/2] RUN bash install.sh                                                                                                                                                  172.2s
 => CANCELED [basepkg 2/2] RUN bash install.sh                                                                                                                                        208.8s
 => ERROR [ngspice 2/2] RUN bash install.sh                                                                                                                                           169.6s
 => [irsim 2/2] RUN bash install.sh                                                                                                                                                   169.3s
 => CANCELED [qucs-s 2/2] RUN bash install.sh                                                                                                                                         191.6s
 => CANCELED [verilator 2/2] RUN bash install.sh                                                                                                                                      199.2s
 => CANCELED [ghdl 2/2] RUN bash install.sh                                                                                                                                           204.5s
 => CANCELED [slang 2/2] RUN bash install.sh                                                                                                                                          196.6s
 => [fault 2/4] RUN bash dependencies.sh                                                                                                                                              169.7s
 => CANCELED [covered 2/2] RUN bash install.sh                                                                                                                                        176.7s
 => [xyce 3/4] COPY images/xyce/scripts/install.sh install.sh                                                                                                                           0.3s
 => CANCELED [xyce 4/4] RUN bash install.sh                                                                                                                                           201.0s
------
 > [ngspice 2/2] RUN bash install.sh:
2.163 Cloning into 'ngspice'...
3.192 warning: filtering not recognized by server, ignoring
54.99 error: RPC failed; curl 56 GnuTLS recv error (-54): Error in the pull function.
54.99 fetch-pack: unexpected disconnect while reading sideband packet
54.99 fatal: early EOF
54.99 fatal: fetch-pack: invalid index-pack output
56.93 install.sh: line 6: cd: ngspice: No such file or directory
56.93 fatal: not a git repository (or any of the parent directories): .git
56.93 install.sh: line 8: ./autogen.sh: No such file or directory
56.93 install.sh: line 11: ./autogen.sh: No such file or directory
------
Dockerfile:179
--------------------
 177 |     ARG NGSPICE_NAME="ngspice"
 178 |     COPY images/ngspice/scripts/install.sh install.sh
 179 | >>> RUN bash install.sh
 180 |
 181 |     #######################################################################
--------------------
ERROR: failed to solve: process "/bin/sh -c bash install.sh" did not complete successfully: exit code: 127

Expected behavior
The environment to build.

Environment:
Docker in a CentOS 7 environment that does have the OpenLane docker working.

Additional context
I plan to try to solve this but just flagging this in the interim.

ghdl not found in .tcl-interpreter during yosys-synth

I'm new to hardware design in general, so please let me know if I am the error.

Describe the bug
openlane2 fails when executed in /foss/designs with
openlane -f VHDLClassic --design-dir /foss/designs/*design_name*/ /foss/designs/*design_name*/config.json
Yosys fails, because some step.tcl cannot find ghdl.
ERROR: TCL interpreter returned an error: invalid command name "ghdl"
Logs attached.
The tclsh and the normal bash execute ghdl just fine.
Verilog flows work like a charme, so I know how to work around by manually translating with ghdl.

I don't know tcl at all, but it seems odd that global variables can get forgotten when executed from other folders.
Thats the reason I figured there might be a problem with Paths or env, hence I post here.
Please let me also know, if you think thats a problem with openlane itself so I can post there.

To Reproduce
Steps to reproduce the behavior:

  1. Setup a container with the start_vnc.bat
  2. connect to the container via your webbrowser
  3. create a folder inside /foss/designs
  4. create a basic config.json (mine config.json)
  5. Open a Terminal in /foss/designs
  6. execute faulty command from above (without the asterix')
    openlane -f VHDLClassic --design-dir /foss/designs/design_name/ /foss/designs/design_name/config.json

Expected behavior
The flow should continue at least.

Environment:

  • OS: Windows, Docker Desktop
  • Operating mode: VNC
  • Version tag latest[03.07.2024]

Additional context
Error log of the run:
error.log
Log of the 01-yosys-vhdlsynthesis step:
yosys-vhdlsynthesis.log
COMMANDS of this step-folder contains:
yosys -c /usr/local/lib/python3.10/dist-packages/openlane/scripts/yosys/synthesize.tcl

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.