ChanServ changed the topic of #yosys to: Yosys Open SYnthesis Suite: https://github.com/YosysHQ/yosys/ | Channel logs: https://libera.irclog.whitequark.org/yosys/
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
cr19011 has joined #yosys
cr1901 has quit [Ping timeout: 250 seconds]
cr19011 is now known as cr1901
emeb_mac has quit [Ping timeout: 258 seconds]
emeb_mac has joined #yosys
nak_ has joined #yosys
nak has quit [Ping timeout: 258 seconds]
emeb_mac has quit [Quit: Leaving.]
tlwoerner_ has joined #yosys
somlo_ has joined #yosys
peeps[zen] has joined #yosys
sm2n_ has joined #yosys
buhman has quit [Ping timeout: 256 seconds]
peepsalot has quit [Ping timeout: 256 seconds]
killjoy has joined #yosys
killjoy has quit [Changing host]
killjoy has joined #yosys
buhman has joined #yosys
philtor has joined #yosys
chipb has joined #yosys
vidbina_ has joined #yosys
vidbina_ has quit [Ping timeout: 268 seconds]
Niklas[m]1 has joined #yosys
strobo has joined #yosys
jeanthom has joined #yosys
vidbina_ has joined #yosys
<lkcl> folks building yosys with gcc-8 (debian/10 stable) fails with requesting -fPIC be added to CFLAGS. just fyi
<lofty> lkcl: which version of yosys?
<lkcl> lofty: latest git
<lofty> latest is not a version
<lkcl> i'm temporarily building with clang instead
<lkcl> gcc --version
<lkcl> gcc (Debian 8.3.0-6) 8.3.0
<lkcl> git master branch, as of right now.
<lkcl> or, more accurately, about 4 hours ago
<lkcl> i've come across this one before (quite frequently, over the years). -fPIC added to CFLAGS does indeed solve the problem
<lofty> lkcl: https://github.com/YosysHQ/yosys/blob/master/Makefile#L88 <-- fPIC is already in there.
<lofty> Wait, added to CFLAGS?
<lofty> That means ABC.
<lkcl> yes, that sounds about right.
<lofty> PR it.
<lofty> Actually, hmm
<lofty> The Yosys makefile never sets CFLAGS ^.^
<lofty> So if anywhere, it would go in the ABC repo
<lkcl> apologies, you use github, so until fedforge is up and running i'll not be able to do that.
<lofty> And, uh, good luck getting anything merged there.
<lkcl> intriguing. does it set CXXFLAGS?
<lofty> Yes, it sets CXXFLAGS, as I pointed to
<lkcl> yes, this is the "normal" response, very sadly. quite disrespectful, i have to be honest.
<lkcl> luckily in this case i have a workaround, which is to use config-clang instead
<gatecat> I wonder if this is a manifestation of https://github.com/YosysHQ/yosys/issues/2011 in some form
* lkcl taking a look
<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]
strobo has joined #yosys
vidbina_ has joined #yosys
vidbina_ has quit [Ping timeout: 258 seconds]
emeb_mac has quit [Ping timeout: 258 seconds]
vidbina_ has joined #yosys
emeb_mac has joined #yosys
vidbina_ has quit [Ping timeout: 240 seconds]
<whitequark> wtf happened here