<pepijndevos>
What is the minimum wage of a peripheral?
proteus-guy has joined #nmigen
<_whitenotifier-3>
[nmigen] whitequark commented on pull request #472: Add r_level and w_level to all FIFOs - https://git.io/JJ7aq
<_whitenotifier-3>
[nmigen] awygle synchronize pull request #472: Add r_level and w_level to all FIFOs - https://git.io/JJ7n2
<_whitenotifier-3>
[nmigen] awygle synchronize pull request #472: Add r_level and w_level to all FIFOs - https://git.io/JJ7n2
<_whitenotifier-3>
[nmigen] awygle commented on pull request #472: Add r_level and w_level to all FIFOs - https://git.io/JJ7rs
* awygle
loves git with all his heart
<awygle>
`git push remote branch` should push your currently checked out commit to remote as branch, not randomly grab your local branch named "branch" (which isn't checked out) and push it
<_whitenotifier-3>
[nmigen] whitequark commented on pull request #472: Add r_level and w_level to all FIFOs - https://git.io/JJ7rV
<whitequark>
the tragic thing is that i have the exact kind of brain damage that makes git easy to understand for me
<whitequark>
i mean, it still drives me mad sometimes, but i find it positive overall, so i'm quite certain about the brain damage part
<whitequark>
i remember looking at SVN in school and thinking "if this is what version control is like, i will never use it" (and then i discovered git)
<_whitenotifier-3>
[nmigen] awygle commented on pull request #472: Add r_level and w_level to all FIFOs - https://git.io/JJ7rP
<whitequark>
seems to be the exact opposite of the usual experience
<awygle>
in my mind git is (at least) two things
<_whitenotifier-3>
[nmigen] whitequark commented on pull request #472: Add r_level and w_level to all FIFOs - https://git.io/JJ7rH
<awygle>
the like... general model of verison control, the data structures, etc
<awygle>
and the command line tool
<awygle>
i quite like the former
<awygle>
and i detest the latter
<awygle>
someday i'll bother to try like, pijul or hg or something, but for now i just uh... get stuff wrong occasionally
<awygle>
also thank you for commenting on that PR so that i stopped obsessively planning to build an additional wall in my apartment at 1am
<whitequark>
uhm
<whitequark>
why
<awygle>
because it is a bad shape
<awygle>
i have a giant useless undifferentiated room, instead of like, "a living room" and "a studio"
<pepijndevos>
my day barely started and already confusing things happening
<whitequark>
oic
<awygle>
and i just resigned my lease for another 18 mo
<proteus-guy>
awygle, you mean re-signed I presume? Otherwise your intent is to be homeless for 18 months. ;-)
<awygle>
and as astonishing as it seems, "frame and drywall a new temporary wall" is somehow the cheapest way to solve this problem
<awygle>
(about half the price of "build a divider out of PVC and cloth" and about a third the price of "buy one of the products nominally for this exact use case")
<whitequark>
huh
<whitequark>
are you going to like... fix it to the house structure?
<awygle>
na. compression fit it between ceiling and floor with that foam stuff. something seal
<awygle>
sill seal
<whitequark>
ohh
<awygle>
i _probably_ won't actually do this.... but it does make sense on several axes, and i do have the required skills. it would just probably piss off the apartment people and do bad things to airflow (which already kinda sucks here)
<pepijndevos>
ahhhhh I was actually installing m-labs nmigen dog
<pepijndevos>
*dohh
<_whitenotifier-3>
[nmigen-boards] GuzTech commented on pull request #103: Add GPDI pins to ulx3s.py - https://git.io/JJ7oU
<pepijndevos>
uh... which AST classes are supposed to have a signed attribute? Not Operator apparently. I can use share, just wondering if this in intentional.
<pepijndevos>
*shape
jeanthom has joined #nmigen
proteus-guy has quit [Ping timeout: 264 seconds]
<pepijndevos>
uhoh... I might have some weird... bug... or not...
<whitequark>
pepijndevos: only the ones which have it themselves
<whitequark>
Const, Signal
<pepijndevos>
right, if you want to deal with any value you have to use shape().signed
<whitequark>
yep
<d1b2>
<edbordin> In hindsight I got used to svn because I didn't know any better. Maybe git has infected my mind the same way. The CLI is definitely terrible though imo
<pepijndevos>
commenting out those lines will break the test_abs test
<pepijndevos>
in that case cast will do some useless slicing and padding, which breaks the test.
<lkcl>
mmm... brain-melted, to be honest :)
<pepijndevos>
I'll try to make a minimal example
<lkcl>
the source code of class Cat simply stores the list it is passed. there's nothing saying it should be signed, so i think it's safe to assume that it'll be "unsigned"
<lkcl>
if you accumulate an AST that's thousands of objects and pass copies of it around (i've seen people do for-loops like that), then thousands of copies end up being given to yosys
<lkcl>
so this is a good example
<lkcl>
print(abs(sig2), resolve(abs(sig2)))
<lkcl>
(m (>= (s (cat (const 0'd0) (const 9'sd-153))) (const 1'd0)) (s (cat (const 0'd0) (const 9'sd-153))) (- (s (cat (const 0'd0) (const 9'sd-153))))) -359
<lkcl>
which is like, whoaaaa.... :)
<lkcl>
can you read that? i can't! :)
<pepijndevos>
sure, but what can you do? Most of that is just abs()
<pepijndevos>
and... it's still wrong
<pepijndevos>
you don't even need the empty const btw
<lkcl>
put the Cat()'d value into another signal prior to running abs
<pepijndevos>
Cat(sig).as_signed() is enough to break it
<lkcl>
i modified resolve() so that it can be used to set a value into the target Signal
<lkcl>
where abs(some Signal) is done, the answer is correct
<lkcl>
however Cat(exact_same_signal), yes the answer goes haywire
<lkcl>
the "solution" as i suggested is to copy the Cat()ed thing into a target Signal
<pepijndevos>
but that needs an eq that needs to be assigned to some comb/sync thing, right?
<lkcl>
and only call abs() on that
<pepijndevos>
Not exactly ergonomic in this case
<lkcl>
indeed it does
<lkcl>
can i recommend looking at a yosys graphviz diagram (show {insertmodule}) on the output from any example that you're doing?
<lkcl>
generate a .il file and then examine it
<pepijndevos>
sure, I can imagine what that will look like
<lkcl>
even on the simplest examples, the graphviz - the use of ASTs that compound like this - should, how can i put it, "freak you out" :)
<lkcl>
if yosys was capable of optimising the (repeated) expressions away correctly, i would not mention it
<pepijndevos>
uh... wat...
<lkcl>
however in complex cases it simply cannot cope
<pepijndevos>
okay that sucks.
<pepijndevos>
I think the only case where it'll repeat statements is in the mux, but yea... not great
<lkcl>
there exists commands _to_ optimise away repeated expressions
<lkcl>
daveshah and others more familiar with yosys know what those are, and they typically get called in all synth commands
<daveshah>
opt_merge; opt_clean would be a starting point
<daveshah>
opt -full for a more aggressive optimisatio
<daveshah>
*n
<lkcl>
however you need to bear in mind that even if it's successful, the approach in the code you're designing places a huge processing burden on yosys... and you have to trust that it will be successful
<lkcl>
thx daveshah
<pepijndevos>
right, well... I'll try to minimize my AST a bit later if it becomes a problem.
<lkcl>
imagine someone setting up an array of 1,000 objects, in a python for-loop, that do "abs" followed by some more math followed by another Mux followed by...
<lkcl>
what's the code designed to do, btw? :)
<pepijndevos>
well, I don't see how I'd implement fixed point math without at least generating some AST... it's up to the user to not go crazy haha (i.e. me)
<lkcl>
it's a FP system where you can specify arbitrary precision?
<lkcl>
(sounds pretty useful)
<pepijndevos>
yea, it builds a fixed point type that does the book keeping and casting with arithmic operations.
<lkcl>
nice.
<pepijndevos>
so if you add two different types obviously it will need some padding and slicing to make it work
<pepijndevos>
Best I can do is not do any *useless* padding and slicing.
<lkcl>
i did an ieee754fp library in nmigen, parameterised to do FP16, FP32 and FP64
<lkcl>
yeah been thinking about how to do transparent (dynamic) SIMD, which needs something similar
<lkcl>
we have a class that can do dynamic partitioning of integer operations
<lkcl>
however, using it to do partitioned IEEE754 is doing my head in
<lkcl>
yes, it comes down to when you want to shift / slice something that is now 16 bits wide (or 11 bit in the case of the FP16 mantissa) and the next cycle you're processing something 32-bit wide (23-bit mantissa)
<lkcl>
in your case, you're quite lucky, because (i hope!) it's a static analysis
<lkcl>
a "cast" function would be the obvious thing to try to do
<lkcl>
however it'd need calling in each of the __add__, __sub__, __ge__ etc. etc. functions to make it "transparent"
<lkcl>
hmm...
<pepijndevos>
yea, I call cast in each operator
<pepijndevos>
And try weakly to avoid doing the cast.
<lkcl>
the @operator decorator. nice.
<lkcl>
remember to also implement __radd__
<_whitenotifier-3>
[nmigen] pepijndevos opened issue #473: Signed math on Cat gives incorrect results - https://git.io/JJ71R
<lkcl>
etc.
<lkcl>
you miiight not need them... it depends on whether you're expecting people (you :) ) to do things such as add Const() or add straight Signal() to this
<pepijndevos>
lkcl, I don't support adding with ordinary python numbers, so radd is not used
<lkcl>
ok. sensible
<lkcl>
anyway. nice work.
<pepijndevos>
thanks
<lkcl>
are you planning to do a formal correctness proof for it?
<lkcl>
ha, i deduce from this (and your first name) that you are from the netherlands? :)
<pepijndevos>
lkcl, you are correct, but Charcuterie sounds french to me, why Dutch besides my name?
<lkcl>
i lived in den haag for 4 years, i learned that it's become a habit there to post a really nice picture of a meal, to your friends, before eating it
<anuejn>
pepijndevos: nice :)
<jeanthom>
pepijndevos, FHDLTestCase was meant to be an internal class for testing nMigen IIRC
<lkcl>
jeanthom: it turns out to be exactly what is needed - generally and widely - for the purposes of all and any formal correctness proofs. "nmigen internal testing" happens to be a subset of that general purpose need
<lkcl>
we have over 30 formal correctness proof unit tests in libresoc.
<lkcl>
and that's only going to go up.
<jeanthom>
while I agree that we need an easy way to do formal assertions in nMigen, the FHDLTestCase had its quirks that made it too confusing to be used by an end-user
<jeanthom>
like having to do python ./mytest.py instead of python mytest.py and probably other things like that
<lkcl>
jeanthom: we fixed that.
<lkcl>
it was a one-line error.
<jeanthom>
has it been fixed in nmigen or in libresoc code?
<lkcl>
in the duplicated copy that we were forced to put into libresoc's nmutil.
<lkcl>
s/forced/had no option other than/
_whitelogger has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
emeb has joined #nmigen
<_whitenotifier-3>
[nmigen] mglb synchronize pull request #463: Add initial support for Symbiflow toolchain for Xilinx 7-series - https://git.io/JJryz
<_whitenotifier-3>
[nmigen] mglb commented on pull request #463: Add initial support for Symbiflow toolchain for Xilinx 7-series - https://git.io/JJ5UD
hitomi2507 has quit [Quit: Nettalk6 - www.ntalk.de]
<_whitenotifier-3>
[nmigen-boards] GuzTech commented on pull request #104: Add OLED connector to ulx3s.py - https://git.io/JJ5qI
emeb_mac has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
<_whitenotifier-3>
[nmigen-boards] awygle commented on pull request #104: Add OLED connector to ulx3s.py - https://git.io/JJ5m3
<_whitenotifier-3>
[nmigen-boards] awygle commented on pull request #103: Add GPDI pins to ulx3s.py - https://git.io/JJ5mC
<_whitenotifier-3>
[nmigen-boards] GuzTech commented on pull request #103: Add GPDI pins to ulx3s.py - https://git.io/JJ5m1
Yehowshua has joined #nmigen
<Yehowshua>
whitequark, I remember we discussed how to replace records
<_whitenotifier-3>
[nmigen-boards] awygle commented on pull request #103: Add GPDI pins to ulx3s.py - https://git.io/JJ5mM
<Yehowshua>
I'm about to write some new record like code
<Yehowshua>
What do you suggest?
<awygle>
wq is on vacation until monday (i believe, certainly no later than that)
<awygle>
record isn't going anywhere in the short term, and we're not going to have the design of packed structs and interfaces worked out for probably at least a couple of months
<awygle>
i'd say run with record for now, just don't use .connect() or directions if you can avoid it
<d1b2>
<286Tech> @awygle: I'm working on the HMDI connector PR for the ULX3S, but I have a question.
<awygle>
shoot
<Yehowshua>
awygle Thanks!
<d1b2>
<286Tech> I need to explicitly get the _p signals for the data pins, since I'm instantiating ODDR primitives by hand. When each pins or diffpair was it's own resource, I could simply do hdmi_red = platform.request('hdmi_red', 0, dir='-').
<d1b2>
<286Tech> But now all the signals are subsignals, and I don't know how to access or request the _p signals now.
<d1b2>
<286Tech> Is that still possible?
<awygle>
hm. good question. let me look into it for a moment
<awygle>
286Tech: you can pass a dictionary to dir= for resources which have subsignals
<d1b2>
<286Tech> Ok, but I need it for both the clock and data, so then it would be something like this? dir={'clk':'-', 'd':'-'}
<awygle>
yes
<d1b2>
<286Tech> Oof, I get a nextpnr assertion :S
<d1b2>
<286Tech> Let me see what it actually generates.
<d1b2>
<286Tech> Hmm, it generates some buffers for the cec, sda, and scl pins which are not used in my design, but other than that it looks normal.
<awygle>
make sure you're not instantiating an illegal topology with the ODDR primitives, i think the routing in that section is pretty particular
<awygle>
did this work before you collected the resources together?
<d1b2>
<286Tech> Yup
Yehowshua has quit [Ping timeout: 245 seconds]
<d1b2>
<286Tech> There is a get_oddr type function in the platform, but it maps the function parameters in a weird way, so I just do it by hand.
<d1b2>
<286Tech> But it works just fine when I use my own Resource without subsignals.
<d1b2>
<286Tech> I've updated nextpnr so let me try again. Dave fixed something recently (I don't know if it's related to this).
<awygle>
if you can dump the verilog from the working and non-working versions i can try to figure something out
<d1b2>
<286Tech> Funny enough, I get extra warnings about nextpnr not recognizing IO_STANDARD. It should be IO_TYPE, but the platform file has IO_STANDARD for the leds for some reason.
<awygle>
mk, i'm in a meeting right now but i'll take a look over lunch
<d1b2>
<286Tech> Sure, thanks 🙂
<miek>
i don't think you need to deal with grabbing the _p signal yourself, it's handled somewhere down the stack. i just hook up the ODDR output directly to the subsignal
<daveshah>
This should be a nicer error, but the problem is because you are trying to use a pseudo-differential top-bank LVCMOS33D pin as something other than an output, which isn't supported by the hardware
<daveshah>
It's probably the 'eth' channel (which is a dubious name, as afaik actual HDMI ethernet would need more passive components and pins or a PHY) that is causing the problem
<d1b2>
<286Tech> But I do use it as an ouput. I instantiate ODDR primitives by hand.
<d1b2>
<286Tech> Hmm
<d1b2>
<286Tech> Let me check
<daveshah>
You don't for the 'eth' pins at a glance
<daveshah>
The main TMDS pins using an ODDR should be fine, I would say
<d1b2>
<286Tech> Yup, you are right. When I remove the eth pins from the platform, then it works.
<d1b2>
<286Tech> The thing is, is that I don't even use the eth pins.
<daveshah>
nMigen is still adding an inout pin and associated BB
<d1b2>
<286Tech> nMigen probably instantiates something for them I guess.
<awygle>
286Tech what does your Resource definition look like right now?
<awygle>
you might want to make `eth` have `dir='o'` in the Resource if it can only be an output
<d1b2>
<286Tech> Sure, but from what I understand, the GPDI port is just an HDMI connector, with the pins connected to the FPGA. You don't have to use it as an HDMI peripheral.
<awygle>
i think that won't affect the case where you grab it with '-' anyway
<d1b2>
<286Tech> All right.
<awygle>
you could define it as a Connector, i suppose, but if it's got a physical HDMI connector it probably makes more sense to leave it as an HDMI definition
<d1b2>
<286Tech> Yeah, I'll leave it as it is.
<awygle>
you might want to default "d" to 'o' also, since it's also LVCMOS33D and presumably in the top-bank as well
<awygle>
and then confirm that '-' still works as expected
<d1b2>
<286Tech> Yeah, the only reason why it works right now is because I've instantiated the ODDR primitives myself.
<d1b2>
<286Tech> Same for clk too then.
<awygle>
ah, yes
<d1b2>
<286Tech> So that would mean that I cannot use it as an HDMI in then.
<awygle>
missed that somehow
<d1b2>
<286Tech> daveshah: Is there no IDDR like primitive?
<daveshah>
There is
<daveshah>
The problem is not to do with DDR
<daveshah>
The problem is that the top bank doesn't support differential inputs
<d1b2>
<286Tech> Ah ok. So then it's not possible to use it as an HDMI input.
<daveshah>
Nope
<d1b2>
<286Tech> In that case, it should definitely be defined as an output.