<_whitenotifier-f>
[nmigen] rroohhh synchronize pull request #517: lib.fifo.AsyncFFSynchronizer: check input and output signal width - https://git.io/JTPFl
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #517: lib.fifo.AsyncFFSynchronizer: check input and output signal width - https://git.io/JTPFD
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #517: lib.fifo.AsyncFFSynchronizer: check input and output signal width - https://git.io/JTPFD
<_whitenotifier-f>
[nmigen] codecov[bot] edited a comment on pull request #517: lib.fifo.AsyncFFSynchronizer: check input and output signal width - https://git.io/JTPFD
<_whitenotifier-f>
[nmigen] whitequark closed pull request #517: lib.fifo.AsyncFFSynchronizer: check input and output signal width - https://git.io/JTPFl
<_whitenotifier-f>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JTPNl
<_whitenotifier-f>
[nmigen/nmigen] rroohhh 05decc4 - lib.fifo.AsyncFFSynchronizer: check input and output signal width
<_whitenotifier-f>
[nmigen] whitequark commented on pull request #517: lib.fifo.AsyncFFSynchronizer: check input and output signal width - https://git.io/JTPN8
<_whitenotifier-f>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JTPNg
<_whitenotifier-f>
[nmigen/nmigen] whitequark 436de71 - Deploying to gh-pages from @ 05decc43b2e66a5cec8b9be880f90d606a76d34b 🚀
jeanthom has quit [Ping timeout: 246 seconds]
<d1b2>
<OmniTechnoMancer> Given issues with ASIC targeting, how terrible of an idea is it to try and use nmigen to develop a 74series CPU?
<whitequark>
OmniTechnoMancer: I know people already use nMigen for ASICs
<whitequark>
the problems I'm listing are really conceptual more than practical
<whitequark>
in other words: go ahead. it'll be fine.
<d1b2>
<OmniTechnoMancer> But ASICs get to have flip flop resets for less cost than discrete ones....
<whitequark>
what i've described above is the assumptions nmigen makes
<whitequark>
if you violate them you are depending on the current implementation
<whitequark>
however, if you know what you're doing (you'd have to, to successfully make this CPU) it's fine to do so
<d1b2>
<OmniTechnoMancer> Hmmm, will have to see how things go
emeb has quit [Quit: Leaving.]
jeanthom has joined #nmigen
emeb_mac has joined #nmigen
jeanthom has quit [Ping timeout: 246 seconds]
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #nmigen
_florent_ has quit [Read error: Connection reset by peer]
ianloic_ has quit [Read error: Connection reset by peer]
sorear has quit [Ping timeout: 260 seconds]
_florent_ has joined #nmigen
ianloic_ has joined #nmigen
sorear has joined #nmigen
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #nmigen
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 258 seconds]
PyroPeter_ is now known as PyroPeter
kernelmethod has joined #nmigen
kernelmethod has quit [Client Quit]
kernelmethod has joined #nmigen
kernelmethod has quit [Client Quit]
chipmuenk has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
_whitelogger has joined #nmigen
jeanthom has joined #nmigen
Asu has joined #nmigen
smkz has quit [Quit: smkz]
Asu has quit [Quit: Konversation terminated!]
Asu has joined #nmigen
<Chips4Makers>
OmniTechnoMancer: I think the main disadvantage for using nMigen for ASIC is that you can have simulation/implementation mismatch if your ASIC flow does not give you the required power-on reset determinism and your code depends on it.
<d1b2>
<OmniTechnoMancer> I have seen already, it is what lead to this thought
<Chips4Makers>
OK, I think it should be possible to define a nmigen platform that uses Pepijns 74series yosys synthesis setup.
<d1b2>
<OmniTechnoMancer> There has been some advances since, been talking with Lofty about it
<d1b2>
<OmniTechnoMancer> not nmigen specifically though
<Lofty>
Chips4Makers: yeah, I wrote the Yosys portion of that
akill has joined #nmigen
DaKnig has quit [Ping timeout: 272 seconds]
emeb has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Read error: Connection reset by peer]
smkz has joined #nmigen
mimir_ has joined #nmigen
<mimir_>
hey folks - i'm implementing a fairly large specification which uses LSB0 addressing everywhere (i.e. 0b01[0] == 1). because nmigen indexes in the reverse order, this's been causing a *lot* of problems. wondering if anybody's got a neat solution to handle this better. a few things i've considered:
<tpw_rules>
that's how nmigen works?
<tpw_rules>
in nmigen 0b01[0] is in fact 1
chipmuenk1 has joined #nmigen
<mimir_>
...that's right, WELP
<tpw_rules>
so is your problem fixed now? :)
<mimir_>
sorry i've got all four quadrants of [(little-endian byte order, big-endian byte order), (lsb0, msb0)] in this project and my brain is *very* small
chipmuenk has quit [Ping timeout: 272 seconds]
chipmuenk1 is now known as chipmuenk
<tpw_rules>
oof
<mimir_>
(but the msb0 stuff is all at the interfaces w/ verilog/vhdl so it's "self-contained" enough not to be a problem)
<tpw_rules>
verilog is lsb0 too...?
<tpw_rules>
at least if you specify that way
<mimir_>
external IP
<tpw_rules>
i'm confused. both verilog and nmigen are LSB0
<mimir_>
ohhh, okay, now i remember what was throwing me off - it's slices being "backwards" from verilog. haven't been working on this project in a month or two and that must've somehow gotten misremembered as "remember the bit order is reversed"
<tpw_rules>
yes
<tpw_rules>
Cat(a, b, c) == {c, b, a}
<tpw_rules>
i think that's the only case where there is a difference
<tpw_rules>
and well you would specify v[0:3] instead of v[3:0]
<mimir_>
cool, okay, gotcha
<tpw_rules>
i think that second one is a pretty easy mistake to catch because you will get a 0 length signal back
<tpw_rules>
maybe for the first one you could do like def Tac(*sigs): return Cat(*sigs[::-1]) which would swap the order around
<mimir_>
so (CLK >> 2) & 7 == CLK[2:4]?
<mimir_>
well, 2:5
<mimir_>
this spec also has inclusive bit ranges to make things extra fun
<tpw_rules>
yes
<mimir_>
ohhhkay
<tpw_rules>
to convert from verilog to python indexing you have to swap the operands and add 1 to the ending one
<mimir_>
is there a decent way to get a warning/error when doing some_10bit_signal.eq(some_longer_signal[0:10]) ? (i.e. not just have it silently zero-extended)
<mimir_>
because i can already tell i'm going to get *that* wrong a lot
<tpw_rules>
that's correct though? you'll get the lowest 10 bits of some_longer_signal
<tpw_rules>
but no afaik there are no extension or truncation warnings, iirc by design
<mimir_>
er, yeah, told you i'd get it wrong :P
<mimir_>
ohkay, will try not to trip over my feet too much on this
<tpw_rules>
yeah i'm not sure what to recommend to deal with the difference
<tpw_rules>
python's way is the most logical to me. verilog and stuff is weird
akill has quit [Ping timeout: 245 seconds]
<FL4SHK>
looks like you guys are talking about how Verilog has downto and upto ranges?
<FL4SHK>
Python ranges are way simpler
emeb_mac has joined #nmigen
jeanthom has quit [Ping timeout: 258 seconds]
<mimir_>
One Case statement can handle multiple cases, right? the source seems to indicate e.g. m.Case(1, 2, 3) should match 1, 2, or 3, but just want to double-check here