<lkcl>
"Configure Yosys build with CXX := clang++" - hmmm
<lofty>
ABC is pretty passively maintained
<lofty>
It's unfortunate that so much of Yosys relies on it (Vivado does too, but they pay Alan to maintain it)
<lkcl>
yes, definitely CXX is not a c compiler, and if flags have been passed through CXXFLAGS but not CFLAGS, that would brak
<lkcl>
oh btw it may be of interest: i spoke to the developer of ABC a few months ago, about a maaaassive memory issue
<lkcl>
he pointed out that there is now a way faster file format
<gatecat>
xaig, or something else ?
<lkcl>
i can't remember off the top of my head
<lofty>
XAIGER.
<lkcl>
1 sec will see if i can find it
<lofty>
But the ABC flow uses BLIF instead.
<lkcl>
yes, AIGER. Alan... Mischenko?
<lkcl>
yeahh. we end up with something like gigabyte BLIF files :)
<lofty>
Alan Mishchenko, yeah.
<lkcl>
ohh i remember what it was: it was SRAMs being expanded out to DFFs
<lkcl>
we ended up with memory corruption, the resultant BLIF file was so large :)
<lkcl>
solved it thanks to Staf Verhaegen (Chips4Makers) who very kindly designed a custom 4k SRAM cell for us
<lofty>
Business as usual then
<lofty>
ABC breaks on big-endian machines and is not ASAN-clean
<lofty>
(LSOracle also breaks on big-endian machines, but there's not a great deal we can do about that)
<lkcl>
lol a known problem, that one, clearly :)
<lofty>
Hey, maybe somebody tries to run Yosys on their IBM z machine they paid xty million for
<lkcl>
i have to say, apart from pushing the boundaries, i'm just deeply impressed that yosys even exists
<lofty>
I'm impressed Yosys exists, but we're quite a way off "pushing the boundaries" :P
<lkcl>
lofty, you know we went to Imec 180nm tape-out, entirely with Libre-licensed tools, last month?
<lkcl>
and not with openroad / openlane, either: it was with alliance / coriolis2
<lkcl>
yosys was a huge part of the success of that
<lofty>
Full disclosure: my present job gets DARPA funding, and that's aimed at improving the OpenROAD flow.
<lkcl>
nice.
<lkcl>
well it benefits everyone
<lofty>
But the future is probably not with ABC; it's with LSOracle. And yes, LSOracle is paying me, but I genuinely do believe their approach is superior
<lofty>
Besides, since it's FOSS it's not like I get paid more for saying that :P
<lkcl>
:)
<mwk>
... ah right, superior non-big-endian clean tool
<mwk>
*sigh* seriously, is there some kind of rule that EDA tools have to be written Like That?
<lkcl>
irony is, in VHDL, Paul Mackerras added Microwatt LE/BE support in something like 80 lines of VHDL.
<lofty>
mwk: Trying to find big-endian hardware for these things is hard, but at least I discovered it >.>
<lkcl>
Power ISA already has a LD/ST-byte-reverse, it was a simple matter of hooking in an XOR gate from MSR.BE into the backend LD/ST
<lkcl>
IBM POWER8 / POWER9 would do it... and Toshaan Bharvani recompiled Fedora for both LE and BE.
<mwk>
really
<mwk>
the whole EDA space has SO MUCH 1990s-era shit C/C++ tooling feel to it
<mwk>
... please someone write a LLVM
<lkcl>
well, just as the linux kernel (largest software project on the planet) is written in c, the amount of time that's gone into it, and the serious resource-sucking nature of EDA, anything other than c/c++ is actually pretty suicidal
<lofty>
mwk: that LLVM is mockturtle
<mwk>
lofty: no it's not
<sorear>
trouble finding hardware?
<mwk>
it's some clever algorithms stuffed into a package
<lofty>
So is LLVM!
<mwk>
but it's not anywhere close to a full flow
<mwk>
LLVM reads C code and outputs runnable binaries
<lofty>
LLVM does no such thing
<lofty>
*Clang* that wraps LLVM does
<mwk>
clang is part of the LLVM project
<lkcl>
clang's a front-end which generates IR.
<lkcl>
LLVM-IR then compiles that into an executable
<lkcl>
that's the very-much-simplified version
<mwk>
I know how LLVM works
<lofty>
The frontend for that is alice.
<lofty>
if clang's job is to turn C code into LLVM IR
<lofty>
Then alice converts Verilog/AIGER/BLIF into mockturtle networks
<lkcl>
if you are expecting a LLVM IR to be the target for EDA tools, such that an extra layer is inserted, this is another layer inserted into what is already well-known to be a hugely CPU-intensive, resource-intensive task
<sorear>
which part of this is CIRCT
<mwk>
the point is: there is a unified set of libraries developed by a unified team that combines together to a full usable flow
* lofty
gives up
<mwk>
and there is no such thing for EDA
<mwk>
yosys/nextpnr is kind-of close, but it has big problems, and abc is one of them
<lofty>
mwk: as one friend to another, I suggest you close your mouth before you stick your foot any further into it.
<lofty>
Or else you might actually make me quit the FOSS EDA scene like I've considered several times before
<lofty>
Because I did not dedicate the better part of a year of my life to studying the state of the art in logic synthesis
<lofty>
finding jobs in the open FPGA community, including one that has not paid me for the better part of eight weeks
<lofty>
for you to tell me I do not know what I'm talking about when it comes to logic synthesis.
<mwk>
lofty: what I'm saying is that EDA, FOSS or not, is not anywhere near the level of maturity or level of unifiedness of toolchains for C/C++ like LLVM; do you really want to dispute that?
<lofty>
see, that's not what you were saying earlier. you were saying that there was no way the EPFL libraries were going to be LLVM standard.
<mwk>
I'm saying they're quite lacking in scope compared to what LLVM is
<lofty>
"it's some clever algorithms stuffed into a package"
<lofty>
how reductionist.
<mwk>
but that's what's important
<lofty>
sure, if you think that EPFL is just some clever algorithms stuffed into a package, then so is ABC. so is LLVM. so is GCC.
<mwk>
yeah, abc is algorithms in a package
<lofty>
"but that's not how LLVM is, LLVM is an intelligent flow from C to machine code"
<mwk>
LLVM and gcc have the defining feature of having a compiler driver
<mwk>
you give it the C file, configure a target, get a binary file
<lofty>
jesus christ.
<mwk>
that's the ease of use that defines an actual usable toolchain
<mwk>
*and* comprehensiveness
lofty has left #yosys [ah, fuck this shit, it's not worth it.]
vidbina_ has quit [Ping timeout: 258 seconds]
<lkcl>
i encountered this when working on samba.
<lkcl>
which is 7+ separate and distinct networking protocols
<lkcl>
and about 25 separate programs (separate networking daemons)
<lkcl>
but as far as end-users were concerned, they'd ask, "hi, i want a samba"
<lkcl>
(singular)
<lkcl>
mwk, you seem to be displaying similar expectations
<lkcl>
an expectation of simplicity which is typically achieved by large billion-dollar companies delivering monolithic products.
<lkcl>
software libre is literally the total polar opposite of that, even within a given project
<lkcl>
apache2 for example was actually just one server that was developed as a use-case of libapr.
<lkcl>
the Apache Software Foundation encouraged and expected other software teams to develop services that had absolutely nothing to do with HTTP or HTTPS
<Sarayan>
Don't we have a numbers of parts for that already? rtlil as the IR, yosys for verilog and maybe vhdl, nmigen for, well, nmigen, nextpnr + a number of backends for final compilation?
<lkcl>
indeed
<lkcl>
then coriolis2 takes either RTLIL or Verilog, calls *back* into yosys to generate BLIF
<mwk>
yes, I expect to have tools that are actually easy to use
<Sarayan>
perhaps a (non-trivial) effort to unify all that into something software-compiler like that actually makes it easy would be possible
<mwk>
and that actually work well together
<lkcl>
coriolis2 then reads the BLIF format and converts it to internal "AP" (Alliance) format
<mwk>
nmigen, by the way, is an example of a project that *gets it right*
<mwk>
and is not developed by a bilion-dollar company
<lkcl>
as well as a subset of VHDL
<mwk>
yosys does not
<lkcl>
mwk: bear in mind you're very much annoying lofty by not listening to what he's saying, i'd be interested to hear why you believe that to be the case
<lkcl>
from my perspective, yosys does an absolutely fantastic job of converting from one file-format to another-file-format
<lkcl>
it does the job, and, in the UNIX philosophy, it does the job well and does not need to be expanded to do other jobs
<Sarayan>
well, yosys does multiple jobs in practice
<lkcl>
(although there is the plugin system which allows people to expand to other areas)
<mwk>
unix philosophy is bullshit and has always been
<mwk>
either way
<mwk>
the problem with yosys is... subtle
<lkcl>
mwk, ahhh, ok. that statement tells me many things.
<Sarayan>
unix' cc has always done compiling, assembling and linking, so there
<mwk>
well, the obvious problem is that we still have no unified tool that takes a .v file and produces a .bit file
<mwk>
that is very much the part that nmigen gets right, btw
<mwk>
but about yosys itself
<lkcl>
mwk: that's because it's not yosys's job.
<lkcl>
yosys is an *intermediary* tool.
<Sarayan>
lkcl: it should be somthing's job
<mwk>
it's simultanously a pack of random passes and a pack of "full synthesis flows"
<lkcl>
i just compiled up enough pieces of symbiflow to get an arty a7 .bit running
<mwk>
and the two are not really well separated
<lkcl>
the basis is that symbiflow *uses* yosys
<lkcl>
just as nmigen uses yosys
<lkcl>
and coriolis2 uses yosys
<lkcl>
and the openroad toolchain uses yosys
<lkcl>
mwk: should yosys add the entire source code of nmigen to its codebase?
<lkcl>
mwk: should yosys add the entire toolchain of coriolis2 to its codebase?
<lkcl>
mwk: should yosys add the entirety of the symbiflow toolchain to its codebase?
<lkcl>
just so that yosys can be "The One Command"?
<lkcl>
mm?
<mwk>
I never said I wanted yosys to be the one command
<lkcl>
you want "yosys to be the one command that does everything for you, everything built-in", yes?
<mwk>
but we *should* have that command, in some form
<lkcl>
why?
<mwk>
because usability matters?
<mwk>
or would you like to have a C compiler where you run the preprocessor, compiler, assembler and linker separately yourself, every time?
<lkcl>
the question you should be asking yourself is: why isn't everyone asking for this "one command"?
<lkcl>
mwk: i am quite happy to create a Makefile that takes care of that task for me.
<lkcl>
Makefiles are where the job of chaining output together happens
<lkcl>
because - again - part of the unix philosophy that you strongly disagree with - make does the job very well of tracking dependencies and allowing you to express them
<mwk>
lkcl: because people, in general, get used to toolchains that suck, having never seen anything better
<mwk>
and EDA is a whole lot of people getting used to toolchains that suck in ways that software development has outgrown some time ago
<lkcl>
i know where you're coming from, it's just that from over 43 years experience in programming i don't have any problem with using small tools and chaining them together
<lkcl>
this is more, i feel, down to EDA hardware engineers not being trained as software engineers
<mwk>
make, by the way, is impressively bad at its nominal job, which is why nowadays we have ninja
<lkcl>
and, also, tolerating s*** proprietary toolchains because they absolutely have to
<lkcl>
ok. yep, i'm done with this conversation, too.
<lkcl>
sorry, mwk: stating that make is "bad" is too much.
<mwk>
yes, there are better tools than make
<mwk>
and believing that tools are good because you're used to them is exactly what gets us into never improving them
<jeanthom>
"EDA hardware engineers not being trained as software engineers" this is totally true from my POV, but is this really a problem?
<mwk>
make has never been good, that's why everyone uses a wrapper like autoconf or cmake, or spends a lot of time making their own mess
<mwk>
you begin either rolling your own mess or using existing wrappers as soon as you want automatically-managed header dependencies in C
<mwk>
sure, it's possible to do this using make itself, but we *have better tools*, and we should be striving to build the same kind of better tools for EDA as well
<mwk>
jeanthom: let's say that software engineering has solved a lot of problems that remain unsolved in the hardware world
<mwk>
often for no good reason
emeb has joined #yosys
vidbina_ has joined #yosys
<Sarayan>
autoconf has never been about generating makefiles, automake is, and automake is an atrocious pile of crap
vidbina_ has quit [Ping timeout: 252 seconds]
GenTooMan has quit [Ping timeout: 258 seconds]
GenTooMan has joined #yosys
emeb has quit [Quit: Leaving.]
vidbina_ has joined #yosys
emeb_mac has joined #yosys
vidbina_ has quit [Ping timeout: 258 seconds]
tmiw_ has joined #yosys
tmiw_ has quit [Quit: leaving]
tmiw has joined #yosys
tmiw is now known as tmiw_
tmiw_ is now known as tmiw
emeb_mac has quit [Ping timeout: 252 seconds]
emeb_mac has joined #yosys
FL4SHK has quit [Ping timeout: 250 seconds]
jeanthom has quit [Ping timeout: 258 seconds]
strobo has quit [Read error: Connection reset by peer]