<awygle>
whitequark: since Record inherets UserValue, and indexing/slicing a UserValue causes it to be lowered, is it ok if the result of the test_iter test case changes? or should i copy Value's (non-lowering) implementations of indexing and slicing into Record?
<whitequark>
awygle: we should get rid of indexing/slicing Records
<whitequark>
yes, that's a breaking change, yes, it's one of the few i planned for 0.3, and i think everyone will actually welcome that
<whitequark>
i consider direct indexing/slicing Records one of my moderate design mistakes
<awygle>
oh, so instead of lowering in that case i just raise an exception and frag the test? (or maybe assertRaises the test)
<whitequark>
just remove the test
<whitequark>
well
<whitequark>
you could change it to Value.cast(rec)
<whitequark>
i don't recall which test it was
<awygle>
wait so i'm confused. are you only talking about _direct_ slicing of records? or are you saying that performing the slice operation on a record should fail (as opposed to causing it to be lowered to a concatenation of field signals which are then sliced)?
<Falteckz>
Do any of the supported GTKWave formats support analog values?
<awygle>
Falteckz: not as far as i know but you can visualize a multi-bit digital signal in a number of analog-ish ways, which is probably what you actually want anyway
<whitequark>
awygle: latter
<whitequark>
in retrospect Record(...)[1] was a mistake
<awygle>
whitequark: okay then, the only function of this test is to make sure that works, so i'll just remove it
<whitequark>
yep
<awygle>
are we going to end up removing records entirely? it seems like we keep stripping them of more and more functionality
<awygle>
not that that's bad
<whitequark>
no, not exactly
<whitequark>
so for one, some sort of "packed struct" will always be needed in the core language
<whitequark>
another is that we'll need some way to represent bundles that appear in module interfaces
<whitequark>
actually, hm
<whitequark>
how do you feel about doing the record redesign and stream design at the same time? then we can hold off the CustomValue stuff until then
<whitequark>
what i'm thinking is that perhaps instead of a single Record doing two things, we could have two distinct entities, think a PackedStruct and an Interface (provisional names)
<whitequark>
PackedStruct could be a Value and it could only be indexed with [""], avoiding the problem of extending the set of operations on Values in that way
<whitequark>
sorry, unclear
<whitequark>
PackedStruct could have its fields accessed only with [""], avoiding the problem of extending Value
<whitequark>
you could also index it like any other Value
<key2>
ktemkin: we tried the liteiclink on the usb3
<key2>
i mean on the usb-c
<key2>
which validates also the usb-3 link theorically
<whitequark>
PackedStruct would also not have Directions or anything like that. just... packed bits
<key2>
ktemkin: as flo's work on usb3 is based on it
<whitequark>
on the other hand Interface would have directions (or whichever variant we end up with), could be connected, wouldn't derive from Value and wouldn't be indexable
<awygle>
whitequark: i do actually like that quite a bit
<awygle>
and we could (maybe) use Interface for the "elaboratable ports should have a direction" thing too
<whitequark>
yes, that's part of the idea
<whitequark>
(we could also make PackedStruct accessible safely via a trick like m.d.<domain>
<ktemkin>
I like the sound of splitting them
<whitequark>
okay, very encouraging feedback!
<whitequark>
i think this feature is too large to go into 0.3, so let's postpone it to 0.4
<whitequark>
0.5 should be the IR refactor, and then i think we can have 1.0
<awygle>
what else is blocking 0.3 now then?
<whitequark>
cxxsim
<whitequark>
that's it
<awygle>
ah, k
* awygle
goes back to figuring out this thing that's almost certainly not actually a synth-sim mismatch
jjeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 264 seconds]
Degi has quit [Ping timeout: 265 seconds]
Degi_ has joined #nmigen
Degi_ is now known as Degi
* zignig
just watched the skywater-pdk presentation by @mithro
<zignig>
will it be possible to nmigen -> asic in the fullness of time?
<whitequark>
there's a tracking issue
<zignig>
so there is , fail on search powers...
<zignig>
going to be an interesting project to watch.
<ananan>
zignig: hah i was just thinking the same thing
jaseg has quit [Ping timeout: 260 seconds]
<ananan>
unless i'm missing something, most of the issues there seem like they can be easily worked around by writing a small top-level verilog wrapper, no?
jaseg has joined #nmigen
<zignig>
ananan: making asics is complicated , by my understanding from the video is that most of the complexity is going to moved into the "compiler" and tooling.
<zignig>
writing an FPGA in nmigen would be cool.
<zignig>
and the final metacircular would be to compile a new version of a processor on itself.
<ktemkin>
pretty reasonable for code inset in a paper
<ktemkin>
who has enough characters for the extra "elf"? =P
<agg>
they had enough space characters to put all those extra spaces in!
<agg>
spare*, I guess
<ananan>
zignig: wdym?
<whitequark>
agg: more verilog-like things make me sad :S
<agg>
it looks like they only output SV and use Verilator for all simulation I think
<ktemkin>
it kind of amazes me that someone would get to the point of designing a new (domain-specific-)language and then be like "hmm... the ability to infer latches... yes, we need that"
<agg>
and yes, it seems a shame to embed a HDL in python and decide to keep as much verilog syntax as you could
<agg>
@always_ff as a decorator is inspired
FFY00 has quit [Ping timeout: 246 seconds]
FFY00 has joined #nmigen
<cr1901_modern>
I kinda can't hate latches... too much old crap uses them
<agg>
from that tiny snipped I don't really understand how their clock domains work but I imagine that's more an abbreviated example
<agg>
ktemkin: but if they didn't allow inferring latches, they wouldn't need to write CheckInferedLatchesPass to detect them!
<ktemkin>
ah, that's right
<ktemkin>
if you don't provide footguns, you won't be able to brag about your excellent diagnostics that sometimes detect them
<ktemkin>
forgive that joking, though; I don't mean to actually pick on the work
<agg>
hmm though despite the paper talking about CheckInferredLatchPass (also spelt CheckInferedLatchPass in their code example) I can't find it in the repo
<cr1901_modern>
Having to specify manual latches (or something approximating their behavior) is fine. I wish nmigen had even that, but wq said that was a hard "no".
<agg>
right, same, I'm mostly curious about other approaches
<agg>
and this has been going since 2017 with thousands of commits, it's a serious project
<ktemkin>
cr1901_modern: I'm good with the idea of having to spend unusual effort to do unusual things
<ktemkin>
at least, in the sense of "unusal" that matches explicitly wanting a latch on an FPGA
<cr1901_modern>
I _think_ a decent number of async writes/reads, even on old crap, could reasonably be replaced with a FF clocked on the opposite edge. But aside from settling on that to emulate the async register file of an old sound chip, I've not looked into it further.
<ktemkin>
I mean, nMigen's not going to stop you from invoking an Instance that has your desired latch behavior
<cr1901_modern>
I wanted something that would generate the right primitive when fed into nmigen.build, to abstract the primitive away.
<ktemkin>
I mean, you could do the terribly cursed thing and write a little behavior description in Verilog, and then Instance that
<cr1901_modern>
Sure why not? I'll make wq very very sad tho. And I don't want to do that :(.
<ktemkin>
having to write some cursed code to make a cursed thing happen seems reasonable
<whitequark>
cr1901_modern: if you want a latch, you can instantiate a $dlatch or a vendor primitive
<whitequark>
that's the supported way
<whitequark>
i don't personally dislike latches--they certainly have their valid uses. it's just that nMigen targets synchronous logic, so it doesn't spend a lot of effort on non-synchronous parts
<awygle>
> it seems like a shame to embed a HDL in python and decide to keep as much verilog syntax as you could
<awygle>
if i was going to write a nuHDL it would be, syntactically, very similar to verilog
<awygle>
for the same reasons that rust looks (at a surface level) a lot like C
<cr1901_modern>
$dlatch way is reasonable. Dunno why I didn't think of it.
<agg>
awygle: would that be an HDL that you write a parser/compiler for, or an HDL embedded in Python?
<awygle>
i wouldn't embed it in python no
<agg>
right, it seems fair enough (maybe) to write a new language that looks a bit like verilog for familiarity, just like rust:c
<awygle>
you have a good point there
<agg>
but if you're embedding inside python, I want to be writing python
<ktemkin>
just, for the love of all that's sacred, please don't make anyone write "end else begin"
<awygle>
sorry, i honestly probably would do that
<awygle>
i might make { sugar for "begin" or vice versa tho
<awygle>
ya gotta meet the people where they are imo
<agg>
you'd allow { or begin, and } or end?
<agg>
how about if(enable) { out=1; end
<awygle>
maybe? idk, i'd have to be doing it to make that call for sure
<awygle>
and i'd require them to match { to } and begin to end
<agg>
:p
<ktemkin>
obviously { matches } and `do` matches `end`~
<agg>
while...elihw
<esden>
cr1901_modern: No problem, the PR for iCEBreaker nmigen examples are on my todo list. I wanted to try them out before I merged them.
<cr1901_modern>
tyvm
<agg>
the same issue of IEEE Micro that had the PyMTL3 paper also has a paper on PyRTL, fun to see articles on two different python-based HDLs at least
<agg>
though that paper's short worked example uses 'sum' as both a built-in method and a variable name which seems a shame
<awygle>
i was more interested in the LiveHD paper
<awygle>
tho i haven't read it yet
<awygle>
i've been following that project for a bit now, it's very interesting
<ktemkin>
if someone wants to do something entirely cursed, I would adore the dadaism of a new-HDL embedded in QuickBASIC 4.5
<cr1901_modern>
HDL core that plays GORILLAS.BAS
<ktemkin>
LLVM HLS backend that creates the ideal CPU to run your GORILLAS.BAS
<ktemkin>
combine with one of the qbasic LLVM frontends
<ktemkin>
*when combined
<cr1901_modern>
MOVBB- Move Banana Bomb
<awygle>
this build is firmly into "go make coffee" territory at this point :(
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 246 seconds]
PyroPeter_ is now known as PyroPeter
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #nmigen
<TD-Linux>
cr1901_modern, if you want to interface with some weird external bus and capture on negative edge etc (with a FPGA) your best bet is using IOBs for that purpose
lkcl_ has quit [Ping timeout: 246 seconds]
mwk has quit [Ping timeout: 264 seconds]
lkcl_ has joined #nmigen
<whitequark>
awygle: you're making myhdl :p
<awygle>
i said i wouldn't embed it in python :p
<whitequark>
oh
<whitequark>
oh i misread
<whitequark>
argh, github crashes constantly
<whitequark>
i'm not going to get any work until i have the laptop fixed am i
<whitequark>
(dont worry i'll have the new motherboard like uh... this evening probably)
<d1b2>
<Darius> github crashes?
<whitequark>
yes
<whitequark>
well, chromium crashes on ... i'm not sure if it's javascript or if just scrolling constantly does this
<whitequark>
something's screwy with my laptop and now doing *anything* immediately raises the CPU temperature to 100°C and then it misbehaves
<whitequark>
replaced the TIM, no cracks on heatpipes, very puzzling behavior all in all
<whitequark>
the bottom line is that without the github issue tracker i can't get any work done
<whitequark>
plus i don't like the idea of downgrading to a pentium 3 celeron
<d1b2>
<Darius> huh that is pretty weird
<d1b2>
<Darius> that would be a bit of a downgrade
<d1b2>
<Darius> unless you use it to run X11/VNC/et al to connect to a 'real' computer to run a browser on!
<whitequark>
i don't have another computer
<d1b2>
<Darius> ah bugger
<whitequark>
(which is why i stock up on spare parts for this one! alas, no motherboard on hand i can use)
<d1b2>
<Darius> uh, do you want another one?
<whitequark>
not very? the overhead of moving between PCs is pretty high for me
<whitequark>
i'll just fix this laptop
<d1b2>
<Darius> yeah fair enough
<whitequark>
if i had a powerful workstation i could plug thunderbolt into i could use it as a build server with IPoTB
<whitequark>
(yes, cursed, i know)
<d1b2>
<Darius> cursed? sounds awesom!
<whitequark>
(yes I did consider running IPoTB to something that isn't even x86)
<whitequark>
(by any measure it is far cheaper to do this hack than to use proper 10GbE *and* you get 20 Gbps)
<d1b2>
<Darius> pretty amazing what mass production does to prices
<whitequark>
no
<whitequark>
well
<d1b2>
<Darius> also, I suppose consumer vs network infra
<whitequark>
some of it yes but like
<whitequark>
thunderbolt desn't have certified cables over 1m
<whitequark>
and even 1m is... optimistic
<whitequark>
i mean
<d1b2>
<Darius> ah yeah
<whitequark>
it works as long as you don't have something exotic nearby
<whitequark>
like "wifi"
<d1b2>
<Darius> lolsob
<whitequark>
my laptop is designed to have the wifi card right on the other side of the board where the TBT controller lives
<whitequark>
to make that work they wrapped it in layers of load bearing copper foil
<d1b2>
<Darius> makes you wonder how many board spins they went through before they discovered that
<whitequark>
if you carelessly remove the foil, any network activity on 2.4G (not on 5G for some reason) drops the link
<whitequark>
well, not just remove, even disturb
<whitequark>
after i discovered that i did a lot of swearing and then wrapped it in even more copper foil, works flawlessly for hours under heavy load
<whitequark>
incredible piece of engineering
<d1b2>
<Darius> yes "incredible"
<d1b2>
<Darius> very "incredible" given the low power of wifi 😕
<whitequark>
strongest thunderbolt controller in the world, howeve,r it is so fragile as to shatter when handled by any force other than the delicate touch of copper foil
<whitequark>
Darius: don't forget that it isn't just a wifi card
<whitequark>
it's a wifi card with antennas attached that are quite far away
<d1b2>
<Darius> that's why you have to laminate it with copper foil!
<whitequark>
so it was getting screwed by wifi *leakage*
<d1b2>
<Darius> what an incredible house of cards
<whitequark>
i recall this isn't the first time intel hits this specific issue
<whitequark>
there was something about usb3 interfering with 5g wifi
<d1b2>
<Darius> I thought USB3 and wifi interference was not uncommon, I've seen plenty of "plug this 2.4GHz (or 5GHz) dongle into a longer cable or use a USB2 hub if you have signal quality problems" in products
<whitequark>
yeah, since it is by design
<whitequark>
i wonder why usb3 doesn't use spread spectr... oh right no dedicated clock. bleh
<whitequark>
i wonder if running a clock over the now-unused usb2 pairs would have mitigated that problem
<sorear>
why do you need a clock separate from what you recover from the downstream?
<whitequark>
spread spectrum
<whitequark>
if your clock is highly stable you don't need one, and in fact you *can* run PCIe purely on recovered clock
<sorear>
so the CDRPLLs don't have enough bandwidth to handle a spread spectrum clock?
<whitequark>
but you want central clock distribution for a few reasons, one of which is being able to do spread spectrum to reduce emi
<whitequark>
i believe so
<whitequark>
i think it's even intentional?
<awygle>
huh til
<awygle>
that makes sense but i always wondered
<whitequark>
which part?
<awygle>
i live in fear of the day i have a need for thunderbolt and find out that in one of my many openings of my laptop i have killed the TB
<awygle>
oh, the pcie refclk thing
<whitequark>
ah
<whitequark>
i think there are other reasons too
<whitequark>
something about power management
<whitequark>
like you might not be able to acquire the recovered clock fast enough for some of the PM modes
<whitequark>
there *are* boards that run PCIe without associated clock (or so I'm told) but apparently it's for like, when you're the system integrator and you solder all that shit on and you carefully configure how it works in the kernel
<whitequark>
i think power management is also why the USB3 LTSSM is quite a bit more complex than PCIe's
<awygle>
mhm
Falteckz has quit [Quit: Connection closed for inactivity]
mwk has joined #nmigen
chipmuenk has joined #nmigen
<jjeanthom>
whitequark, I'm back
<whitequark>
jjeanthom: ah, i think i fixed the Tristate issue you were hitting
<whitequark>
and also another one
<jjeanthom>
whitequark, awesome, thanks!
Asu has joined #nmigen
jjeanthom has quit [Ping timeout: 244 seconds]
<whitequark>
05:34 < whitequark> i'm not going to get any work until i have the laptop fixed am i
<whitequark>
turns out chromium had a *really* bad regression
<whitequark>
the laptop is fine
_whitelogger has joined #nmigen
<d1b2>
<Darius> @whitequark honestly I am shocked that a userland application would cause such issues
<TD-Linux>
with nmigen-soc is there any way to memory map a lower bus width peripheral to a wider bus, and have it automatically convert into e.g. 2 reads?
<TD-Linux>
I thought this was what "sparse" buses were supposed to be but it doesn't seem to be doing that
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 256 seconds]
chipmuenk1 is now known as chipmuenk
<TD-Linux>
oh I reread it again and ok sparse buses just zero extend the words
<FL4SHK>
whitequark: yes, I know how to use github
<FL4SHK>
let me go ahead and try to make the patch
<_whitenotifier-b>
[nmigen-boards] fl4shk opened pull request #72: fix DE0-CV (bank and cs) - https://git.io/JJTDR
<_whitenotifier-b>
[nmigen-boards] Ravenslofty commented on pull request #72: fix DE0-CV (bank and cs) - https://git.io/JJTyJ
<jfng>
TD-Linux: for wishbone, this would require a width down-converter
<jfng>
there is an up-converter proposal at #21 (which I'll review asap)
<jfng>
so I guess a down-converter should follow
<_whitenotifier-b>
[nmigen-boards] ECP5-PCIe opened pull request #73: Update SPI definition in interface.py to match new terminology - https://git.io/JJTH4
FL4SHK has quit [Ping timeout: 240 seconds]
XgF has quit [Ping timeout: 240 seconds]
FL4SHK has joined #nmigen
XgF has joined #nmigen
<awygle>
Damn, I can't believe chromium fucked up that badly
Asu has quit [Read error: Connection reset by peer]
Asu has joined #nmigen
<_whitenotifier-b>
[nmigen] jeanthom commented on issue #418: Simulation of Verilog output doesn't match nMigen simulation - https://git.io/JJT5U
chipmuenk has quit [Ping timeout: 246 seconds]
jeanthom has quit [Ping timeout: 244 seconds]
chipmuenk has joined #nmigen
<ktemkin>
I gave up on Chromium on my XPS a while back; since its rendering process kept interfacing with the kernel in ways that made it hard for other things to use the GPU
<ktemkin>
which made Wayland compositors very angry
<d1b2>
<Qyriad> Every once in a while Chromium still crashes my compositor and I kind of just deal with it.
<mithro>
whitequark: Would you mind setting up your logger for #skywater-pdk channel?
<awygle>
firefox 4 lyfe :shrug:
<awygle>
huh, i wonder if that emoji-fies on the discord end?
<awygle>
whitequark: i know there are many things that would make this difficult and/or problematic, but has there been any thought of attaching a frequency to a ClockDomain?
<awygle>
(or alternately, does that already exist/work and i just missed it)
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 244 seconds]
chipmuenk1 is now known as chipmuenk
FFY00 has quit [Ping timeout: 256 seconds]
FFY00 has joined #nmigen
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #nmigen
<awygle>
missing rust enums in nmigen :(
<d1b2>
<Qyriad> Rust's enums make me happy
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 256 seconds]
chipmuenk1 is now known as chipmuenk
smkz has quit [Quit: smkz]
smkz has joined #nmigen
<awygle>
me too
<awygle>
and they're so good for specifically opcodes/instructions
<d1b2>
<TiltMeSenpai> I haven't looked much into if this can be integrated into nmigen yet
<Degi>
Cant IntEnum be used for that?
<Degi>
awygle: You can do platform.add_clock_constraint(self.tx_clk, 250e6 / self.gearing), though I think thats more for the pnr
<awygle>
yeah i'm talking about propagating that to the clockdomain object in a way where it can be used to drive synthesis decisions
<awygle>
occasioned by me needing a timer that fires after 200 ns
<d1b2>
<Qyriad> @TiltMeSenpai huh; that looks pretty good, actually. I wonder how likely it is to actually make it into Python, though.
<d1b2>
<TiltMeSenpai> I really hope it does
<d1b2>
<TiltMeSenpai> I mean they added @ in 3.5 for matrix multiplication, which... why...
<d1b2>
<TiltMeSenpai> I don't think I've seen that in any code base yet
jeanthom has joined #nmigen
<d1b2>
<Qyriad> I didn't even know that was a thing
<d1b2>
<TiltMeSenpai> python has so many weird features that nobody really knows about or uses
<d1b2>
<TiltMeSenpai> reading pep's can be kinda fun
<d1b2>
<TiltMeSenpai> @ also has no standard library implementation, so while it's called the matrix multiplication operator, you're pretty unlikely to break things if you use it as a random infix operator (similar to pathlib abusing /)
<vup>
awygle: there was some discussion about it in #392 for usage in simulations
<awygle>
hmm kinda yeah
<awygle>
tangentially related at least
<Degi>
That'd be pretty useful for frequency synthesizers heh