ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen · IRC meetings each Monday at 1800 UTC · next meeting November 23th
_whitenotifier-4 has quit [Remote host closed the connection]
emeb has quit [Quit: Leaving.]
<whitequark> awygle: ok, not even (*keep*) makes yosys preserve a non-input that is a register
<whitequark> (for cxxrtl to consume)
<whitequark> this is because it's not even an optimization... at this point it's just normalized to the init value of the register
<d1b2> <esden> Is lambdasoc still the recommended codebase to build upon for RISC-V SOC building using nmigen?
<whitequark> nmigen-soc is not yet generally usable, no
<whitequark> awygle: ironically, this is the consequence of calling proc_prune. which i wrote. ahhh, the consequences of my own actions...
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
<cr1901_modern> Is there a meeting tomorrow (Not that I've anything to bring up)?
ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen · IRC meetings each Monday at 1800 UTC · next meeting TBD
<whitequark> cr1901_modern: no; i'm still focusing on cxxrtl
<whitequark> though the end is in sight
<cr1901_modern> Ack, keep going :)!
lkcl has quit [Ping timeout: 256 seconds]
lkcl has joined #nmigen
emeb_mac has quit [Read error: Connection reset by peer]
emeb_mac has joined #nmigen
lkcl has quit [Ping timeout: 240 seconds]
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
lkcl has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
lkcl has quit [Ping timeout: 240 seconds]
Felkin has joined #nmigen
<Felkin> Yo, yo. Am I right to assume that the only way to get cordic up and running would be by using migen-soc's implementation and fixing up for nmigen?
<whitequark> i think someone might have implemented cordic for nmigen?
<whitequark> but in any case, since it's a pure compute module, you should be able to get it working in no time with nmigen.compat
lkcl has joined #nmigen
<Felkin> Gotcha, will probably give it a go later in the week then. Thanks~
<Felkin> Will try implementing MUSIC using it. Lack of docs on cordic as a whole is killing me. Everyone has a cordic implementation, but no one does anything more than a sin(x) example.
Felkin has quit [Remote host closed the connection]
<whitequark> i know essentially nothing about cordic
<tpw_rules> oh he left
<tpw_rules> i wrote some cordic math routines for avr once
<tpw_rules> they're base 10 but
<tpw_rules> they did implement tan and ln and inverse of those (and the rest of the trig functions through identities)
Felkin has joined #nmigen
<Felkin> Oh I'm here! Just on phone so in/out
<tpw_rules> how did you see my messages then :P
<Felkin> Those notes on cordic would be invaluable
<d1b2> <Darius> I saw some in FPGAs for doing DDS
<d1b2> <TiltMeSenpai> cordic hurts my brain. For some reason, I could never really understand trig
<whitequark> tpw_rules: we have a logger!
<Felkin> Yep, quark's logger
<d1b2> <Darius> Xilinx have a DDS compiler which uses it but I guess that's not relevant to nmigen 😄
<tpw_rules> oh i remembered trying to find it, failing, and assuming you preferred to keep it private
<tpw_rules> all i really have is source code with some block comments
<Felkin> Any examples are helpful
<tpw_rules> let me see if i have the document i wrote on it easily available
<whitequark> tpw_rules: it's literally in the topic
<tpw_rules> i was trying to look because i couldn't access the channel at the time :D
<whitequark> because freenode guidelines require that
<whitequark> oh
<tpw_rules> Felkin: are you a code or a words type of person
<Felkin> Code, for sure
<tpw_rules> alright. the license on what follows is "please don't broadcast the code far and wide"
<Felkin> Roger that
<tpw_rules> the cordic stuff starts in the first file around line 431. the second file generates the "math_consts.h" which encodes the CORDIC lookup tables
<Felkin> Great, thank you so much! This will be invaluable
<tpw_rules> for base 2, really just replace all the 10s with 2s
<tpw_rules> iirc this is largely what i used to implement it: http://www.jacques-laporte.org/TheSecretOfTheAlgorithms.htm but the page has rotted pretty badly and was never very clear
<Felkin> Will check it out. Cordic blew my mind when I learned about it a week or so.
<tpw_rules> it's really neat. and yeah it seems to me (along with anything math >_>) to be very over and yet under explained
<Felkin> Ago* while learning MUSIC. I feel like with nmigen it could be used well for some neat small footprint designs
<tpw_rules> what is MUSIC?
lkcl has quit [Ping timeout: 260 seconds]
<Felkin> It's a direction of arrival estimation algorithm
<tpw_rules> ah
<Felkin> Based on eigen decomposition, very neat too I'm how simple it is.
<Felkin> I got this drone dataset for my DSP class, pitched to use MUSIC on it, check performance. Then implement via cordic, compare.
<Felkin> I'm working on a sort of review of the current state of FPGA design for machine learning workloads. A core part of it is taking a set of algorithms and implementing em using HLS, xilinx block diagrams and then a newer HDL, going with nmigen. I'm thinking of covering cordic as part of the set, since LUT utilization will be an important point if
<Felkin> comparison
lkcl has joined #nmigen
jeanthom has joined #nmigen
Felkin has quit [Ping timeout: 245 seconds]
<emeb_mac> CORDIC is pretty fun. I did a CORDIC rectangular/polar converter for use in demodulation in nmigen a while back -> https://github.com/emeb/orangecrab_adc/blob/master/gateware/nmigen/r2p.py
jeanthom has quit [Ping timeout: 256 seconds]
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
chipmuenk has joined #nmigen
jeanthom has joined #nmigen
nelgau has quit [Remote host closed the connection]
nelgau has joined #nmigen
nelgau has quit [Read error: Connection reset by peer]
nelgau has joined #nmigen
nelgau has quit [Client Quit]
nelgau has joined #nmigen
lkcl has quit [Ping timeout: 256 seconds]
lkcl has joined #nmigen
samlittlewood has quit [Quit: samlittlewood]
<whitequark> awygle: okay, so i explored turning undriven signals into registers in back.rtlil
<whitequark> i now understand this is impossible because they get assigned to their reset value in each module where they're used
samlittlewood has joined #nmigen
lkcl has quit [Ping timeout: 256 seconds]
<awygle> Ah
lkcl has joined #nmigen
<whitequark> awygle: mkay, i have more things to discuss
<awygle> It's 3am here so we'll have to do that tomorrow
<whitequark> works
<awygle> I'll ping you
lkcl has quit [Ping timeout: 240 seconds]
<Sarayan> you can't drive the compilation from the clang python module? That's rather annoying
lkcl has joined #nmigen
<whitequark> let me double-check
<Sarayan> ah yeah, that's rather minimalist
<Sarayan> so definitely not a solution
m4ssi has joined #nmigen
<whitequark> hrm
<whitequark> and it actually works
zignig has joined #nmigen
* zignig is in .au so the timespace is werid...
<zignig> is anyone awake? apart from the sleepless.
<Sarayan> wq: doesn't it has the exact same issues than clang?
<Sarayan> I mean, you could say "clang version > n has to be in the path" and just call the programs?
<zignig> Sarayan: what are you building nmigen at the moment?
<Sarayan> I tend not to use nmigen as whitequark intends, e.g. I use it to generate the rtlil and I call yosys/clang/etc myself
<whitequark> that's actually intended use of nmigen (back.rtlil is a public API)
<whitequark> it's just that most people don't really care for that, and i recognize that it is valid for them to not care
<Sarayan> Yeah, you're rather open on how to use your tools, and that's really cool
lkcl has quit [Ping timeout: 240 seconds]
Stary has quit [Ping timeout: 260 seconds]
FFY00 has joined #nmigen
lkcl has joined #nmigen
<whitequark> Sarayan: re zig: what it does is it also drags along a working standard library, even on "weird" systems like alpine or windows
<whitequark> so this potentially reduces the amount of additional things that have to be installed to use cxxrtl to... zero
<whitequark> (pip install nmigen[builtin-yosys,builtin-cxx], and that's it)
<Sarayan> ah, that's nice
<Sarayan> personally I'd say "you need a working clang" and not do any technical dependencies
<Sarayan> but that's just me
<whitequark> thing is it's not just "working clang" but more like "working clang abi-compatible with your python"
<sorear> only 45MB according to that blog post? wow
<whitequark> oh and the other thing it provides is a ccache equivalent
Stary has joined #nmigen
<Sarayan> Since cxxrtl is not embedding anything from python I'm not sure how you can not be abi-compatible... or worse if there's a possible abi-compatibility issue whether something you provide doesn't have a bigger chance to be incompatible with the python you don't provide
<Sarayan> Urgh, reading the thread what you want is libtool, or more precisely what libtool sohuld have been
<whitequark> oh and *another* thing it does is it embeds some target-specific knowledge about flags so that i don't have to e.g. think about -fPIC
<whitequark> or, hm, let me recheck
<whitequark> that might be another part of zig
<whitequark> yup, it does handle that
<Sarayan> yeah, -fPIC and stuff is a pain
<whitequark> so i can't really fall back to bare clang from zig c++
<whitequark> i'd have to fall back to cmake, which knows about the -fPIC stuff
<whitequark> or meson or w/e
<Sarayan> and that information is not in python-config either, sadly
<whitequark> it's sort of in `sysconfig`
<Sarayan> what is sysconfig?
<whitequark> but not really in a way that's usable outside of concatenating random parts of sysconfig together
<whitequark> try `import sysconfig`
<Sarayan> CCSHARED = "-fPIC"
<Sarayan> CFLAGSFORSHARED = "-fPIC"
<Sarayan> LDCXXSHARED = "g++ -pthread -shared"
<Sarayan> yeah, there's some stuff in there, but it looks fragile
<whitequark> it is very much fragile
<whitequark> when it works, it really is to a large extent by chance
<whitequark> e.g. pypy doesn't have LDCXXSHARED, because LDCXXSHARED is an accident of how cpython build process works
<Sarayan> ouch
<Sarayan> pretty much what I meant with fragile indeed
<Sarayan> mwahahaha
<Sarayan> libtool is a Python library for creating a Python library, and also manages versions and uploading to PyPi with twine
<Sarayan> libtool runs in Python 3+ and only in Windows.
<whitequark> so on pypy i glue CXX with LDCXXSHARED.split()[1:]
<whitequark> which is horrifying
<Sarayan> by now, is there any linux where -shared -fPIC doesn't work? I wonder if it's not just 3 sets of very similar flags, one for each system
<Sarayan> I doubt you care that much about hpux
<Sarayan> and sysconfig should get you the platform reliably at least
<whitequark> i care about windows and macos too
<Sarayan> sure, but are there multiple sets of flags for those?
<Sarayan> or can you just have a 3-entries table?
<whitequark> for windows, yes, definitely
<whitequark> well
<Sarayan> damn
<whitequark> at the very least you have mingw python and vc++ python
<whitequark> it's *mostly* the latter but people use the former too
<whitequark> horrifyingly, people also use cygwin python, which is something i actually refuse to actively support
<whitequark> because you gotta draw a line somewhere
<Sarayan> does anything from python tell you which it is? Can sysconfig tell you?
<cr1901_modern> upstream python wants to pretend mingw/GNU ABI not to exist
<cr1901_modern> whitequark: If it makes things easier, I'm happy for you to NOT support mingw python in this case
<whitequark> well zig cc makes that a no-brainer
<cr1901_modern> I'm doing something not-recommended; I accept the consequences
<whitequark> i'm slightly more worried about msvc python actually
<cr1901_modern> zig proper supports msvc abi better than mingw; I don't know if that extends to "zig cc"
<Sarayan> ah damn, I don't have nmigen installed anymore
* Sarayan fixes that
<whitequark> there's `zig cl`
<whitequark> i'm not sure if `zig c++` supports msvc abi
<cr1901_modern> msvc and mingw are both "tier 2" targets on the zig matrix IIRC, but the focus is getting msvc working
<cr1901_modern> msvc might even be "tier 1". Anyways, I don't have a native zig for Windows- I can't be arsed to compile the correct clang version for it :P.
<whitequark> i'm honestly not sure if this even matters for nmigen's purposes
<whitequark> like Sarayan mentioned, getting an ABI incompatibility with cxxrtl is not trivial because cxxrtl's C API is so simple
<Sarayan> and python does not use any c++ system lib
<whitequark> python does use msvcrt though
<Sarayan> and cxxrtl doesn't use much of libc I think
<whitequark> so suppose i print from cxxrtl code
<whitequark> yeah... that's not gonna work so well
<Sarayan> yeah, there's danger there
<daveshah> yeah, I think we've hit stuff like that with nextpnr
<Sarayan> well, mingw and vc c++ abi are fully incompatible
<Sarayan> I mean the C abis
<cr1901_modern> The C ABIs are compatible
<whitequark> vc++ doesn't even have a (stable) c++ abi
<Sarayan> cr1901: reaaaaaaaaaaaally?
<whitequark> they have to be compatible to some extent or you couldn't use windows dlls from mingw code
<Sarayan> or well, it's the linux (itanium) and windows ones that are incompatible then
<cr1901_modern> I can link against a *.lib compiled with msvc with a gcc application :)
<Sarayan> ah, I guess mingw uses the windows aby then
<whitequark> itanium in this context would be only the c++ abi
<cr1901_modern> and it doesn't crash
<cr1901_modern> That's my definition of compatible :)
<whitequark> i'm not really sure wtf happens with SEH and what are the exact implications of it
<Sarayan> there's using different registers for function parameters, that's hitting C too afaict
<whitequark> c parameter passing abi *has* to be compatible or you couldn't use any winapi
<Sarayan> yeah, makes sense
<whitequark> (well, you should be able to opt into having it compatible)
<Sarayan> they must have gcc/clang generate windows-type parameters
<whitequark> yep
<cr1901_modern> whitequark: Anyways, I haven't been following this convo/what you're trying to accomplish closely. I commented b/c I anticipated mingw python to be brought up and how me using it has caused you woes in the past. >>
<Sarayan> then c++ is another layer of crap on top of that of course
<Sarayan> in particular C++ method pointer encoding, that's a bad one
<whitequark> not me
<whitequark> wasmtime folks
<cr1901_modern> And my initial SSH impl that you told me to drastically simplify :P
<whitequark> wait, was mingw somehow involved there?
<cr1901_modern> I tried making logic to customize where paramiko looked for keys
<cr1901_modern> b/c the only default is %USERPROFILE%/.ssh on Windows
<cr1901_modern> And mine are under my bash $HOME/.ssh
<cr1901_modern> You told me to "symlink %USERPROFILE%/.ssh to $HOME/.ssh" rather than customize nmigen. That's fine.
<d1b2> <DX-MON> GCC has support for the windows calling conventions and uses the MSVC ABI on windows when you say __attribute__((dllexport)) and __attribute__((dllimport)) at the very least, hence why it doesn't 'splode
<cr1901_modern> If I used a msvc python this would've been a non-issue
<whitequark> oh right
<d1b2> <DX-MON> it also supports __cdecl and friends
<cr1901_modern> So if "whatever you're doing w/ cxxrtl" would cause problems w/ mingw, I don't have a problem w/ considering "whatever you're doing w/ cxxrtl" out-of-scope for mingw
<cr1901_modern> That's all
<Sarayan> what is "adopt" supposed to be in a cxxrtl context?
<whitequark> Sarayan: grab black boxes from the argument
<Sarayan> oh, fucked my install
<whitequark> so like a move constructor but only move black boxes
<whitequark> open to better naming
<Sarayan> it's more that it explodes on that when you have a version mismatch between headers and generator
<Sarayan> compiles now, cool
<whitequark> oh yeah
<whitequark> see, with builtin-yosys that's not possible :p
<Sarayan> huhuhu
<Sarayan> tried just for kicks, clang++ -O3 -shared -fPIC -I/people/galibert/share/yosys/include m68000.cc -o m68000.so gives me a .so that links and works correctly with other c++ code
<Sarayan> m68000.cc being cxxrtl-generated
<whitequark> yeah, that's the normal way to build on x86_64
<Sarayan> fucking cyclone v
<whitequark> oh?
<Sarayan> wq: there's a list of "default bits to set" in the tables that are just derivable from the default values of the muxes and/or routers
<Sarayan> except for, oh, 100 bits or so that are coming from who knows where
<Sarayan> so there's the eternal question, did I miss something or did they just add a pile of bits in there just because?
<lkcl> tpw_rules, aw doh, we've been planning to use CORDIC for just about all of the transcendentals because of the huge coverage
<lkcl> we've an IEEE754 FP sin/cos now, using them, and the plan is to add log2, exp, expm1, log1p, atan2, acos etc. next
m4ssi has quit [Remote host closed the connection]
<lkcl> whitequark: although i do appreciate that you wanted a full range of interoperability by using ctypes, and eliminated all other options, perhaps it might be time to re-evaluate the idea of code-generating python c-based module source code? although it would be a pain for pypy, i did not recommend the python c-based module as a mutually-exclusive option *instead* of the use of ctypes, i raised it for consideration as a multiply-redundant
<lkcl> (faster) alternative
<lkcl> which, it seems, given abi issues, might actually provide better interoperability (except on pypy)
* lkcl wonders if they have an equivalent of c-based modules
<lkcl> interesting. there does exist something called cppyy which eliminates the JIT overhead
<lkcl> and apparently it works with cpython as well
jeanthom has quit [Ping timeout: 265 seconds]
jeanthom has joined #nmigen
_whitelogger has joined #nmigen
<whitequark> lkcl: i do not generate python c-based modules
<whitequark> er, sorry, i misread
<whitequark> ok, so the issue with that suggestion is that it doesn't actually solve much
<whitequark> distutils' CXXFLAGS is such that the CXXRTL code is significantly slower than it could be
<whitequark> no matter what i do, i can't use distutils, so what kind of interface code there is, is besides the point
<whitequark> to elaborate, if i cannot ship a solution that is effectively "turnkey", it's not that i do not have a solution. it's that i request the end user to provide a compiler command line
<whitequark> if CXXRTL code is too slow with the "turnkey" solution, that is also exactly what they would have to do
chipmuenk has quit [Remote host closed the connection]
emeb_mac has joined #nmigen
cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Ping timeout: 260 seconds]
jeanthom has joined #nmigen
emeb has joined #nmigen
lsneff has quit [*.net *.split]
lsneff has joined #nmigen
<carlomaragno> Nmigen rocks
<carlomaragno> Just a periodic reminder
mwk has quit [Ping timeout: 260 seconds]
mwk has joined #nmigen
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
<ktemkin> mithro: kickass; thanks
cr1901_modern has left #nmigen [#nmigen]
cr1901_modern has joined #nmigen
<lkcl> whitequark: interesting. i always thought that "python setup.py build" with c-based modules worked all the time, every time, i mean, that was the whole point
<lkcl> arg not being able to rely on python-distutils, got it. that messes things up.
<lkcl> carlomaragno: it does :)
<awygle> whitequark: howdy. still wanna discuss?