<_whitenotifier-3>
[nmigen-soc] whitequark commented on issue #6: RecursionError when elaborating a csr.Multiplexer with alignment >= 8 - https://git.io/JvZVC
<_whitenotifier-3>
[nmigen-soc] whitequark commented on issue #6: RecursionError when elaborating a csr.Multiplexer with alignment >= 8 - https://git.io/JvZV8
focus has joined #nmigen
<_whitenotifier-3>
[nmigen/nmigen] whitequark pushed 2 commits to master [+0/-0/±4] https://git.io/JvZVo
<_whitenotifier-3>
[nmigen-soc] jfng commented on issue #6: RecursionError when elaborating a csr.Multiplexer with alignment >= 8 - https://git.io/JvZwP
focus has joined #nmigen
<_whitenotifier-3>
[nmigen-soc] whitequark commented on issue #6: RecursionError when elaborating a csr.Multiplexer with alignment >= 8 - https://git.io/JvZrI
<_whitenotifier-3>
[nmigen/nmigen] whitequark pushed 2 commits to master [+0/-0/±4] https://git.io/JvZoV
<_whitenotifier-3>
[nmigen/nmigen] whitequark 86b57fe - hdl.dsl: type check when adding to m.domains.
<_whitenotifier-3>
[nmigen/nmigen] whitequark 3df4297 - hdl.dsl: reject name mismatch in `m.domains.<name> +=`.
<_whitenotifier-3>
[nmigen] whitequark closed issue #282: Assigning local domain with different name - https://git.io/JvZow
<_whitenotifier-3>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JvZXV
<_whitenotifier-3>
[nmigen/nmigen] whitequark 9301e31 - test_lib_fifo: define all referenced FSM states.
<_whitenotifier-3>
[nmigen] adamgreig commented on issue #280: pysim2 doesn't write input signals to VCD - https://git.io/JvZXX
<awygle>
whitequark: i also like .as_signed, and the interactive console seems nice but not tremendously useful without an interactive simulator/waveform viewer
<whitequark>
awygle: the idea is that the console would be an interface to the simulator
<whitequark>
but... yeah, an interactive waveform viewer is difficult
<awygle>
yes
<awygle>
i want to be able to adjust pipeline delays in real-time to line signals up with each other, things like that
<whitequark>
right, ok, that's much more ambitious
<awygle>
indeed
<whitequark>
still worth thinking about... some day
<awygle>
so i am broadly in favor of the console thing, but would likely not use it much and primarily see it as a step to future things.
<awygle>
although as i'm thinking about it i did have that "how do i see the value of this Const expression" problem the other night so... maybe i'm underestimating its usefulness
<whitequark>
yes, that's what prompted it; though you're not the first
<_whitenotifier-3>
[nmigen] whitequark commented on issue #310: hdl.ast.Value.word_select() works incorrectly on actual platform (ECP5 Versa) - https://git.io/JvZM4
<_whitenotifier-3>
[nmigen] whitequark closed issue #310: hdl.ast.Value.word_select() works incorrectly on actual platform (ECP5 Versa) - https://git.io/JvZMB
<awygle>
whitequark: what's the intended separation between nmigen/lib, nmigen-soc, and nmigen-io?
<whitequark>
nmigen/lib is stuff that's of overwhelmingly general usefulness (like CDC) and which also varies from vendor to vendor (like... well... CDC)
<whitequark>
nmigen-stdio is implementations of standard IO like UART or SPI where the FPGA-side interface is just signals/fifos/etc
<whitequark>
nmigen-soc is the plumbing for memory/io buses that SoCs are full of
<whitequark>
it's not strictly speaking limited to SoCs in the sense of "something with a CPU core"
<whitequark>
it's more like, "here are all the parts you can construct a SoC from, and also other things"
<whitequark>
specifically out of scope for nmigen-soc is all the junk that you need to build a toolchain, a BIOS, etc
<whitequark>
which was in scope for misoc/litex
<whitequark>
there are far too many approaches for that (Windows? Rust or C? which architectures? LLVM/Clang or GCC? Nix or Makefiles? etc etc) and it's a bikeshed I'm *super* uninterested in
<ktemkin>
which is good, since these things only generally wind up being maintainable (and thus maintained) if they're focused rather than trying to provide Everything Related (TM)
<whitequark>
yeah; I imagine _florent_ will port LiteX to nMigen at some point and then that'll provide all the toolchain stuff. I'm totally happy with that.
<whitequark>
and I'm sure there will be other approaches too and I'm happy with that too.
<whitequark>
I'll just make sure they can use the same plumbing with no issues.
<whitequark>
ZirconiumX: does quartus warning suppression actually work for you? it doesn't for my copy of it...
<whitequark>
18.1.0
<ZirconiumX>
Yeeaah, it seems rather finicky.
<awygle>
whitequark: seems like you'd run into overlap between nmigen-stdio and nmigen-soc, since you'll want to be able to configure your cores for UART or SPI, no?
<ZirconiumX>
I think the idea here is that you can have a UART segment agnostic to the SoC bus, awygle
<jfng>
you could have wrappers in nmigen-soc for cores in nmigen-stdio
<jfng>
for example, an AsyncSerialPeripheral in nmigen-soc, that provides a CSR interface to control an AsyncSerial core in nmigen-stdio
<awygle>
mm. so drag everything that'd come from a register, like e.g. baud rate, out to a port of the nmigen-stdio module?
<jfng>
yes, and RX/TX data, strobes, etc. and maybe FIFOs in both directions
<awygle>
I see
<jfng>
but then, if a peripheral also has a memory interface, like say, a DRAM controller, it would not be bus-agnostic
<jfng>
so maybe these wrappers should not be in nmigen-soc
<whitequark>
this is all correct yeah
<whitequark>
it's not entirely clear yet what to do with a DRAM controller
<whitequark>
i figure we'll just decide once we get there
<awygle>
so just to list some stuff ZirconiumX and i have coming down the pipe (all or none of which may end up being written in nmigen and/or upstreamed): UART - nmigen-stdio UTMI/ULPI - nmigen-stdio. SPI-mode SD card - nmigen-stdio (probably in two parts). DDR2 - nmigen-soc maybe? unclear. I2C - nmigen-stdio. yes?
<whitequark>
yup
<awygle>
what about like, a hypothetical controller for a specific I2C peripheral? is that kind of thing in scope?
<whitequark>
hmm
<whitequark>
unless it's something so common as to be "industry standard" then no
<whitequark>
btw, there is one important blocker for populating more stuff in nmigen-stdio
<whitequark>
a stream interface needs to be added to nmigen.lib
<whitequark>
there's been some progress towards that (private communication with key2 i think) but it's a topic worthy of a wider discussion
<awygle>
can you elaborate on "stream interface"? i think i basically understand what you mean but want to make sure
<whitequark>
it should be definitely based on AXI4-Stream, and the payload should definitely be an nMigen Record or something similar
<whitequark>
and there should be an easy way to insert a FIFO anywhere, and in general connect things together in a flow graph style
<whitequark>
that last one is the main stumbling block, actually
<whitequark>
Record.connect (which implements the Migen interface with minimal changes) is pretty footgunny
<whitequark>
AFAICT it was an ad-hoc generalization of the way MiSoC implemented CSRs
<whitequark>
except it's not really very... general
<whitequark>
you can use it to connect Wishbone interfaces 1:1, but the way the API is shaped lets you connect Wishbone interfaces 1:n too
<whitequark>
and that doesn't actually work unless your peripherals implement a very specific kind of Wishbone subset (one where dout is always 0 when the peripheral is not addressed,)
<whitequark>
another issue is that you can use DIR_FANIN to do "wired-OR" for flags you might have around, but you can't do any other function
<_whitenotifier-3>
[nmigen/nmigen] whitequark pushed 2 commits to master [+0/-0/±10] https://git.io/JvZFl
<_whitenotifier-3>
[nmigen/nmigen] whitequark 5888f29 - xilinx_{7series,ultrascale}: run `report_methodology`.
<_whitenotifier-3>
[nmigen/nmigen] whitequark 3e2ecdf - build.res,vendor: place clock constraint on port, not net, if possible.
<awygle>
Do you have a specific affection for axi4-stream over Avalon-st or the pipelined modes of WB4?
<whitequark>
WB is... let's say, not very good in general
<whitequark>
I consider it a legacy bus and while it has first class support, that's mostly because it's historically popular in OSHW
<whitequark>
I haven't investigated Avalon-ST in detail but it seems virtually identical to AXI4-Stream
<whitequark>
the idea is to not have AXI4-Stream put in nmigen.lib *verbatim*, but rather have a very similar stream interface that can have near-zero-cost adapters to specific buses
<awygle>
sure, ok
<whitequark>
in practice I suspect it'll be something like "can be bridged to either axi4-stream or avalon-st, and to that end, handles edge cases in a way restricted enough to be compatible with both"
<whitequark>
it'll be necessary to look closely at everything we want to interface with first, maybe that wouldn't work out, but you see the general direction
<awygle>
the only major issue with WB i'm really aware of is that it's underspecified, so "wishbone-compatible" doesn't mean much
<awygle>
but i can't say i've investigated deeply
<whitequark>
that's the main one
<whitequark>
for example, I'm still not sure exactly how error and retry strobes are supposed to work
<awygle>
in any case, this discussion would probably be better captured on an issue. would you like me to file one?