| *** tpb <[email protected]> has joined #yosys | 00:00 | |
| *** cr19011 <cr19011!~William@2601:8d:8600:911:b49d:fc45:e620:8cca> has joined #yosys | 01:09 | |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:dd5b:fb73:8d84:fc76> has quit IRC (Ping timeout: 250 seconds) | 01:11 | |
| *** cr19011 is now known as cr1901 | 01:14 | |
| *** emeb_mac <[email protected]> has quit IRC (Ping timeout: 258 seconds) | 03:44 | |
| *** emeb_mac <[email protected]> has joined #yosys | 03:45 | |
| *** nak_ <nak_!~nak@yosys/nak> has joined #yosys | 04:24 | |
| *** nak <nak!~nak@yosys/nak> has quit IRC (Ping timeout: 258 seconds) | 04:26 | |
| *** emeb_mac <[email protected]> has quit IRC (Quit: Leaving.) | 07:06 | |
| *** tlwoerner_ <[email protected]> has joined #yosys | 08:04 | |
| *** somlo_ <[email protected]> has joined #yosys | 08:04 | |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #yosys | 08:04 | |
| *** sm2n_ <sm2n_!~sm2n@user/sm2n> has joined #yosys | 08:04 | |
| *** buhman <buhman!sid411355@user/buhman> has quit IRC (Ping timeout: 256 seconds) | 08:06 | |
| *** killjoy <killjoy!~nameless@user/killjoy> has quit IRC (Ping timeout: 252 seconds) | 08:06 | |
| *** tlwoerner <[email protected]> has quit IRC (Ping timeout: 245 seconds) | 08:06 | |
| *** chipb <chipb!~chipb@user/chipb> has quit IRC (Ping timeout: 245 seconds) | 08:07 | |
| *** philtor <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 08:07 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 256 seconds) | 08:07 | |
| *** sm2n <sm2n!~sm2n@user/sm2n> has quit IRC (Ping timeout: 256 seconds) | 08:07 | |
| *** killjoy <[email protected]> has joined #yosys | 08:07 | |
| *** somlo <[email protected]> has quit IRC (Remote host closed the connection) | 08:08 | |
| *** buhman <buhman!sid411355@user/buhman> has joined #yosys | 08:08 | |
| *** philtor <[email protected]> has joined #yosys | 08:08 | |
| *** chipb <chipb!~chipb@user/chipb> has joined #yosys | 08:09 | |
| *** vidbina_ <[email protected]> has joined #yosys | 08:13 | |
| *** vidbina_ <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 08:42 | |
| *** Niklas[m]1 <Niklas[m]1!~nsmlzlmat@2001:470:69fc:105::c93a> has joined #yosys | 08:46 | |
| *** strobo <[email protected]> has joined #yosys | 09:12 | |
| *** jeanthom <[email protected]> has joined #yosys | 09:22 | |
| *** vidbina_ <[email protected]> has joined #yosys | 11:08 | |
| lkcl | folks building yosys with gcc-8 (debian/10 stable) fails with requesting -fPIC be added to CFLAGS. just fyi | 11:31 |
|---|---|---|
| lofty | lkcl: which version of yosys? | 11:37 |
| lkcl | lofty: latest git | 12:24 |
| lofty | latest is not a version | 12:24 |
| lkcl | i'm temporarily building with clang instead | 12:24 |
| lkcl | gcc --version | 12:24 |
| lkcl | gcc (Debian 8.3.0-6) 8.3.0 | 12:24 |
| lkcl | git master branch, as of right now. | 12:24 |
| lkcl | or, more accurately, about 4 hours ago | 12:25 |
| lkcl | i've come across this one before (quite frequently, over the years). -fPIC added to CFLAGS does indeed solve the problem | 12:27 |
| lofty | lkcl: https://github.com/YosysHQ/yosys/blob/master/Makefile#L88 <-- fPIC is already in there. | 12:28 |
| lofty | Wait, added to CFLAGS? | 12:28 |
| lofty | That means ABC. | 12:29 |
| lkcl | yes, that sounds about right. | 12:29 |
| lofty | PR it. | 12:30 |
| lofty | Actually, hmm | 12:30 |
| lofty | The Yosys makefile never sets CFLAGS ^.^ | 12:30 |
| lofty | So if anywhere, it would go in the ABC repo | 12:30 |
| lkcl | apologies, you use github, so until fedforge is up and running i'll not be able to do that. | 12:30 |
| lofty | And, uh, good luck getting anything merged there. | 12:31 |
| lkcl | intriguing. does it set CXXFLAGS? | 12:31 |
| lofty | Yes, it sets CXXFLAGS, as I pointed to | 12:31 |
| lkcl | yes, this is the "normal" response, very sadly. quite disrespectful, i have to be honest. | 12:32 |
| lkcl | luckily in this case i have a workaround, which is to use config-clang instead | 12:32 |
| gatecat | I wonder if this is a manifestation of https://github.com/YosysHQ/yosys/issues/2011 in some form | 12:33 |
| * lkcl taking a look | 12:33 | |
| lkcl | "Configure Yosys build with CXX := clang++" - hmmm | 12:34 |
| lofty | ABC is pretty passively maintained | 12:35 |
| lofty | It's unfortunate that so much of Yosys relies on it (Vivado does too, but they pay Alan to maintain it) | 12:35 |
| lkcl | yes, definitely CXX is not a c compiler, and if flags have been passed through CXXFLAGS but not CFLAGS, that would brak | 12:35 |
| lkcl | oh btw it may be of interest: i spoke to the developer of ABC a few months ago, about a maaaassive memory issue | 12:36 |
| lkcl | he pointed out that there is now a way faster file format | 12:36 |
| gatecat | xaig, or something else ? | 12:36 |
| lkcl | i can't remember off the top of my head | 12:37 |
| lofty | XAIGER. | 12:37 |
| lkcl | 1 sec will see if i can find it | 12:37 |
| lofty | But the ABC flow uses BLIF instead. | 12:37 |
| lkcl | yes, AIGER. Alan... Mischenko? | 12:37 |
| lkcl | yeahh. we end up with something like gigabyte BLIF files :) | 12:38 |
| lofty | Alan Mishchenko, yeah. | 12:38 |
| lkcl | ohh i remember what it was: it was SRAMs being expanded out to DFFs | 12:38 |
| lkcl | we ended up with memory corruption, the resultant BLIF file was so large :) | 12:39 |
| lkcl | solved it thanks to Staf Verhaegen (Chips4Makers) who very kindly designed a custom 4k SRAM cell for us | 12:39 |
| lofty | Business as usual then | 12:40 |
| lofty | ABC breaks on big-endian machines and is not ASAN-clean | 12:40 |
| lofty | (LSOracle also breaks on big-endian machines, but there's not a great deal we can do about that) | 12:40 |
| lkcl | lol a known problem, that one, clearly :) | 12:41 |
| lofty | Hey, maybe somebody tries to run Yosys on their IBM z machine they paid xty million for | 12:42 |
| lkcl | i have to say, apart from pushing the boundaries, i'm just deeply impressed that yosys even exists | 12:42 |
| lofty | I'm impressed Yosys exists, but we're quite a way off "pushing the boundaries" :P | 12:43 |
| lkcl | lofty, you know we went to Imec 180nm tape-out, entirely with Libre-licensed tools, last month? | 12:43 |
| lkcl | and not with openroad / openlane, either: it was with alliance / coriolis2 | 12:43 |
| lkcl | yosys was a huge part of the success of that | 12:44 |
| lofty | Full disclosure: my present job gets DARPA funding, and that's aimed at improving the OpenROAD flow. | 12:44 |
| lkcl | nice. | 12:45 |
| lkcl | well it benefits everyone | 12:45 |
| 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 | 12:46 |
| lofty | Besides, since it's FOSS it's not like I get paid more for saying that :P | 12:47 |
| lkcl | :) | 12:49 |
| mwk | ... ah right, superior non-big-endian clean tool | 12:57 |
| mwk | *sigh* seriously, is there some kind of rule that EDA tools have to be written Like That? | 12:57 |
| lkcl | irony is, in VHDL, Paul Mackerras added Microwatt LE/BE support in something like 80 lines of VHDL. | 12:59 |
| lofty | mwk: Trying to find big-endian hardware for these things is hard, but at least I discovered it >.> | 12:59 |
| 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 | 13:00 |
| lkcl | IBM POWER8 / POWER9 would do it... and Toshaan Bharvani recompiled Fedora for both LE and BE. | 13:00 |
| mwk | really | 13:00 |
| mwk | the whole EDA space has SO MUCH 1990s-era shit C/C++ tooling feel to it | 13:01 |
| mwk | ... please someone write a LLVM | 13:03 |
| 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 | 13:03 |
| lofty | mwk: that LLVM is mockturtle | 13:03 |
| mwk | lofty: no it's not | 13:04 |
| sorear | trouble finding hardware? | 13:04 |
| mwk | it's some clever algorithms stuffed into a package | 13:04 |
| lofty | So is LLVM! | 13:05 |
| mwk | but it's not anywhere close to a full flow | 13:05 |
| mwk | LLVM reads C code and outputs runnable binaries | 13:05 |
| lofty | LLVM does no such thing | 13:05 |
| lofty | *Clang* that wraps LLVM does | 13:06 |
| mwk | clang is part of the LLVM project | 13:06 |
| lkcl | clang's a front-end which generates IR. | 13:07 |
| lkcl | LLVM-IR then compiles that into an executable | 13:07 |
| lkcl | that's the very-much-simplified version | 13:07 |
| mwk | I know how LLVM works | 13:07 |
| lofty | The frontend for that is alice. | 13:08 |
| lofty | if clang's job is to turn C code into LLVM IR | 13:08 |
| lofty | Then alice converts Verilog/AIGER/BLIF into mockturtle networks | 13:08 |
| 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 | 13:08 |
| sorear | which part of this is CIRCT | 13:08 |
| mwk | the point is: there is a unified set of libraries developed by a unified team that combines together to a full usable flow | 13:08 |
| * lofty gives up | 13:09 | |
| mwk | and there is no such thing for EDA | 13:09 |
| mwk | yosys/nextpnr is kind-of close, but it has big problems, and abc is one of them | 13:09 |
| lofty | mwk: as one friend to another, I suggest you close your mouth before you stick your foot any further into it. | 13:10 |
| lofty | Or else you might actually make me quit the FOSS EDA scene like I've considered several times before | 13:12 |
| 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 | 13:13 |
| lofty | finding jobs in the open FPGA community, including one that has not paid me for the better part of eight weeks | 13:13 |
| lofty | for you to tell me I do not know what I'm talking about when it comes to logic synthesis. | 13:14 |
| 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? | 13:16 |
| 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. | 13:18 |
| mwk | I'm saying they're quite lacking in scope compared to what LLVM is | 13:19 |
| lofty | "it's some clever algorithms stuffed into a package" | 13:20 |
| lofty | how reductionist. | 13:20 |
| mwk | but that's what's important | 13:20 |
| 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. | 13:20 |
| mwk | yeah, abc is algorithms in a package | 13:21 |
| lofty | "but that's not how LLVM is, LLVM is an intelligent flow from C to machine code" | 13:21 |
| mwk | LLVM and gcc have the defining feature of having a compiler driver | 13:21 |
| mwk | you give it the C file, configure a target, get a binary file | 13:21 |
| lofty | jesus christ. | 13:21 |
| mwk | that's the ease of use that defines an actual usable toolchain | 13:21 |
| mwk | *and* comprehensiveness | 13:22 |
| *** lofty <[email protected]> has left #yosys (ah, fuck this shit, it's not worth it.) | 13:22 | |
| *** vidbina_ <[email protected]> has quit IRC (Ping timeout: 258 seconds) | 13:22 | |
| lkcl | i encountered this when working on samba. | 13:23 |
| lkcl | which is 7+ separate and distinct networking protocols | 13:24 |
| lkcl | and about 25 separate programs (separate networking daemons) | 13:24 |
| lkcl | but as far as end-users were concerned, they'd ask, "hi, i want a samba" | 13:24 |
| lkcl | (singular) | 13:24 |
| lkcl | mwk, you seem to be displaying similar expectations | 13:25 |
| lkcl | an expectation of simplicity which is typically achieved by large billion-dollar companies delivering monolithic products. | 13:25 |
| lkcl | software libre is literally the total polar opposite of that, even within a given project | 13:26 |
| lkcl | apache2 for example was actually just one server that was developed as a use-case of libapr. | 13:27 |
| lkcl | the Apache Software Foundation encouraged and expected other software teams to develop services that had absolutely nothing to do with HTTP or HTTPS | 13:27 |
| 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? | 13:27 |
| lkcl | indeed | 13:28 |
| lkcl | then coriolis2 takes either RTLIL or Verilog, calls *back* into yosys to generate BLIF | 13:28 |
| mwk | yes, I expect to have tools that are actually easy to use | 13:28 |
| Sarayan | perhaps a (non-trivial) effort to unify all that into something software-compiler like that actually makes it easy would be possible | 13:28 |
| mwk | and that actually work well together | 13:29 |
| lkcl | coriolis2 then reads the BLIF format and converts it to internal "AP" (Alliance) format | 13:29 |
| mwk | nmigen, by the way, is an example of a project that *gets it right* | 13:29 |
| mwk | and is not developed by a bilion-dollar company | 13:29 |
| lkcl | as well as a subset of VHDL | 13:29 |
| mwk | yosys does not | 13:29 |
| 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 | 13:30 |
| lkcl | from my perspective, yosys does an absolutely fantastic job of converting from one file-format to another-file-format | 13:31 |
| 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 | 13:31 |
| Sarayan | well, yosys does multiple jobs in practice | 13:31 |
| lkcl | (although there is the plugin system which allows people to expand to other areas) | 13:31 |
| mwk | unix philosophy is bullshit and has always been | 13:32 |
| mwk | either way | 13:32 |
| mwk | the problem with yosys is... subtle | 13:32 |
| lkcl | mwk, ahhh, ok. that statement tells me many things. | 13:32 |
| Sarayan | unix' cc has always done compiling, assembling and linking, so there | 13:32 |
| mwk | well, the obvious problem is that we still have no unified tool that takes a .v file and produces a .bit file | 13:33 |
| mwk | that is very much the part that nmigen gets right, btw | 13:33 |
| mwk | but about yosys itself | 13:33 |
| lkcl | mwk: that's because it's not yosys's job. | 13:33 |
| lkcl | yosys is an *intermediary* tool. | 13:33 |
| Sarayan | lkcl: it should be somthing's job | 13:33 |
| mwk | it's simultanously a pack of random passes and a pack of "full synthesis flows" | 13:34 |
| lkcl | i just compiled up enough pieces of symbiflow to get an arty a7 .bit running | 13:34 |
| mwk | and the two are not really well separated | 13:34 |
| lkcl | the basis is that symbiflow *uses* yosys | 13:34 |
| lkcl | just as nmigen uses yosys | 13:34 |
| lkcl | and coriolis2 uses yosys | 13:35 |
| lkcl | and the openroad toolchain uses yosys | 13:35 |
| lkcl | mwk: should yosys add the entire source code of nmigen to its codebase? | 13:35 |
| lkcl | mwk: should yosys add the entire toolchain of coriolis2 to its codebase? | 13:35 |
| lkcl | mwk: should yosys add the entirety of the symbiflow toolchain to its codebase? | 13:36 |
| lkcl | just so that yosys can be "The One Command"? | 13:36 |
| lkcl | mm? | 13:36 |
| mwk | I never said I wanted yosys to be the one command | 13:36 |
| lkcl | you want "yosys to be the one command that does everything for you, everything built-in", yes? | 13:37 |
| mwk | but we *should* have that command, in some form | 13:37 |
| lkcl | why? | 13:37 |
| mwk | because usability matters? | 13:37 |
| mwk | or would you like to have a C compiler where you run the preprocessor, compiler, assembler and linker separately yourself, every time? | 13:37 |
| lkcl | the question you should be asking yourself is: why isn't everyone asking for this "one command"? | 13:37 |
| lkcl | mwk: i am quite happy to create a Makefile that takes care of that task for me. | 13:38 |
| lkcl | Makefiles are where the job of chaining output together happens | 13:38 |
| 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 | 13:39 |
| mwk | lkcl: because people, in general, get used to toolchains that suck, having never seen anything better | 13:39 |
| 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 | 13:40 |
| 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 | 13:40 |
| lkcl | this is more, i feel, down to EDA hardware engineers not being trained as software engineers | 13:40 |
| mwk | make, by the way, is impressively bad at its nominal job, which is why nowadays we have ninja | 13:41 |
| lkcl | and, also, tolerating s*** proprietary toolchains because they absolutely have to | 13:41 |
| lkcl | ok. yep, i'm done with this conversation, too. | 13:42 |
| lkcl | sorry, mwk: stating that make is "bad" is too much. | 13:42 |
| mwk | yes, there are better tools than make | 13:44 |
| mwk | and believing that tools are good because you're used to them is exactly what gets us into never improving them | 13:45 |
| jeanthom | "EDA hardware engineers not being trained as software engineers" this is totally true from my POV, but is this really a problem? | 13:45 |
| 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 | 13:46 |
| mwk | you begin either rolling your own mess or using existing wrappers as soon as you want automatically-managed header dependencies in C | 13:46 |
| 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 | 13:47 |
| mwk | jeanthom: let's say that software engineering has solved a lot of problems that remain unsolved in the hardware world | 13:50 |
| mwk | often for no good reason | 13:50 |
| *** emeb <[email protected]> has joined #yosys | 13:58 | |
| *** vidbina_ <[email protected]> has joined #yosys | 14:31 | |
| Sarayan | autoconf has never been about generating makefiles, automake is, and automake is an atrocious pile of crap | 14:54 |
| *** vidbina_ <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 15:38 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has quit IRC (Ping timeout: 258 seconds) | 15:50 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has joined #yosys | 15:50 | |
| *** emeb <[email protected]> has quit IRC (Quit: Leaving.) | 15:59 | |
| *** vidbina_ <[email protected]> has joined #yosys | 16:06 | |
| *** emeb_mac <[email protected]> has joined #yosys | 16:06 | |
| *** vidbina_ <[email protected]> has quit IRC (Ping timeout: 258 seconds) | 17:03 | |
| *** tmiw_ <[email protected]> has joined #yosys | 17:41 | |
| *** tmiw_ <[email protected]> has quit IRC (Quit: leaving) | 17:46 | |
| *** tmiw <[email protected]> has joined #yosys | 17:51 | |
| *** tmiw is now known as tmiw_ | 17:55 | |
| *** tmiw_ is now known as tmiw | 17:55 | |
| *** emeb_mac <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 19:33 | |
| *** emeb_mac <[email protected]> has joined #yosys | 19:37 | |
| *** FL4SHK <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 21:26 | |
| *** jeanthom <[email protected]> has quit IRC (Ping timeout: 258 seconds) | 21:27 | |
| *** strobo <[email protected]> has quit IRC (Read error: Connection reset by peer) | 21:30 | |
| *** strobo <[email protected]> has joined #yosys | 21:31 | |
| *** vidbina_ <[email protected]> has joined #yosys | 21:32 | |
| *** vidbina_ <[email protected]> has quit IRC (Ping timeout: 258 seconds) | 21:37 | |
| *** emeb_mac <[email protected]> has quit IRC (Ping timeout: 258 seconds) | 21:38 | |
| *** vidbina_ <[email protected]> has joined #yosys | 22:00 | |
| *** emeb_mac <[email protected]> has joined #yosys | 22:16 | |
| *** vidbina_ <[email protected]> has quit IRC (Ping timeout: 240 seconds) | 23:03 | |
| whitequark | wtf happened here | 23:05 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!