Installation question: anaconda3 Sifting through t...
# chipalooza
c
Installation question: anaconda3 Sifting through the installed containers and virtualization environments from Telluride 2021 workshop, I find anaconda3 (ubuntu MATE 2020.4) Does this have to do with any skywater installation, or can I safely disregard it for purposes of the chipalooza 2024?
l
For what it's worth, I've created this "tutorial" to help my team in setting up the tools. We used a VM with a freshly installed Ubuntu 22.04 LTS as the base OS. Everything seems to be working just fine.
Copy code
# XSCHEM
sudo apt install git -y
sudo apt update
sudo apt upgrade -y
mkdir $HOME/Analog
cd $HOME/Analog
git clone <https://github.com/StefanSchippers/xschem.git> xschem-src
cd xschem-src

sudo apt install flex -y
sudo apt install bison -y
sudo apt install libx11-dev -y
sudo apt install tk8.6-dev -y
sudo apt install libxpm-dev -y
sudo apt install libcairo2-dev -y
sudo apt install libjpeg-dev -y
sudo apt install libx11-xcb-dev -y
sudo apt install libxrender-dev -y
sudo apt install tcl8.6-dev -y
sudo apt install gawk -y
sudo apt install tcl-tclreadline -y

su
./configure
make
make install

su your_username
sudo apt install xterm -y
sudo apt install vim-gtk3 -y
cd $HOME
xschem

# MAGIC
cd $HOME/Analog
git clone <git://opencircuitdesign.com/magic> 
cd magic

sudo apt install m4 -y
sudo apt install python3 -y
sudo apt install mesa-common-dev -y
sudo apt install libglu1-mesa-dev -y
sudo apt install libncurses-dev -y

su
./configure
make
make install

su your_username
cd $HOME
magic

# NGSPICE
cd $HOME/Analog
git clone <git://git.code.sf.net/p/ngspice/ngspice> ngspice-ngspice
cd ngspice-ngspice
mkdir release

sudo apt install adms -y
sudo apt install autoconf -y
sudo apt install libtool -y
sudo apt install automake -y
sudo apt install libxaw7-dev -y
sudo apt install libxmu-dev -y
sudo apt install libxext-dev -y
sudo apt install libxft-dev -y
sudo apt install fontconfig -y
sudo apt install freetype* -y
sudo apt install libreadline6-dev -y

su
./autogen.sh --adms
cd release
../configure --with-x --enable-xspice --disable-debug --enable-cider --with-readline=yes --enable-predictor --enable-osdi --enable-openmp
make
make install

su your_username
mkdir $HOME/.xschem/simulations
cd $HOME/.xschem/simulations
echo "set ngbehavior=hsa" >> .spiceinit
echo "set ng_nomodcheck" >> .spiceinit
cd $HOME
ngspice

# OPENPDKS
cd $HOME/Analog
git clone <git://opencircuitdesign.com/open_pdks>
cd open_pdks/

su
./configure --enable-sky130-pdk --enable-sram-sky130
make
make install
make distclean

su your_username
cd $HOME

# NETGEN
cd $HOME/Analog
git clone <git://opencircuitdesign.com/netgen>
cd netgen/

su
./configure
make
make install

su your_username
cd $HOME
netgen

sudo apt update
sudo apt upgrade -y
sudo apt autoremove --purge -y
t
@Christoph Maier: There was a dependency on anaconda in the original google sky130 repository that I removed in my fork or it. You can safely disregard it.
@Lucas Daudt Franck: Looks good, at a glance. Note that
sudo apt install adms
is not used because ngspice no longer supports it. It can be removed.
👍 1
c
@Tim Edwards, and now configuration and dependency hell starts. In ngspice42, autogenerated files generated by at least another layer of autogenerated files contain a spurious
Copy code
#define hicum0numStates 0
and generate an error
Copy code
In file included from hicum0.c:8:
hicum0defs.h:2899:25: error: expected identifier before numeric constant
 2899 | #define hicum0numStates 0
      |                         ^
hicum0defs.h:3025:5: note: in expansion of macro 'hicum0numStates'
 3025 |     hicum0numStates
      |     ^~~~~~~~~~~~~~~
make[5]: *** [Makefile:490: hicum0.lo] Error 1
make[4]: *** [Makefile:396: all] Error 2
make[3]: *** [Makefile:578: all-recursive] Error 1
make[2]: *** [Makefile:401: all-recursive] Error 1
make[1]: *** [Makefile:1480: all-recursive] Error 1
make: *** [Makefile:506: all-recursive] Error 1
(for example) Once the header exists, on can just eliminate the #define …numStates 0 line, but the compiler crashes for each of the autogenerated devices. Not having to deal with this kind of obfuscation layer crap is the primary reason to stick to analog design …
What was the problem with ADMS, anyhow? (I fixed at least something … now how would I push that back, and to whom?)
t
I'm not sure there was any specific problem with ADMS, it's just that openVAF/OSDI superseded it, and works as a plug-in, making ADMS both redundant and less useful.
c
@Tim Edwards, I followed your recommendation [http://opencircuitdesign.com/] to install the core tools, and was extremely happy how straightforward the upgrade of my native Ubuntu 20.04.6 LTS (not test, yet) of magic, xschem, and netgen from Telluride 2021 was. You recommended ngspice 42, which is the current master (or, politically correct, main?) version, so I tried to compile that. The make crashed, because the setup procedure generated a whole series of ADHS (ADMS?) model files with a recurring error that stopped the build every single instance. Fixing the individual offending header files manually is possible, but so tedious that I'd rather design a comparatively simple analog block, like a Sallen&Key filter, in the time I waste on software engineers' version and configuration hell. So I did a forensic deep dive into the tangled mess of software layers and pinpointed the offending line. Now ngspice 42 with your recommended configuration options (include ADMS) compiles and builds. I just need to push back that fix to the unforked git repository and blame the individual whodunit directly and personally, because unlike in an open-source free-for-all mess, that guy actually knows what the expletive deleted he thought he was doing, and could point me to a test to verify that I didn't just make the make crashes go away, but actually fixed the problem.
@Tim Edwards, as for anaconda3, this could be used to make the python version hell that I seem to be running into with CACE go away by "just" duplicating all the native tools and PDKs that cace needs to play with nicely into a virtualized environment. I much rather deal with the native environment of the analog natives I happened to run into at ISCAS'98, but for that, you'd have to eliminate the version-dependent dependencies from the native setup — or get rid of CACE entirely, because that's a tool for the convenience of suits, not analog designers, anyhow. For now, I'll focus on updating my native sky130 PDK and make it play with the necessary tools (xschem, magic, ngspice, netgen). As for CACE etc., there's always the comparatively easy way to design the analog building blocks on both sides of divide et impera specifications.