cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Ping timeout: 240 seconds]
_whitelogger has joined #nmigen
proteus-guy has quit [Ping timeout: 268 seconds]
Degi has quit [Ping timeout: 265 seconds]
Degi has joined #nmigen
MadHacker has joined #nmigen
XgFgX has joined #nmigen
XgF has quit [Disconnected by services]
nurelin has joined #nmigen
kbeckmann2 has joined #nmigen
nurelin_ has quit [*.net *.split]
adamgreig has quit [*.net *.split]
MadHacke1 has quit [*.net *.split]
kbeckmann1 has quit [*.net *.split]
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
adamgreig has joined #nmigen
_whitelogger has joined #nmigen
kernelmethod has joined #nmigen
kernelmethod is now known as kmtd
kmtd has quit [Quit: Konversation terminated!]
kmtd has joined #nmigen
kmtd has quit [Client Quit]
kmtd has joined #nmigen
kmtd is now known as kernelmethod
kernelmethod has quit []
kernelmethod has joined #nmigen
proteus-guy has joined #nmigen
_whitelogger has joined #nmigen
kernelmethod has quit [Ping timeout: 260 seconds]
_whitelogger has joined #nmigen
Asu has joined #nmigen
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel_ has joined #nmigen
electronic_eel_ is now known as electronic_eel
<
Degi>
Hm nmigen complains about a signal being driven from multiple fragments, but each subsignal is driven by a different fragment...
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel has joined #nmigen
electronic_eel has quit [Ping timeout: 258 seconds]
electronic_eel has joined #nmigen
<
whitequark>
Degi: each subsignal? can you post an MCVE?
<
Degi>
MCVE? It gave a warning about flattening the hierarchy but actually worked in the end.
<
ZirconiumX>
Minimal, Complete and Verifiable Example
<
ZirconiumX>
I'm gonna be honest, that's an odd architecture
<
ZirconiumX>
Perhaps "unidiomatic" is a better term
<
ZirconiumX>
So, I think nMigen is doing this at the Signal level
<
ZirconiumX>
At which point the error makes sense
<
whitequark>
what ZirconiumX said is correct
<
whitequark>
the cause of the warning is that nMigen turns every Signal into a module port when it emits hierarchical Verilog modules
<
whitequark>
there is no way to do that, in general, if the bits of that signal are driven from different moules in first place
<
whitequark>
hence the warning and the flattening
kbeckmann2 is now known as kbeckmann
kbeckmann has quit [Quit: WeeChat 2.7]
kbeckmann has joined #nmigen
kernelmethod has joined #nmigen
kmtd has joined #nmigen
kernelmethod has quit [Ping timeout: 260 seconds]
<
mwk>
hmm, what'd be wrong with using inout in this case?
<
mwk>
I mean, it's messy and all, but wouldn't it work?
kmtd has quit [Ping timeout: 255 seconds]
kmtd has joined #nmigen
<
whitequark>
I thought Yosys doesn't support internal inout when I was implementing tht
<
whitequark>
I'm not sure if it does
awygle has quit [Remote host closed the connection]
awygle has joined #nmigen
<
_whitenotifier-3>
[nmigen-boards] sjolsen opened pull request #51: resources.display: Apply inversion setting to dp -
https://git.io/Jvig9
<
_whitenotifier-3>
[nmigen-boards] whitequark commented on pull request #51: resources.display: Apply inversion setting to dp -
https://git.io/Jvigp
<
_whitenotifier-3>
[nmigen-boards] whitequark closed pull request #51: resources.display: Apply inversion setting to dp -
https://git.io/Jvig9
<
_whitenotifier-3>
[nmigen/nmigen-boards] sjolsen c330044 - resources.display: Apply inversion setting to dp
<
mwk>
whitequark: it should work AFAICT
<
mwk>
I mean, I can't immediately think of anything that would break it
<
mwk>
I'd even say it's a reportable bug if you do find something
<
whitequark>
okay, I will take note of this for the future rewrite of that part of the code
<
whitequark>
#191 requires that rewrite
Asu has quit [Remote host closed the connection]
kmtd has quit [Ping timeout: 240 seconds]
<
_whitenotifier-3>
[nmigen] whitequark closed pull request #329: Implement solution to AsyncFIFO resets, as in #328 -
https://git.io/JvVCG
<
_whitenotifier-3>
[nmigen/nmigen] awygle 4601dd0 - Correctly handle resets in AsyncFIFO.
<
_whitenotifier-3>
[nmigen] whitequark commented on pull request #329: Implement solution to AsyncFIFO resets, as in #328 -
https://git.io/JviaK
<
awygle>
oh! surprising. expected more changes lol
<
whitequark>
I did approve it on the last round, besides some comment wording
<
whitequark>
I think the logic is pretty bulletproof there