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
Vinalon has quit [Ping timeout: 256 seconds]
Vinalon has joined #nmigen
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
Vinalon has quit [Remote host closed the connection]
Vinalon has joined #nmigen
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<_whitenotifier-9> [nmigen] ewenmcneill commented on issue #362: `convert(ports=)` is a hotspot of beginner issues - https://git.io/JfIOy
<TD-Linux> Sarayan, btw if you do decide to implement a 68040 I have another application for it (x68000 accelerator). I've already built the hardware...
<tpw_rules> i remember this being asked but i don't remember the answer: nmigen statements execute in program order, right? m.d.sync += x.eq(1) and then later m.d.sync += x.eq(2) results in x = 2?
<awygle> Yeah
<ktemkin> pretty much, yeah
<ktemkin> I think about it as: every time a python .eq() executes, it updates the netlist that decides the next value of a given signal (non-comb) or the value of a given signal (comb)
<_whitenotifier-9> [nmigen] hofstee commented on issue #185: ASIC support tracking issue - https://git.io/JfIZq
<ktemkin> if you're not in a special block (like a "with m.If"), it more or less just replaces that logic, like you have there (the const `2` replacing the const `1`)
<ktemkin> if you're in a special block (e.g. m.If), the way the netlist is updated changes to "match the block's behavior"
<ktemkin> https://gist.github.com/ktemkin/a070b9ec8cc9cdb85e5cbf18638dac87 <-- in this case, the .eq() inside the m.If() changes the netlist by adding a mux that selects between the existing next-`x` logic, and the newly assigned next-`x` logic based on the value of `a`
<ktemkin> so you'd wind up with logic that says "the next state of `x` is `0` if `a` is false, or `1` if `a` is true" in your netlist
<ktemkin> this all essentially boils down to the behavior that you're describing
<ktemkin> </probably-too-much-info>
<_whitenotifier-9> [nmigen] hofstee opened pull request #365: remove non-verilog code at start of output - https://git.io/JfIZn
<_whitenotifier-9> [nmigen] codecov[bot] commented on pull request #365: remove non-verilog code at start of output - https://git.io/JfIZw
<_whitenotifier-9> [nmigen] codecov[bot] edited a comment on pull request #365: remove non-verilog code at start of output - https://git.io/JfIZw
<_whitenotifier-9> [nmigen] codecov[bot] edited a comment on pull request #365: remove non-verilog code at start of output - https://git.io/JfIZw
<_whitenotifier-9> [nmigen] codecov[bot] edited a comment on pull request #365: remove non-verilog code at start of output - https://git.io/JfIZw
<tpw_rules> ok yeah that's what i was asking but was too lazy to explain properly
<tpw_rules> thank you for the additional information
____ has joined #nmigen
pinknok has joined #nmigen
chipmuenk has joined #nmigen
pinknok has quit [Ping timeout: 272 seconds]
futarisIRCcloud has joined #nmigen
pinknok has joined #nmigen
pinknok has quit [Ping timeout: 265 seconds]
thinknok has joined #nmigen
Asu has joined #nmigen
lkcl has quit [Ping timeout: 250 seconds]
Vinalon has quit [Ping timeout: 260 seconds]
thinknok has quit [Ping timeout: 272 seconds]
lkcl has joined #nmigen
proteus-guy has quit [Ping timeout: 265 seconds]
proteus-guy has joined #nmigen
lkcl has quit [Ping timeout: 265 seconds]
lkcl has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
rohitksingh has quit [Quit: No Ping reply in 180 seconds.]
rohitksingh has joined #nmigen
thinknok has joined #nmigen
<vup> would it be possible to emit warning if you forget to add a statement to a clock domain?
<vup> or is there any reason why Statements shouldn't be a subclass of MustUse?
<vup> this looks like it is already built for that: https://github.com/nmigen/nmigen/blob/master/nmigen/hdl/ir.py#L123
thinknok has quit [Remote host closed the connection]
<whitequark> vup: right now it's set up so that only formal statements result in the warning
<whitequark> see afece150016ec928b30c569515a321f65f81155b
<vup> I see
<anuejn> would you accept a pr that tries to deal with that?
chipmuenk has joined #nmigen
<whitequark> anuejn: do you expect you'll be able to implement it in a reasonable way? I tried and couldn't
<anuejn> i havent looked into it but i will try :)
<whitequark> this is unlikely to be implementable in a nice way while we still have AST transformers, so be aware that your PR is unlikely to be merge
<whitequark> *merged
<anuejn> whitequark: we could just silence the warning for all assignments coming from nmigen/hdl/*.py
<anuejn> or do you consider this to be to ugly
<whitequark> determined how?
<whitequark> AST transformers preserve src_lco
<whitequark> *src_loc
<anuejn> stmts = [signal.eq(Const(signal.reset, signal.width))"
<anuejn> i see something like "/site-packages/nmigen/hdl/xfrm.py:528: UnusedMustUse: (eq (sig write_id) (const 4'd0)) created but never used
<anuejn> oh sorry for bad paste
<whitequark> hm
<whitequark> that's a different one, from DomainLowerer
<ktemkin> I suspect there's a whole class of warnings like that one that'd be more cleanly implemented as e.g. linter plugins
Vinalon has joined #nmigen
<whitequark> MustUse is a bit different because it relies on the GC
<anuejn> so i have done something
<anuejn> rather ugly but it has no false positives for the test suite and my usecase ;)
<anuejn> whitequark: what do you think about that from a conceptual perspective?
<whitequark> sorry, not happening
<whitequark> there is nothing more permanent than a temporary hack; and therefore the only way to avoid having permanent hacks is to avoid adding temporary ones in first place.
<anuejn> ok right
cyberclown has joined #nmigen
<_whitenotifier-9> [nmigen] whitequark reviewed pull request #365 commit - https://git.io/JfI1v
<_whitenotifier-9> [nmigen] whitequark reviewed pull request #365 commit - https://git.io/JfI1f
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #nmigen
thinknok has joined #nmigen
<Vinalon> so I was thinking of making a PR with a board file for Lattice's "ICE40UP5K-B-EVN" breakout board, but I'm not sure how to set up Resource objects for its DIP switches.
<ZirconiumX> Vinalon: do the switches just set it to 1 or 0?
<Vinalon> the board has space for pull-up resistors, but they are not populated by default. So I think they might expect you to configure the pins as inputs with pull-ups
<Vinalon> otherwise it seems like the inputs would be floating when the switches are open. Is there a way to describe that with the 'Attrs' property or something?
<awygle> anybody have an extremely simple wishbone device core that i could use for simulation testing of a host core?
<Vinalon> oh, it looks like 'Attrs(PULLUP=1)' should work - sorry, I should've looked more closely at the existing board files
* awygle sighs, starts writing a wb timer core
____ has quit [Quit: Nettalk6 - www.ntalk.de]
<awygle> in nmigen, how do i communicate which of several attached Lattice chips should be programmed?
<whitequark> uh oh
<whitequark> i think the most palatable answer might be "run the programmer manually"
<awygle> uh oh
<awygle> :p
* awygle looks around to be sure he's unobserved, then casually unplugs one
<awygle> oh look at that problem solved >_>
<whitequark> i mean it's not really doing anything complex under the hood
<whitequark> the toolchain_program method is one subprocess.check_call
<whitequark> i've just never actually thought about what will happen if you have several identical boards
<whitequark> which is a bit embarrassing to admit, indeed
thinknok has quit [Ping timeout: 272 seconds]
<cr1901_modern> awygle might be having an ECP5 problem, but can e.g. iceprog even distinguish two identical boards (or different boards, same FTDI chip)?
<awygle> doubt it
<whitequark> they should have different serials iirc
<whitequark> not sure though
<daveshah> Yes,, it is possible to specify by serial number
<awygle> i think the serials are stored in the eeprom
<awygle> so if you don't have one you're SOL
<daveshah> Or bus and device index in the worst case
<daveshah> Or whatever the proper Linux USB terms are
<whitequark> they do have EEPROMs
<cr1901_modern> And how do you easily find that info out on non-Linux :P?
<daveshah> I think the icebreakers should have unique serials at least
<awygle> at least one of my attached boards does not have an EEPROM attached to the FTDI
<daveshah> It's probably in device manager somewhere?
* cr1901_modern will need to check later
<daveshah> It's definitely exposed to Windows somehow, I'm sure I've accessed it via C# years ago
<cr1901_modern> Oh I believe you, I just don't know how to do it. Therefore it must be difficult :P.
<awygle> whitequark: is there an easy way to run the codecov thing _once_, or is it inextricable from CI? also how hard would it be to set up for one of my own projects?
<whitequark> awygle: do you want to measure coverage in some way, or something else more specific?
<awygle> "measure coverage in some way" is a pretty good description of what i want
<awygle> i wrote a bunch of tests, i'm not sure if they're... "enough" tests.
<awygle> and i would like to outsource the work of figuring out what "enough" means to a robot
<whitequark> oh! moment
<whitequark> try something like $ python3 -m coverage run -m unittest discover
<ZirconiumX> I feel like I discussed "branch" coverage at one point
<whitequark> after installing coverage
<whitequark> then $ python3 -m coverage html
<whitequark> done
<awygle> sweet
<awygle> thanks
<awygle> how does this work given that the python is not exactly what is executing? or does the pysimness of it all mean it still works?
<whitequark> oh, you want to measure coverage of *gateware*
<whitequark> that won't work.
<awygle> ok, that's more or less what i figured lol
<whitequark> but not for the reason you expect
<whitequark> it does measure coverage of the generated code just fine
<whitequark> the problem is that it can't really map it back to your source
<whitequark> it *is* possible to do that, i've done this for pythonparser
<_whitenotifier-9> [nmigen] hofstee synchronize pull request #365: remove non-verilog code at start of output - https://git.io/JfIZn
chipmuenk has quit [Quit: chipmuenk]
<_whitenotifier-9> [nmigen] codecov[bot] edited a comment on pull request #365: remove non-verilog code at start of output - https://git.io/JfIZw
<_whitenotifier-9> [nmigen] whitequark synchronize pull request #365: remove non-verilog code at start of output - https://git.io/JfIZn
<_whitenotifier-9> [nmigen] codecov[bot] edited a comment on pull request #365: remove non-verilog code at start of output - https://git.io/JfIZw
<_whitenotifier-9> [nmigen] whitequark closed pull request #365: remove non-verilog code at start of output - https://git.io/JfIZn
<_whitenotifier-9> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JfIN9
<_whitenotifier-9> [nmigen/nmigen] hofstee ed0f508 - back.verilog: add workaround for evaluation Verific behavior.
<_whitenotifier-9> [nmigen] whitequark commented on pull request #365: remove non-verilog code at start of output - https://git.io/JfIN7
<awygle> whitequark: what's the difference between add_process and add_sync_process in pysim?
<whitequark> awygle: the latter aliases `yield` as `yield Tick(domain)`, no other difference
<whitequark> the reason those APIs exist is because I was going to improve pysim in a particular direction, which I have since started doubting
lkcl has quit [Ping timeout: 264 seconds]
Asu has quit [Quit: Konversation terminated!]
<awygle> ah
<vup> does anybody have recommendations for a backend to target to visualize nmigen module hierarchies, maybe something that supports busses? I tried netlistsvg, but the result isn't really readable: https://files.niemo.de/out.svg
<ZirconiumX> vup: nMigen's module hierarchy is in general a bit difficult to read
<ZirconiumX> This is due to nMigen considering two instantiations of the same Elaboratable different modules
<ZirconiumX> Because monkey-patching makes assuming modules are "pure" difficult
<vup> yeah, I know, for now I am fine with that
<tpw_rules> oh, that's why that happens. i was going to ask at some point because it seemed strange
<vup> as I want to draw the connections between modules, I actually want to see every instance separately
<awygle> i'm not aware of anything much better than netlistsvg
<whitequark> ZirconiumX: well, not exactly that, though you're close
<whitequark> it's mostly because of migen compatibility
lkcl has joined #nmigen
Vinalon has quit [Remote host closed the connection]