ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
levi has quit [Ping timeout: 246 seconds]
levi has joined #nmigen
peteut has quit [Ping timeout: 240 seconds]
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
proteus-guy has joined #nmigen
peteut has joined #nmigen
peteut has quit [Ping timeout: 268 seconds]
<Sarayan> Fuck entropy, energy ftw
<Sarayan> hi all
<Sarayan> does someone perchance happen to have IEEE 1800-2017 handy?
<whitequark> sci-hub has it
<Sarayan> hmmm, not sure how the search for it there
<Sarayan> ahhh, it seems to have a doi
<Sarayan> yay
<Sarayan> only 1315 pages
<awygle> but a readable 1315 pages :p
<Sarayan> huhuhu
<awygle> it's actually not that bad, as these things go. it's just... a lot
<awygle> what has you pulling out the standard this evening?
<Sarayan> verible is terrible
<Sarayan> also it's morning here
<awygle> lol
<Sarayan> not only it's really not designed for integration with anything, but it depends on google's let's reinvent libc++ library
<awygle> i wonder if that's where they got the name
<Sarayan> so I'm reconsidering my life choices^W^W^Wwhether to integrate it in yosys, extend the existing parser or create a new, sv-specific parser
<whitequark> google's reinvent libc++ library?
<whitequark> which is that?
<awygle> looks like mithro slapped a makefile _on top of_ bazel: somehow i feel like that is unlikely to help?
<Sarayan> or well, let's reinvent boost
<Sarayan> there's still the abseil dependency which is, I consider, way worse
<awygle> how deeply integrated is it?
<Sarayan> plus the lack of ast and stuff
<awygle> sure, it's not really ready for this use case, that's clear
<Sarayan> it's all over the place
<whitequark> bleh, unfortunate
<awygle> check out instead?
<Sarayan> in part to add c++17 stuff to c++11, in part to add new stuff
<awygle> absolutely not an endorsement, just some stuff i'm aware of
<Sarayan> slang is intriguing
peteut has joined #nmigen
<awygle> slang seems the most promising to me
<Sarayan> of course it uses yet another package manager
<awygle> ~*~C++~*~
<Sarayan> because why the fuck not, heh?
<whitequark> that's not really different than most non-C/C++ software
<whitequark> i guess there are actually people who complain about nmigen having dependencies...
<Sarayan> nmigen does pip, and pip is the closest to standard in the python world as one can make it
<awygle> at least python, rust, etc have canonical package managers, instead of just yolo-ing at the language level like c/c++ do
<whitequark> conan aims to be the canonical c/c++ language package manager, right?
<awygle> tbf the c langs kind of predate package management, so
<Sarayan> mwahahahha python, *a* canonical package manager?
<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
<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> is a template based build system, somewhat similar to what edalize does
<awygle> that is probably what i meant then
<awygle> drives the EDA tools, nmigen.back deals with languages?
<whitequark> 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, 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
<ZirconiumX> Oh damn
<ZirconiumX> That'll help
<mwk> ZirconiumX: morning
<ZirconiumX> Morning mwk
<whitequark> awygle: re firrtl: reminds me of this:
<awygle> whitequark: did i tell you that i randomly ran into one of your lab notes fairly recently?
<whitequark> ha. which one?
<awygle> was reverse-engineering a board, googled a part number, you were the only source for the datasheet :p
<whitequark> which?
<whitequark> wow
<whitequark> was it for the RAM?
<awygle> yep
<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
<whitequark> sweet!
<awygle> hokay bedtime, goodnight all :)
<whitequark> night
proteus-guy has quit [Ping timeout: 272 seconds]
XgF has joined #nmigen
<whitequark> Sarayan: ping
<whitequark> Sarayan: so, the bug you indicated earlier (;)
<whitequark> it is a bug in my code, but not in nmigen or cxxrtl
<Sarayan> oh?
<whitequark> Sarayan: please remove the `expose` line in the yosys script
<whitequark> it's causing a miscompilation
<whitequark> instead, enumerate ports using the, well, ports=[..] argument to convert()
<Sarayan> ports[] takes what, overdrive.o_nhsy, etc?
<whitequark> yeah
<Sarayan> ok, so I need to create it first, no problem
<Sarayan> can I automagically scan for o_* in the class?
<Sarayan> not sure if that's doable in python
<whitequark> kinda gross but sure
<whitequark> you need i_* too
<whitequark> moment
<Sarayan> I don't have any i_* yet amusingly, but eventually I should
<whitequark> Sarayan: [sig for attr, sig in vars(mod).items() if attr[:2] in ("i_", "o_")]
<Sarayan> yep, that fixed it
<Sarayan> or not
<Sarayan> well, I'll see this evening, I can't do it right now. Thanks a lot in any case :-)
<whitequark> np
<whitequark> could be another bug
<whitequark> elsewhere
<Sarayan> including in my code
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel_ has joined #nmigen
electronic_eel_ has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
<awygle> good morning
<whitequark> o/
<ZirconiumX> Morning, awygle
<jfng> would a policy for backporting bugfixes to stable releases be a reasonable thing?
<jfng> we could have an nmigen v0.1 branch, and cherry-pick bugfixes to it
<whitequark> jfng: I think I would rather release more often
<whitequark> stable branches aren't out of question, but it's a lot of effort that is perhaps better spent elsewhere
<whitequark> so if we direct part of that effort towards making upgrades painless, the overall benefit would be higher
<jfng> yeah, and we haven't got that many users
<jfng> how about time based releases ? e.g. once per month
<jfng> DeprecationWarnings are very useful
<ZirconiumX> Once a month is perhaps too much; maybe once every three months or so
<ZirconiumX> Really I think it depends on development speed
<whitequark> i was about to suggest once per two months :p
<awygle> and i was going to say 6 weeks or 12 weeks
<whitequark> where?
<whitequark> I should have fixed all those, and they don't grep here
<jfng> ohh right, I checked out on the wrong commit
<_whitenotifier-3> [nmigen] whitequark commented on issue #291: Need a way to attach attributes to memories -
<whitequark> ok, there were four issues on the tracker for 0.2
<whitequark> and they were all just features/improvements, so I moved them all to 0.3
<whitequark> I'll sleep on it and release 0.2 tomorrow then
<jfng> great, thanks !
peteut has quit [Ping timeout: 268 seconds]
peteut has joined #nmigen
peteut has quit [Ping timeout: 268 seconds]
peteut has joined #nmigen
peteut has quit [Ping timeout: 246 seconds]
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
Asu has quit [Ping timeout: 240 seconds]
Asu has joined #nmigen
Asu has quit [Remote host closed the connection]