ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
<_whitenotifier-3> [nmigen/nmigen] whitequark pushed 2 commits to master [+1/-0/±6]
<_whitenotifier-3> [nmigen/nmigen] whitequark 9fb4a4f - _unused: extract must-use logic from
<_whitenotifier-3> [nmigen/nmigen] whitequark afece15 - hdl.ast: warn on unused property statements (Assert, Assume, etc).
<_whitenotifier-3> [nmigen] whitequark closed issue #303: Usability? Can we warn if a Statement is never assigned to a domain? -
<_whitenotifier-3> [nmigen] Success. 82.34% (+0.15%) compared to 687d3a3 -
<_whitenotifier-3> [nmigen] Success. 88.88% of diff hit (target 82.19%) -
<_whitenotifier-3> [nmigen] Success. 82.26% (+0.07%) compared to 687d3a3 -
<_whitenotifier-3> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-3> [nmigen/nmigen] whitequark 6fd7cba - hdl.dsl: don't allow inheriting from Module.
<_whitenotifier-3> [nmigen] whitequark closed issue #286: Misleading error when trying to use self.comb when inheriting from Module -
<_whitenotifier-3> [nmigen] Success. 82.34% (+0.08%) compared to afece15 -
<_whitenotifier-3> [nmigen] Success. 100% of diff hit (target 82.26%) -
<_whitenotifier-3> [nmigen] Success. 82.27% (+<.01%) compared to afece15 -
<_whitenotifier-3> [nmigen] whitequark commented on issue #302: nmigen generates invalid RTLIL with negative shifts -
<whitequark> anyone has opinions on whether signed shifts should be legal?
<whitequark> there's precedent for not having signed operations legal: div/mod
<awygle> Signed shifts bad.
<awygle> I can't construct even a hypothetical case where a negative shift is desirable
<whitequark> gotcha.
<_whitenotifier-3> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-3> [nmigen/nmigen] whitequark cce6b86 - build.plat: align pipeline with Fragment.prepare().
<_whitenotifier-3> [nmigen] whitequark closed issue #307: AssertionError not in -
<_whitenotifier-3> [nmigen] Success. 82.32% (+0.05%) compared to 6fd7cba -
<_whitenotifier-3> [nmigen] Failure. 50% of diff hit (target 82.27%) -
<_whitenotifier-3> [nmigen] Failure. 82.24% (+-0.03%) compared to 6fd7cba -
<_whitenotifier-3> [nmigen] Failure. 50.00% of diff hit (target 82.27%) -
<awygle> whitequark: so i want to have a constant value from which i select bits based on a signal (counter). what's the best way to do that? things i've tried - list of bits [0, 0, 0, 1], Const(0b0001)
<awygle> the second gives me a TypeError: Cannot index value with (sig counter)
<awygle> ah, bit_select it seems
<awygle> i was a bit surprised i couldn't slice it
<whitequark> yep
<whitequark> you can't slice with signals because the width of whatever [] returns must be constant
<whitequark> or it's not synthesizzable
<awygle> i see. and python expects you to be able to slice with a variable
<whitequark> yes, the arguments to [] are arbitrary expression
<whitequark> *expressions
<awygle> are submodules supposed to show up in the hierarchy in gtkwave?
<whitequark> yes
<awygle> hm. i suspected i was doing something wrong and that only adds more weight to the suspicion. i have top->top in gtkwave, instead of top->top->bus as i expected.
<whitequark> hm
<awygle> oh ok resolved, i wasn't passing a pin down the hierarchy correctly
_whitelogger has joined #nmigen
proteus-guy has joined #nmigen
_whitelogger has joined #nmigen
<Sarayan> signed shifts as in the vlue shifted is signed or the count is signed?
<Sarayan> because right shift of signed values with sign extension is rather useful
<Sarayan> whitequark, if I remove the clockdomain I'm getting AttributeError: 'k053252' object has no attribute 'sync'
<Sarayan> in:
<Sarayan> yield Tick(ccu.sync)
<Sarayan> File "", line 16, in stimulus_proc
<Sarayan> what should I yield to?
<whitequark> yield Tick()
<_whitenotifier-3> [nmigen] ZirconiumX commented on issue #302: nmigen generates invalid RTLIL with negative shifts -
<Sarayan> works perfectly, thanks
<_whitenotifier-3> [nmigen-boards] nicolas-robin opened issue #46: PR from m-labs/nmigen-boards not in nmigen/nmigen-boards -
<ZirconiumX> Sarayan: right hand side being signed, e.g. x << -3
<Sarayan> I've seen cases where it would have been useful in software. Doubt it's that useful in hardware though
<_whitenotifier-3> [nmigen/nmigen-boards] whitequark pushed 6 commits to master [+2/-0/±4]
<_whitenotifier-3> [nmigen/nmigen-boards] nicolas-robin 8841d22 - ice40_hx8k_b_evn: fix swapped RTS/CTS
<_whitenotifier-3> [nmigen/nmigen-boards] nicolas-robin 6c0f904 - ice40_hx8k_b_evn: fix swapped DTR/DSR
<_whitenotifier-3> [nmigen/nmigen-boards] nicolas-robin 4f21323 - blinky: replace deprecated Signal(max=...) (#42)
<_whitenotifier-3> [nmigen/nmigen-boards] ... and 3 more commits.
<_whitenotifier-3> [nmigen-boards] whitequark commented on issue #46: PR from m-labs/nmigen-boards not in nmigen/nmigen-boards -
<_whitenotifier-3> [nmigen-boards] whitequark closed issue #46: PR from m-labs/nmigen-boards not in nmigen/nmigen-boards -
<_whitenotifier-3> [nmigen] whitequark commented on issue #302: nmigen generates invalid RTLIL with negative shifts -
<Sarayan> Is there an example somewhere I can use on how to go from a nmigen .py a yosis-generated C++ simulation code while not targetting any specific fpga/environment?
<whitequark> Sarayan: unfortunately not yet, cxxsim is basically alpha code
<Sarayan> I want C++ for a bunch of reasons (speed, video rendering, interfacing with mame, etc)
<whitequark> yeah, makes sense
<Sarayan> so do you recommend I try with yosys alpha code, of that I add some kind of C++ target to nmigen?
<whitequark> former
<whitequark> hmmm
<whitequark> let me try to help you here
<Sarayan> I'd like to start with the k053252, since it's working and simple and easy to see if the result is correct
<whitequark> yes. is your module done?
<Sarayan> yeah
<Sarayan> small and sweet :-)
<whitequark> okay, can you post it + explain how you'd like to connect it to mame or w/e?
<whitequark> then I'll make you an example and hopefully you could follow along on your own with the rest
<Sarayan> For a start I'd like to be able to run tick() and get the o_* signals, possibly even change the i_ ones
<Sarayan> from a dedicated C++ program
<Sarayan> in fact, if I have that I'm good
<Sarayan> oh, forgot to push the removal of sync. one sec
<whitequark> alrighty, that's not too hard
<Sarayan> pushed
<Sarayan> Yeah, I suspect it's not hard at all, but it's.. obscure
<whitequark> idneed it is
<Sarayan> if you run tick() you get the video signals for the overdrive (it's an arcade game) screen configuration, so you can see the outputs moving without having to do any particular protocol
<Sarayan> I'm not even entirely sure the inputs work, I haven't tested them :-)
<whitequark> okay, let me build yosys first
<Sarayan> I'm currently pulling, should I hit your tree instead?
<whitequark> yes
<Sarayan> ok
<whitequark> write_cxxrtl branch
<Sarayan> compiled and installed, wee
<Sarayan> Yosys 0.9+1706 (git sha1 4ef8c4b3, gcc 9.2.0 -fPIC -Os)
<whitequark> Sarayan: hm, o_db is always ff
<whitequark> can you tell me what to probe?
<whitequark> oh nvm it works
<whitequark> generates nvsy nhsy
<Sarayan> sy/bk yes
<Sarayan> also, o_db is not supposed to be 0xff when you read address e or f
<Sarayan> 0-d are write-only
<whitequark> ah
<Sarayan> h* cycles every 384 cycles, v* every 384*264
<whitequark> ok, so i get almost exactly 5 MIPS
<whitequark> but on every cycle it does fpritnf(stdout, "...")
<whitequark> without the printf, and in the most unsafe simulation mode, i get 32 MIPS
<whitequark> or rather MCPS
<whitequark> 8 MCPS in the most safe simulation mode
<whitequark> (any sane nmigen design will run in the "most unsafe, fastest mode")
<Sarayan> nice, the clock is 6MHz
<Sarayan> was doing 6KCPS, roughly
<whitequark> super dirty but:
<Sarayan> looks like it has an appropriate level of complexity
<Sarayan> and it works, thanks a lot
<whitequark> :D excellent
<Sarayan> that means that even once I've added the half dozen missing circuits I should be able to generate one screen in a small amount of time
<Sarayan> Phil B. has a screen dump done with a logic analyzer, there's no better comparison possible :-)
<whitequark> sweet!!
<whitequark> let me know how it goes
<Sarayan> I shall :-)
<Sarayan> I suspect it's not really doable on a fpga because the game has 11M of roms on something like 8 or 9 buses, all accessed in parallel, on a 6 or 12 MHz clock. 11M is too much to be inside the fpga, and that's a lot of bandwidth for random access on an external ram
<Sarayan> mister manages 150MHz max with its external sdram board
<Sarayan> (aka de-10)
<whitequark> roms?
<whitequark> then just use a nor flash
<whitequark> wait
<whitequark> *eight buses at the same time*?!
<Sarayan> well, it's not really buses
<Sarayan> but for instance the first 68k has its dedicated program rom, the second has its, the two roz chips each have one, the two line chips each have one, the sound cpu has one, the sound chip has one
<Sarayan> and they can obviously all being read at the same time
<Sarayan> because they're not connected to each other in the first place, only to the chips that use them
<Sarayan> so even with a 12MHz clock, that's a lot of accesses
<Sarayan> for your curiosity
<Sarayan> the '252 is on page 10, top middle
<Sarayan> 51316 = roz chip, 53250 = line chip, 53246/53247 = sprites. 53251 = mixer (selects for each pixel who wins)
<Sarayan> these are those I hope to recreate
<Sarayan> using the ram/register state from mame
<Sarayan> to see what it looks like
<whitequark> right
<whitequark> hmmm
<whitequark> could you use for example 8 QSPI flashes?
<Sarayan> you don't need to find an answer :-)
<whitequark> alrighty
<Sarayan> that's a lot of i/os, isn't it
<Sarayan> I didn't intend to nerd-snipe you
<whitequark> that's just 32 pins
<Sarayan> ah yeah spi
<whitequark> less if you time multiplex them by running your thing at 48 MHz
<whitequark> like a barrel processor
<whitequark> it's obnoxious but doable
<Sarayan> the'yre wide, goes from 8 to.. I think the max is 16 on that one wide
<Sarayan> gx is 32 wide for the tiles, iirc 64 for the sprites
<whitequark> so... DDR QSPI gives you 1 byte/cycle
<whitequark> with SPI clock being 4x your system clock it's barely doable
<whitequark> i do not want to be the one to make that work
<Sarayan> huhuhu
<Sarayan> neither am I :-)
<Sarayan> good thing nobody has to make it work
<Sarayan> cleaned things up a bit (makefile, etc) and push
<Sarayan> with that, I can do whatever I want :-)
_whitelogger has joined #nmigen
<_whitenotifier-3> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±4]
<_whitenotifier-3> [nmigen/nmigen] whitequark 49758a3 - hdl.ast: prohibit shifts by signed value.
<_whitenotifier-3> [nmigen] whitequark closed issue #302: nmigen generates invalid RTLIL with negative shifts -
<ZirconiumX> whitequark: since you mentioned `yield Tick()`, I was going back through some old(er) code which used `yield`. Should there be a DeprecationWarning lint for it?
<_whitenotifier-3> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-3> [nmigen/nmigen] whitequark a295e35 - hdl.ast: update documentation for Signal.
<_whitenotifier-3> [nmigen] whitequark closed issue #288: Signal.__doc__: Mention `range`'s `Shape.cast`able Variant -
<whitequark> ZirconiumX: no
<whitequark> that entire interface likely needs to be replaced with something different
<ZirconiumX> Mm, I see
<_whitenotifier-3> [nmigen] Success. 82.26% (+0.02%) compared to cce6b86 -
<_whitenotifier-3> [nmigen] Success. 91.66% of diff hit (target 82.24%) -
<_whitenotifier-3> [nmigen] Success. Absolute coverage decreased by -0.05% but relative coverage increased by +9.42% compared to cce6b86 -
<_whitenotifier-3> [nmigen] Success. 82.26% (+0.07%) compared to 49758a3 -
<_whitenotifier-3> [nmigen] Success. Coverage not affected when comparing 49758a3...a295e35 -
<_whitenotifier-3> [nmigen] Success. 82.18% remains the same compared to 49758a3 -