cr1901_modern has quit [Ping timeout: 260 seconds]
cr1901_modern has joined #nmigen
jeanthom has joined #nmigen
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
happycube has quit [Ping timeout: 264 seconds]
happycube has joined #nmigen
Asu has joined #nmigen
chipmuenk has joined #nmigen
<kbeckmann>
the platform file for gowin is starting to get quite large. is it preferrable if i submit a minimal PR and do follow-ups later on, rather than submitting a big "fully featured" one?
<whitequark>
minimal PR + follow-ups is good
<kbeckmann>
ok! thanks. it's getting a bit convoluted with the xdr support.
<lsneff>
Is there any way to turn off the signal width expansion thing?
<lsneff>
I keep running into bugs with accumulators not overflowing.
<whitequark>
there isn't; people have expressed an interest in lints but it would not be easy to make a precise lint for this case
<whitequark>
the usual convention is to assign to an accumulator like `m.d.sync += acc.eq(acc + 1)`, which inherently truncates to the accumulator size
<lsneff>
I guess I meant accumulator a bit more broadly. I have to worry about addresses expanding beyond their correct width when adding offsets into them, that kind of thing.
<lsneff>
Something which might work would be an additional add operator that doesn't do width widening?
<lsneff>
Could even be a funciton
<whitequark>
you can write such a function easily
<whitequark>
def my_add(a, b): return (a + b)[:max(len(a), len(b))]
<lkcl>
,s
* lkcl
has a new split keyboard... :)
<lkcl>
lsneff: have you considered writing unit tests (or formal proofs) that test the limits of the accumulator?
<lsneff>
lkcl: I'd like to do formal proofs, but I'm very new to fpgas and hardware description, so I'm still working my way through learning the basics
<lsneff>
whitequark: Does adding an integer to a signal widen the signal based on the magnitude of the integer?
<whitequark>
yes, indirectly; when a Python integer is cast to an nMigen value, the width of the value is determined by the magnitude
<awygle>
whitequark: am i correctly reading that nmigen-yosys doesn't include read_verilog?
<whitequark>
awygle: correct. we can include it if there's a reason to
<awygle>
this is the end of a train of thought, let me back it up
<awygle>
there's been a lot of discussion around nmigen formal lately which has shown that it is difficult (and also not the focus of the current release)
<awygle>
the most stable thing to do in the near term might be to write verilog wrappers for formal
<whitequark>
you
<whitequark>
you're incredibly optimistic if you assume yosys supports SVA well
<whitequark>
it supports ... barely enough SVA, and doesn't even try to do like, error checking on the input code
<awygle>
yeah, i know that. i have used it before for formal stuff.
<whitequark>
i cannot in good faith endorse this approach to the extent where it becomes the recommended way to do things
<awygle>
i'm not suggesting it as a recommendation, just thinking about it for me personally
<whitequark>
hmm
<awygle>
and again, short term
<whitequark>
why do you need nmigen-yosys for that?
<awygle>
so anyway, my next thought was "would that make distribution more complicated"
<awygle>
you still need the full yosys dep to do the formal proofs
<whitequark>
yowasp has a yosys that can do smtbmc
<awygle>
but what if you want to just build the thing without running the formal proofs? is nmigen-yosys sufficient for that?
<awygle>
hm, i wonder if nmigen-yosys supports read_verilog
<awygle>
and now you're caught up
<whitequark>
right. for anything you might want nmigen-yosys, there is yowasp-yosys, which uses the exact same tech but isn't cut-down
<awygle>
by "full yosys dep" above i mean a full yosys install either from source or yowasp, but not nmigen-yosys
<awygle>
i guess you can always make the call to include or not include verilog files in python, for cases where you're not running the proofs
<whitequark>
if you have any asserts in synthesis they will currently fail (AFAIK)
<whitequark>
so you have to do it anyway
<awygle>
anyway, not asking for any changes, just making sure i was reading hte shell script right
<whitequark>
yeah
<awygle>
oh, really? that's surprising but i guess not too shocking
<whitequark>
it will eventually likely include read_verilog, for cxxsim
<lsneff>
I'm not sure if this is a bug or if I'm just not getting it, but subtracting one from an inverted signal increases the width by one bit
<lsneff>
and inverting it also increases the width, which I guess makes sense, but it is pretty confusing
<lsneff>
Yep, turned out I'm dumb and didn't realize that `-` isn't `~`
chipmuenk has quit [Quit: chipmuenk]
FFY00 has quit [Ping timeout: 260 seconds]
FFY00 has joined #nmigen
<lsneff>
whitequark: Would you be interested in a pr that adds typing hints to nmigen?
<whitequark>
no; I acknowledge that typing hints are useful, but to be useful in nMigen specifically, they require a substantial amount of design effort before any coding starts
samlittlewood has quit [Ping timeout: 260 seconds]
samlittlewood has joined #nmigen
<lsneff>
Okay, I understand that
samlittlewood has quit [Ping timeout: 260 seconds]
samlittlewood has joined #nmigen
<mithro>
@whitequark / @ktemkin - Do you know if there is a diagram somewhere which shows where the various bits in the PCIe stack map to things like LitePCIe / ECP5-PCIe / Yumewatari ?
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
<awygle>
i'd also be interested in that (or just a verbal explanation)
samlittlewood has quit [Ping timeout: 256 seconds]
samlittlewood has joined #nmigen
samlittlewood has quit [Ping timeout: 265 seconds]
samlittlewood has joined #nmigen
samlittlewood has quit [Ping timeout: 240 seconds]
samlittlewood_ has joined #nmigen
samlittlewood_ has quit [Ping timeout: 265 seconds]
samlittlewood has joined #nmigen
samlittlewood has quit [Ping timeout: 240 seconds]
samlittlewood has joined #nmigen
emeb_mac has joined #nmigen
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #nmigen
samlittlewood has quit [Ping timeout: 265 seconds]
<lsneff>
When using something like picorv32, is there a generally suggested way of specifying that certain signals are accessible at certain addresses? It's easy enough to do as a one-off, but is there some sort of memory map primitive which would make it more reusable?
samlittlewood has joined #nmigen
samlittlewood has quit [Ping timeout: 264 seconds]
samlittlewood_ has joined #nmigen
samlittlewood_ has quit [Ping timeout: 260 seconds]
samlittlewood has joined #nmigen
samlittlewood_ has joined #nmigen
samlittlewood has quit [Ping timeout: 246 seconds]
samlittlewood_ is now known as samlittlewood
jeanthom has quit [Ping timeout: 260 seconds]
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #nmigen
alexhw has quit [Ping timeout: 240 seconds]
Asu has quit [Ping timeout: 258 seconds]
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #nmigen
samlittlewood has quit [Ping timeout: 260 seconds]
alexhw has joined #nmigen
emeb has quit [Quit: Leaving.]
samlittlewood has joined #nmigen
samlittlewood has quit [Ping timeout: 256 seconds]