<kbeckmann>
I'm getting hit by "YosysWarning: Design contains feedback wires, which require delta cycles during evaluation." when doing cxxrtl.convert() with my design - is there a convenient way to find out what the feedback is exactly?
<_whitenotifier-b>
[YoWASP/yosys] whitequark pushed 1 commit to update-deps/0 [+0/-0/±1] https://git.io/JJtFm
<whitequark>
kbeckmann: the warning is correct in that you will require additional (more than 1) delta cycles
<whitequark>
in this case I think it will be 3 delta cycles per eval rather than 1
<kbeckmann>
alright
<whitequark>
assuming you can take the speed hit, that shouldn't cause any issues
<kbeckmann>
great, thanks for the explanation.
<kbeckmann>
is it a bad style to write the code like it is done? would it be better to explicitly set each bit to the fully evaluated depencendy chain?
<whitequark>
it is not an inherently bad style
<kbeckmann>
okay. asking because i honestly don't know what is good or bad :).
<whitequark>
the problem here is that cxxrtl works with word-wide registers
<whitequark>
this is important e.g. for introspectability
<whitequark>
this means that the entire register is represented as one value
<whitequark>
and that all operations on the register are performed on the entire thing as once
<kbeckmann>
right, that makes sense.
<whitequark>
as a consequence if a register depends on itself it'd have to be evaluated multiple times until it converges
<whitequark>
actually now that i look closer, that would be a lot more than 3 delta cycles
<whitequark>
anyway, so there is a pass `splitnets -driver` that would split the register such that there's no apparent feedback
<whitequark>
you can't currently ask back.cxxrtl to use it
<kbeckmann>
oh interesting. would it be in nmigen/back/cxxrtl.py in the yosys script where i'd add this?
<kbeckmann>
(tried to hack it in there but i didn't get any measurable performance gains, but thanks for letting me know that it exists!)
<whitequark>
do you still get any warnings?
<kbeckmann>
I don't really have a clue what I'm doing right now.. but anyway, if i put it before the read_ilang, i get the same warning as before. if i put it immediately after, i get the following warning for all modules "Ignoring module dvid2vga because it contains processes (run 'proc' command first). "
<kbeckmann>
if i add the proc command, i get an assert. Assert `!it.first.has_const()' failed in kernel/rtlil.cc:1507.
<whitequark>
right ok so if you get any warnings it's not actually working
<kbeckmann>
i see
<whitequark>
do you need the performance improvement or do things work fine for now?
<kbeckmann>
not really, but it's always nice with performance.
Degi has quit [Ping timeout: 256 seconds]
<kbeckmann>
currently implementing a tmds/dvid to vga decoder and it takes a few seconds to crunch a frame which is completely fine.
<whitequark>
then i'd say not bother with it for now
<whitequark>
eventually i'll make sure the parts will fit together, but that will take some time
Degi has joined #nmigen
<kbeckmann>
alright. i'm really happy that we have cxxrtl now, it's so fast compared to the python simulation. it enables a lot of nice use cases.
<whitequark>
\o/
jaseg has quit [Ping timeout: 244 seconds]
jaseg has joined #nmigen
jaseg has quit [Ping timeout: 246 seconds]
jaseg has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
electronic_eel has quit [Ping timeout: 258 seconds]
electronic_eel has joined #nmigen
<whitequark>
so here's something funny
<whitequark>
i keep rewriting pysim to be more modular so that cxxsim can coexist with it (as you might want to cosimulate python and c++ code)
<whitequark>
i'm on my third attempt and each one has been a failure
<whitequark>
seems like gradually improving cxxsim so that there needn't have to be one huge commit changing the entire thing is the way to go here
<d1b2>
<Darius> "what if we do all this work and we only get a better code base out of it??"
<whitequark>
huh?
<whitequark>
no, it's more that pysim is so bad that in its current state it's impossible to add cxxsim such that they coexist
<whitequark>
fun fact: the predecessor to pysim was even worse
<whitequark>
at least pysim produces correct results!
<whitequark>
better simulation through horrors
<d1b2>
<Darius> ahh OK
<d1b2>
<Darius> correct results is definitely good for a simulator...
<_whitenotifier-b>
[YoWASP/yosys] whitequark pushed 1 commit to develop [+1/-0/±0] https://git.io/JJqfx
<_whitenotifier-b>
[YoWASP/yosys] whitequark f6ba08e - [skip ci] Add an auto-updater.
<whitequark>
hm, i don't like this PR creation scrpit
<_whitenotifier-b>
[yosys] whitequark opened pull request #5: Auto-update - https://git.io/JJqtd
<_whitenotifier-b>
[yosys] whitequark created branch update-deps - https://git.io/JJtFY
<d1b2>
<286Tech> Question: Should things like PLL, DDR I/O, etc for the different brands be integrated in nmigen (just like Litex)? And if so, should it be in nmigen or for example in nmigen-stdio?
<whitequark>
by "DDR" what do you mean exactly?
<d1b2>
<edbordin> it sounds like maybe we're talking about fpga primitives?
<d1b2>
<286Tech> Yup
<d1b2>
<286Tech> Often used primitives
<whitequark>
aha, so DDR I/O is already supported in nmigen
<whitequark>
as well as xDR for x>2
<whitequark>
on some platforms
<d1b2>
<286Tech> Ah ok
<whitequark>
PLL is planned but no actual work has been done towards that end
<whitequark>
you can start it! open an issue and begin summarizing PLL capabilities for all supported families
<whitequark>
so that we know what sort of abstraction would cover them well
<d1b2>
<286Tech> That's what I wanted to do 🙂
<whitequark>
great!
<d1b2>
<286Tech> Would it be a problem if I looked at Litex does it? (in terms of licensing issues maybe)
<d1b2>
<286Tech> Since my Pythonese isn't the best 😛
<d1b2>
<286Tech> *how Litex does it
<whitequark>
nope, LiteX uses a compatible license
<whitequark>
besides, copyright is based on textual inclusion, and it's unlikely that any code will be shareable directly
<d1b2>
<286Tech> Cool, then I'll start looking into all the PLLs from different brands and summarize them in an issue. Then I'll see if I can cook up some implementations.
<whitequark>
sure
<whitequark>
just to make it clear, my bandwidth is fairly limited and will remain so for the next several months, so your implementation might not be merged quickly
<whitequark>
it would be a good idea to recruit people to test it in that time
<d1b2>
<286Tech> Oh that's no problem 🙂 I would also like things to be worked out properly beforehand, instead of trying to clean up a mess afterwards 😉
<d1b2>
<286Tech> Been burned by that before
<whitequark>
ok, great!
<_whitenotifier-b>
[nmigen/nmigen] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/JJqmK
<_whitenotifier-b>
[nmigen/nmigen] whitequark 3c3cfd4 - back.pysim: reset timeline as well.
<_whitenotifier-b>
[nmigen/nmigen] whitequark 6d41756 - back.pysim: only extract signal names if VCD is requested.
<_whitenotifier-b>
[yosys] whitequark opened pull request #6: Auto-update - https://git.io/JJq8p
* zignig
finally gets the bootloader working, cycle time on dev goes from 55s down to 3s
<zignig>
working boneless SOC with hex program upload.
Asu has quit [Read error: Connection reset by peer]
Asu has joined #nmigen
<lkcl>
whitequark: thank you for replying about Record. with the care and thought you're putting into it, we're good.
<_whitenotifier-b>
[nmigen/nmigen] whitequark pushed 1 commit to master [+4/-0/±1] https://git.io/JJqRk
<_whitenotifier-b>
[nmigen/nmigen] whitequark d7a87fe - back.pysim→sim.pysim; split into more manageable parts.
<_whitenotifier-b>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JJqRt
<_whitenotifier-b>
[nmigen/nmigen] whitequark 6176fcc - Deploying to gh-pages from @ d7a87fef42b32fe6813480fb144e1e2ae7ffdf1c 🚀
<vup>
whitequark: sounds reasonable
<whitequark>
ok well the auto-merge functionality clearly doesn't work
<whitequark>
guess i can hit a button once per week manually or something
<_whitenotifier-b>
[YoWASP/yosys] whitequark pushed 1 commit to develop [+2/-1/±0] https://git.io/JJqRN
<_whitenotifier-b>
[YoWASP/yosys] whitequark abb8d5a - [skip ci] Add an auto-updater.
<_whitenotifier-b>
[YoWASP/nextpnr] whitequark pushed 1 commit to develop [+2/-1/±0] https://git.io/JJq0R
<_whitenotifier-b>
[YoWASP/nextpnr] whitequark 1c16237 - [skip ci] Add an auto-updater.
daveshah has joined #nmigen
<_whitenotifier-b>
[nmigen-soc] jfng synchronize pull request #19: periph: add a PeripheralInfo class for metadata. - https://git.io/JJvQM
<_whitenotifier-b>
[nmigen-soc] codecov[bot] edited a comment on pull request #19: periph: add a PeripheralInfo class for metadata. - https://git.io/JJvQy
<_whitenotifier-b>
[nmigen] GuzTech opened issue #425: Support for PLL primitives - https://git.io/JJquS
<_whitenotifier-b>
[nmigen-soc] codecov[bot] edited a comment on pull request #19: periph: add a PeripheralInfo class for metadata. - https://git.io/JJvQy
<_whitenotifier-b>
[nmigen-soc] jfng commented on pull request #19: periph: add a PeripheralInfo class for metadata. - https://git.io/JJquQ
<d1b2>
<286Tech> I've been busy gathering information on all types of PLLs but this is what I could come up with for now 🙂
daveshah has quit [Remote host closed the connection]
daveshah has joined #nmigen
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
<_whitenotifier-b>
[nmigen] jeanthom commented on issue #425: Support for PLL primitives - https://git.io/JJqgh
cr1901_modern has quit [Ping timeout: 272 seconds]
<FL4SHK>
now building a Python-based assembler of sorts
<FL4SHK>
thinking of following in nMigen's footsteps
<_whitenotifier-b>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JJqX8
<_whitenotifier-b>
[nmigen/nmigen] whitequark ae76f89 - Deploying to gh-pages from @ 30e2f91176edcd1c8766c2cb11f413b9c77936b9 🚀
daveshah has quit [Remote host closed the connection]
daveshah has joined #nmigen
ktemkin has joined #nmigen
Cynthia_ has joined #nmigen
key2 has joined #nmigen
daveshah_ has joined #nmigen
daveshah has quit [Remote host closed the connection]
daveshah_ is now known as daveshah
gravejac has joined #nmigen
Qyriad has joined #nmigen
mithro has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Ping timeout: 258 seconds]
_florent_ has joined #nmigen
Cynthia_ is now known as Cynthia
esden has joined #nmigen
pdp7 has joined #nmigen
bubble_buster has joined #nmigen
ianloic has joined #nmigen
sorear has joined #nmigen
Asuu has quit [Read error: Connection reset by peer]
guan has joined #nmigen
rohitksingh has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
proteus-guy has joined #nmigen
withig is now known as nengel
<d1b2>
<Falteckz> Sorry. I've been offline because I use IRCCloud which was down for about 18 hours. Just going to use Discord for now until I stand up my own IRC bouncer
<d1b2>
<Falteckz> whitequark: The upstream fix is already landed? That's exciting. Will update this morning.
Asu has joined #nmigen
proteus-guy has quit [Ping timeout: 272 seconds]
Asu has quit [Read error: Connection reset by peer]
Asuu has joined #nmigen
Asuu has quit [Read error: Connection reset by peer]
Asuu has joined #nmigen
Asuu has quit [Client Quit]
<_whitenotifier-b>
[nmigen] GuzTech opened pull request #426: [WIP] Initial implementation of ECP5 PLL instantiation - https://git.io/JJqHg
<_whitenotifier-b>
[nmigen] GuzTech commented on issue #425: Support for PLL primitives - https://git.io/JJqHa
<_whitenotifier-b>
[nmigen] codecov[bot] commented on pull request #426: [WIP] Initial implementation of ECP5 PLL instantiation - https://git.io/JJqHV
<_whitenotifier-b>
[nmigen] codecov[bot] edited a comment on pull request #426: [WIP] Initial implementation of ECP5 PLL instantiation - https://git.io/JJqHV
<_whitenotifier-b>
[nmigen] GuzTech commented on pull request #426: [WIP] Initial implementation of ECP5 PLL instantiation - https://git.io/JJqHS