ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen
levi_ has quit [Read error: Connection reset by peer]
levi_ has joined #nmigen
bubble_buster has quit [Ping timeout: 240 seconds]
mithro has quit [Ping timeout: 240 seconds]
bubble_buster has joined #nmigen
mithro has joined #nmigen
Degi has quit [Ping timeout: 264 seconds]
Degi_ has joined #nmigen
Degi_ is now known as Degi
levi_ is now known as levi
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #nmigen
futarisIRCcloud has joined #nmigen
jeanthom has joined #nmigen
Asu has joined #nmigen
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
chipmuenk has joined #nmigen
Sarayan has joined #nmigen
<zignig> whitequark: after much deliberation I find my self missing a few things.
<zignig> is there a way do dump heirachy post elaborate and before synth ?
<zignig> I understand that it is a lambda squiggle.
<zignig> I it would be possible to dump the submodules vs class it would be possible to build cxxrtl constructs,
* zignig needs to sleep more and type less.
<Lofty> zignig: may I ask what your use-case is for this?
<zignig> Lofty: attempting to put a boneless into cxxrtl and bind peripherals to c++ templated objects.
<Lofty> Well, nmigen dumps RTLIL, and then cxxrtl takes it in
<zignig> yep and I find a disconnect between named nmigen and cxxrtl cariables.
<zignig> *v
<Lofty> That sounds like a bug, but I don't know what optimisation level you're passing to write_cxxrtl
<zignig> indeed , the degub_info() means that you can get a space delimimted heir. from cxxrtl , but I can squeeze it out of nmigen elaboratable.
<zignig> *can
<zignig> '*can't
* zignig 's fingers are failing.
<zignig> Lofty: what are you buildinf at the moment?
<Lofty> ...?
<Lofty> I've been working on synth_intel_alm a bit
<zignig> with nmigen ?
<zignig> I have been trying to reflect nmigen_boards , but I keep on getting distracted...
<Lofty> In terms of nmigen stuff...not all that much
<Lofty> I might revisit my chess program
<Lofty> Having accidentally nuked the source code of it while moving from WSL1 to WSL2
<zignig> oops :)
<zignig> what board do you have?
* zignig thinks that cxxrtl can provide for the boardless.
<Lofty> DE-10 Nano
<Lofty> Which uses the Cyclone V
<zignig> cool
futarisIRCcloud has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
<whitequark> zignig: use back.cxxrtl.convert_fragment
<whitequark> that gives you two return values, the C++ code and the map from signals to hierarchical names
chipmuenk has quit [Ping timeout: 256 seconds]
chipmuenk has joined #nmigen
jeanthom has joined #nmigen
Asu has quit [Quit: Konversation terminated!]
pbsds43 has joined #nmigen
pbsds has joined #nmigen
pbsds43 has quit [Remote host closed the connection]
<whitequark> kbeckmann: what's "pergola"?
<whitequark> nvm found it
<whitequark> kbeckmann: hey, nice board, and I like your code too
<kbeckmann> thanks :)
<whitequark> are you building those for other people? i rly want to play with the dvi-d stuff now
<kbeckmann> i'm currently a bit stuck because of some bad design decisions, so will make a second rev to clear those up. note to self: sharing the flash between the MCU and the ECP5 was not a great idea.
<kbeckmann> yeah that is the idea. i want to finish the board and ideally make a small production run of it.
<whitequark> (i have enough devboards that can do this but a versa is too complex and expensive to do stuff like that on a whim)
<whitequark> cool
<kbeckmann> yeah the bom is like 20 usd or so, which was the point of it. cheap and not too many things on it.
<whitequark> btw you don't need __main__ stuff in __init__.py
<kbeckmann> i have parts for a few more boards. i can solder one up and ship to you if you like.
<whitequark> and i think you can't actually use it
<whitequark> to answer that question
<whitequark> yep, that would be great, assuming you won't drop the firmware support for that rev or if it won't need reflashes
<whitequark> (not sure what's the situation with the errata)
<kbeckmann> sure that will not be a problem. and if you need to reflash it, it has both SWD pins and a usb rom bootloader.
<whitequark> cool ty
<whitequark> > pdm = Signal(pdm_in.shape().width + 1)
<whitequark> i normally write this as `Signal(len(pdm_in) + 1)`
<whitequark> i'm thinking the manual should include a cheatsheet with common operations
<kbeckmann> ah, thanks. yeah that would be really helpful.
<whitequark> > sync_clk_freq = platform.lookup(platform.default_clk).clock.frequency
<kbeckmann> there is not a lot of code out there written in nmigen. i have mostly been looking at Luna and the code itself.
<whitequark> that should be platform.default_clk_frequency
<whitequark> precisely because that construct is so unwieldy otherwise
<whitequark> yeah
<whitequark> kbeckmann: have there been any frustrations you encountered while writing that code?
<whitequark> anything that can be improved in nmigen?
<kbeckmann> yeah.. but when i have realized how to use it it is kinda obvious
<kbeckmann> connectors is something i didn't get at all because i couldn't figure out how to use them
<whitequark> oh, yeah
<whitequark> they're just a way to rename pins
<kbeckmann> but it seems you can just pass conn=... in a Resource
<kbeckmann> here some example would be really helpful
<whitequark> yep
<kbeckmann> and again, obvious when you know the answer :)
<kbeckmann> one thing that i am not sure if it is a good or bad thing, is that it's not possible to drive individual bits in a signal from different clock domains. i guess this is per design as it prevents dangerous mistakes?
<whitequark> so that's actually a surprisingly complicated issue
<kbeckmann> i can imagine...
<whitequark> not in the sense of code
<whitequark> but in the sense of design
<whitequark> right now, it would not be hard to let you do that in nmigen, it's just one condition
<whitequark> but it would cause a number of problems
<whitequark> - first, it would cause problems for cxxrtl. cxxrtl *does* handle them (https://github.com/YosysHQ/yosys/pull/2145, https://github.com/YosysHQ/yosys/pull/2142)
<whitequark> but it's tricky, it makes VCD files worse, and it makes the nmigen cxxsim more complicated
<whitequark> and probably slower too
<whitequark> - second, if those signals ever end up as ports, it is no longer possible to answer "which domain is the port driven from?"
<kbeckmann> oh i see.
<whitequark> so for example, nmigen's CDC analysis (https://github.com/nmigen/nmigen/issues/6) will get more complicated on its own
<kbeckmann> it seems like an odd use case but i can still see why one wants to do it. in my case i just split up my wide signal.
<whitequark> but an even worse problem is that if you *export* a module from nmigen, or import a module from another HDL, you'll then need to describe ports at bit granularity
<kbeckmann> ohh right.
<whitequark> oh wait
<whitequark> also the yosys verilog backend struggles a lot with such signals
<whitequark> currently it will sometimes produce invalid verilog https://github.com/YosysHQ/yosys/issues/2035
<whitequark> I'm curious, where did you encounter this?
<kbeckmann> oh..
<whitequark> maybe we can provide a palatable workaround
<kbeckmann> it was when i was trying to generate multiple rgb color values in a slower clockdomain and doing a gearbox by writing strange code :)
<whitequark> right, ok
<whitequark> then I guess my recommendation boils down to "don't do that"
<kbeckmann> yep :)
<kbeckmann> i am not very experienced with HDL at all, so i'm partly learning hdl in general, while learning nmigen. so i will keep making strange mistakes for sure.
<whitequark> experienced designers have also expressed the desire for being able to drive a signal from multiple domains
<whitequark> so it's not (just?) a beginner mistake
<kbeckmann> i see. maybe they have a very specific usecase in mind.
<kbeckmann> and i'm just doing things wrong :)
<whitequark> it's for CDC i think
<kbeckmann> right
<whitequark> so... pretty similar to what you want
<whitequark> it's just so hard to support properly that accepting the limitation might be better in long run
<whitequark> fun fact
<whitequark> in verilog it is legal to write `always @(posedge clocks[0])`
<whitequark> and the amount of code in cxxrtl necessary to handle that correctly is staggering
<kbeckmann> oh...
<whitequark> this feature is like the inverse of the one we were discussing
<kbeckmann> trying to understand why one wants to bundle up multiple clocks in the same signal/wire
<kbeckmann> oh yeah another minor frustration. simulations. i struggled a bit to get the phase right when having multiple clocks. usually i want the simulation to begin with a low clock so you can see the initial state and what happens after the first clock edge.
<kbeckmann> trying to remember if this was a real problem or not. but i remember having issues with it.
<whitequark> quite possibly real, simulations are a bit of a weak point currently
<whitequark> btw, how do i run the simulation?
<whitequark> can't seem to figure it out from your code
<kbeckmann> python -m unittest -v pergola.applets.dvid.DVIDSim
<kbeckmann> it's a hack...
<whitequark> ooh
<kbeckmann> it's definitely not a unittest :D
<whitequark> so, a small piece of advice
<whitequark> twll, two
<whitequark> *well, two
<whitequark> first, you probably don't need the inline threshold, at least if you're slowing down the sim anyway
<whitequark> it helps when running vexriscv, which is a massive design
<kbeckmann> it did a huge difference, 15->22 fps or so
<kbeckmann> if you pull again there will be an fps counter :)
<whitequark> interesting
<whitequark> okay, will need to look into it more properly then
<whitequark> actually you could help with this if you wanted
<kbeckmann> i can try..
<whitequark> i'm thinking that sprinkling __attribute__((always_inline)) in cxxrtl.h might help
<whitequark> but i'm not sure where exactly
<kbeckmann> ah
<whitequark> maybe at alu()? all value<> members?..
<whitequark> doesn't seem to help for cxxrtl_yosys functions but maybe i did it wron
<whitequark> the reason I'm talking about using attributes is the other advice
<whitequark> oh wait that one doesn't apply for you, sorry
<whitequark> but it will for people using cxxsim so attributes are still important
<kbeckmann> hmm is there a simple way to see which functions were inined and then based on that we know what to inline
<whitequark> you can use objdump to see which functions were *not* inlined
<kbeckmann> right
<whitequark> and you can set inline threshold and diff
<kbeckmann> ah right
<whitequark> i get 38 fps
<whitequark> can get 64 fps with a hacky workaround
<whitequark> wait, 38 fps was with old yosys, hold on
<kbeckmann> wow
<whitequark> okay, no, 38 with yosys master, i think i had the right version installed
<kbeckmann> note that i am simulating the inactive area as well
<kbeckmann> might get faster with different vga parameters
<whitequark> i do *not* recommend using this workaround
<whitequark> but it does show what the simulation is capable of, with some improvements
<kbeckmann> oh, okay :)
<whitequark> like, i'm not oging to forbid you from doing it, i'm not a cop
<whitequark> it's just that it can and likely will break without warning sometime
pbsds has quit [Quit: Leaving]
<kbeckmann> hehe :). yeah that did bump up the frame rate a bit
<kbeckmann> oh! not just a bit, that's a lot faster. getting 45 on my machine now.
<whitequark> hrmmm
<whitequark> what do you say you look into attributes, and i look into making this a proper fix? :)
<kbeckmann> sure!
<kbeckmann> also thanks a lot for helping out so much. it's greatly appreciated.
<whitequark> np
<kbeckmann> -fno-exceptions gave 27 -> 30 fps
<whitequark> ooh
<whitequark> no noticeable difference here, strangely
<whitequark> hm
<whitequark> can you double check if that really helps, and if yes, whether adding noexcept to the function does the same?
<whitequark> to the eval and commit functions specifically
<kbeckmann> ok adding __attribute__((always_inline)) before mul_ss made a huge difference
<kbeckmann> that gives almost the same performance as having -inline-threshold=99999
<whitequark> fascinating
<kbeckmann> i am sure this is highly dependent of the design..
<whitequark> what if you add always_inline on every function in cxxrtl_yosys?
<whitequark> does that recover the rest?
<kbeckmann> i can try
<kbeckmann> yeah now i get virtually the same framerate
<kbeckmann> i'll diff the objdump again
<kbeckmann> there is some _Rb_tree_iterator that doesn't get inlined
<whitequark> that's ok, it's not on eval/commit path
<kbeckmann> alright
<kbeckmann> otherwise it's equivalent now
<whitequark> okay, excellent
RaYmAn has joined #nmigen
jeanthom has quit [Ping timeout: 260 seconds]
<Lofty> Itanium zero-cost exceptions that are neither for Itanium nor zero-cost
<Lofty> It not being for Itanium is a good thing though
<Lofty> You're welcome, whitequark
<whitequark> :p
<Lofty> :3
<Lofty> Night everyone
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 256 seconds]
chipmuenk1 is now known as chipmuenk