<_whitenotifier-3>
[nmigen] sbourdeauducq commented on issue #116: Should memory read ports use domain="comb" or domain=None instead of synchronous=False? - https://git.io/fjKNM
<_whitenotifier-3>
[nmigen] sbourdeauducq reopened issue #116: Should memory read ports use domain="comb" or domain=None instead of synchronous=False? - https://git.io/fjoyb
<_whitenotifier-3>
[m-labs/nmigen] sbourdeauducq pushed 1 commit to master [+0/-0/±1] https://git.io/fjKNQ
<sb0>
whitequark: is this get_input/output/... architecture going to work with things like transceiver clock buffers on xilinx (e.g. IBUFDS_GTE3)?
<sb0>
that's one special case where you don't want any i/o buffer on the pin, and there are probably others
<sb0>
transceiver data pins too
<sb0>
whitequark: also for PinsB don't you want the inverting logic to be pushed into the design?
<sb0>
in many cases it's free when you just modify a LUT contents; adding an inverting LUT that the synthesizer won't touch uses more resources, degrades timing, and potentially causes issues with things like IOB registers or SERDES
_whitelogger has joined #m-labs
philwright_ has quit [Quit: Leaving]
<sb0>
whitequark: if there are unused I/Os in a design, they still appear as IB, and this then causes yosys/nextpnr failures
<sb0>
ERROR: Cell '$4' cannot be bound to bel 'X38/Y0/PIOB' since it is already bound to cell 'uart_0__rx__io$tr_io'
<sb0>
with crappy error messages like this
<sb0>
*unused inputs
<sb0>
this occurs if you use the uart resource for TX only, for example
tweakoz has joined #m-labs
rohitksingh_work has joined #m-labs
<sb0>
hmm there are other bugs. this new way of doing I/O seems to trigger many yosys/nextpnr problems
early` has quit [Ping timeout: 248 seconds]
early has joined #m-labs
<sb0>
rjo: did you find projects using rust+lwip?
rohitksingh has joined #m-labs
<rjo>
sb0: iirc whitequark even wrote a rust lwip wrapper and there were people interested in it.
<sb0>
the first artiq rust firmware used lwip, yes
<sb0>
there were many problems with it (it is unclear how much of that were due to that liteeth packet buffer bug, since iirc there were attempts to copy data which would have masked that bug) and smoltcp started after that
proteusdude has quit [Ping timeout: 245 seconds]
proteusdude has joined #m-labs
m4ssi has joined #m-labs
<rjo[m]>
I remember whitequark pointing people to that old code recently.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<_whitenotifier-3>
[nmigen] sbourdeauducq opened issue #123: better names for I/O primitive instances - https://git.io/fj6eF
<whitequark>
sb0: regarding IO buffers, if you don't want any IO buffer on the pin, you do something like this:
<whitequark>
that definitely needs to be documented better
<whitequark>
regarding inverting logic, let me think about it a bit
<_whitenotifier-3>
[nmigen] whitequark commented on issue #116: Should memory read ports use domain="comb" or domain=None instead of synchronous=False? - https://git.io/fj6vf
<whitequark>
sb0: regarding "ERROR: Cell '$4' cannot be bound to bel" etc, can you add an issue with an MCVE? this shouldn't happen.
<whitequark>
as for triggering yosys/nextpnr problems, using inout ports directly triggers even worse problems that are usually silent miscompilations, and is not really an option
<sb0>
I get issues even with the simplest designs...
<whitequark>
so where is the github issue then?
<sb0>
as for the object returned by platform.request(), is it best practice to use it directly in .eq(), or do x.o.eq(...) / ....eq(x.i)
<sb0>
forthcoming, i'm looking into the xilinx stuff atm
<whitequark>
ok
<whitequark>
regarding the returned object, the best practice is using x.o and x.i
<whitequark>
anyway, I gave the IOB instantiation code a fair amount of testing and didn't get anything like the yosys/nextpnr errors you show, so there must be something different that I'm missing
<sb0>
ok moment I'm nearly done with the xilinx stuff
<_whitenotifier-3>
[m-labs/nmigen-boards] sbourdeauducq pushed 1 commit to master [+1/-0/±0] https://git.io/fj6vl
cr1901_modern has quit [Ping timeout: 268 seconds]
<_whitenotifier-3>
[nmigen] sbourdeauducq opened issue #124: nextpnr error: Cell cannot be bound to bel since it is already bound - https://git.io/fj6vV
<whitequark>
both rx and tx ended up bound to C11.
<whitequark>
and for that matter, omigen didn't detect it either.
<whitequark>
so let's just add some code to nmigen to detect and handle this case
<_whitenotifier-3>
[nmigen] whitequark commented on issue #124: nextpnr error: Cell cannot be bound to bel since it is already bound - https://git.io/fj6vy
<sb0>
okay. i have another two nextpnr crashes that seem related to i/o changes, but the repro is large...
<whitequark>
file them as is, I have minimization tools
<whitequark>
I wrote a bugpoint pass for yosys
<_whitenotifier-3>
[nmigen] whitequark opened issue #125: "comb" should not be accepted as a name in ClockDomain(), DomainRenamer(), etc - https://git.io/fj6fe
<_whitenotifier-3>
[nmigen] sbourdeauducq commented on issue #125: "comb" should not be accepted as a name in ClockDomain(), DomainRenamer(), etc - https://git.io/fj6fI
<_whitenotifier-3>
[nmigen] whitequark commented on issue #125: "comb" should not be accepted as a name in ClockDomain(), DomainRenamer(), etc - https://git.io/fj6fq
<whitequark>
sb0: my main argument for read_port(domain="comb") is for symmetry with m.d.comb and m.d["comb"]
<whitequark>
I think it would be unnecessarily confusing if we had to teach people that in some contexts, combinatorial domain is called "comb" but in others it is called None with no apparent logic to it
<whitequark>
also, if you are writing generic code, maybe you want to do something like: mem.read_port(domain); m.d[domain] += ...
<sb0>
ah, right, you changed the syntax
<whitequark>
yes
<whitequark>
that was actually rjo's idea, but I liked it.
<sb0>
I thought m.d.sync was shorthand for m.d.sync.sys like in migen
<whitequark>
ah.
<sb0>
in that case ok
<_whitenotifier-3>
[nmigen] whitequark commented on issue #116: Should memory read ports use domain="comb" or domain=None instead of synchronous=False? - https://git.io/fj6fc
<_whitenotifier-3>
[nmigen] whitequark closed issue #116: Should memory read ports use domain="comb" or domain=None instead of synchronous=False? - https://git.io/fjoyb
<whitequark>
sb0: I have this idea for an API and I want to know what you think about it
<whitequark>
let's say I have an instruction decoder that has a ton of signals as outputs. I want to be able to tap into combinatorial outputs as well as register them, without writing too much code
<whitequark>
so the natural thing is to do something like:
<whitequark>
self.o = Record([...])
<whitequark>
self.r = Record.like(self.o)
<whitequark>
self.ce = Signal()
<whitequark>
with m.If(self.ce): m.d.sync += self.r.eq(self.o)
<whitequark>
the thing is that currently the inner signals in Record can't be created with options. you can't make them reset_less, can't set reset value, can't set the decoder
<whitequark>
maybe we should extend Layout to allow that?
<_whitenotifier-3>
[nmigen] whitequark opened issue #126: Record.like ignores modifications to signals - https://git.io/fj6fV
tweakoz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rohitksingh_work has quit [Read error: Connection reset by peer]
<_whitenotifier-3>
[nmigen] whitequark commented on issue #124: Detect pin/ball conflicts between resources when they are requested - https://git.io/fj6I2
<_whitenotifier-3>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fj6IP
<_whitenotifier-3>
[m-labs/nmigen] whitequark 7059cb4 - hdl.rec: thread src_loc_at to all inner Signals and Records.
<_whitenotifier-3>
[nmigen] whitequark closed issue #124: Detect pin/ball conflicts between resources when they are requested - https://git.io/fj6vV
<_whitenotifier-3>
[nmigen] whitequark commented on issue #124: Detect pin/ball conflicts between resources when they are requested - https://git.io/fj6Lt