<awygle>
is conan endorsed by the committee? i've never heard of it before tbh
<Sarayan>
a makefile-ish generator should not download dependencies, that's a fucking abstraction inversion
<whitequark>
it isn't, it's just a third party program
<whitequark>
Sarayan: hm? that's cmake
<whitequark>
people download dependencies in cmake too and *that* is really awful
<whitequark>
usually it's over http and without checksumming, too
<Sarayan>
yeah, slang fucking integrated conan in the cmakefile
<whitequark>
oh
<whitequark>
ok yeah that sucks
<whitequark>
maybe they'd be open to reconsidering?
<whitequark>
or even vendoring the two tiny libs they use
<Sarayan>
fmt and Catch2?
<whitequark>
yeah
<awygle>
could open an issue or hit him up in the gitter channel
<awygle>
seems fairly active
<whitequark>
wait, you don't need catch2 even
<whitequark>
it's just for tests
<awygle>
whitequark: meant to ask you this the other day but you looked at edalize for nmigen.back, right? did you decide it was inadequate in some way?
<whitequark>
awygle: yes, and yes
<Sarayan>
hmmmm, it's forgetting to add its own include directory in -I
<Sarayan>
but that's only the tests
<awygle>
what was inadequate about it?
<whitequark>
looking atm
<whitequark>
ah yeah
<whitequark>
the problem was that it used make
<whitequark>
that's quite unfortunate on windows, because it means nmigen has to depend on mingw or cygwin
<whitequark>
(it uses gnu make extensions too)
<awygle>
that seems fairly incidental, did it use make in some central way? if not feels like switching to e.g. scons wouldn't be that hard, i could talk to olof about it
<whitequark>
wait, nmigen.back or nmigen.build?
<whitequark>
nmigen.back specifically avoids messing with temporary files, etc, being as non-invasive as possible. ideally at some point we'll ship yosys in wasm as a pip package or something like that.
<awygle>
i don't know the differences
<whitequark>
nmigen.back.rtlil is pure Python
<whitequark>
nmigen.back.verilog uses Yosys to convert RTLIL to Verilog
<whitequark>
nmigen.build is a template based build system, somewhat similar to what edalize does
<awygle>
that is probably what i meant then
<awygle>
nmigen.build drives the EDA tools, nmigen.back deals with languages?
<whitequark>
nmigen.build focused on two properties:
<whitequark>
(yes)
<whitequark>
1) it needs to work on windows and linux equally well without any compromises (i.e. no bashisms unless toolchain requires them on unix; no third party interpreters on windows)
<whitequark>
2) it needs to produce *portable build plans* rather than work directories, so that
<whitequark>
2a) you can copy the build plan (a zip archive) to a remote server and build it there, or perhaps upload it to a github issue as an MCVE
<whitequark>
2b) no step of the process before the actual build would touch the filesystem
<Sarayan>
nmigen/yosys/cxxrtl was trivial to integrate using make
<Sarayan>
it was very nice
<awygle>
those seem like very good properties, yes
<Sarayan>
I'm not 100% on the lack of separation between HDL and "code generation", but I must admit it works
<whitequark>
awygle: the thing is that edalize isn't actually very complex, nor does it contain a lot of development effort (with all respect to olof, it's just a simple library)
<Sarayan>
arguably, I should be the one separating it mind you
<awygle>
yeah, that's not too surprising honestly
<awygle>
fusesoc is similar
<awygle>
but with the benefit of more time
<whitequark>
and nmigen has fairly specific requirements that would likely mean extending edalize and developing with lockstep in it or something
<awygle>
mhm
<awygle>
was just curious
<whitequark>
for example, take a look at the vivado script
<awygle>
hate to see more fragmentation in the ecosystem, but also, gotta use the best tool for your use case
<whitequark>
it uses some clever tcl to extract FF synchronizer input delay specifications and apply them to the right clock in Vivado
<whitequark>
anyway. i don't really feel like this is fragmentation. edalize is an application-specific frontend for a bunch of EDA tools. so is nmigen.build, and the two of them have different applications
<awygle>
yep
<whitequark>
what i felt would be fragmentation would be, for example, if nmigen gained its own c++ backend
<whitequark>
so i convinced key2 that it would be better to do yosys cxxrtl
<whitequark>
(which i should finish upstreaming soon-ish)
<Sarayan>
arguably, the properties of nmigen makes it more suitable to generate efficient native code than generic verilog
<Sarayan>
are loops allowed in particular?
<awygle>
yeah cxxrtl is Good
<whitequark>
generic? yes. but cxxrtl doesn't deal with verilog, generic or not
<awygle>
at least as a concept, and probably in implementation just because you're good at what you do
<whitequark>
cxxrtl deals with rtlil alone, which is equivalent to a subset of synthesizable verilog
<whitequark>
awygle: thanks :)
<Sarayan>
awygle: oh the implementation is nice, I'm shaking out some bugs and it's going to be just beautiful
<awygle>
(this is wildly off topic but i feel a need to complain at somebody - i'm in the office at 1am, and there's _still_ a coworker next to me yelling into a conference line, and another coworker failing to implement functionality i critically need)
<Sarayan>
I suspect I'm the first one external to use it in anger :-)
<whitequark>
awygle: wow, that seems a bit dysfunctional
<awygle>
i have no idea what jim is doing here, to be honest. i assume he's conferencing with one of our offices in another geo.
<Sarayan>
the former is just an annoying twit I guess, the latter is more problematic. Is the functionality actually doable? :-)
<awygle>
i'm only here due to bad time management on my part
<Sarayan>
(anyone tends to become an annoying twit once conference calls happen)
<awygle>
yes, the functionality is doable, and i was told it worked now as of like... 2pm this afternoon, and i need it by 7:30am
<whitequark>
Sarayan: i think actually there was someone who used cxxrtl before you
<Sarayan>
wq: cool
<awygle>
whitequark: this office is actually _surprisingly_ functional usually, but jim (coworker) is one of those "can't say no" types, and this project in particular has been a bit of a mess.
<awygle>
at least all my bosses up to the CEO realize it's a mess and are giving me the support and authority i need to pull it off
<whitequark>
awygle: i just mean... the only times i've been in an office at 1am was when i was late to the train, or when the aircon at home was broken. and i thought i tend to stay late.
<whitequark>
if it works for you, i guess it's fine though.
<awygle>
i went home at 4 and took a nap
<whitequark>
good luck with the mess.
<whitequark>
ah.
<awygle>
thanks, it'll be fine, i just felt like complaining :p
<awygle>
lmao, last commit at 1pm: "another attempt at fixing $feature"
<Sarayan>
okay, slanf is compiled, nice
<Sarayan>
slang
<awygle>
nice
<Sarayan>
of course slang is the name of another package too, but heh
<Sarayan>
ok, it's parsing fx68k without bitching, that's nice
<Sarayan>
errr
<Sarayan>
whitequark, given fx68k is written in systemverilog, is there any change cxxrtl can tackle it?
<Sarayan>
it's synchronous sv and stuff, but still it's sv
<Sarayan>
not rtlil
<Sarayan>
at least not explicitly
<whitequark>
Sarayan: if you can get yosys to synthesize it, the answer is "yes, definitely
<Sarayan>
ok, good
<Sarayan>
I'm not losing my time then :-)
<whitequark>
(really, if you can get yosys to parse it)
<ZirconiumX>
Morning
<awygle>
i kinda want to write a yosys firrtl frontend
<Sarayan>
(surprise, yosys doesn't parse it, but we already knew that)
<whitequark>
(but if it parses incorrectly somehow and doesn't synthesize because of that, then i'm not responsible for it not simulating :)
<whitequark>
awygle: sounds pretty good imo
<whitequark>
i'm thinking about an nmigen firrtl backend
<awygle>
seems very approachable as aproject too
<awygle>
nicely specified, fairly small scope, should map pretty well to rtlil
<awygle>
got other shit going on (hi ZirconiumX), but maybe later
<whitequark>
wow, firrtl doesn't have negedge stuff?
<whitequark>
i didn't expect that
<Sarayan>
ZX: quartus_asm has a PDB_DUMP_ASCII option hidden somewhere in the config, I'm trying to make it enable it
<whitequark>
was it because of ICSI/ISSI mess of the names?
<awygle>
probably
<whitequark>
i had *so much* trouble finding it
<whitequark>
i recall spending like four hours googling various IC logo collections
<awygle>
well thank you for saving me from that fate
<whitequark>
awygle: have you hit the lack of -D/-I in nmigen verilog support yet?
<awygle>
no
<whitequark>
huh. less useful than i thought, i guess
<awygle>
well, i shouldn't say no
<awygle>
as sump2 still doesn't work, so i haven't actually gotten a verilog instance working yet
<awygle>
so maybe that's why :p
Asu has joined #nmigen
<awygle>
in case anyone was worried about me, i have now fixed the broken functionality.
<whitequark>
heh. what was it?
<awygle>
importing settings didn't update the existing settings
<awygle>
just created a new settings o ject and threw it away
<awygle>
i have now completed a successful dry run on my development system, time to do a less dry run ( a wet run? ... no, definitely not that) on the real hardware and then go to bed woohoo