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
Asuu has quit [Remote host closed the connection]
SpaceCoaster has quit [Ping timeout: 260 seconds]
SpaceCoaster has joined #nmigen
_whitelogger has joined #nmigen
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #nmigen
SpaceCoaster has quit [Ping timeout: 260 seconds]
SpaceCoaster has joined #nmigen
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±3] https://git.io/JfXjD
<_whitenotifier-f> [nmigen/nmigen] shawnanastasio 2f7c3bf - hdl.rec: preserve shapes when constructing a layout.
<_whitenotifier-f> [nmigen] whitequark closed issue #393: Signal decoder inference for Enums doesn't work for Layout members - https://git.io/JfKgr
<_whitenotifier-f> [nmigen] whitequark closed pull request #394: hdl.rec: don't save casted shapes in Layout constructor - https://git.io/Jf6IM
<_whitenotifier-f> [nmigen] whitequark commented on pull request #394: hdl.rec: don't save casted shapes in Layout constructor - https://git.io/JfXjS
jeanthom has joined #nmigen
Asu has joined #nmigen
chipmuenk has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Read error: Connection reset by peer]
chipmuenk has quit [Quit: chipmuenk]
chipmuenk has joined #nmigen
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
* Sarayan waves
<whitequark> hi
<Sarayan> introspection interface?
<whitequark> yeah
<whitequark> also lets people drive stuff from C
<Sarayan> no bussing when you have Signal(8) ?
<Sarayan> of course some insane person could have a Signal(8) hald comb half sync
<whitequark> bussing?
<Sarayan> Well, accessing a Signal(8) a a uint8_t
<Sarayan> as a
<Sarayan> or wider, of course
<whitequark> you access anything 32 bits or under through uint32_t
<whitequark> 64 bits through uint32_t[2]
<Sarayan> Oh, it's depth that's 1, not width, sorry
<Sarayan> misread
<Sarayan> Signals >32 are stored lsb-first I guess? It's not said anywhere
<whitequark> uh, yeah, good point actually
<Sarayan> The \ prefix is coming from yosys, right?
<whitequark> yes
<Sarayan> and $ for generated stuff?
<whitequark> normally you won't see any $
<Sarayan> hmmm
<whitequark> right now there debug info generation code skips all $names
<whitequark> but i keep my options open
<Sarayan> that's why you leave the \ in?
<whitequark> yeah
<whitequark> not entirely sure yet if that's the right choice
<Sarayan> there are arguments both ways
<Sarayan> will you provide a c++ enum interface with std::function and no data
<Sarayan> ?
<whitequark> enum?
<Sarayan> cxxrtl_enum
<whitequark> nop
<whitequark> just use the debug info directly from c++
<Sarayan> I just find the static method trampolines annoying, but heh
<whitequark> do not use the c api from c++
<whitequark> thats stupid
<whitequark> use the c++ api from c++
<Sarayan> there's a c++ introspection api?
<whitequark> oh
<whitequark> sorry, i totally forgot that i never pushed it anywhere
<Sarayan> mwahahahaha
<Sarayan> Shrodinger API
<Sarayan> there and not there at the same time
<Sarayan> hmmm, the C++ api seems to be missing a thing or two
<whitequark> like what?
<Sarayan> like I want to lookup an item at startup for fast access during the sim, how do I do that?
<whitequark> you call `debug_info` once, it builds a map for you, you look up in that map
<whitequark> the references are valid for the lifetime of the design
peepsalot has quit [Ping timeout: 272 seconds]
<Sarayan> ok
Asuu has quit [Quit: Konversation terminated!]
<Sarayan> so design.debug_info(items); clk = items["i_clk"].data; and use *clk ?
<whitequark> correct
<Sarayan> ok, simple enough
<whitequark> yep, simple is what i'm aiming for
<whitequark> c++ has more than enough bullshit for me to add more
<Sarayan> and I can get memories, I can recurse, I can enumerate if I'm not sure of a name
<Sarayan> That's going to make my life significantly nicer
<Sarayan> I really like it
<whitequark> :)
<Sarayan> up to now I had to push up internal signals into the main module interface to be able to look at them
<Sarayan> that was not pleasant
<whitequark> wait
<Sarayan> I'm sure it was possible to find them somewhere
<Sarayan> I just had no clue how
<whitequark> the debug interface doesn't make it any easier
<Sarayan> and the names were "interesting"
<whitequark> instead of items["\\submod \\i_clk"] you can always use top.p_submod.p_i__clk
<Sarayan> even after flatten?
<whitequark> ohh
<whitequark> ok so the flattening is a bit tricky
<Sarayan> I mean at the start of cxxrtl flatten was required
<whitequark> let me rebase that branch so you can actually use non-flattened names
<whitequark> yes
<whitequark> you still want it for performance
<whitequark> hang on
* Sarayan goes grab a coke :-)
<whitequark> okay, rebased, *now* you can use original names even in flattened designs
<Sarayan> neat
<Sarayan> finding the correct variable name in flattened designs was a little too much :-)
<whitequark> yeah, that's fair, I momentarily forgot about that
<Sarayan> one can't think of everything
Asu has joined #nmigen
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 246 seconds]
chipmuenk1 is now known as chipmuenk
peepsalot has joined #nmigen
futarisIRCcloud has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Read error: Connection reset by peer]
jeanthom has quit [Ping timeout: 272 seconds]
Asuu has quit [Remote host closed the connection]
Asu has joined #nmigen
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
<agg> i'm rebuilding an old design with new nmigen and getting "nmigen.hdl.cd.DomainError: Signal (rst io) refers to reset of reset-less domain 'io'", but the traceback is all nmigen internals from build(), so I can't figure out where the errant signal is actually coming from
<agg> is there any way to work out what module that signal is being defined in or anything like that?
<agg> a binary search of deleting things suggests it might be to do with asyncfifo, hmm
<Lofty> Can you paste the backtrace?
<agg> further deletions suggest one AsyncFIFO is causing the problem and a second AsyncFIFO with the clock domains the other way around is fine, even though both domains in question are reset_less, hmmm
<agg> i know asyncfifo had a few changes since this last build (e.g. i was using din and dout and readable and we and re signals, which are now r_data/r_rdy/etc)
<agg> but afaict AsyncFIFO uses w_rst=ResetSignal(...., allow_reset_less=True)
<agg> hmm, I think what's happening is: I have a domain "x" which is reset_less, I have a module Foo containing AsyncFIFO(w_domain="y"), and I do DomainRenamer({"y": "x"})(Foo()) in my top level
<agg> and somehow y getting renamed to x is causing the asyncfifo to still want an actual reset signal?
<agg> the other AsyncFIFO has w_domain=sync which is also reset_less but doesn't get renamed
<agg> so maybe ResetSignal(allow_reset_less=True) breaks with domains which aren't defined at all but are later renamed to reset_less signals?
<_whitenotifier-f> [nmigen] adamgreig opened issue #400: ResetSignal's allow_reset_less fails on renamed reset_less domains - https://git.io/Jf1zx
<_whitenotifier-f> [nmigen] adamgreig opened pull request #401: Preserve allow_reset_less when remapping ResetSignal. Closes #400 - https://git.io/Jf1g4
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
jay_ has joined #nmigen
jay_ has quit [Remote host closed the connection]
SpaceCoaster has quit [Ping timeout: 272 seconds]
<_whitenotifier-f> [nmigen] codecov[bot] commented on pull request #401: Preserve allow_reset_less when remapping ResetSignal. Closes #400 - https://git.io/Jf1gp
<_whitenotifier-f> [nmigen] codecov[bot] edited a comment on pull request #401: Preserve allow_reset_less when remapping ResetSignal. Closes #400 - https://git.io/Jf1gp
chipmuenk has quit [Ping timeout: 246 seconds]
futarisIRCcloud has joined #nmigen
jeanthom has joined #nmigen
chipmuenk has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
<agg> just checking i understand AsyncFIFO's fwft behaviour properly: after a single write, I expect to see valid r_data and r_rdy==1, and if I then blip r_en, r_rdy becomes 0 and r_data is no longer valid?
<agg> so essentially r_rdy is more like "r_data valid" and r_en is like "acknowledge that i've seen the current data, go to the next entry if available"
<agg> or in other words, r_data always shows me what's currently in the top of the queue, and r_rdy shows if the queue contains anything (in other words, if r_data is valid)
chipmuenk has quit [Ping timeout: 246 seconds]
chipmuenk has joined #nmigen
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
FFY00 has quit [Remote host closed the connection]
lkcl_ has quit [Ping timeout: 256 seconds]
chipmuenk has quit [Quit: chipmuenk]
lkcl_ has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Ping timeout: 272 seconds]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 246 seconds]
jeanthom has joined #nmigen
FFY00 has joined #nmigen
Asuu has quit [Remote host closed the connection]
jeanthom has quit [Ping timeout: 260 seconds]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 246 seconds]
FFY00 has quit [Remote host closed the connection]
jeanthom has joined #nmigen
FFY00 has joined #nmigen
jeanthom has quit [Remote host closed the connection]
jeanthom has joined #nmigen
<tpw_rules> agg: yes
<tpw_rules> then r_en acknowledges the top of the queue and the next entry is available on r_data the next cycle (if any)
jeanthom has quit [Ping timeout: 246 seconds]