cr1901_modern has quit [Ping timeout: 240 seconds]
jaseg has quit [Ping timeout: 240 seconds]
jaseg has joined #nmigen
electronic_eel has quit [Ping timeout: 258 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter_ is now known as PyroPeter
emeb_mac has quit [Ping timeout: 240 seconds]
emeb_mac has joined #nmigen
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #nmigen
Yehowshua has joined #nmigen
<Yehowshua>
It seems the combinational statements such as `m.d.comb += lhs.eq(rhs)` inside conditionals such as` m.If` default to 0 outside the conditional
<Yehowshua>
but not so for synchronous statments
<awygle>
Nmigen won't let you infer latches
<awygle>
Which is what the alternative id
<Yehowshua>
Ah makes sense
<Yehowshua>
Subtelties
Yehowshua has quit [Remote host closed the connection]
lkcl__ has joined #nmigen
lkcl_ has quit [Ping timeout: 265 seconds]
emeb_mac has quit [Quit: Leaving.]
<whitequark>
awygle: pong
Asu has joined #nmigen
cr1901_modern has joined #nmigen
<awygle>
zzz unfortunately. Mañana
Chips4Makers has quit [Ping timeout: 244 seconds]
Chips4Makers has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Ping timeout: 240 seconds]
Asu has joined #nmigen
Asuu has quit [Ping timeout: 240 seconds]
falteckz has joined #nmigen
<falteckz>
How recently did Simulator move from nmigen.sim.pysim to nmigen.back.pysim?
<whitequark>
a few days ago
<whitequark>
er
<whitequark>
it moved from nmigen.sim.pysim to nmigen.sim
<whitequark>
nmigen.back.pysim is the old location from nmigen 0.2
<falteckz>
Gosh. My env is all kinds of messed up
<whitequark>
yeah it's unfortunate how it was moved twice
<falteckz>
nmigen.sim is here to stay?
<whitequark>
yes
<falteckz>
Cool!
<whitequark>
i'm confident that the new simulator design i came up with is a good one
<falteckz>
Does much need to be changed?
<falteckz>
LUNA follows nMigen Github so it's broken, wondering what I need to change to get it going
<whitequark>
so far (i.e. going by what was pushed to master), all changes except for moving the module are completely internal
<whitequark>
so you just need to adjust the path
<falteckz>
Thanks!
<falteckz>
I should make a USB tester, the amount of time I waste on USB cables with broken data lines -.-"
<falteckz>
Anyone know if there are some "open" USB Vendor/Product IDs that identify as particular device classes?
<falteckz>
Windows in all its wisdom, just drops a device if it isn't recognized vid/pid pair
<whitequark>
i'm pretty sure that's not what windows does
<whitequark>
as in i've personally developed several USB devices and tested them on Windows...
<whitequark>
never wrote an inf file in my life
peepsalot has quit [Read error: Connection reset by peer]
samlittlewood has quit [Read error: Connection reset by peer]
samlittlewood has joined #nmigen
happycube has quit [Ping timeout: 264 seconds]
happycube has joined #nmigen
sorear has quit [Ping timeout: 244 seconds]
tannewt has quit [Ping timeout: 244 seconds]
key2 has quit [Ping timeout: 244 seconds]
ianloic_ has quit [Ping timeout: 244 seconds]
Cynthia has quit [Read error: Connection reset by peer]
yuriks has quit [Ping timeout: 244 seconds]
Cynthia has joined #nmigen
sorear has joined #nmigen
tannewt has joined #nmigen
ianloic_ has joined #nmigen
yuriks has joined #nmigen
<DaKnig>
Yehowshua it does not default to 0; it defaults to the reset value. you can see that in the manual or in help(Signal) iirc
<DaKnig>
if all assignments are inactive (this (and all other) If does not currently do anything) it defaults to the reset value which defaults to 0
<DaKnig>
falteckz: the USB cable rule- there's only ever one working USB cable, no matter how many you have :)
<DaKnig>
there's also "the USB superposition principle" - no matter how you hold the cable, it would take at least 3 tries of putting it in, realizing it doesnt fit, rotating and trying again , till it finally gets in; the theory is simple- until observed, the male USB A connector is in a superposition of both "up" and "down" states. when you try the first time, it decides that this is the one that would
<DaKnig>
fit, after you try it. so you rotate it a second time, then it is flipped.
<DaKnig>
ok I'll stop with my USB science.
key2 has joined #nmigen
<falteckz>
@DaKnig Can confirm, that seems to be true. Only one good cable.
<falteckz>
@whitequark, You might just be right and it seems the issue is with the gateware. Thanks for mentioning not writing an INF file. I shall stop trying to write one that works.
<whitequark>
I have some demos for the FX2 that you can run yourself and see that it works
<whitequark>
if you have FX2
<falteckz>
I appreciate it, but I only have an TinyFPGA BX
<falteckz>
How ambitious is it these days to build a custom SOC on an FPGA and expect to be able to use it like a Microcontroller, with the obvious added benefits of dedicated gateware?
<falteckz>
I'm thinking I'd really _like_ to use an FPGA for my next project, a HID Hardware Controller. But also, Cortex-M4 is easy
<whitequark>
I think it really mostly depends on your comfort level with various tech
<whitequark>
there's no single answer that fits everyone
levi has quit [Ping timeout: 240 seconds]
FL4SHK has quit [Ping timeout: 240 seconds]
key2 has quit [Ping timeout: 240 seconds]
key2 has joined #nmigen
levi has joined #nmigen
FL4SHK has joined #nmigen
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
key2 has quit [Read error: Connection reset by peer]
key2 has joined #nmigen
happycube has quit [Ping timeout: 256 seconds]
happycube has joined #nmigen
happycube has quit [Ping timeout: 240 seconds]
key2 has quit [Read error: Connection reset by peer]
levi has quit [Read error: Connection reset by peer]
levi has joined #nmigen
key2 has joined #nmigen
happycube has joined #nmigen
levi has quit [Quit: Connection closed for inactivity]
rattboi has quit [Ping timeout: 260 seconds]
cr1901_modern has quit [Quit: Leaving.]
rattboi has joined #nmigen
cr1901_modern has joined #nmigen
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
Asu has quit [Ping timeout: 240 seconds]
happycube has quit [Ping timeout: 256 seconds]
happycube has joined #nmigen
lkcl__ has quit [Ping timeout: 265 seconds]
Asu has joined #nmigen
Asu has quit [Quit: Konversation terminated!]
Asu has joined #nmigen
<cr1901_modern>
whitequark: when you say "If all assignments to some signal bits are inactive, their final values are determined by the signal’s domain, combinatorial or synchronous." in https://nmigen.info/nmigen/latest/lang.html#lang-assignorder >>
<cr1901_modern>
is that a shorthand for saying "in combinatorial domain, the signal takes on the reset value (to avoid a latch), and in synchronous domain the signal's value is unmodified"?
lkcl has joined #nmigen
<whitequark>
yes
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
emeb has joined #nmigen
cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Ping timeout: 240 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
Asu has quit [Ping timeout: 240 seconds]
Asu has joined #nmigen
emeb has quit [Ping timeout: 240 seconds]
chipmuenk has joined #nmigen
emeb has joined #nmigen
Yehowshua has joined #nmigen
<Yehowshua>
DaKnig, you're quite right! But only for combinational assignments in conditionals
<Yehowshua>
falteckz, you're having USB troubles with the TinyFPGABx?
<Yehowshua>
What kind of issues, I've done a few things with Luna on it
Yehowshua has quit [Remote host closed the connection]
emeb_mac has joined #nmigen
<TiltMeSenpai>
whitequark: hello, this is actually the nmigen channel, where I intended to send that message re. Memory and block rams
<whitequark>
yea
<TiltMeSenpai>
are there any guidelines as to when Memory should equal a block ram? Context is I'm working on an intel 8080 implementation for fun, and I noticed that the ~8k of ROM did not derive a block ram
<TiltMeSenpai>
I don't have an example yet, bc there's other things in my implementation that are broken
<whitequark>
TiltMeSenpai: async read port?
<TiltMeSenpai>
ah, I'm reading from sync
<TiltMeSenpai>
that'll do it, thanks
chipmuenk has quit [Quit: chipmuenk]
jeanthom has joined #nmigen
jeanthom has quit [Remote host closed the connection]
jeanthom has joined #nmigen
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
DaKnig has quit [Ping timeout: 264 seconds]
DaKnig has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
DaKnig has quit [Ping timeout: 264 seconds]
DaKnig has joined #nmigen
DaKnig has quit [Changing host]
DaKnig has joined #nmigen
<awygle>
whitequark: ping 2, the sequel to ping
<whitequark>
awygle: pong
<awygle>
so i was looking at the async fifo level thing
<awygle>
and i quickly got philosophical (what *is* an async fifo?)
<awygle>
the problem we currently have is that we're using the level of the unbuffered fifo for the level of the buffered one, but on the write side this doesn't work, because the buffer part reads out a value from the unbuffered fifo to hold it in the buffer
<awygle>
we can solve this problem by holding an extra bit of state on the write side, maybe
<awygle>
but then i started thinking about what level we actually want to know on the write side
<whitequark>
oh
<awygle>
and whether we wanted a non-FWFT async fifo buffered
<awygle>
and got in my head about it
<whitequark>
let me try an answer i thought on for about a millisecond: on the write side i want to know how much space is left
<whitequark>
if i care about the level at al
<whitequark>
*all
<awygle>
and the "capacity" of 1025 (or 513 or whatever) plus the level gives you that
<awygle>
assuming we pick an appropriate level?
<DaKnig>
what types does `init` in `Memory` accept?
<DaKnig>
any iterable?
<DaKnig>
I was thinking about using PIL to load an image into a ROM
<awygle>
(rephrasing the above: we're happy with the capacity of a buffered async fifo being POT+1 from a user perspective?)
<DaKnig>
it exposes an iterable (and index-able) thing that holds integers
<whitequark>
awygle: oh, yeah, that's how we already deal with SyncFIFOBuffered
<whitequark>
this has actually caused some consternation for me back in the day
<whitequark>
because there's an inherent tension between having exactly the depth you asked and being able to fit in BRAMs nicely / be POT
<awygle>
exactly, i figured you'd litigated this before
<whitequark>
this is how we ended up with AsyncFIFO(exact_depth=)
<whitequark>
iirc, oMigen... simply lied to you about the depth or the level or something
<whitequark>
you can probably look it up if you want. it struck me as particularly uncivil
<DaKnig>
also another question- I can use Memory as a "matrix of bits", right?
<whitequark>
DaKnig: yes, any iterable
<awygle>
i also wanted to ask about the tension of "asyncfifo doesn't support non-pot depths" and "exact_depth exists" (both of which are claimed in the docs)
<whitequark>
if you pass exact_depth=True then you have to add 1 yourself
<whitequark>
presumably if you care about depth *that much* you can just afford the mental overhead
<whitequark>
like maybe you have some precise scheduling code or w/e
<whitequark>
i'm sure if you have that you'll manage tracking an off-by-1
<DaKnig>
what I mean with "matrix of bits" is - `Memory(width=w, depth=d)[2][3]` for example
<awygle>
what if you pass exact_depth=13 tho?
<whitequark>
it doesn't work!
<whitequark>
just like if you passed exact_depth=512 to AsyncFIFOBuffered
<awygle>
ahhh yeah ok i see
<whitequark>
in the very hypothetical situation where someone cares about this case, they can implement this without breaking the interface or any of the consumers
<whitequark>
in the meantime i'm 100% happy with the error
<awygle>
that's a bit counterintuitive but also probably better than the alternative, and at least you can't end up in a broken-ass state without knowing about it
<whitequark>
exactly
<whitequark>
most people won't use exact_depth=True because they don't care
<whitequark>
that's the happy path i tried to preserve while also not having inconsistent properties on the object
<awygle>
and today all exact_depth does is like... tell you if you got the math wrong when you were calculating your required depth, but eventually non-pot exact_depth might work and nothing will break
<whitequark>
i'm not actually sure how the CDC works out with that
<whitequark>
but people probably did figure out a way to make non-POT AsyncFIFO by this point
<awygle>
it's definitely more complicated but it seems like there must be _a_ solution
<awygle>
anyway. so if the AsyncFIFO is empty and the buffer has a value, we want w_level == 1
<awygle>
just treat the buffer like an additional storage element
<whitequark>
correct
<awygle>
mk. it's not immediately obvious to me the best way to make that work but i'll figure it out.
<whitequark>
i also do not insist on having this feature, either immediately or at all
<whitequark>
you seemed to have an easy solution so it was easy for me to lgtm it
<awygle>
yeah fair but i put it in and it's broken, so i want to fix it
<whitequark>
right, just saying that you shouldn't feel obliged to fix it as opposed to just reverting it
<awygle>
copy
<whitequark>
i have absolutely no opinion beyond "wow neat i didn't realize you can just do that"
<whitequark>
which, well, i guess it's not quite as easy? :D
<awygle>
secondly, i get why AsyncFIFO always has fwft, but it would be pretty easy to make fwft=False work on AsyncFIFOBuffered, is that desireable at all?
<whitequark>
... so about that
<awygle>
(dunno why it would be....)
<whitequark>
that fwft= argument is some of the worst oMigen holdovers and something i personally regret
cr1901_modern has quit [Ping timeout: 256 seconds]
<whitequark>
you see, the problem is that the API of the FIFO changes radically based on the constructor argument. and not just the API but rather an implicit runtime contract
<awygle>
yup
<whitequark>
the only reason this isn't a massive footgun is because no one wants non-FWFT FIFOs
<awygle>
yup
<whitequark>
we should like... get rid of that for good
<whitequark>
it bothers me a lot
<awygle>
a better design would maybe be SyncFIFONonFWFT or whatever
<awygle>
if we desperately needed them
<whitequark>
yeah
<whitequark>
maybe we can take a look at that while designing streams?
<awygle>
sure
<whitequark>
it's somewhat related
<awygle>
i was gonna suggest slapping a deprecation warning on fwft=False for 0.3
<awygle>
but that's probably premature
<whitequark>
i think it is
<awygle>
xaz
<awygle>
.... thank you for your contribution, cat
<whitequark>
lol
<awygle>
ok. today i will fix w_level, file an issue for discussion of fwft, and also write all the rfcs i said i'd write. in some order, probably not that one
<awygle>
thanks wq
<whitequark>
sounds great! it's also fine if it takes more than today
<awygle>
how are things?
<whitequark>
working on cxxsim, turns out i have to extend cxxrtl a bit
<whitequark>
actually
<awygle>
yeah i made the valuecastable changes yesterday which seemed like the thing you cared about most
<whitequark>
if you have some free time, let me grab uh, some coffee, because i could use discussing it with someone
<awygle>
sure, happy to
<whitequark>
yeah, valuecastable is something that has a lot of demand from end users
<FL4SHK>
so my plans have kind of evolved a bit...
<whitequark>
i think like three people have asked in the last several weeks
<FL4SHK>
wait, I be interrupting something
<whitequark>
FL4SHK: go ahead
<FL4SHK>
I want to develop the hardware and some of the software (GCC, Binutils) for my next computer
<FL4SHK>
going to buy an expensive FPGA dev board
<awygle>
oh on the VC subject - did you want me to work towards the other two parts, deprecating UserValue and migrating the internal stuff to ValueCastable, before 0.3 as well?
<whitequark>
awygle: that would be great
<awygle>
mk, wilco
<whitequark>
UserValue is clearly fundamentally broken and the earlier we get rid of it the better
<FL4SHK>
I am currently in the process of switching to Gentoo on my existing machine because I want to run a source-based distro on the FPGA computer
<awygle>
yup
<whitequark>
plus I'm poking at cxxsim which is kinda late too
<FL4SHK>
going to develop the hardware in nMigen
<FL4SHK>
should end up with some hardware modules I can contribute
<FL4SHK>
Like, probably going to be making a DDR3 or something controller
<whitequark>
cool!
<_whitenotifier-3>
[nmigen] awygle commented on pull request #369: [WIP] AsyncFIFO: disable read from dual-port Memory when FIFO empty - https://git.io/JUthc
<_whitenotifier-3>
[nmigen] awygle closed pull request #369: [WIP] AsyncFIFO: disable read from dual-port Memory when FIFO empty - https://git.io/JfL76
<whitequark>
i think -stdio is not quite at the point where that would work, but it's a good impetus to get it there
<FL4SHK>
since this is intended to be a daily driver it'll probably involve also making an HDMI driver, maybe?
<FL4SHK>
will at least involve a VGA driver (which I've written already)
<awygle>
mrr my poor DDR2 controller has languished for like two weeks. stupid capitalism.
<whitequark>
tbh i think any really serious peripheral upstreaming effort must start with streams
<awygle>
do memory controllers really need streams?
<awygle>
they may be the only thing that doesn't lol
<whitequark>
yeah, was more thinking about VGA & HDMI
<FL4SHK>
If I had a web browser available right now maybe I'd take a peek at that
<DaKnig>
how'd you do this on the lang level?
<whitequark>
it's stdlib stuff
<awygle>
(OT: i love how if you close a PR without it being merged GitHub is like "so yknow, you could delete your branch... or your fork.... or your github account... just saying"
<whitequark>
the lang changes required are minor to nonexistent (once ValueCastable is in, the new Record interface doesn't actually touch the language anymore)
<DaKnig>
what benefits does that provide for HDMI/VGA?
<whitequark>
minor ones
<whitequark>
there's nothing stopping you from building a perfectly functional HDMI peripheral right now
<whitequark>
it's mostly that i aim higher than just "perfectly functional"
<awygle>
that should be your twitter bio lol. bonus points if you drop "ly functional"
<DaKnig>
can you give an example though, how high this would be? like , "here's a bus, put x,y there and after a clock you receive a pixel" or something like that?
<whitequark>
awygle: ouch
<awygle>
DaKnig: you'd have some kind of DMA core that turns a framebuffer in memory into a stream going into the HDMI peripheral, which would just turn pixels into HDMI and not have to know about framebuffers
<whitequark>
^
<awygle>
whitequark: sorry, bad joke
<whitequark>
awygle: it's a good callout though :p
<awygle>
purely from a place of respect i assure you :p
<whitequark>
oh i understand
<whitequark>
DaKnig: so you've seen how convenient it is to glue things together with unix pipes, right?
<DaKnig>
awygle: so you would just have to provide the Memory that is the frame buffer? or also the DMA core?
<DaKnig>
I am confused/
<whitequark>
streams are kind of the same idea fundamentally
<DaKnig>
awit there are HDLK langs that have this already?
<yuriks>
DaKnig: it's just an interface abstraction to let the HDMI module receive pixel data without caring where it's coming from, and similarly let a DMA engine stream data somewhere no matter where it's going. And do you have an interoperable interface to do that kind of stuff without needing to have adapters to hook up two modules together
<whitequark>
yup
Asu has quit [Quit: Konversation terminated!]
<DaKnig>
ok sounds good.
<DaKnig>
Im sold. the moment you said "you dont have to make your own HDMI adapter"...
<awygle>
^ that's exactly why i'm so psyched to work on nmigen-stdio and friend
<awygle>
s
<DaKnig>
look I wasted a few months trying to get HDMI right; I'll admit Im not the sharpest, and I did not spend 100% of my time on that... but in the end I just bought a VGA pmod.
<awygle>
tbh i mostly want to see if i will ever be able to get over my NIH syndrome for HDL...
<DaKnig>
so a stream is like a regular port, that expects input in the form of a record/signal that is known to use a specific protocol? did I get that right?
<whitequark>
that's the basic idea yea
<awygle>
we haven't really designed them yet, but yeah, that plus some flow control stuff
<whitequark>
the details will rely on the new recods
<whitequark>
which is why we really need those too :p
<awygle>
litex has their own version right now, you can take a look at that if you want to look into it more
<DaKnig>
ooh. what do the new records offer?
<whitequark>
they don't exist yet
<awygle>
the idea is to split apart "packed struct" and "interface" as concepts (they're currently very muddled in Record)
<DaKnig>
so `connect` is a way to connect two interfaces together?
<DaKnig>
I see why that does not fit together with "packed structs"
<whitequark>
yeah
<whitequark>
so
<whitequark>
*so "packed structs" were also inheriting from Value/UserValue which brought its own set of problems
<DaKnig>
but that would require a direction for each member of the interface
<whitequark>
sorta
<DaKnig>
and ... nmigen does not track directions :)
<DaKnig>
or does it
<awygle>
it doesn't. this is all interconnected lol
<whitequark>
it would be on the level of Interface alone
<whitequark>
but some day nmigen will
<whitequark>
and we'll hook these things up to each other
Yehowshua has joined #nmigen
<Yehowshua>
yooo - I'm liking the sound of the stream stuff
<Yehowshua>
will it support crossing clock domains?
<Yehowshua>
Like from bus to HDMI?
<DaKnig>
that sounds like a bad idea.
<awygle>
again, not designed yet, but probably we'd have a stream adapter that had one side in one clock domain and another in another, powered by AsyncFIFO under the hood?
<Yehowshua>
DaKnig, memory is often in separate domain
<DaKnig>
an HDMI converter always receives data in one clock domain and outputs on another
<DaKnig>
crossing clock domains with "streams" does not sound like a good idea to me
<DaKnig>
if its done internally, that's another story.
<whitequark>
awygle: yep
<Yehowshua>
I'm kinda wondering about elastic buffer vs AFIFO
<awygle>
which is basically "Same thing, different implication"
<Yehowshua>
Oh haha
<Yehowshua>
thx
<awygle>
:)
<whitequark>
awygle: lmk if/when you have time for some cxxrtl related brain picking
<whitequark>
actually, wait
<whitequark>
do you do c++ at all?
<awygle>
i do
<whitequark>
ok cool
<awygle>
not on your level, probably, but it was actually my first programming language
<whitequark>
then you'll feel as miserable about this as i am
<whitequark>
oh, i started with c++ too
<whitequark>
granted, it was c++ builder and i *mostly* used vcl at first
<FL4SHK>
It was my first programming language
<whitequark>
can't say i learned any useful amount of the language
<awygle>
i used djgpp
<FL4SHK>
it is still my most used language
<whitequark>
my condolences
<FL4SHK>
actually it is also my favorite
<Yehowshua>
lol
<awygle>
whitequark: anyway i'm basically around all day today (so for the next ~9 hours)
<DaKnig>
do you ~ab~use templates a lot in cxxsim?
<whitequark>
ah, great. i'm going to get more awake than i am right now and ping you
<awygle>
:thumbsup:
<whitequark>
DaKnig: no. in fact cxxsim, counterintuitively, never directly uses c++
<FL4SHK>
What does it do then?
<awygle>
... i also want coffee. is 2pm too late for coffee?
<whitequark>
(cxxsim is a python module, which cannot easily use c++, so it uses a c api that is exported by the simulator core)
<whitequark>
the simulator core is called "cxxrtl" and ... whether what i am doing is "abuse" is up to you
<FL4SHK>
awygle: no, any time is fine!
<DaKnig>
ah. so it just generates C++ code?
<FL4SHK>
I might want to go get some from Panera
<whitequark>
nope, well, not directly
<whitequark>
cxxsim asks yosys to generate c++ code, through the cxxrtl backend
<Yehowshua>
reading backlog, awygle what's this ping/pong thing?
<whitequark>
then it builds that code as a shared library with a c api, loads it, and starts simulating
<whitequark>
Yehowshua: so you know /usr/bin/ping?
<whitequark>
same idea
<awygle>
"ping" -> "are you online and available for a synchronous discussion?"
<awygle>
"pong" -> "yes, i am"
<awygle>
"ping" comes from /usr/bin/ping, "pong" from the game ping-pong, which is etymologically very interesting lol
<Yehowshua>
whitequark, yehowshuaimmanuel@Yehowshuas-MBP:~$pong-bash: pong: command not found
<Yehowshua>
only halfway works
<awygle>
you need a response to "ping", "pong" seems natural if you're familiar with ping-pong
<DaKnig>
well as long as it's C I guess I would be able to at least look at the source code :)
<awygle>
we could use "marco" and "polo" i guess :p
<Yehowshua>
I like ping-pong, its cute
<DaKnig>
just can't stand C++ code; Im one of those "C purists"
<awygle>
some people use SYN and ACK but those people i mostly find insufferable
<whitequark>
awygle: i'm pretty sure some protocols actually call the response "PONG"
<Yehowshua>
My friend used to ACK every text message
<whitequark>
such as ... IRC
<miek>
they dropped /usr/bin/pong after users got tired of running it manually
<yuriks>
awygle: I just had coffee and it's 2pm here too so ;w;b
<awygle>
i'm gonna start using CQ
<whitequark>
lol
<whitequark>
DaKnig: there's no actual C code involved
<whitequark>
cxxrtl *and* cxxrtl's C interface export, well, a C ABI
chipmuenk has joined #nmigen
<whitequark>
but the actual guts are in C++
<awygle>
or QRL i guess?
<yuriks>
so PING/PONG is fine but SYN/ACK is insufferable?
* awygle
is a very bad ham
<awygle>
yuriks: specifically SYN, for some reason? it's not universal, just a correlation
<yuriks>
I kinda get it, though
<Yehowshua>
You're a ham - callsign?
<awygle>
KJ6ZNK
<awygle>
... i maybe shouldn't have answered that, for opsec reasons, but oh well. i use my own name after all.
chipmuenk1 has joined #nmigen
<whitequark>
awygle: yeah your callsign is 4th link in ddg
<Yehowshua>
no worries
<whitequark>
kind of a lost cause
<awygle>
yup
<whitequark>
hell, ddg was so kind as to give me your zipcode in big letters
<awygle>
it's an old address anyway lol
<whitequark>
:s
<Yehowshua>
I'm not a ham, been procrastinating on registering
<awygle>
i got mine so i could run comms for a high-altitude balloon test
<Yehowshua>
Also, spent all my gadget money on cameras instead of antennas...
chipmuenk1 has quit [Client Quit]
<awygle>
in like, 2012 i think?
chipmuenk has quit [Ping timeout: 244 seconds]
<DaKnig>
for a second I thought that was a radio id of somebody.
<Yehowshua>
Well, FPGAs and hams go hand in hand
<DaKnig>
then I remembered that the year 2000 has gone by a long time ago.
<Yehowshua>
Ever count how many FPGAs you can find at a hamfest?
Yehowshua has quit [Remote host closed the connection]
<DaKnig>
so; I have something like this: `font_rom = Memory(width = 128, depth = 128, init=font_integers)` ; I was planning to use that like so: `font_rom[x][y]` where x,y are Values; should work right?
<DaKnig>
well- [y][x], but this does not matter that much.
<whitequark>
nope
<whitequark>
for several reasons
<whitequark>
first, you cannot index memory with [] in synthesis, that only works in simulation
<DaKnig>
ah. right.
<whitequark>
you'd need to add a read_port() and then do a word_select()
<DaKnig>
I'd use a read port.
<whitequark>
right
<DaKnig>
why word_select? I want a single bit.
<whitequark>
oh
<whitequark>
okay, word_select still works for that, though it's identical to bit_select in that scenario
<DaKnig>
dont try to make sense of it. this does not make sense. as long as it works though...
chipmuenk has joined #nmigen
<whitequark>
if you use a read port and do bit_select() or whatever it will synthesize
<whitequark>
which FPGA is that?
<DaKnig>
series 7, why does that matter?
<DaKnig>
why are you suggesting bit_select btw? why not [] - iirc they are the same...
<DaKnig>
I want the tools , if possible, to either infer BRAM or map it to some combinational logic. I really dont care. also, at the clock rate Im running it... this does not matter.
<whitequark>
>>> x = Signal(8); y = Signal(3); x[y]
<yuriks>
if you're selecting a single bit from the output, dunno about the width=128 either
<whitequark>
TypeError: Cannot index value with (sig y)
<whitequark>
bit_select/word_select exist specifically for the case where the offset is a Value rather than an integer
<DaKnig>
... but why
<DaKnig>
why did you decide not to use [] syntax with Values?
<yuriks>
they have very different implications synthesis-wise
<DaKnig>
you can overload [] any way yo want, no?
<whitequark>
because you provide the lower and the higher bound to [:], it is not possible, in general, to determine the size of the resulting value
<whitequark>
since you can just pass arbitrary x and y into v[x:y]
<whitequark>
nmigen requires the sizes of every Value to be known at almost every point (with few exceptions that aren't relevant here)
<DaKnig>
does regular indexing in python internally translate into slicing?
<whitequark>
oh, are you saying that, eveh though [x:y] can't work in general, [x] could have still worked?
<DaKnig>
yes
<DaKnig>
is that the same mechanism in python?
<DaKnig>
if so, I was not aware.
<whitequark>
yeah
<whitequark>
it's the same method, __getitem__
<DaKnig>
in my head those are very different constructs.
<DaKnig>
one of em uses the : token
<DaKnig>
which is not that common in python
<DaKnig>
well; ok. design choices I guess.
<whitequark>
so, purely from technical point of view, i could have done what you want
<whitequark>
it'd just be inconsistent and surprising because, yeah, [x] and [x:y] are the same conceptual operation
<whitequark>
[x:y:z] as well
lkcl_ has joined #nmigen
<DaKnig>
Im more used to operator overloads in C++; very much different from python in many things. on every level.
<whitequark>
indeed
<whitequark>
if you squint really hard you could call __getitem__ overloaded
<whitequark>
since it does dispatch on the argument type
<DaKnig>
sometimes it feels like you cant have both elegance and consistency.
<whitequark>
so, the : in x:y thing? that's actually a syntax for making a slice() object
<DaKnig>
yeah. makes total sense.
<whitequark>
>>> class c:
<whitequark>
>>> c()[1:2]
<whitequark>
... def __getitem__(self, x): return x
<whitequark>
slice(1, 2, None)
<whitequark>
speaking of which
<whitequark>
i have *absolutely no idea* why slice() and range() are both a thing
<yuriks>
you can't use the syntax in arbitrary places though, right? (unlike rust)
<whitequark>
nope
<whitequark>
it's pretty much just special-cased to that one place
<DaKnig>
wait is `slice` a thing
<DaKnig>
wot
<yuriks>
(where slice and range are also the same thing, too :D)
<whitequark>
yes! try it
<DaKnig>
shouldnt that basically be a tuple
<yuriks>
whitequark: I think range only works with integers?
<whitequark>
yuriks: oooooh
lkcl has quit [Ping timeout: 256 seconds]
<whitequark>
it also has slice.indices()
<DaKnig>
python looks fancy and modern until you dig too deep.
<yuriks>
python is old af
<yuriks>
I'm surprised at how non-crusty it is tbh
<DaKnig>
every time I come here and learn a new thing about python, Im horrified.