kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined ##openfpga
tlwoerner has joined ##openfpga
Degi has quit [Ping timeout: 260 seconds]
Degi has joined ##openfpga
Bike has quit [Quit: Lost terminal]
_whitelogger has joined ##openfpga
cr1901_modern has joined ##openfpga
cr1901_modern1 has quit [Ping timeout: 258 seconds]
_whitelogger has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
<omnitechnomancer>
Is there any way to get dot to convert somewhat large diagrams from yosys show? or do I just have to wait forever?
<tnt>
wait forever
<omnitechnomancer>
alas
<tnt>
usually I try to only show part of the design I'm interested in ...
<tnt>
large diagrams are unreadable anyway.
<omnitechnomancer>
So a SERV with no register file or RF interface adapting fits into 163 74 series logic devices assuming no horrible synthesis problems which I need to check for
flammit has quit [Ping timeout: 272 seconds]
guan has quit [Ping timeout: 272 seconds]
pointfree has quit [Ping timeout: 272 seconds]
flammit has joined ##openfpga
guan has joined ##openfpga
pointfree has joined ##openfpga
reportings has quit [Ping timeout: 272 seconds]
reportings has joined ##openfpga
flammit has quit [Ping timeout: 272 seconds]
flammit has joined ##openfpga
indefini[m] has quit [Quit: Idle for 30+ days]
jeanthom has joined ##openfpga
<z0ttel>
omnitechnomancer: Have you tested json output with netlistsvg rendering? I felt like those were faster on my machine.
<omnitechnomancer>
though I am not sure where some input ports went
<z0ttel>
yeah, those tend to end up close to where they're used.
<z0ttel>
If all the ports are just labelled "input" and "output", it's a bug that names with dots in them aren't rendered.
<omnitechnomancer>
hmmm
<omnitechnomancer>
the thing is also pretty big so difficult to navigate
OmniMancer has quit [Quit: Leaving.]
indy has quit [Read error: Connection reset by peer]
indy has joined ##openfpga
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
<implr>
I wonder how much hate would a 'add bazel as a build system' yosys pr get
* whitequark
stabs implr
<whitequark>
if i have to use a jvm to build yosys i would literally fork it instead
<whitequark>
more seriously, i had a plan for a while to refactor the yosys makefiles so that they can be used to export a DAG
<whitequark>
then add a root CMakeLists.txt that would pick that up (abc already does something similar)
jeanthom has joined ##openfpga
<implr>
was thinking of more an alternative than a replacement, i have zero desire to implement the billion different flags the cursed makefiles expose
<daveshah>
The problem with that is you then have two totally separate build systems to maintain
<whitequark>
^ yep
<whitequark>
even though i'd prefer if yosys had cmake, i think that maintaining a completely separate cmake build system is intractable
<whitequark>
maintaining makefiles alone is hard enough!
<whitequark>
since a total replacement has been vetoed multiple times, the only viable solution i see left is a partial replacement
<whitequark>
basically using Makefile.inc files as a declarative build system
<daveshah>
Yes, that does make sense
<whitequark>
(i also feel like cmake is a slightly better option because nextpnr also uses it, but if someone does the job of converting Makefile.inc files to be declarative they damn well deserve to pick their choice of a build system)
<whitequark>
(pssst tag me as a reviewer if you do)
<implr>
yeah i honestly expected nothing more than a veto, those are very sensible reasons
<implr>
the case for massive bazel-like systems is mostly in integration (at least for me), including across multiple languages
<whitequark>
yeah, i feel that
<implr>
so eg. you pin yosys, nextpnr, spinalhdl,vexriscv to exact commit hashes, bazelify your cpp harness for cxxrtl, your hdl, your rv code
<whitequark>
the problem with massive bazel-like systems is that they're a nightmare to work with if you're not a googler
<whitequark>
since angle switched to gn i was not able to build it
<implr>
and then you build everything with a single command
<whitequark>
(as a part of solvespace build)
<whitequark>
(something i am *really* glad is not my problem anymore
<implr>
well i *was* a googler for all of 6 months and i have already been cursed
<whitequark>
i mean i did the same thing with cmake subprojects
<implr>
it really warps your perception, especially since they have a entire teams dedicated to maintaining all the builds
<whitequark>
yeah
<whitequark>
pros: you have a team dedicated to maintaining builds. cons: your software requires having a team dedicated to maintaining builds
<implr>
also my personal hot take is that all the google build systems *except* bazel have no real reasons for existing and most of them are a product of 'we want bazel but we're opensource and bazel is not yet'
<implr>
also bazel used to have crap windows support, reportedly better now
<whitequark>
mhm
<whitequark>
my hot take is that i'll start looking into google build systems once chromium docs no longer effectively say that the recommended way to build it is to become a google employee but there are some workarounds available
<whitequark>
i've had enough of android (though, i do admit, kati is interesting and soong, while being as undocumented as Android.mk, actually is easier to get to work)
<implr>
fair, the chromium situation is ridiculous
mumptai has quit [Remote host closed the connection]
jeanthom has quit [Ping timeout: 240 seconds]
jeanthom has joined ##openfpga
jeanthom has quit [Ping timeout: 258 seconds]
emeb has joined ##openfpga
mumptai has joined ##openfpga
emeb_mac has joined ##openfpga
q3k has joined ##openfpga
* q3k
reads backlogs from irclog.whitequark
<q3k>
some declarative config that could be either ingested into make or bazel would be useful
<q3k>
the problem is that the prime candidate for that sort of extremely verbose, declarative description of build rules for a project really seems to be cc_library/cc_binary bazel calls
<q3k>
don't know of anything else that would be this anal regarding explicit dependencies
<q3k>
but honestly the biggest problems with building yosys with bazel right now is abc
<q3k>
the existing yosys layout and coding standards are of a high enough quality that writing bazel rules for that is quite easy, and so is just maintaining them as an overlay
<q3k>
like, while the makefiles are cursed, the directory layout and dependencies between source code files is pretty structured