ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each 1st & 3rd Monday at 1800 UTC · next meeting July 20th
jeanthom has quit [Ping timeout: 272 seconds]
gregdavill has joined #nmigen
lkcl__ has joined #nmigen
lkcl_ has quit [Ping timeout: 256 seconds]
<_whitenotifier-b> [nmigen] programmerjake commented on issue #429: values in vcd are zero despite simulation's nonzero values -
Degi has quit [Ping timeout: 258 seconds]
Degi has joined #nmigen
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined #nmigen
<_whitenotifier-b> [nmigen] programmerjake commented on issue #429: values in vcd are zero despite simulation's nonzero values -
<_whitenotifier-b> [nmigen] programmerjake commented on issue #429: values in vcd are zero despite simulation's nonzero values -
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #nmigen
<_whitenotifier-b> [nmigen] programmerjake edited a comment on issue #429: values in vcd are zero despite simulation's nonzero values -
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 258 seconds]
PyroPeter_ is now known as PyroPeter
electronic_eel has quit [Ping timeout: 258 seconds]
electronic_eel has joined #nmigen
<whitequark> tpw_rules: yeah it's related
<whitequark> i just haven't really had the time to work on something except for nmigen for months
<_whitenotifier-b> [nmigen] whitequark commented on issue #429: values in vcd are zero despite simulation's nonzero values -
<tpw_rules> i mean i'm not expecting or waiting for an implementation from you
<whitequark> tpw_rules: i kinda wanted a regalloc from the start
gregdavill_ has joined #nmigen
gregdavill has quit [Read error: Connection reset by peer]
<awygle> would the regalloc be mandatory, opt in, or opt out?
<whitequark> opt in
<_whitenotifier-b> [YoWASP/yosys] whitequark 047e0b0 - Add yowasp-sby binary.
<_whitenotifier-b> [YoWASP/yosys] whitequark pushed 1 commit to sby [+1/-0/±5]
<_whitenotifier-b> [yosys] whitequark created branch sby -
guan has quit [Ping timeout: 256 seconds]
ianloic has quit [Ping timeout: 256 seconds]
ianloic has joined #nmigen
guan has joined #nmigen
_whitelogger has joined #nmigen
<_whitenotifier-b> [YoWASP/yosys] whitequark pushed 1 commit to sby [+1/-0/±5]
<_whitenotifier-b> [YoWASP/yosys] whitequark d6e9078 - Add yowasp-sby binary.
yuriks has joined #nmigen
<whitequark> awygle: okay i packaged sby
<whitequark> it's... slow
<whitequark> the nmigen testsuite is 8 times slower with yowasp-yosys+sby than with native-yosys+sby
<whitequark> well, sby is not slow, yowasp-yosys has a horrendous startup latency
<awygle> Interesting
<awygle> I find what gets slow and what doesn't fascinating
<whitequark> it's not that interesting tbh
<whitequark> yowasp-yosys (the full version, not the cut down nmigen one) just has really huge startup latency
<whitequark> 2 seconds on my machine
<whitequark> that's with hot cache
<awygle> why tho
<whitequark> bytecode validation i think
<whitequark> has anyone here actually got the quicklogic toolchain to work
<whitequark> i find it absolutely unbearable
<trabucayre> whitequark: I'm checking my script ... Sorry to beta testing aspect...
<awygle> I'm not cool enough to get one lol
<awygle> Bedtime. Goodnight all.
<whitequark> trabucayre: can you give me a tarball of /opt/ql or something
<whitequark> just... something that does not involve conda at any stage whatsoever
<trabucayre> I've no conda in toolchain directory. But not in build time... missing
<trabucayre> I try to send archive, but my upload is slow and I use gentoo...
<whitequark> thanks!
<trabucayre> I'm retrying to build everything with in a docker container, maybe I must adding the Dockerfile too
Asu has joined #nmigen
<trabucayre> pff the archive is 117M...
<whitequark> that's fairly small all things considered
<whitequark> but if you use ADSL that's still a lot of suffering
<whitequark> (i think nextpnr is actually much larger)
<trabucayre> I use ADSL :)
<trabucayre> copper -> 128KB/s
<whitequark> *ouch*
<whitequark> my condolences
<trabucayre> thanks :)
<whitequark> so that's uh... 20 minutes of upload and you can't use your connection at all during that time
<whitequark> pretty awful
<whitequark> assuming your ADSL modem doesn't have bufferbloat; if it does you'll just never upload it at all
<trabucayre> usually it's ok... But bit boring
<_whitenotifier-b> [YoWASP/yosys] whitequark pushed 1 commit to develop [+1/-0/±5]
<_whitenotifier-b> [YoWASP/yosys] whitequark d6e9078 - Add yowasp-sby binary.
<_whitenotifier-b> [YoWASP/yosys] whitequark deleted branch sby
<_whitenotifier-b> [yosys] whitequark deleted branch sby -
<whitequark> on the last ADSL connection i had, the modem was seriously misconfigured
<whitequark> i had to put an openwrt router in front of it and throttle the upload on the egress side
<whitequark> otherwise it would buffer seveal megabytes, drop everything i send after that, and then 2 minutes later all my connections would time out
Asu has left #nmigen ["Konversation terminated!"]
<trabucayre> my modem is not so bad
<whitequark> the only scar i have i got from punching that modem
<trabucayre> 50% !! :)
<whitequark> (protip: don't do that, the ABS is thick and contains hidden screws)
<trabucayre> Yes. Not a good idea...
<trabucayre> funny thing: a full rebuild is faster than uploading the archive...
<_whitenotifier-b> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+1/-0/±1]
<_whitenotifier-b> [nmigen/nmigen-boards] alanvgreen 8c3a3c0 - Update license and copyright info
<_whitenotifier-b> [nmigen/nmigen-soc] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-b> [nmigen/nmigen-soc] alanvgreen 24d28bb - Update license and copyright info
<_whitenotifier-b> [nmigen/nmigen-stdio] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-b> [nmigen/nmigen-stdio] alanvgreen eb30b02 - Update license and copyright info
<whitequark> aha, thanks!
<whitequark> got an example i can use to check if it still works on my machine?
<trabucayre> j'espere que ca va fonctionner
<trabucayre> I've tried all qorc-sdk
<trabucayre> sorry : I hope that it will work
<whitequark> mhm
<whitequark> what i mean is i can't find any examples
<whitequark> ... that aren't a 11 minute video anyway
<trabucayre> cd GCC_Project && make
<trabucayre> If you have an gcc toolchain + fpga toolchain It work (in my computer :) )
<whitequark> i'm pretty sure i don't have a gcc toolchain for it
<whitequark> let's see
<trabucayre> most distribution provides a package for that
<whitequark> yeah i do have one after all
<whitequark> trabucayre: i think that has a part missing
<whitequark> qlfasm doesn't work
<whitequark> but i can install that easily enough
<trabucayre> doesn't work or is missing ?
<whitequark> it's present in python/qlfasm
<trabucayre> yes
<whitequark> but i think it references your local pip packages or something
<whitequark> well aside from having the wrong shebang
<trabucayre> could you paste error? maybe something to find to it
<trabucayre> this toolchain is really boring to compile ...
<whitequark> pkg_resources.DistributionNotFound: The 'quicklogic-fasm' distribution was not found and is required by the application
<whitequark> yes, it's incredibly obnoxious
<whitequark> okay, i got a bitstream
<whitequark> pip install git+
<whitequark> pip install git+
<whitequark> this installs the python bits, which was actually the least annoying part of the process
<trabucayre> I need to document this...
<trabucayre> It's near impossible to build this toolchain in only one try
<whitequark> yep
<whitequark> trabucayre: anyway, lemme know when you update it and i'll mention it as something less painful and actually working
<whitequark> less painful than conda
<trabucayre> Ok!
<trabucayre> First I need to fix issues, second document and third avoid conda in build time...
<whitequark> sounds great!
<trabucayre> I've spent my last weekend to build a toolchain!
<trabucayre> to find howto build to be more precise
jeanthom has joined #nmigen
_whitelogger has joined #nmigen
lkcl_ has joined #nmigen
lkcl__ has quit [Ping timeout: 246 seconds]
<trabucayre> whitequark: script failure is no only my fault, with symbiflow-arch-defs repository hash used last week the build is success, with the current HEAD the build fail
<whitequark> right
<whitequark> maybe checkout a specific commit?
<trabucayre> I'll try first with the good commit to have a script working. After that, I'll trying to fix script with HEAD
<trabucayre> but It's usually better to use a specific commit instead of branch
jeanthom has quit [Remote host closed the connection]
Ekho has quit [Ping timeout: 244 seconds]
Ekho has joined #nmigen
<lkcl_> trabucayre, whitequark: my friend phil asked a friendly ISP to set the MTU to 500 and they actually did it (gosh).
<lkcl_> he told me that one of the reasons why ISPs set MTUs so large is so that they can "win" the "speed wars" by reducing UDP/TCP packet overhead... sigh
<lkcl_> trabucayre: i'm on a mobile 3G/LTE connection, using three mobile. it's... ok. better than 128k/s ADSL. if you're in the UK, smarty are doing a deal: unlimited data for GBP 20/month. they're a 3rd party ISP on Hutchinson Lab's network.
<lkcl_> of course if you're _really_ out in the middle of nowhere, 3G/LTE might not work :) to compensate for that, we got a high gain antenna for the 3G/LTE hotspot and it does well. except when it rains :)
<trabucayre> lkcl_: thanks but I live in France and I'm quite near the middle of nowhere :)
<lkcl_> whitequark: i successfully built nextpnr-ecp5 (and its dependency) without GUI, python *or* boost, and it was successful, worked, and is one heeelll of a lot smaller.
<trabucayre> Usually to sent big files I use my laboratory connection :)
<lkcl_> trabucayre: :) ah, then if you get any kind of mobile phone signal _at all_, try a Hong-Kong-based PokeFI. they are international roaming yet only charge USD $3 per gigabyte and they *don't* steal your money after only one month. we have two, for emergencies.
<lkcl_> trabucayre: directional antennae to the lab? Mikrotic's equipment can do 50 km :)
<lkcl_> you got line of sight to the lab? teehee
<whitequark> lkcl_: pretty sure you can't build nextpnr without boost
* lkcl_ double-checking the config.log on the builds, 1 sec
<trabucayre> lkcl_: no too far :)
<trabucayre> Yes. My script works again !
<lkcl_> nextpnr$ ldd nextpnr-ecp5
<lkcl_> => /usr/lib/x86_64-linux-gnu/ (0x00007f50f44f1000)
<lkcl_> whitequark: yep you're right. i just remember it being an absolute pig. ah i remember now: i disabled *python-boost* and it worked.
<whitequark> yeah, doesn't ship with boost-python either
<lkcl_> -rwxr-xr-x 1 lkcl lkcl 111M Jul 11 12:53 nextpnr-ecp5
<lkcl_> holy cow.
<lkcl_> that's after symbol stripping!
<lkcl_> trabucayre: yay
<whitequark> that's the embedded chipdb
<whitequark> the actual code is less than a megabyte iirc
<lkcl_> whitequark: i investigated the vcd symbols issue that jacob raised. nmigen is actually outputting zeros into the vcd file, which is legally and correctly formatted
<whitequark> sure. can you produce an MCVE?
<whitequark> I've checked some of the designs I use to test (Minerva mostly) and they're ok
<whitequark> so it's some combination of what nmigen does and what you're doing
<lkcl_> interestingly, where (from alan's commit, 303ea18) the vcd file will contain Enum names / string info, there's not even those enum names. i checked a diff
<lkcl_> whitequark: oof. that's a lot of work. the DIV unit is... massive for a reason. i'll see if there's a smaller example to start from, that would be far less work.
<whitequark> you could also bisect nmigen
<lkcl_> give me some time to check some of the other code and some of the examples we have (ones that also do pipelining)
<whitequark> i don't think there are any breaking changes between 303ea18 and current master
<lkcl_> i did (manually).
<whitequark> i'm not sure why jacob wasn't able to bisect it
<whitequark> oh. which commit is the issue, then?
<lkcl_> i found that the commit immediately before alan's one broke things, the one with pysim.back. after 10 minutes i stopped the simulation, it was just locked up 100% CPU
<lkcl_> then the one that got things "working" again (simulation-wise, not vcd wise) was back.pysim: only extract signal names if VCD is requested.
<lkcl_> 6d417568ad6
<lkcl_> give me a mo to check if there's any simpler examples that also have (validly-written) zeros in the vcd file
<whitequark> lkcl_: ahhh i see
<lkcl_> ehn. odd/obtuse. the multiply pipeline works perfectly fine.
<whitequark> right so i think i can give you a patch you can apply on top of 2606ee33a that fixes it
<whitequark> i know what the "lockup" is (it's not a lockup, i just pessimized it by a very high constant factor)
<lkcl_> ah super. happy to try it out
<lkcl_> gtkwave div_simulator.vcd. "really recursively-import 17,980 signals?" [Y/n]
<Lofty> whitequark: can I quote that?
<Lofty> "it's not a lockup, i just pessimized it by a very high constant factor"
<trabucayre> whitequark: my repo has been updated. All feedbacks are welcome.
<lkcl_> whitequark: at the nmigen bugreport, ?
* lkcl_ brb, coffee
<TD-Linux> I noticed that litex has a wishbown down/upconverter
<TD-Linux> would it be acceptable to port that to nmigen-soc
<lkcl_> hmm it's actually really tricky to create a MCVE, here, because this is pipelines. each stage's input and output data format critically define the relationships to the previous and next stages... *and* to the "manager" of the pipeline.
<whitequark> Lofty: yep
<whitequark> TD-Linux: there's already a PR
<TD-Linux> ah thanks. I guess I can review it
<TD-Linux> and maybe add the downconverter if the original author doesn't want to
<lkcl_> whitequark: btw, we have a POWER9 simulator of the div instructions (in python of course). the nmigen HDL simulation *still gives correct values* compared to the python-based POWER9 ISA simulator, even when the vcd file's output is incorrect.
<whitequark> sure
<lkcl_> TD-Linux: we'd appreciate it (and be interested).
<lkcl_> whitequark: i just wanted to emphasise that, that it appears only to be the output to the vcd file, rather than the alternative error: "actual nmigen Simulation producing zeros" which it definitely isn't. strangely, glancing through the (17,000!!!) vcd signals, _some_ signals are non-zero.
<lkcl_> ack
<lkcl_> ah that's pretty simple :)
<whitequark> yes, which is why i overlooked it
<whitequark> it causes minerva VCDs to blow up 20x
<whitequark> so what happens there is instead of placing the traces for a signal on every hierarchy level where the signal is used,
<whitequark> it places the traces for every signal on every hierarchy level
<whitequark> so if you have a heavily hierarchical design the constant factor will be extremely high
<whitequark> worse, until recently pyvcd did not have aliases
<whitequark> so if a signal was used in 20 modules, i would actually have to dump it 20 times
<whitequark> speaking of which
<lkcl_> urk
<lkcl_> yeah we're looking at 872k vcd files for running a single instruction.
<lkcl_> the MUL pipeline, running 100 simulated instructions, is 1.7 mbytes.
<lkcl_> it looks like that was it - give me a moment to check a more complex operation
<lkcl_> whitequark: yeah that's good.
<lkcl_> yeah it's a 5-level-deep class hierarchy for the DIV pipeline. that's not even embedded in a core: it's the *pipeline* unit test!
<lkcl_> GPUs are... yeah :)
<_whitenotifier-b> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-b> [nmigen/nmigen] whitequark 0a90aa1 - sim.pysim: use VCD aliases to reduce space and time overhead.
<whitequark> this should make VCD dumps somewhat faster and a lot smaller
<_whitenotifier-b> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13]
<_whitenotifier-b> [nmigen/nmigen] whitequark 9ed648a - Deploying to gh-pages from @ 0a90aa1b1709fcfce48751c345b4b466ac09fc1e 🚀
<lkcl_> whitequark: interestingly, div_simulator.vcd increased in size. 1.1mb (up from 872k)
<lkcl_> but, i had to use master (not 2606ee33a) so it's not a fair comparison
<whitequark> increased in size between what and what?
<lkcl_> ahh against HEAD-1, yes absolutely. HEAD-1 (previous commit) was 1.5mb
<whitequark> ah yep
<whitequark> so i think there actually were some signals that weren't dumped before at all
<TD-Linux> oh nice the author of that pr also made a ao68000 nmigen-soc wrapper
<TD-Linux> time to compare mine and see what I did wrong
<lkcl_> but the vcd file from 2606ee33a was only... ah yes most likely
<lkcl_> TD-Linux: oh! that'll be Staf Verhaegen, am i right? :)
<TD-Linux> yes. in a rare turn of events I've met him irl but don't know what his irc handle is
<lkcl_> Staf's doing a retro-controller project and also he's acting as the bridge between Foundries and Libre/Open Silicon projects
<lkcl_> he signs NDAs so that you don't have to
<whitequark> Staf made a pretty significant contribution to nMigen's architecture through our discussions of better ASIC support
<lkcl_> he's working with Jean-Paul from Sorbonne University on a version of nsxlib and some Cell Libraries (including GPIO pads) so that you can create a *full chip layout*, then give him the scripts to run it, and he will substitute the "real" Foundry Cell Libraries
<whitequark> well, none of the ideas we worked out are implemented yet, but he provided some major insights that will come in useful
<lkcl_> whitequark: yeah he's extremely knowledgeable. as a community in general we're damn lucky to have him
<lkcl_> he worked in the silicon industry and got fed up of the NDAs, the duplication that comes from that, and the artificially-high cost of silicon as a result
<lkcl_> fantastic
* lkcl_ still hasn't had that coffee. kettle boiled 10 mins ago though :)
<lkcl_> Staf will be doing the "final completion phase" for us of the Oct 2020 tape-out. as it's funded by NLNet, and is only 180nm, it doesn't "matter" so much, acting more of a test case for the entire concept, more than anything
<lkcl_> he's already done one test ASIC back in... april (testing the Libre Cell Libraries)
<FL4SHK> got my SymbolTable class built
<FL4SHK> It's not got named scopes
<FL4SHK> but it probably should...
jeanthom has joined #nmigen
gregdavill_ has quit [Ping timeout: 260 seconds]
jordigw has quit [Quit: leaving]
jeanthom has quit [Ping timeout: 258 seconds]
<awygle> Morning
<_whitenotifier-b> [nmigen-boards] tdaede opened pull request #76: Add OrangeCrab board. -
<_whitenotifier-b> [nmigen-boards] miek commented on pull request #76: Add OrangeCrab board. -
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
<_whitenotifier-b> [nmigen-boards] tdaede commented on pull request #76: Add OrangeCrab board. -
DaKnig has joined #nmigen
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
<DaKnig> hello, I got nMigen recommended to me by someone, does it support the series-7 zynq family?
<TD-Linux> in nmigen, what happens to an unconnected dir="i" pin
<TD-Linux> *dir="o"
<DaKnig> I have the arty z7 board, is that compatible? how should I set it up to work with vivado?
<FL4SHK> it's compatible
<_whitenotifier-b> [nmigen-boards] tdaede synchronize pull request #76: Add OrangeCrab board. -
<_whitenotifier-b> [nmigen-boards] tdaede commented on pull request #76: Add OrangeCrab board. -
<_whitenotifier-b> [nmigen-boards] tdaede synchronize pull request #76: Add OrangeCrab board. -
<_whitenotifier-b> [nmigen-boards] tdaede synchronize pull request #76: Add OrangeCrab board. -
jeanthom has joined #nmigen
<DaKnig> thanks.
<whitequark> TD-Linux: unconnected dir="o" becomes logical low
<whitequark> so, low if Pins, high if PinsN
<TD-Linux> whitequark, hmm. how should I handle the "top up" pins, then? I don't want them to be shorted if they aren't used
<TD-Linux> I suppose I could set them to dir="io"
<whitequark> "top up" ?
<TD-Linux> or I could use PinsN for vccio
<TD-Linux> whitequark, see ##openfpga
<TD-Linux> tl;dr extra "virtual" power and ground pins
<_whitenotifier-b> [nmigen-boards] tdaede synchronize pull request #76: Add OrangeCrab board. -
jeanthom has quit [Ping timeout: 240 seconds]
<whitequark> TD-Linux: oh, hm
<whitequark> we have no established convention for this
<agg> "danger pins"
<agg> Sort of want the platform definition to hardcode them to output 0 or 1 and not allow reassignment, wonder if you could have a special pin type or something
<TD-Linux> either that or a flag to prevent you from acquiring the subsignal
<TD-Linux> without api changes I think Pins/PinsN, dir="o" plus a scary name would be ok
lkcl__ has joined #nmigen
<DaKnig> what does the F in nMigen FHDL stand for?
lkcl_ has quit [Ping timeout: 256 seconds]
<DaKnig> also how do I get it to work with my board? has a TBD section for this
Asu has joined #nmigen
Asu has quit [Client Quit]
<awygle> there's already a board definition file for the arty z7
<awygle> so all you need to do is, in your nmigen script, from nmigen_boards.arty_z7 include ArtyZ7Platform
<FL4SHK> that's what I mentioned earlier
<FL4SHK> DaKnig is here at the behest of me
<awygle> then instantiate it with platform = ArtyZ7Platform(top_module)
<awygle> and build it with
<DaKnig> aweygle thanks.
<whitequark> DaKnig: "FHDL" as a whole is a legacy name we should just get rid of to reduce confusion
<whitequark> technically "F" means "Fragment" but it's no longer important
<DaKnig> I see
<cr1901_modern> Back when nmigen was new, I tried writing down notes between the differences of an "omigen" fragment and "nmigen" fragment. Well, that didn't happen. And probably won't happen now :(.
<FL4SHK> so I've decided to make an AST of sorts in my assembler
<FL4SHK> ...but only for expressions
gregdavill_ has joined #nmigen
<FL4SHK> expressions can only be integers
<FL4SHK> 32-bit ones, to be specific
<FL4SHK> any use of an immediate value produces either a 32-bit immediate or a smaller one
<FL4SHK> 32-bit immediates end up getting encoded into a `pre` instruction containing the top bits and then the actual instruction
<FL4SHK> so `pre; add` for example would allow add immediate to use a 32-bit immediate
<FL4SHK> `pre` is an actual instruction that exists
<FL4SHK> blocks interrupts
<FL4SHK> so it acts kind of like a THUMB 1 `bl`
loxodes has quit [Quit: WeeChat 1.4]
loxodes has joined #nmigen
<mithro> whitequark: FYI _florent_ wrote up about his thoughts on LiteX and nMigen -- would be worth to take a look over and see if it makes sense to you
<whitequark> mithro: seems basically fine
<whitequark> my preference would be to keep improving nmigen-stdio and nmigen-soc to the point where litex would be much "thinner"
<whitequark> nmigen-soc specifically considers e.g. building linux out of scope
<whitequark> so litex (or something like it) would *always* have a place in the nmigen ecosystem
<whitequark> but i'm hoping we don't duplicate basic cores
<whitequark> right now my focus is on docs and then on streams, which are foundational for any kind of SoC or really any serious FPGA project
<mithro> What is in nmigen-stdio?
<whitequark> right now? a slightly broken UART
<whitequark> what should be? all sorts of I/O that *isn't* inherently tied to SoC buses
<whitequark> so there is a separate UART, Ethernet, SPI etc cores that just use streams (similar to AXI4 Stream)
<whitequark> and then in nmigen-soc there are wrappers that expose them to a SoC
<whitequark> my thoughts are that SoCs are fun, but building things without needing a SoC can be far more powerful
<whitequark> so the split is ideal
<whitequark> of course some things can't really be split
<awygle> what would be an example of such?
<whitequark> I was thinking of memory controllers, but the more I consider it, the more I wonder if it's a failure of imagination
<awygle> (also don't forget cxxsim when enumerating your focuses :)
<awygle> yeah i was thinking about that too, i think i can imagine e.g. a DDR2 controller where much of it is in nmigen-stdio
<whitequark> cxxsim is nearly done
<whitequark> there's maybe a day or two of work left?
<whitequark> i'm just having like... a weekend
<whitequark> first in a long time
<mithro> whitequark: Is there a split between "interfaces for IO / connection" and cores that use those interfaces at all?
<mithro> whitequark: I was wondering if there was a way we could merge litex-boards and nmigen-boards -- I like a lot of how nmigen-boards works better....
_whitelogger has joined #nmigen
lkcl_ has joined #nmigen
lkcl__ has quit [Ping timeout: 258 seconds]
lkcl__ has joined #nmigen