<_whitenotifier-b>
[nextpnr] github-actions[bot] created branch update-deps - https://git.io/JJY7T
<_whitenotifier-b>
[nextpnr] github-actions[bot] opened pull request #7: Auto-update - https://git.io/JJ1RO
<awygle>
tpw_rules: re: boneless, instead of just talking out my ass i decided to actually look up why generator objects were removed
<awygle>
they were removed in commit 7df70059d1483677b1c4d24eaed3bac323b32a11
<awygle>
Generators can no longer be added as processes, since that would break reset(); only generator functions may be. If necessary, they may be added by wrapping them into a generator function; a deprecated fallback does just that. This workaround will raise an exception if the simulator is reset and restarted.
<tpw_rules>
ok well a) is what i'm doing and b) does not apply because all the tests still run
<awygle>
the deprecated fallback got removed in July when everything deprecated in nmigen 0.2 got removed, i'm pretty sure
<awygle>
so that explains why boneless used to work and now doesn't
<awygle>
so it sounds like the "right" thing to do is to rework the generator to be a generator function, but the lambda-wrapping is fine. obviously the choice of what to commit is yours tho.
<_whitenotifier-b>
[nmigen] whitequark commented on pull request #469: back+cli: Add FIRRTL, json and dot backends. Add ability to use them with cli.main - https://git.io/JJ10m
emeb_mac has quit [Ping timeout: 265 seconds]
<whitequark>
DaKnig: if you want generics on Verilog side your only option is connect_rpc, which is better than most newHDLs, where your only option is to manually pregenerate a bunch of Verilog for this purpose
emeb has quit [Ping timeout: 240 seconds]
<whitequark>
(in fact I wrote connect_rpc specifically because the other solution is ridiculous)
emeb has joined #nmigen
<whitequark>
tpw_rules: the generator function workaround you mentioned is OK, glasgow has the same fix
<whitequark>
it's not ideal but i'm totally fine with having it in the meantime
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
<awygle>
can i do a yosys out of context build with nmigen?
<awygle>
i just want to see how big this elaboratable is
<awygle>
also does nextpnr have out of context builds?
<whitequark>
try `yosys -p synth`
<whitequark>
well, let me rephrase
<whitequark>
yosys actually doesn't care that much about context
<whitequark>
it wouldn't even insert IOBs in most cases (it might for inouts with tristate, i think?)
<mwk>
some flows do, eg. for xilinx you want -noiopad
<whitequark>
ah
<mwk>
... and of course it's inconsistent
FFY00 has quit [Remote host closed the connection]
<awygle>
lol cool cool
FFY00 has joined #nmigen
<awygle>
hm. wq, can i check whether an nmigen module has registered outputs?
<whitequark>
nope, in fact, i would say the question doesn't necessarily make sense
<whitequark>
depending on the specific thing you ask
<awygle>
yeah, i didn't really think so
<awygle>
that would have to be what, post-yosys? assuming the FOSS flow
<whitequark>
e.g. suppose you connect an output directly to an input
<whitequark>
is it registered? the answer is "if the input is registered"
<whitequark>
but maybe you want a weaker guarantee
<whitequark>
then it might be possible to answer this
<awygle>
basically, looking only at the module, is there any logic between the output signal and the most upstream flip-flop. a purely combinational module would return "no"
<awygle>
err, "yes, there is logic, no, it does not have registered outputs"
<whitequark>
the... most upstream flip-flop?
<whitequark>
what do you mean?
* awygle
longs for the ability to doodle in IRC
<whitequark>
let me try and answer the question how i understand it
<whitequark>
in nmigen you can fairly easily check whether a signal is driven from comb or sync domain
<whitequark>
would that suffice?
<awygle>
i suppose so
<awygle>
yes
<whitequark>
so let's say: comb += a.eq(b), sync += b.eq(c)
<whitequark>
is a registered or not, according to the rule you care about?
<awygle>
i would accept "a is not registered" as an answer here
<whitequark>
ok, yeah, you can find what you need in Fragment
<awygle>
even though yes if you expand the circuit it would be
<awygle>
ok, cool
<whitequark>
basically i think you can check registered-ness by running `sig not in frag.iter_comb()`
<whitequark>
this isn't a public API but it's unlikely to change in immediate future
<whitequark>
it might or might not become a public API, leaning to "might not and will be changed at some point"
<awygle>
mk
<awygle>
since it's not public it wouldn't necessarily go through a deprecation cycle, right?
<awygle>
(that's nbd i just want to make sure my expectation is correct)
<whitequark>
yes. the default is "it won't", though if it turns out people actually do rely on it, then it might anyway
<awygle>
sweet. thanks
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
<d1b2>
<edbordin> @whitequark was your main objection to taskkill in sby just the use of a subshell? or did you want to try to do the equivalent of SIGTERM?
<d1b2>
<edbordin> So far I have an impl that will kill them all like taskkill does
<whitequark>
edbordin: yeah, the use of a subshell
<whitequark>
can i take a look?
<d1b2>
<edbordin> phew, because it looks like trying to do sigterm on windows is a can of worms
<whitequark>
edbordin: that doesn't look too bad, but, perhaps a dumb question
<whitequark>
oh
<whitequark>
are you killing the processes recursively?
<d1b2>
<edbordin> it's not very sophisticated - it just lists all the pids first then kills them one by one
<d1b2>
<edbordin> the set doesn't guarantee any ordering
<whitequark>
nvm, i found out the answer
<whitequark>
looks like i didn't quite appreciate the complexity involved here
<whitequark>
different question
<d1b2>
<edbordin> apparently the real way to do this kind of thing on windows is to create a "job". but even then that apparently can't nest more than one level below the parent so... it's just a quirk of windows I guess
<d1b2>
<edbordin> ask away
<whitequark>
edbordin: what's the reason you can't use creationflags=subprocess.CREATE_NEW_PROCESS_GROUP ?
<whitequark>
I think there was some, but I don't recall anymore
<d1b2>
<edbordin> some of this process management stuff in python has features that only work on posix - I would not be surprised if that is one of those features. but it's worth checking
<whitequark>
no, it's one of those which works *only on windows*
<whitequark>
i think it might be doing the thing which you implemented
<whitequark>
but i also might be wrong
<d1b2>
<edbordin> hmm, either way I'm very prepared to throw away my implementation if we can lean on one in the standard lib
<whitequark>
i got a bit suspicious when you mentioned toolhelp snapshots but i didn't recall whether there was a reason that'd be the only way
<d1b2>
<edbordin> asyncio.create_subprocess_shell docs point to asyncio.loop.subprocess_shell which says "This is similar to the standard library subprocess.Popen class called with shell=True", so I guess maybe it will accept that kwarg
FL4SHK has quit [Ping timeout: 246 seconds]
<d1b2>
<edbordin> idk how to test this because even on sby master I haven't yet figured out how to get a process to keep running after sby exits
<d1b2>
<edbordin> but if your hunch is right then hopefully we can terminate the process group with os.kill(self.p.pid, signal.CTRL_C_EVENT)
FL4SHK has joined #nmigen
<whitequark>
or just any other signa
<whitequark>
*signal
<whitequark>
(which translates to TerminateProcess)
<d1b2>
<edbordin> will terminateprocess kill the whole group?
<d1b2>
<edbordin> in which case the most robust method would probably be: snapshot process tree, send ctrl+c to group, wait, kill any processes still running using TerminateProcess
<d1b2>
<edbordin> but really, the current posix impl just sends sigterm so ctrl+c is probably a reasonable analog to that
<sorear>
if you terminate processes one at a time you can't deal with a process rapidly spawning subprocesses
<whitequark>
sorear: not in scope
<d1b2>
<edbordin> well no, but unless your SMT solver is a forkbomb we can probably accept that limitation
<DaKnig>
whitequark: wdym by "the other solutions are ridiculous"?
<DaKnig>
I think the one that would make most sense would be to have Signal/Const as an interface, with specified width (32 for vhdl `integer`)
<DaKnig>
why is that not a good solution? surely you discussed something similar
<whitequark>
DaKnig: oh! sure, you can turn a constant into a port just fine
<whitequark>
(either by keeping it an input syntactically, or by transforming it into a parameter somehow)
<DaKnig>
I dont mean a port, I mean to use that as a generic
<whitequark>
the immediate reason is that you can't do this and keep using yosys to emit verilog
<whitequark>
but the more important reason is that this only lets you do a small subset of all possible generics
<whitequark>
for example, you can't vary port width that way
<d1b2>
<edbordin> z3 and yices seem to die on their own anyway if stdin gets closed on them, perhaps cr1901_modern will have some tips for testing this
<whitequark>
edbordin: just to check, what happens if you send signal.SIGKILL?
<d1b2>
<edbordin> just trying that now. again, it's a little hard to tell because they die on their own shortly after the parents closes stdin
<whitequark>
maybe you can use one of the sysinternals tools to see the precise order of the things
<d1b2>
<edbordin> not a bad idea. fwiw even without that flag set to create process group, killing the shell still results in the children dying
<d1b2>
<edbordin> I'm not testing with avy or super_prover though, maybe they are more prone to hanging around
emeb_mac has quit [Quit: Leaving.]
FL4SHK has quit [Ping timeout: 256 seconds]
<d1b2>
<edbordin> ok, well I think I'm convinced. only when I create a process group and send ctrl+break do I see an exit code from z3 and yices that indicates they got the signal
<d1b2>
<edbordin> thanks for the guidance whitequark, I hope you're taking some time to recuperate and that I didn't hinder that
<whitequark>
you're fine
<d1b2>
<edbordin> might put this ctypes code in a github gist in case it comes in handy some day
Asu has joined #nmigen
<d1b2>
<edbordin> whitequark if I get rid of the ctypes stuff do you think it's ready for PR? I don't really care how long it sits there
<whitequark>
edbordin: sure, seems perfect
<whitequark>
i'll nominate it on the next SEDA meeting as well
<whitequark>
well, the next one i participate in
<d1b2>
<edbordin> awesome
<cr1901_modern>
edbordin: Nice work. And no I don't have any advice, it was a bit too long ago at this point.
<d1b2>
<edbordin> Thanks for doing the bulk of the work last year!
<cr1901_modern>
Thanks for doing the other 50%, which was making it production quality :P
<d1b2>
<edbordin> It is sometimes funny how much time can go into one tiny diff :P
jeanthom has joined #nmigen
<d1b2>
<edbordin> In the meantime, I noticed the windows cmdline substitutions are breaking the ABC backend so that is probably worth tackling as well before I start shipping on windows
<cr1901_modern>
edbordin: Just realized... the CTRL+C handler also addresses the third disadvantage listed on Windows (re: signal handlers)? https://github.com/YosysHQ/SymbiYosys/pull/39
<d1b2>
<edbordin> cr1901_modern I didn't see error messages like the examples you have for that third disadvantage, but I'm not sure I understand what was going on there so couldn't say if this approach changes it or if it's just an intermittent thing
<_whitenotifier-b>
[nmigen-boards] whitequark commented on pull request #101: Added Arty S7 support - https://git.io/JJ1d4
<DaKnig>
how do I include verilog modules into the nmigen module?
<whitequark>
what do you mean by "include"?
<DaKnig>
I want it to generate a verilog file that has other modules as components, map ports etc
<Lofty>
Instance then, I think
<Lofty>
*them
<DaKnig>
and how would I set the clock of each instance?
<DaKnig>
they all run at different rates
<DaKnig>
and one of them represents the PLL
<Lofty>
ClockSignal(<domain>)
<Lofty>
If you have them as nMigen domains, anyway
<whitequark>
wait
<DaKnig>
I have one nmigen module (translated from vhdl) and a few vhdl modules (it doesnt matter for vivado; vhdl/verilog, it works the same)
<whitequark>
yeah, if you want to drive an instance's port from an nmigen clock domain, or vice versa, you can connect a ClockSignal to the corresponding instance port
<DaKnig>
Lofty: where can I find examples for using `Instance`? is that the same as in the platform files?
<Lofty>
Yep, as well as the inst.py nMigen example
<DaKnig>
so I see that the names of the submodule pins encode the direction/meaning, what does _p mean?
<Lofty>
DaKnig: "_p" or "p_"?
<Lofty>
The latter is a parameter
<DaKnig>
_p oops
<DaKnig>
ah.
<DaKnig>
p_**
<_whitenotifier-b>
[nmigen-boards] Fatsie commented on pull request #101: Added Arty S7 support - https://git.io/JJ1NE
<_whitenotifier-b>
[nmigen-boards] Fatsie edited a comment on pull request #101: Added Arty S7 support - https://git.io/JJ1NE
<_whitenotifier-b>
[nmigen-boards] whitequark commented on pull request #101: Added Arty S7 support - https://git.io/JJ1Nd
<_whitenotifier-b>
[nmigen-boards] Fatsie commented on pull request #101: Added Arty S7 support - https://git.io/JJ1NA
<_whitenotifier-b>
[nmigen-boards] whitequark commented on pull request #101: Added Arty S7 support - https://git.io/JJ1Af
<DaKnig>
what's the type of the p_ params?
<DaKnig>
is it int?
<whitequark>
you can pass a Const, an int, or a string
<whitequark>
an int will be as wide as needed, but at least 32 bits wide
<DaKnig>
and doing `portname=Signal()` is the way you map the ports?
<_whitenotifier-b>
[nmigen-boards] Fatsie commented on pull request #101: Added Arty S7 support - https://git.io/JJ1hC
<_whitenotifier-b>
[nmigen-boards] Fatsie opened pull request #102: Arty A7: rename cpu_reset resource to rst. - https://git.io/JJ1ha
SpaceCoaster has quit [Read error: Connection reset by peer]
SpaceCoaster has joined #nmigen
SpaceCoaster has quit [Client Quit]
SpaceCoaster has joined #nmigen
jeanthom has joined #nmigen
<d1b2>
<286Tech> Uhm, I'm trying to request a button from the ULX3S platform, and I keep getting an error: TypeError: request() missing 1 required positional argument: 'name'
<d1b2>
<286Tech> I'm porting the dvi example for the ULX3S to nmigen btw.
<d1b2>
<286Tech> Ugh, I'm an idiot.
<d1b2>
<286Tech> platform().build...
<DaKnig>
platforms are classes
<d1b2>
<286Tech> Yeah
<DaKnig>
you are supposed to call the constructor via ClassName()
<d1b2>
<286Tech> I got that from some example code, but variants holds the classes but doesn't call the constructors (obviously), so I have to do that myself.
<d1b2>
<286Tech> But that was only done on the last line, and I needed to call functions on it. Doesn't work if the objects is not created yet.
<_whitenotifier-b>
[nmigen] pbsds commented on pull request #469: back+cli: Add FIRRTL, json and dot backends. Add ability to use them with cli.main - https://git.io/JJMUR
<_whitenotifier-b>
[nmigen] whitequark commented on pull request #469: back+cli: Add FIRRTL, json and dot backends. Add ability to use them with cli.main - https://git.io/JJMU9
jeanthom has quit [Ping timeout: 240 seconds]
<_whitenotifier-b>
[nmigen] pbsds commented on pull request #469: back+cli: Add FIRRTL, json and dot backends. Add ability to use them with cli.main - https://git.io/JJMkG
<_whitenotifier-b>
[nmigen] pbsds edited a comment on pull request #469: back+cli: Add FIRRTL, json and dot backends. Add ability to use them with cli.main - https://git.io/JJMkG
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
<d1b2>
<286Tech> I want to assign to the p signal of a DiffPairs but I get an error that there is no p field, only i, o, and oe.
<whitequark>
286Tech: nmigen instantiates an appropriate differential buffer for you
<whitequark>
if you want to avoid that, use dir="-"
<d1b2>
<286Tech> I instantiated an ODDRX1F by hand, and I want to assign the output of it to the _p of a diff pair. Does it also instantiate stuff in that case?
<d1b2>
<286Tech> I just assigned to .o and it didn't complain (the design doesn't work yet, but I'm sure that's my fault).
<whitequark>
it doesn't know whether you instantited ODDRX1F
<whitequark>
you have to tell it by using dir="-" (or probably dir={"subsignal":"-"})
<d1b2>
<286Tech> Ah I see. Thank you!
SpaceCoaster has quit [Ping timeout: 240 seconds]
DaKnig has quit [Ping timeout: 256 seconds]
DaKnig has joined #nmigen
_whitelogger has joined #nmigen
Asu has quit [Quit: Konversation terminated!]
cr1901_modern1 has joined #nmigen
FL4SHK has joined #nmigen
cr1901_modern has quit [Ping timeout: 265 seconds]
<awygle>
i know the xdr stuff is standardized by the pins, but what about alignment? are we planning to standardize that?
emeb_mac has joined #nmigen
<whitequark>
yes
<whitequark>
it's been a longstanding issue
<whitequark>
i haven't tackled it because, frankly, i just have been really busy with other things
<whitequark>
open an rfc?
<awygle>
sure
<awygle>
(later today most likely)
<awygle>
when you said "longstanding issue" i was prepared to feel like a real jackass for not seeing it in the issues lol
<_whitenotifier-b>
[nmigen] awygle commented on issue #467: Inconsistency between a parameter name for AsyncFFSynchronizer and FFSynchronizer - https://git.io/JJMnp
<awygle>
can i tell nmigen to just give me, like... some pins? i want to test how big/fast this module is, but it keeps getting eaten at some point, probably because i'm not hooking up the inputs to anything besides "a Signal() that's never assigned to" in my test program
<awygle>
guess i could use the Connector in the Versa platform, probably
<awygle>
ignoring the thousands of unnecessary imports lol
<whitequark>
awygle: so you don't care about the specific platform, right?
<awygle>
right, just that it's an ECP5 with the proper speed grade
<whitequark>
can you do verilog.convert(ports=[...]) and then do synth_ecp5 manually?
<awygle>
yep that's what i'm doing right now
<awygle>
just was wondering if i could do it all in nmigen, because the environment is nice and shelling out feels bad lol
<whitequark>
currently no
<whitequark>
but maybe we should have it
<whitequark>
open an RFC?
<awygle>
heh
<awygle>
sure
<_whitenotifier-b>
[nmigen] whitequark commented on issue #467: Inconsistency between a parameter name for AsyncFFSynchronizer and FFSynchronizer - https://git.io/JJMCg
<_whitenotifier-b>
[nmigen] whitequark commented on issue #467: Inconsistency between a parameter name for AsyncFFSynchronizer and FFSynchronizer - https://git.io/JJMCo
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
<_whitenotifier-b>
[nmigen] awygle commented on issue #467: Inconsistency between a parameter name for AsyncFFSynchronizer and FFSynchronizer - https://git.io/JJMCD
<whitequark>
for everything we should discuss "on the next meeting"
<whitequark>
feel free to stuff it on everything we should discuss on the next meeting, if you remember, because i don't...
<awygle>
Ah, sweet, good idea
<agg>
awygle: fwiw i've wanted to do that sort of a thing a bunch too (basically an out of context synth of a module to check speed/resource or to make it easier to optimise parts of a design)
<awygle>
agg: good to know, thanks!
<agg>
but didn't find any particularly good ways either, I think i did basically just make a new dummy platform with a load of io pins
<awygle>
in this particular case i have a hard (as well as difficult) frequency requirement for one particular module and i want to make sure i don't ruin it as i add functionality
<agg>
yea, makes sense
<agg>
i see it as sort of an integration test where we already have unit tests
<agg>
or more like a benchmark I guess
<agg>
since i'm not really interested in running a testbench against it, just measuring its timing and resource usage, and maybe making a test pass/fail based on it, but more likely comparing that benchmark across commits or whatever
<agg>
v handy for optimising speed/area
cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Ping timeout: 240 seconds]