<harryho>
whitequark: Sorry but I think I haven't got the whole picture here. In Migen I saw one difference between `get_obj_var_name` and `get_var_name` is that the prior removes underscore(s) from the variable name, but is that of importance in nMigen? Like if someone used `get_obj_var_name` in Migen, can `get_var_name` in nMigen completely replace that? Thank you very much once again!
<harryho>
Oh and sorry about that incomplete msg, I misclicked enter >_<
<whitequark>
ahh, I misremembered how it works, let me take another look
<harryho>
Thanks a lot!
<whitequark>
it looks like get_obj_var_name is used for things like ClockDomain, and get_var_name is used for things like Signal via trace_back
<whitequark>
in nMigen, trace_back is less necessary because the fragment tree is compiled down to a hierarchy of modules, so get_var_name is used directly
<whitequark>
moreover, get_obj_var_name traverses the stack upwards until it finds a class that isn't derived from the caller's class (I think) which is a pretty strange thing to do
<whitequark>
in nMigen, get_var_name gets an explicit argument that indicates which stack frame to get the variable name from, so I would say that it supercedes all tracer functions from oMigen.
<whitequark>
by the way, you're porting CSR from oMigen, right?
<whitequark>
well, misoc
<harryho>
Yes!
<whitequark>
normally when porting things from oMigen I stop and consider whether they perhaps need an improvement in their design, by collecting common problems / gotchas / feedback on how they work and seeing if that can be incorporated. have you (or perhaps sb0) looked at that?
<mtrbot-ml>
[mattermost] <sb10q> ime the main issue with the current system is making reads atomic when the CSR is larger than the bus word
<whitequark>
sb: yeah, I remember that. is there a single place to track all these issues? I was thinking of creating nmigen-cores and/or nmigen-soc already.
<mtrbot-ml>
[mattermost] <sb10q> currently this is handled manually in the cores by adding a "update" CSR that you write to update before you read
<mtrbot-ml>
[mattermost] <sb10q> which is annoying, inelegant and comes with a performance hit
<mtrbot-ml>
[mattermost] <sb10q> a better option is to make everything atomic (since that's what you want 99% of the time) and have a pre-defined order to access the parts
<mtrbot-ml>
[mattermost] <sb10q> and when the first part is accessed, the others are updated
<whitequark>
yeah, that sounds reasonable
<mtrbot-ml>
[mattermost] <sb10q> that requires the bus to have a read notification mechanism, which wishbone does but the simple CSR bus does not
<whitequark>
I was also thinking about ergonomics of CSR in code of cores
<whitequark>
IIRC JF hit some problems there in Minerva
<mtrbot-ml>
[mattermost] <sb10q> I think we can simply drop the simple CSR bus
<mtrbot-ml>
[mattermost] <sb10q> since after we add a read notification is becomes very much like wishbone and it's not worth it to add another bus standard
<mtrbot-ml>
[mattermost] <sb10q> re. nmigen-cores/nmigen-soc, use heavyx?
<mtrbot-ml>
[mattermost] <sb10q> if you don't need those, you can use any other package manager
<mtrbot-ml>
[mattermost] <sb10q> whitequark: there's the question of where to put the bus and CSR components
<mtrbot-ml>
[mattermost] <sb10q> are those also "cores"?
<mtrbot-ml>
[mattermost] <sb10q> and yes, we should add tests. @harryho could do that...
<whitequark>
sb: here's the plan I had in mind: nmigen-cores implements protocols, things like SPI, I2C, JTAG TAP, and so on. nmigen-soc adapts these cores to various buses, wishbone of course but I suspect it would pay off to not hardcode everything to wishbone specifically
<whitequark>
then heavyx would use both of them, plus some other legacy / foreign cores, plus native code toolchains, plus other things to provide a turnkey solution based on Nix
sb0 has joined #m-labs
<cr1901_modern>
AXI seems popular as well
<sb0>
whitequark: so how do you define the CSRs in nmigen-cores?
<sb0>
or, even, a DMA master?
<whitequark>
sb0: a CSR is basically an interface, right? a rw or ro register.
<sb0>
yep, but you'd need to put the abstract definition somewhere
<whitequark>
CSRs are collected from a hierarchy, and then exposed via an adapter to some bus, like Wishbone
<sb0>
does that go in nmigen-cores?
<whitequark>
ah, sorry, I misunderstood
<whitequark>
good question. things like Wishbone and CSR have no real use outside of SoCs, right? so they go to nmigen-soc. but I'm open to feedback on this.
<sb0>
okay, but then what's the interface in nmigen-cores?
<whitequark>
so let's say we have an UART, that would have something like tx_stb,tx_data,tx_full,rx_* as an interface.
<whitequark>
so microscope or any other design could use it.
<whitequark>
then, separately, there would be an adapter to Wishbone, which would have CSRs and maybe a FIFO.
<sb0>
okay so you just want a light library of protocol adapters?
<sb0>
with ad-hoc interfaces for each protocol
<whitequark>
correct
<sb0>
okay, yeah we can do that
<whitequark>
I would also like to write formal specifications for them, which is certainly easier if there's no Wishbone in between
<cr1901_modern>
sb0: In minerva, how do you specify the IRQ vector?
<sb0>
jfng: ^
<cr1901_modern>
First time looking at it... it's a really cool core :o
<sb0>
whitequark: but maybe nmigen-cores isn't the best name then
<sb0>
what exactly goes in there? I/O cores?
<sb0>
maybe nmigen-ioprotocols?
<whitequark>
sb0: hmm. maybe even just nmigen-io ?
<sb0>
you could confuse it with the platform I/O
<whitequark>
or something like nmigen-std, because it's implementing industry-standard protocols
<whitequark>
and because it's like a standard library
<sb0>
ok
<sb0>
or stdio :)
<whitequark>
heh
<sb0>
let's do nmigen-stdio :)
<cr1901_modern>
cute
<whitequark>
okay
<whitequark>
that's a pretty descriptive name after all
* zignig
is looking forward to a bunch of drop in modules.
<zignig>
I think making sure that the device naming is aligned with nimgen-board is important.
<whitequark>
sure
proteusguy has quit [Ping timeout: 245 seconds]
<harryho>
Thanks everyone, as a new guy in FPGA I'm learning a lot from our exchange. So in `nmigen-stdio` should we also include DRAM?
<whitequark>
in theory yes... in practice the more complex protocols like SATA and DDR were handled by lite* projects
<whitequark>
for various complex reasons, migen and litex have historically diverged more than they really should have
<whitequark>
hopefully nmigen will fix that. I think it would make sense to have things like PIPE, SATA and DDR in nmigen-stdio, in principle, as there are lots of SoC-less designs that still need memory for various reasons, like caches
<zignig>
having them in a form that makes it _possible_ to drop them into a Soc , but still be able to have them unitary.
<whitequark>
yeah.
<sb0>
whitequark: DDR support in artiq is from misoc, not litedram
<sb0>
what is PIPE?
<whitequark>
PHY Interface for PCI Express, but it also works for SATA and USB3
<whitequark>
it's an Intel thing. uncharacteristically for Intel it's reasonably good
<sb0>
so it's basically a FPGA transceiver wrapper?
<whitequark>
I think it's mostly for ASICs, but yes, it is a wrapper for SERDES/PCS
<sb0>
xilinx can't even get transceivers compatible across 7-series...
<whitequark>
but that's the whole point of PIPE, no?
<sb0>
yeah
<whitequark>
wrap all the xilinx crap for every FPGA series and not think about it again, hopefully
rohitksingh has quit [Ping timeout: 264 seconds]
<sb0>
just pointing out the bar isn't very high
<whitequark>
Intel uses PIPE on their CPUs, you can soft strap processor lanes to PCIe, SATA, USB3, and GigE
<sb0>
is it possible to get deterministic latency with PIPE?
<sb0>
if there's a good library for various FPGAs we could move DRTIO to that
<cr1901_modern>
Is PIPE "ULPI for USB3 and friends"?
<whitequark>
cr1901_modern: more or less
<whitequark>
yeah, we could have ULPI there too
<whitequark>
sb0: let's see
<whitequark>
sb0: ok well, I checked the latest version of the spec and they added a lot of strange complicated things to it, so maybe it's not such a good idea after all
<whitequark>
it also doesn't support deterministic latency after all
<sb0>
I wonder why so many transceivers use a barrel shifter for comma alignment instead of slipping the clock divider...
<sb0>
the second solution uses less resources, has less state, and is det-lat
<whitequark>
basically, there's "original PIPE" which includes aligner and elastic buffer, and "SerDes PIPE", which exposes raw SERDES to fabric
<whitequark>
completely unencoded, so you'd have to do 8b10b in fabric too
<whitequark>
impossible to meet timing with this on ECP5 for 5GT/s for example
<whitequark>
so it's useless
<sb0>
where does the timing fail?
<whitequark>
and in "original PIPE" alignmnent operation is not specified, so you get no guarantees
<whitequark>
oh
<sb0>
the only 8b10b timing that is actually critical is running disparity control, the rest can be pipelined
<whitequark>
hmmmm
<sb0>
and you can perhaps play carry chain tricks for the running disparity logic
<whitequark>
sb0: ECP5 fabric is slow enough that you need 1:4 gearing
<sb0>
ok
<whitequark>
you get 1:2 in the SERDES/PCS, and then you add a soft gearbox for 1:2 more
<sb0>
might still work
<sb0>
you just get a long chain for the RD control
<whitequark>
40 bits at 125 MHz on ECP5 seems challenging
<whitequark>
I think you get about 4-5 logic levels
<sb0>
most of those bits are processable in parallel
<sb0>
maybe tweak the pipeline a bit if timing fails
<whitequark>
I'll take a look
<whitequark>
my point was though, "original PIPE" incorporates 8b10b and FIFOs
<whitequark>
if one would implement PIPE such that it uses bit slip, it would provide deterministic latency with much less headache
<sb0>
bit slip == divider slip?
<sb0>
it's really the clock you want to change there
<whitequark>
hmm
<sb0>
i.e. extend or shorten the divider pulse by a small amount and repeatedly to reach comma align without clock glitches
<sb0>
but much SERDES silicon doesn't do that and implement idiotic and/or buggy crap instead
<whitequark>
it's not actually documented
<whitequark>
it has a word aligner that's certainly a barrel shifter
<whitequark>
with variable latency depending on alignment
<whitequark>
well, yeah, it calls it "barrel shift"
<sb0>
xilinx has it (they call it "PMA RX slide mode"), but it's shitty
<whitequark>
it also has a "bit slip" mode which is totally undocumented
<sb0>
the workaround I use is to reset the RX crap repeatedly, which gives a random phase every time, until comma align
<whitequark>
yeah, I remember that
<whitequark>
why is it shitty btw?
<sb0>
first, it only works when you have the elastic buffer enabled, which makes it useless
<sb0>
and it also has 1/2 UI non-determinism for some reason
<whitequark>
I see
<sb0>
there's a paper on another technique where they use a MMCM to regenerate the clock based on the barrel shifter position
<whitequark>
ew
<sb0>
that avoids the longer and random acquisition time that comes with the repeated resets, but it's more complex and uses more FPGA resources
<_whitenotifier>
[nmigen] RobertBaruch commented on issue #195: Mapping FSM state to integer, then as index in array of signals? - https://git.io/fjhOy
<_whitenotifier>
[nmigen] whitequark commented on issue #195: Mapping FSM state to integer, then as index in array of signals? - https://git.io/fjhOH
<_whitenotifier>
[nmigen] whitequark commented on issue #195: Mapping FSM state to integer, then as index in array of signals? - https://git.io/fjhO7
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 258 seconds]
<whitequark>
sb0: I'm looking at #97 again (CDC primitive naming bikeshed) and here's the best convention I came up with for FIFOs: r_domain, r_data, r_en, r_empty, w_domain, w_data, w_en, w_full. for gearbox: i_width, i_domain, o_width, o_domain. objections?
<whitequark>
one specific thing I wanted to avoid is the case where SyncFIFO is used and din is accidentally used instead of dout or vice versa, which produces no migen or pnr errors and is not easily seen at a glance
<_whitenotifier>
[nmigen] RobertBaruch commented on issue #195: Mapping FSM state to integer, then as index in array of signals? - https://git.io/fjhOA
<_whitenotifier>
[nmigen] whitequark commented on issue #195: Mapping FSM state to integer, then as index in array of signals? - https://git.io/fjhOp
<_whitenotifier>
[nmigen] RobertBaruch commented on issue #195: Allow multiple `with m.State("..."):` statements for the same state - https://git.io/fjhOh
<davidc__>
whitequark: thats actually something I was thinking about recently; a migen linter
<davidc__>
I might try to make a list of things it would be nice to have lints for
<whitequark>
davidc__: I'm not a huge fan of linters
<whitequark>
half of what linters do is paper over failures of language and compiler design, and the other half would be best served by something like an autoformatter
<whitequark>
but it is useful to have that list anyway, to use it for guidance
cr1901_modern has joined #m-labs
cr1901_modern1 has quit [Ping timeout: 245 seconds]
sb0 has quit [Ping timeout: 258 seconds]
sb0 has joined #m-labs
harryho has quit [Remote host closed the connection]
mumptai has joined #m-labs
cr1901_modern has quit [Ping timeout: 245 seconds]
cr1901_modern has joined #m-labs
cr1901_modern has quit [Quit: Leaving.]
<acathla>
What's the proper use of differential input in migen? Someone has a simple example? I tried Subsignal("lvds_p", Pins("G2"), IOStandard("LVDS_25")) but then if I use the pin directly, there is no differential use.
<jfng>
cr1901_modern1: minerva does not support vectored interrupts atm
cr1901_modern has joined #m-labs
<davidc__>
whitequark: I'm thinking more like cargo clippy, I guess. "Hey you used this pattern. This is a simpler option", or "You used a CSRStorage register as a submodule (oMigen)"
<davidc__>
the latter throws an error not obvious for a beginner to the language
m4ssi has joined #m-labs
rohitksingh has joined #m-labs
m4ssi has quit [Remote host closed the connection]