---------- Forwarded message ---------- From: ludwig jaffe ludwig.jaffe@gmail.com Date: Saturday, February 2, 2019 Subject: Tools for VLSI Design - LibreSilicon flavored Live-DVD To: Staf Verhaegen staf@fibraservi.eu
Debian based is enough imho. Also openSuSE is not so much used for development. Fedora and especially centos/rhel has a much smaller package wealth compared to debian or ubuntu which is based on debian. People with rpm distros could try to use the alien tool. But I will support debian and ubuntu as these are preffered by me.
Cheers
Ludwig
On Saturday, February 2, 2019, Staf Verhaegen staf@fibraservi.eu wrote:
ludwig jaffe schreef op za 02-02-2019 om 18:40 [+0100]:
Toolchain: Hi I could maintain a repository to be added to /etc/apt/sources.list /etc/apt/sources.list.d/libresilicon
Alternatively maybe repos can be maintained for a few selected OSes on
openSUSE build Service. I do think for example some academic environments are still based on Centos or derivatives like Scientific Linux.
greets, Staf.
so apt will find the packages this should work for debian and ubuntu and one could try to statically
link the tools if they need old stuff like motif or even older stuff that could create dependency problems as every distro is a bit different.
But the first step is to maintain a dynamically linked version of the
tools for debian stable and ubuntu lts.
This should be not too much work. No need fir a life cd. Just a howto for adding our repo to the distribution.
Regarding electric: how to host a 600M tarball of html code docunentation. Github accepts only 100M blobs. So splitting up the docu part of electric
did not help much.
If you want to code with electric git clone levush/electric read the readme on compiling and have gixygen and graphviz installed to
make the docu.
There is still a path problem in the Doxyfile as relative paths sonehow
are not working correctly.
If someone knows better please look at the different Versions of Doxyfile
in the project and improve it.
The code base is quite huge so one would need to surf the code to
understand it. Doxygen is a cool tool for analysis of code written by others.
If we want to develop with electric we need to find what should be
improved and try to understand the code to the extend needed fir this task.
Otherwhise electric sits there beeing rescued from beeing depublished in
favor of the shity java version but thats it.
Cheers
Ludwig
On Saturday, February 2, 2019, Hagen SANKOWSKI <hsank@po
steo.de> wrote:
Hello Ludwig, Hello List.
Thanks Ludwig for your Effort to compile some tools!
I came across the fact, that the Debian family of Distributions has already compiled packages for qflow, which also includes yosys and
magic..
IMHO we should have a working tool flow, which allows us to work on our project and others to follow us.
Ludwig, do you like to setup and maintain a (Debian/Mint clone) Live-DVD with all tools already installed tools?
I would vote (at least) for
- qflow
- yosys
- magic
- klayout
- electric
- (lua)latex (while with easier UTF-8 usage!)
all in the latest and greatest version. Plus all stuff we are developing here, like
- lsc
- popcorn
- melmac
- ... etc.
Additional (in later versions) I can think about distributing nice documentations not only about the process, but also how-to, cookery books of how to make chips.
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
Hello Ludwig.
At least David is a OpenSuse Tumbleweed user. And he already showed me the possibility to build/compile Debian Packages on OpenSuse Server farm.
So, if your machine is probably to week, OpenSuse's build service is an option.
Regards, Hagen.
On 2/3/19 9:48 AM, ludwig jaffe wrote:
---------- Forwarded message ---------- From: ludwig jaffe <ludwig.jaffe@gmail.com mailto:ludwig.jaffe@gmail.com> Date: Saturday, February 2, 2019 Subject: Tools for VLSI Design - LibreSilicon flavored Live-DVD To: Staf Verhaegen <staf@fibraservi.eu mailto:staf@fibraservi.eu>
Debian based is enough imho. Also openSuSE is not so much used for development. Fedora and especially centos/rhel has a much smaller package wealth compared to debian or ubuntu which is based on debian. People with rpm distros could try to use the alien tool. But I will support debian and ubuntu as these are preffered by me.
Cheers
Ludwig
On Saturday, February 2, 2019, Staf Verhaegen <staf@fibraservi.eu mailto:staf@fibraservi.eu> wrote:
ludwig jaffe schreef op za 02-02-2019 om 18:40 [+0100]:
Toolchain: Hi I could maintain a repository to be added to /etc/apt/sources.list /etc/apt/sources.list.d/libresilicon
Alternatively maybe repos can be maintained for a few selected OSes on
openSUSE build Service. I do think for example some academic environments are still based on Centos or derivatives like Scientific Linux.
greets, Staf.
so apt will find the packages this should work for debian and ubuntu and one could try to statically
link the tools if they need old stuff like motif or even older stuff that could create dependency problems as every distro is a bit different.
But the first step is to maintain a dynamically linked version of the
tools for debian stable and ubuntu lts.
This should be not too much work. No need fir a life cd. Just a howto for adding our repo to the distribution.
Regarding electric: how to host a 600M tarball of html code docunentation. Github accepts only 100M blobs. So splitting up the docu part of
electric did not help much.
If you want to code with electric git clone levush/electric read the readme on compiling and have gixygen and graphviz installed
to make the docu.
There is still a path problem in the Doxyfile as relative paths
sonehow are not working correctly.
If someone knows better please look at the different Versions of
Doxyfile in the project and improve it.
The code base is quite huge so one would need to surf the code to
understand it. Doxygen is a cool tool for analysis of code written by others.
If we want to develop with electric we need to find what should be
improved and try to understand the code to the extend needed fir this task.
Otherwhise electric sits there beeing rescued from beeing depublished
in favor of the shity java version but thats it.
Cheers
Ludwig
On Saturday, February 2, 2019, Hagen SANKOWSKI <hsank@po
steo.de http://steo.de> wrote:
Hello Ludwig, Hello List.
Thanks Ludwig for your Effort to compile some tools!
I came across the fact, that the Debian family of Distributions has already compiled packages for qflow, which also includes yosys and
magic..
IMHO we should have a working tool flow, which allows us to work on our project and others to follow us.
Ludwig, do you like to setup and maintain a (Debian/Mint clone) Live-DVD with all tools already installed tools?
I would vote (at least) for
- qflow
- yosys
- magic
- klayout
- electric
- (lua)latex (while with easier UTF-8 usage!)
all in the latest and greatest version. Plus all stuff we are developing here, like
- lsc
- popcorn
- melmac
- ... etc.
Additional (in later versions) I can think about distributing nice documentations not only about the process, but also how-to, cookery books of how to make chips.
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Hi Hagen,
I headed that OpenSuse has such a compile farm, as otherwise *nobody* would build packages for suse. Lets make Slackware tgz packages :-)
Cheers
Ludwig
On Sunday, February 3, 2019, Hagen SANKOWSKI hsank@posteo.de wrote:
Hello Ludwig.
At least David is a OpenSuse Tumbleweed user. And he already showed me the possibility to build/compile Debian Packages on OpenSuse Server farm.
So, if your machine is probably to week, OpenSuse's build service is an option.
Regards, Hagen.
On 2/3/19 9:48 AM, ludwig jaffe wrote:
---------- Forwarded message ---------- From: ludwig jaffe <ludwig.jaffe@gmail.com <mailto:ludwig.jaffe@gmail.com
Date: Saturday, February 2, 2019 Subject: Tools for VLSI Design - LibreSilicon flavored Live-DVD To: Staf Verhaegen <staf@fibraservi.eu mailto:staf@fibraservi.eu>
Debian based is enough imho. Also openSuSE is not so much used for development. Fedora and especially centos/rhel has a much smaller package wealth compared to debian or ubuntu which is based on debian. People with rpm distros could try to use the alien tool. But I will support debian and ubuntu as these are preffered by me.
Cheers
Ludwig
On Saturday, February 2, 2019, Staf Verhaegen <staf@fibraservi.eu mailto:staf@fibraservi.eu> wrote:
ludwig jaffe schreef op za 02-02-2019 om 18:40 [+0100]:
Toolchain: Hi I could maintain a repository to be added to /etc/apt/sources.list /etc/apt/sources.list.d/libresilicon
Alternatively maybe repos can be maintained for a few selected OSes on
openSUSE build Service. I do think for example some academic environments are still based on Centos or derivatives like Scientific
Linux.
greets, Staf.
so apt will find the packages this should work for debian and ubuntu and one could try to statically
link the tools if they need old stuff like motif or even older stuff that could create dependency problems as every distro is a bit different.
But the first step is to maintain a dynamically linked version of the
tools for debian stable and ubuntu lts.
This should be not too much work. No need fir a life cd. Just a howto for adding our repo to the distribution.
Regarding electric: how to host a 600M tarball of html code
docunentation.
Github accepts only 100M blobs. So splitting up the docu part of
electric did not help much.
If you want to code with electric git clone levush/electric read the readme on compiling and have gixygen and graphviz installed
to make the docu.
There is still a path problem in the Doxyfile as relative paths
sonehow are not working correctly.
If someone knows better please look at the different Versions of
Doxyfile in the project and improve it.
The code base is quite huge so one would need to surf the code to
understand it. Doxygen is a cool tool for analysis of code written by others.
If we want to develop with electric we need to find what should be
improved and try to understand the code to the extend needed fir this
task.
Otherwhise electric sits there beeing rescued from beeing depublished
in favor of the shity java version but thats it.
Cheers
Ludwig
On Saturday, February 2, 2019, Hagen SANKOWSKI <hsank@po
steo.de http://steo.de> wrote:
Hello Ludwig, Hello List.
Thanks Ludwig for your Effort to compile some tools!
I came across the fact, that the Debian family of Distributions has already compiled packages for qflow, which also includes yosys and
magic..
IMHO we should have a working tool flow, which allows us to work on our project and others to follow us.
Ludwig, do you like to setup and maintain a (Debian/Mint clone)
Live-DVD
with all tools already installed tools?
I would vote (at least) for
- qflow
- yosys
- magic
- klayout
- electric
- (lua)latex (while with easier UTF-8 usage!)
all in the latest and greatest version. Plus all stuff we are
developing
here, like
- lsc
- popcorn
- melmac
- ... etc.
Additional (in later versions) I can think about distributing nice documentations not only about the process, but also how-to, cookery books of how to make chips.
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
I reared my phone autocorrect.
On Sunday, February 3, 2019, ludwig jaffe ludwig.jaffe@gmail.com wrote:
Hi Hagen,
I headed that OpenSuse has such a compile farm, as otherwise *nobody*
would build packages for suse.
Lets make Slackware tgz packages :-)
Cheers
Ludwig
On Sunday, February 3, 2019, Hagen SANKOWSKI hsank@posteo.de wrote:
Hello Ludwig.
At least David is a OpenSuse Tumbleweed user. And he already showed me the possibility to build/compile Debian Packages on OpenSuse Server farm.
So, if your machine is probably to week, OpenSuse's build service is an option.
Regards, Hagen.
On 2/3/19 9:48 AM, ludwig jaffe wrote:
---------- Forwarded message ---------- From: ludwig jaffe <ludwig.jaffe@gmail.com <mailto:
ludwig.jaffe@gmail.com>>
Date: Saturday, February 2, 2019 Subject: Tools for VLSI Design - LibreSilicon flavored Live-DVD To: Staf Verhaegen <staf@fibraservi.eu mailto:staf@fibraservi.eu>
Debian based is enough imho. Also openSuSE is not so much used for development. Fedora and especially centos/rhel has a much smaller package wealth compared to debian or ubuntu which is based on debian. People with rpm distros could try to use the alien tool. But I will support debian and ubuntu as these are preffered by me.
Cheers
Ludwig
On Saturday, February 2, 2019, Staf Verhaegen <staf@fibraservi.eu mailto:staf@fibraservi.eu> wrote:
ludwig jaffe schreef op za 02-02-2019 om 18:40 [+0100]:
Toolchain: Hi I could maintain a repository to be added to /etc/apt/sources.list /etc/apt/sources.list.d/libresilicon
Alternatively maybe repos can be maintained for a few selected OSes on
openSUSE build Service. I do think for example some academic environments are still based on Centos or derivatives like Scientific
Linux.
greets, Staf.
so apt will find the packages this should work for debian and ubuntu and one could try to statically
link the tools if they need old stuff like motif or even older stuff that could create dependency problems as every distro is a bit
different.
But the first step is to maintain a dynamically linked version of the
tools for debian stable and ubuntu lts.
This should be not too much work. No need fir a life cd. Just a howto for adding our repo to the distribution.
Regarding electric: how to host a 600M tarball of html code
docunentation.
Github accepts only 100M blobs. So splitting up the docu part of
electric did not help much.
If you want to code with electric git clone levush/electric read the readme on compiling and have gixygen and graphviz installed
to make the docu.
There is still a path problem in the Doxyfile as relative paths
sonehow are not working correctly.
If someone knows better please look at the different Versions of
Doxyfile in the project and improve it.
The code base is quite huge so one would need to surf the code to
understand it. Doxygen is a cool tool for analysis of code written by others.
If we want to develop with electric we need to find what should be
improved and try to understand the code to the extend needed fir this
task.
Otherwhise electric sits there beeing rescued from beeing depublished
in favor of the shity java version but thats it.
Cheers
Ludwig
On Saturday, February 2, 2019, Hagen SANKOWSKI <hsank@po
steo.de http://steo.de> wrote:
Hello Ludwig, Hello List.
Thanks Ludwig for your Effort to compile some tools!
I came across the fact, that the Debian family of Distributions has already compiled packages for qflow, which also includes yosys and
magic..
IMHO we should have a working tool flow, which allows us to work on
our
project and others to follow us.
Ludwig, do you like to setup and maintain a (Debian/Mint clone)
Live-DVD
with all tools already installed tools?
I would vote (at least) for
- qflow
- yosys
- magic
- klayout
- electric
- (lua)latex (while with easier UTF-8 usage!)
all in the latest and greatest version. Plus all stuff we are
developing
here, like
- lsc
- popcorn
- melmac
- ... etc.
Additional (in later versions) I can think about distributing nice documentations not only about the process, but also how-to, cookery books of how to make chips.
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
-- Send from mobile phone with autocorrection / autofill. Blame my phone for
typos.
Well, support what you're like. Every nice packages would be great.
IMHO even without Slackware we got different targets.
1st, all the Engineers in the Chip Making Business, namely fabs, which dealing with the big three proprietary Vendors (Cadence, Synopsys and Mentor) are sitting on RedHat Enterprise Machines (some few are fine with CentOS 5 or 6, not 7)
2nd, most Geeks which are ambitious and matching our early adopter status seems to be Debian & Co users. Clifford (the yosys guy) e.g. develops primarily for Ubuntu (IMHO).
3rd, almost all Hipsters are using fancy, shiny MacOS laptops (without reasonable RAM and computing power).
4th, there are some folks outside with very personally configured machines - we could catch with the Live-System.
How do we set the focus? Attracting the 1st group would also would mean RPMs - but I am fine with the 2nd group and DEBs.
Regards, Hagen.
On 2/3/19 9:56 AM, ludwig jaffe wrote:
Hi Hagen,
I headed that OpenSuse has such a compile farm, as otherwise *nobody* would build packages for suse. Lets make Slackware tgz packages :-)
Cheers
Ludwig
On Sunday, February 3, 2019, Hagen SANKOWSKI <hsank@posteo.de mailto:hsank@posteo.de> wrote:
Hello Ludwig.
At least David is a OpenSuse Tumbleweed user. And he already showed me the possibility to build/compile Debian Packages on OpenSuse Server farm.
So, if your machine is probably to week, OpenSuse's build service is an option.
Regards, Hagen.
On 2/3/19 9:48 AM, ludwig jaffe wrote:
---------- Forwarded message ---------- From: ludwig jaffe <ludwig.jaffe@gmail.com
mailto:ludwig.jaffe@gmail.com <mailto:ludwig.jaffe@gmail.com mailto:ludwig.jaffe@gmail.com>>
Date: Saturday, February 2, 2019 Subject: Tools for VLSI Design - LibreSilicon flavored Live-DVD To: Staf Verhaegen <staf@fibraservi.eu mailto:staf@fibraservi.eu
<mailto:staf@fibraservi.eu mailto:staf@fibraservi.eu>>
Debian based is enough imho. Also openSuSE is not so much used for development. Fedora and especially centos/rhel has a much smaller package wealth compared to debian or ubuntu which is based on debian. People with rpm distros could try to use the alien tool. But I will support debian and ubuntu as these are preffered by me.
Cheers
Ludwig
On Saturday, February 2, 2019, Staf Verhaegen <staf@fibraservi.eu
<mailto:staf@fibraservi.eu mailto:staf@fibraservi.eu>> wrote:
ludwig jaffe schreef op za 02-02-2019 om 18:40 [+0100]:
Toolchain: Hi I could maintain a repository to be added to /etc/apt/sources.list /etc/apt/sources.list.d/libresilicon
Alternatively maybe repos can be maintained for a few selected OSes on
openSUSE build Service. I do think for example some academic environments are still based on Centos or derivatives like Scientific
Linux.
greets, Staf.
so apt will find the packages this should work for debian and ubuntu and one could try to statically
link the tools if they need old stuff like motif or even older stuff that could create dependency problems as every distro is a bit different.
But the first step is to maintain a dynamically linked version of the
tools for debian stable and ubuntu lts.
This should be not too much work. No need fir a life cd. Just a howto for adding our repo to the distribution.
Regarding electric: how to host a 600M tarball of html code
docunentation.
Github accepts only 100M blobs. So splitting up the docu part of
electric did not help much.
If you want to code with electric git clone levush/electric read the readme on compiling and have gixygen and graphviz installed
to make the docu.
There is still a path problem in the Doxyfile as relative paths
sonehow are not working correctly.
If someone knows better please look at the different Versions of
Doxyfile in the project and improve it.
The code base is quite huge so one would need to surf the code to
understand it. Doxygen is a cool tool for analysis of code written by others.
If we want to develop with electric we need to find what should be
improved and try to understand the code to the extend needed fir this
task.
Otherwhise electric sits there beeing rescued from beeing depublished
in favor of the shity java version but thats it.
Cheers
Ludwig
On Saturday, February 2, 2019, Hagen SANKOWSKI <hsank@po
steo.de http://steo.de http://steo.de> wrote:
Hello Ludwig, Hello List.
Thanks Ludwig for your Effort to compile some tools!
I came across the fact, that the Debian family of Distributions has already compiled packages for qflow, which also includes yosys and
magic..
IMHO we should have a working tool flow, which allows us to work on our project and others to follow us.
Ludwig, do you like to setup and maintain a (Debian/Mint clone)
Live-DVD
with all tools already installed tools?
I would vote (at least) for
- qflow
- yosys
- magic
- klayout
- electric
- (lua)latex (while with easier UTF-8 usage!)
all in the latest and greatest version. Plus all stuff we are
developing
here, like
- lsc
- popcorn
- melmac
- ... etc.
Additional (in later versions) I can think about distributing nice documentations not only about the process, but also how-to, cookery books of how to make chips.
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com mailto:Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com mailto:Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
-- Send from mobile phone with autocorrection / autofill. Blame my phone for typos.
On Sunday, February 3, 2019, Hagen SANKOWSKI hsank@posteo.de wrote:
.
1st, all the Engineers in the Chip Making Business, namely fabs, which dealing with the big three proprietary Vendors
.
How do we set the focus? Attracting the 1st group would also would mean RPMs -
Suggest doing that... when they offer money in the form of sponsorship to do so.
No more spongeing.
Hi Hagen,
you are right. We should support RHEL aka as CentOS / scientific. I would build a RPM ppa repo, and need to find out how to do it. But here we should support the newest stable Centos. Scientific is roughly the same, but testing it is some work so I want to concentrate on some reference systems (I will then use VMs {debian, ubuntu-studio-lts, centos} to test install the stuff) But I dont like centos, because: I played around with different PPA for centos / fedora and after a while, I got a completely screwed system with dependencies completely f*cked up. (Install fnord-lib > 1.42 and install fnord-lib <1.23). Debian is more complete then centos and centos uses older versions of libraries compared to especially ubuntu. As Ubuntu is quite modern and well maintained, many developers like it. And for non secure systems I use ubuntu-studio so multi media works fine out of the box as my standard desktop machine. Also ubuntu-studio it does not have the stupid adware bloat of ubuntu, where I never look again as they lost their credits with this adware shipping shit. Using qubes template VMs I can fight against the hell of a screwed up centos, I am sure :-)
Mac: no hipster mac will ever be supported! No Mac stuff will ever be bought as the apple quality sucks! I had (I was lured in by a student discount offer) a new mac book pro with core2duo and pci-express slot where the screen died after 1,5 years and the battery blew up like a bread in the oven and apple did not care for warranty "sue us if you dare to" So apple should die. If you *really* (no right and middle mouse button -> how to use xfig! ) like mac-os buy a dell-pig machine (laptop or workstation and make it a hackintosh -> mac and dell are build after intel arch specs)
Recommended HW: And I use my "secure"-os which is qubes on a pig machine (no hipster mac stuff will ever be bought as the apple quality sucks). A pig machine is a big fat workstation made by dell or HP containing at least one xeon cpu and enough RAM (>32GB) to have several VM running at the time. The pig machines can be used with qubes-os and depending on your peripheral needs (I often play with PCI-X and scsi so the architecture with fbdimm and core4duo based 45nm xeons is perfect for that, as it is imho the last lecacy-rich architecture) If you want just build software go for a modern pig machine with lots of RAM and CPU cores, and ask for an electricity flat or see the machine as a aux. heating system :-) "RAM is like engine displacement and it can only be replaced by more engine displacement or RAM respectively" And "If you thought you know linux, just install qubes-os and learn how to drill a hole into your right and left knees while trying to do something that you thought is 5 minutes on a linux shell"
Cheers
Ludwig
ludwig jaffe schreef op zo 03-02-2019 om 12:25 [+0100]:
Hi Hagen,
you are right. We should support RHEL aka as CentOS / scientific. I would build a RPM ppa repo, and need to find out how to do it.
Opensuse build service does actually just that even for all major dpkg and rpm based OSes. Staf.
libresilicon-developers@list.libresilicon.com
-
Hagen SANKOWSKI -
ludwig jaffe -
Luke Kenneth Casson Leighton -
Staf Verhaegen