<DaKnig>
... I got the precedence wrong.. but that shouldnt matter still
<DaKnig>
no, it solved it! but... uh why
lkcl has joined #nmigen
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #nmigen
cr1901_modern has joined #nmigen
cr1901_modern has quit [Ping timeout: 246 seconds]
cr1901_modern1 has joined #nmigen
cr1901_modern has joined #nmigen
cr1901_modern1 has quit [Ping timeout: 240 seconds]
cr1901_modern has quit [Ping timeout: 240 seconds]
cr1901_modern has joined #nmigen
cr1901_modern has quit [Ping timeout: 260 seconds]
cr1901_modern has joined #nmigen
cr1901_modern has quit [Client Quit]
cr1901_modern has joined #nmigen
cr1901_modern has quit [Ping timeout: 240 seconds]
emeb has joined #nmigen
jeanthom has joined #nmigen
<_whitenotifier-b>
[nmigen-boards] Fatsie opened pull request #101: Added Arty S7 support - https://git.io/JJ1IR
<_whitenotifier-b>
[nmigen-boards] Fatsie commented on pull request #101: Added Arty S7 support - https://git.io/JJ1Ir
jeanthom has quit [Ping timeout: 260 seconds]
<_whitenotifier-b>
[nmigen-boards] Fatsie commented on pull request #101: Added Arty S7 support - https://git.io/JJ1tI
<tpw_rules>
DaKnig: because & has a higher precedence than ==
<DaKnig>
and so what?
<DaKnig>
the question is not why it did not work
cr1901_modern has joined #nmigen
<DaKnig>
its why it says that it is converting something to python bool
<Lofty>
It's because it *is*
<Lofty>
That was phrased badly; it *is* converting nMigen values to booleans
<Lofty>
As tpw_rules says, & has higher precendence than ==
<Lofty>
So, this boils down to `self.vsync == (C(1) & last_vsync) == C(0, 1)`
<Lofty>
Which is evaluated left to right as `(self.vsync == (C(1) & last_vsync)) == C(0, 1)`
<Lofty>
And somewhere within that Python is calling Value.__bool__()
<Lofty>
Which raises the error you see
<Lofty>
I don't know enough about python semantics to know where exactly it is, though
<Lofty>
I hope that helps a little, DaKnig
<tpw_rules>
i suspect it's in the last comparison
<tpw_rules>
actually, maybe C(1) is truthy?
<tpw_rules>
Lofty: did you see my question about versions earlier in scrollback? have any opinion?
<DaKnig>
I mean , Const & Signal is a Value, and doing Value==Signal is still a Value
<DaKnig>
not a bool
<Lofty>
Apparently Python has decided that it is
<Lofty>
Again: the reason you see that is because __bool__() was invoked to contextually convert to a boolean
<DaKnig>
and this is what I asked :)
<DaKnig>
why?
<Lofty>
DaKnig: thinking about it a bit, I remember wq mentioning that Python has `x < y < z` as syntax that obeys its own rules
<Lofty>
And I think "x == y == z" is the same
<Lofty>
For example, "5 == 5 == 5" would evaluate to false if you evaluated it left to right (True != 5)
<Lofty>
But instead it evaluates to true
<Lofty>
I think what Python *might* be doing is `(self.vsync==(C(1) & last_vsync)) and ((C(1) & last_vsync==C(0,1))`
<Lofty>
And at that point it should become clearer why __bool__ is being invoked
<Lofty>
<Lofty> But instead it evaluates to true <-- because Python is doing "5 == 5 and 5 == 5"
<Lofty>
DaKnig: in other words, you stumbled on a separate language item disguised by the whitespace
<Lofty>
tpw_rules: no, and it's not in the web IRC logs that I can find
<tpw_rules>
weird
<tpw_rules>
"so i've been using a somewhat arbitrary commit of nmigen (0e40dc0a2d336945dfe0669207fe160cafff50dc) because i didn't want to deal with things changing. is there anything exciting to get by upgrading? is master good right now? are records good yet?"
<tpw_rules>
was the question i asked
<sorear>
I mean, _whitelogger was not in the channel when you said that
<Lofty>
records are...still deprecated, as far as I know
<tpw_rules>
what should i use instead
<Lofty>
At present it doesn't have a replacement, but there's issue #342
<Lofty>
Essentially Record is trying to do two things
<FL4SHK>
is `PackedStruct` available now?
<FL4SHK>
`PackedStruct` is essentially how I was using `Record`
<FL4SHK>
I used regular Python classes like SV interfaces
<awygle>
it's not, and it won't be for probably a fair while. cxxsim needs to be finished before we can release 0.3 before we can start working on the Record redesign (or, well, putting code into master for it at least)
<awygle>
tpw_rules: records are still bad lol, sorry
<tpw_rules>
so in boneless some tests don't work with latest nmigen because case is a generator function and it's used like sim.add_sync_process(case(self)) but generator objects aren't supported anymore
<tpw_rules>
is sim.add_sync_process(lambda: (yield from case(self))) a satisfactory enough fix
<tpw_rules>
i mean it does work but i don't understand the rest of the code enough to just pass case
<awygle>
seems ok to me, but i don't understand why the generator object support was removed, so, not sure
<awygle>
"go with it til wq gets back from vacation imo"
<tpw_rules>
well she gave me extra special privileges to commit to boneless master and i don't want to commit something gross
<awygle>
ah, fair
<tpw_rules>
but last time i asked about her approval she wasn't doing well and got pretty upset. i hope she feels better when she comes back
<DaKnig>
how do I get generics when compiling to verilog level?
<FL4SHK>
do you want generics to exist in the Verilog side?
<DaKnig>
I have a "compile time constant" thing you can choose (polarity of some signals)
<FL4SHK>
or are you satisfied with that being handled nMigen side?
<DaKnig>
FL4SHK: I dont actually know verilog well enough to answer I think
<DaKnig>
what I mean is that thing that uses #
<DaKnig>
or generic in vhdl
<FL4SHK>
VHDL's generics are quite nice
<FL4SHK>
but nMigen's are better
<DaKnig>
in nMigen I just use a python integer
<DaKnig>
it works well enougj
<FL4SHK>
you can just pass the integer as a Python integer to the module's constructor
<DaKnig>
...I know
<DaKnig>
how do I expose that in verilog
<DaKnig>
?
<FL4SHK>
does `Const` do what you're after?
<DaKnig>
well I guess
<FL4SHK>
I've never needed things to show up Verilog side
<FL4SHK>
I don't think you can get a parameterized module in nMigen to be parameterized in Verilog
<vup>
you can actually do something like that with yosys connect_rps
<mwk>
basically yosys spawns an nmigen process as a worker, and can delegate submodule instantiations from Verilog to that process
<mwk>
which can in turn instantiate Verilog modules, and so on
<DaKnig>
ok nvm I think I wont do that :)
<daveshah>
In this case, the easiest way would just be to make the setting a module input
<daveshah>
It will probably get constant folded by the synthesiser anyway
<mwk>
... if you use flatten, yes
<DaKnig>
I guess I do..?
<mwk>
ice40?
<DaKnig>
arty z7
<mwk>
oh
<mwk>
vivado synthesis or yosys?
<DaKnig>
vivado
<mwk>
... no idea then
<daveshah>
Vivado does at least some cross boundary optimisations
<daveshah>
I think it pretty much flattens it and then reconstructs a hierarchy for P&R purposes after synthesis, but this is configurable and I don't know the detail
<DaKnig>
I dont think it matters either way, Im ok with wasting a gew LUTs and this is not the bottleneck in terms of timing.
<DaKnig>
are there "reverse polarity signals"?
<DaKnig>
(in nmigen)
<DaKnig>
to use as inverted ports
SpaceCoaster has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
<DaKnig>
mwk: doesnt yosys treat all code in its internal representation for optimization?
<tpw_rules>
i have this problem a lot, except a previous commit removed the control key and this is the only way i found to press it
<mwk>
DaKnig: well yes
<DaKnig>
so shouldnt this optimization happen before backend stage kicks in?
<mwk>
the backend controls the whole flow
<DaKnig>
it does?
<mwk>
or, well, rather the synth script in yosys terminology
<mwk>
yeah
<DaKnig>
i was able to optimize a design without specifying backend
<DaKnig>
ah.
<mwk>
then you chose the generic one
<DaKnig>
I see.
<mwk>
there's the common "synth" script which just gives you generic gates cells, or maybe generic LUT cells if you prefer
<mwk>
nothing fancy
<mwk>
and then there are synth_ice40 etc. scripts, which support the various FPGAs
<mwk>
the hierarchy/flatten calls are inside these scripts and the default options are, unfortunately, different between them
<DaKnig>
so you can still tell it to flatten on any backend, by customize that script
<mwk>
or by passing the option
SpaceCoaster has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
SpaceCoaster has joined #nmigen
emeb_mac has joined #nmigen
SpaceCoaster has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
SpaceCoaster has joined #nmigen
emeb has quit [Ping timeout: 240 seconds]
emeb has joined #nmigen
Asu has quit [Remote host closed the connection]
emeb_mac has quit [Ping timeout: 246 seconds]
emeb_mac has joined #nmigen
<DaKnig>
its ridiculous that in python you can do something like `def foo(bar:bool=3):`
<DaKnig>
I know that it should be the job of the linter to warn about this, and dynamic types and whatnot, but I'd expect it would at least check hte default value....
<_whitenotifier-b>
[nmigen] pbsds opened pull request #469: back+cli: Add FIRRTL, json and dot backends. Add ability to use them with cli.main - https://git.io/JJ18s
<_whitenotifier-b>
[nmigen] DaKnig opened issue #470: feedback caused by python Conditional Expressions - https://git.io/JJ1BG
<_whitenotifier-b>
[nmigen] DaKnig commented on issue #470: feedback caused by python Conditional Expressions - https://git.io/JJ1BZ
<DaKnig>
you know what they say, dont touch your computer when you have 3 hours of sleep in the last 48 hours :) (well nobody says that, but now somebody might)