ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting August 17th
<lkcl> oleee! fixed the implementation of POWER9 "cmp" instruction. litex memtest works - just about to test on an ecp5 FPGA...
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #nmigen
emeb has quit [Read error: Connection reset by peer]
lkcl_ has joined #nmigen
lkcl has quit [Ping timeout: 240 seconds]
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
<happycube> re prjbureau: nice. cheap, 5v, and hopefully microchip'll keep it around for a while ;)
<whitequark> that's exactly the idea
<awygle> the big one has split rails right?
<awygle> so you can use it for level shifting applications?
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #nmigen
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel_ has joined #nmigen
<whitequark> awygle: not officially
<whitequark> and i think it doesn't actually have those
<whitequark> unfortunately
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter_ is now known as PyroPeter
<awygle> Mmmm bummer
<whitequark> there's the ATF15xxBE variant, which does advertise two IO banks
<whitequark> except... it hasn't been manufactured for a long time
<awygle> I see
<_whitenotifier-3> [nmigen-boards] whitequark synchronize pull request #101: Added Arty S7 support -
<_whitenotifier-3> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+1/-0/±0]
<_whitenotifier-3> [nmigen/nmigen-boards] Fatsie d20fb96 - Added Arty S7 support
<_whitenotifier-3> [nmigen-boards] whitequark closed pull request #101: Added Arty S7 support -
<_whitenotifier-3> [nmigen-boards] whitequark commented on pull request #101: Added Arty S7 support -
electronic_eel_ is now known as electronic_eel
emeb_mac has quit [Quit: Leaving.]
Asu has joined #nmigen
proteus-guy has joined #nmigen
hitomi2507 has joined #nmigen
<_whitenotifier-3> [nmigen] pepijndevos opened issue #478: Support division of negative numbers? -
<_whitenotifier-3> [nmigen] whitequark commented on issue #478: Support division of negative numbers? -
<_whitenotifier-3> [nmigen] pepijndevos commented on issue #478: Support division of negative numbers? -
<_whitenotifier-3> [nmigen] whitequark commented on issue #478: Support division of negative numbers? -
proteus-guy has quit [Ping timeout: 240 seconds]
proteusguy has quit [Ping timeout: 256 seconds]
<_whitenotifier-3> [nmigen] pepijndevos commented on issue #478: Support division of negative numbers? -
proteusguy has joined #nmigen
proteusguy has quit [Ping timeout: 265 seconds]
ianloic has quit [Read error: Connection reset by peer]
sorear has quit [Ping timeout: 244 seconds]
_florent_ has quit [Read error: Connection reset by peer]
_florent_ has joined #nmigen
ianloic has joined #nmigen
<_whitenotifier-3> [nmigen] whitequark reviewed pull request #461 commit -
sorear has joined #nmigen
proteusguy has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Ping timeout: 260 seconds]
<_whitenotifier-3> [nmigen] whitequark reviewed pull request #461 commit -
DaKnig has quit [Ping timeout: 265 seconds]
DaKnig has joined #nmigen
Asuu has quit [Ping timeout: 256 seconds]
Asu has joined #nmigen
<lkcl_> does anyone have - or know of - any examples of using nmigen-soc wishbone arbiter to reduce 64-bit bus requests down to 32 bit?
<lkcl_> i'm running into difficulties with litex 64-bit to 32-bit bus arbitration and wanted to eliminate litex as the potential source of a bug
<DaKnig> how can I get NaN in python as a float?
<DaKnig> ah right, the old `float("nan")`
<lkcl_> DaKnig: interesting question! i constructed it and used sfpy (python bindings to softfloat-3). there has to be a simpler way
<lkcl_> ah. import math, then "math.nan"
<lkcl_> float ("nan") only works in python 3.5 and below
<lkcl_> DaKnig: which version of python are you using?
<lkcl_> the reason i ask is because nmigen only works with python 3.6, and according to that stackoverflow report, float("nan") was deprecated after 3.5
<DaKnig> wdym python 3.5 and below
<DaKnig> I use python 3.6
<lkcl_> python3.6 and above
<lkcl_> then according to that stackoverflow, float("nan") should not work
<lkcl_> it says to use math.nan
<lkcl_> Python 3.7.2 (default, Jan 3 2019, 02:55:40)
<lkcl_> >>> float("nan")
<lkcl_> nan
<DaKnig> see? works just fine
<lkcl_> well that worked :)
<DaKnig> same for infinity
<DaKnig> float("inf")
* lkcl_ sigh gotta love incorrect stackoverflow answers...
<miek> it's not incorrect..
<miek> it's saying that math.nan was new in 3.5, before that you could use float("nan") instead
<lkcl_> ah note this though:
<lkcl_> miek: ah yes i see that now, thank you
<lkcl_> hmm interestingly we can't use this capability in the nmigen-based ieee754fpu library, because python nan/inf still relies on the underlying processor definition of ieee754.
* lkcl_ tracked down nmigen_soc wishbone InterconnectShared.
<lkcl_> i *think* i can do what i need with that. create a 32-bit wishbone.Interface record and add it as the output...
<DaKnig> > implying there's only one type of NaN :)
<lkcl_> DaKnig: yes. signalling NaNs and quiet NaNs
<lkcl_> and don't get me started on the differences between x86, PowerISA, ARM and RISC-V
<lkcl_> urrr....
<lkcl_> jon dawson's verilog ieee754 fp implementation, the unit tests use a c library.
<lkcl_> so of course, when you compile the unit tests on an ARM machine or a POWER9 machine, you get *different test answers*
<lkcl_> we're trying to develop a nmigen-based POWER9-compliant IEEE754, doing the development predominantly on x86 hardware.
<lkcl_> wark-wark :)
<DaKnig> you can test that on your phone using ARM :) Im sure if somebody was able to run this on the rpi0 then running it in termux is not out of the question
<DaKnig> modern smartphones' processors are pretty fast (ofc not as fast as your PC) expecially if you can use all the cores
<lkcl_> the point is that if we try to rely on the ARM definition of IEEE754FP by calling an ARM FP instruction to produce the result of a calculation
<lkcl_> it's going to produce a *different answer* than if we called an x86 FP instruction
<lkcl_> and in some cases, the instruction might not exist at all (IEEE754 FP16 for example)
Asu has quit [Read error: Connection reset by peer]
<lkcl_> or... some hardware might have FP80, some might have FP128.
<DaKnig> I got that, but you can compare that to both x86 and ARM to get uh a better idea about if it works well or not
<lkcl_> ah that's the point: we have to be absolutely dead-accurate to POWER9, under all circumstances: we already know it'll be incompatible
<lkcl_> POWER9 has extra rounding modes for example that x86 doesn't have
<DaKnig> ah. I see. do you have a POWER9 machine?
<lkcl_> sponsored access to a TALOS-II workstation, thanks to Raptor Engineering, yes
* lkcl_ whew
<DaKnig> very cool!
<lkcl_> so - believe it or not - we actually have to write an ieee754 software-emulation library
Asu has joined #nmigen
<lkcl_> running its unit tests on POWER9 first, to check that they're compatible in all possible combinations / modes
<lkcl_> *then* run the same tests against the nmigen HDL
<lkcl_> urrr... :)
<lkcl_> i'm mentioning this as a cautionary tale if you are planning to use python's "nan" as a "verification" of a nmigen-based HDL implementation of FP :)
<lkcl_> or... anything like that
<DaKnig> thanks for that; I hope I wont have to deal with implementing 754 accurately
<lkcl_> lol consider yourself lucky :)
<DaKnig> Im having enough trouble with HDMI and htat is not even supposed to be hard :(
<lkcl_> mmm didn't enjoydigital do something called litehdmi?
<DaKnig> I have to make my own though
<lkcl_> ah i was thinking of something to look at, comparatively
<lkcl_> if you know what i mean?
<lkcl_> hdmi2usb - i think it's by mithro
<DaKnig> this is not HDMI
<DaKnig> that's TMDS
<DaKnig> most implementations I found online were for TMDS
<DaKnig> although HDMI should be back comp with that, my monitor doesnt like straight TMDS
<lkcl_> ahh interesting
<DaKnig> in HDMI you have to send packets, ask the screen what res it accepts, check the polarity of the sync signals...
<lkcl_> yes i was just tracking that
<DaKnig> what else
<DaKnig> have to make preamble, guard bands
<lkcl_> yyeah
<lkcl_> ok so there's a protocol "on top of" TMDS?
<DaKnig> more like 10 protocols on top of TMDS
<lkcl_> dang
<DaKnig> all called HDMI together
<DaKnig> well that's not true
<DaKnig> TMDS itself is many protocols together
<DaKnig> o wait I messed up; HDMI is back comp with DVI/D, is what I meant.
<DaKnig> its internal encoding is called TMDS
<lkcl_> it sounds very much like the story "hello i want a samba", where people have no idea that samba is about 25 different services over *seven* separate networking protocols
<DaKnig> TMDS has many protocols inside it, and HDMI adds a few more
<lkcl_> is this how you can do things like get ethernet-over-hdmi, and USB3-over-hdmi?
<DaKnig> I have no idea
<DaKnig> but when you add scary words like USB to HDMI it makes me feel uncomfortable
<lkcl_> :)
<DaKnig> ;-)
<DaKnig> basically DVI-D maps parallel 8-bit VGA signals to serial 10-bit that are then transmitted at 10x the speed. when data transfer is active, you encode the pixels in one scheme, when its not active, there's another scheme for encoding the [vh]sync signals
<DaKnig> that's not that hard; just a LUT plus a tiny bit of logic (or what they did here, actually implementing this in pure logic)
<DaKnig> then comes HDMI- you start by asking the screen what modes it supports, place your bets on one of them (because screens lie), add some guard bands and preambles before and after the active video data; but then you have to send data packets (audio and such) encoded in TERC4 which is now the 4th protocol I mentioned so far
<lkcl_> jaezz
<lkcl_> does the monitor you have support DVI-D?
<DaKnig> not as complex as floats in 754 :)
<DaKnig> nope; my monitor doesnt support DVI-D
<lkcl_> urr that's a pity. it sounds like a simpler first target
<DaKnig> I learned that the hard way, tinkering with my code and seeing that it doesnt work
<lkcl_> from what i understand, it's still possible to do EDID though with DVI-D, right? or... that's over the I2C interface that's not actually part of the hi-speed Tx/Rx but is part of the 19 pins
<lkcl_> something like that?
<DaKnig> I am not sure actually; Im just assuming a constant resolution that most monitors support
<DaKnig> 800x600
<DaKnig> at 8bit per channel
<_whitenotifier-3> [nmigen-soc] jfng opened pull request #25: periph: add a ConstantMap container for configuration constants. -
<DaKnig> the what the heck? I can not import nmigen..?
<DaKnig> NameError: name 'nmigen' is not defined
<DaKnig> I get this error when nmigen tries to compile my design
<DaKnig> not on the line where I import it
<DaKnig> ah oops. nvm me.
emeb has joined #nmigen
<awygle> oo, intersting paper wq
a72 has joined #nmigen
a72 has quit [Remote host closed the connection]
emeb has quit [Ping timeout: 260 seconds]
emeb has joined #nmigen
emeb has quit [Ping timeout: 240 seconds]
emeb has joined #nmigen
<pepijndevos> how does an IRC meeting work?
<awygle> we show up, wq has an agenda usually, and we talk about various issues and design questions.the idea is to do a kind of tick/tock between design and implementation. this week would be on the implementation side but i suspect since wq was out last week we'll do design instead. if you have something you want the team to discuss, feel free to bring it up and it'll get put into the agenda.
<whitequark> i was out for two weeks, right?
<awygle> because of the async, talk-over-each-other nature of IRC (and because there's lots to talk about) things tend to run a bit long so far but hopefully we'll get in a groove
<awygle> were you? totally possible, i don't recall. time has no meaning.
<awygle> to clarify i know you were on vacation for 2 weeks but i don't remember if we skipped two meetings
<whitequark> ah hm
<whitequark> we had a meeting on 3rd so we skipped one
<pepijndevos> Yea wq mentioned discussing one of the bugs I found, which actually turned out to be not really a bug but more of a design question.
<awygle> yeah so that "meta:nominated" label is new for tagging issues to talk about at upcoming meetings
<pepijndevos> And uh... if the conclusion is "document it" fine, but if it leads to reconsidering array design, I have a larger problem in building abstractions on top of Array.
hitomi2507 has quit [Quit: Nettalk6 -]
<lkcl_> hi folks, am exhausted today. resting: will pop in to review / read, however apologies may need to drop out of conversations on short notice.
<awygle> i'm very busy this morning as well, trying to clear space for the meeting, we'll see how well that goes
<whitequark> sounds like it might make sense to postpone?
<awygle> i don't think i make that necessary, i should be able to participate in anything really critical
<whitequark> alright
jeanthom-mobile has joined #nmigen
<jeanthom-mobile> hi everyone
<whitequark> hi all
<whitequark> anyone has a strong preference either way?
<whitequark> right now we have:
<whitequark> - PulseSynchronizer (both i_domain and o_domain, no way around that)
<whitequark> - ResetSynchronizer (just domain; specifies the domain to be reset, of course)
<whitequark> - AsyncFFSynchronizer (just domain; this is basically the same functionally as ResetSynchronizer, but it doesn't specifically require you to use the synchronized signal as a reset)
<whitequark> - FFSynchronizer (just o_domain)
<awygle> i kind of like "just domain" but i can see the "o_domain" argument
<awygle> basically the Reset and AsyncFF synchronizers synchronizer from "no domain" (async) to "some domain"
<whitequark> the way we ended up here is by making FFSynchronizer consistent with PulseSynchronizer (both have i/o), and then AsyncFFSynchronizer with ResetSynchronizer
<awygle> whereas the PulseSynchronizer and FFSynchronizer synchronize from "one domain" to "another domain"
<whitequark> wait
<whitequark> FFSynchronizer *absolutely* can synchronize async signals
<whitequark> that's what you do with async inputs!
<awygle> yeah the analogy doesn't really work
<awygle> i'm just saying i think that's how it came to be
<whitequark> ahh yea
<awygle> actually i think i'm talking myself into o_domain
<whitequark> hrm
<whitequark> so, do you think o_domain is clearer?
<awygle> i think that's debatable but i think consistency is desirable, and as you say pulse synchronizer must have o_domain (and we have it in lots of other places too like AsyncFIFO)
<awygle> i don't think o_domain is _less_ clear, and i think it's more consistent
<awygle> the counterargument is breakage, esp. for ResetSynchronizer
<whitequark> right, and we already have the thing where SyncFIFO aliases level as r_level/w_level
<whitequark> hmmm
<whitequark> i actually think we don't necessarily need to change ResetSynchronizer
<whitequark> it's special
<whitequark> it can just... stay special
<awygle> i'm ok with that
<_whitenotifier-3> [nmigen] whitequark commented on issue #467: Inconsistency between a parameter name for AsyncFFSynchronizer and FFSynchronizer -
<whitequark> awygle: hm, you did a bit of nmigen issue triage in the past, right?
<whitequark> i think github has permissions for that specifically, so i think i can give you that
<whitequark> if you want, anyway
<awygle> sure
<awygle> i have the sysadmin's curse, i always want all the powers and forget that comes with responsibilities :P
<pepijndevos> lol
<ktemkin> I've gone past that into running the hell away from (or heavily disclaimer'ing) most things
<awygle> you are wiser than i
<whitequark> i think it's done. github is weird but whatever
<pepijndevos> hiiiiiii
<whitequark> in short: what is the shape of Array([Const(0xff, unsigned(8)), Const(0xff, signed(8))]) ?
<pepijndevos> For my understanding... how is the shape of an array used?
<whitequark> the current answer is signed(9) and it is mathematically correct, albeit possibly unintuitive
<whitequark> (well, not the shape of the array, but the shape of the array proxy)
<whitequark> >>> Array([Const(0xff, unsigned(8)), Const(0xff, signed(8))])[Signal(0)].shape()
<whitequark> signed(9)
<pepijndevos> The counterpoint is that currently just Array([Const(0xff, signed(8))]) is *also* signed(9) for no apparent reason
<whitequark> yes
<whitequark> I was about to mention that
<whitequark> *that* seems to be a clear bug
<whitequark> absolutely no reason for it
<whitequark> regarding the former case.
<whitequark> i'm certain of two things:
<whitequark> - first, any answer that makes Array([Const(0xff, unsigned(8)), Const(0xff, signed(8))])[Const(0)] return a negative number is wrong (and seriously backwards-incompatible too)
<whitequark> so, unsigned(8) is out
<whitequark> - second, any answer that makes Array([-1, 0, 1]) not work is user-hostile (and seriously backwards-incompatible, too)
<whitequark> so we can't raise an exception if you have heterogeneous elements in an array
<whitequark> do we have any other choices?
<pepijndevos> I would say that Array([-1, 0, 1]) is kinda homogeneous in intent, and I would not be surprised if all of these got cast to the largest type
<pepijndevos> Which is what probably ends up happening on usage
<pepijndevos> So I think for the mixed case the current behaviour is correct
<whitequark> well, ArrayProxy.shape() specifically casts to the largest type
<whitequark> so yes
lkcl__ has joined #nmigen
<whitequark> what do we want to change here, besides the case of arrays of purely-signed elements that currently spuriously extends?
<pepijndevos> I have one tangentially related suggestion...
<whitequark> the one you mentioned earlier?
emeb_mac has joined #nmigen
<pepijndevos> if all elements of an array have the same attribute, Array could just return that attribute rather than a proxy.
lkcl_ has quit [Ping timeout: 256 seconds]
<pepijndevos> But regarding this bug, I don't think anything else needs changing
<whitequark> you mean, a proxy could return that attribute rather than another proxy?
<pepijndevos> yea, and that extends to array as well. Say you have a homogeneous array and there is no special case for shape(), it would call shape on the entire array, find it's a fixed value and return that shape.
<whitequark> but... that's what already happens
<whitequark> max(n,n,n,n...)=n
<whitequark> (save for the bug re: signed-only contents)
<pepijndevos> yea, but now shape is a special case, I'm thinking if it's possible to generalise
<pepijndevos> My concrete issue is that my fixed point class specifies the fractional bits and it require tricky wrapping with a special array wrapper
<whitequark> i don't like your idea very much for one reason: what is "equality"?
<pepijndevos> Maybe a super specific problem I have abstracting over Values, but if the shape behaviour were generic to other attributes it would be useful to me hehe
<whitequark> i need something reflexive and transitive to be able to rely on it in ArrayProxy
<whitequark> but __eq__ doesn't have to be
<whitequark> in fact for floats it won't be
<pepijndevos> not sure I understand
<whitequark> well
<whitequark> wait, i think i understand what you want here, moment
<pepijndevos> (don't want to take too much time with my fringe problem, also ok with just fixing the signed shape problem and moving on)
<whitequark> no, i think it's reasonable to discuss
<pepijndevos> okay
<whitequark> your use case of building a HLS-y thing on top of nMigen is very much in scope, and I'd have nominated it myself if you weren't here
<pepijndevos> right
<whitequark> i don't think it's fringe either :p
<pepijndevos> This describes my problem a bit:
<pepijndevos> All my ideas and solutions so far are very fragile hehe (including the one I just suggested)
<_whitenotifier-3> [nmigen] whitequark opened issue #479: Add `proc -nomux` to Yosys and migrate to it -
<whitequark> pepijndevos: let me see what we can do
<whitequark> so, i see two solutions here, both of which you might find unsuitable
<whitequark> - make your Q (is that the name?) class ValueCastable. now you can just stuff it into Arrays
<whitequark> - make your own QArray/QArrayProxy without using Array, where QArrayProxy would be ValueCastable
<pepijndevos> For reference, my current solution:
<whitequark> the main drawbacks of them i see as:
<whitequark> - for first solution, well, you lose type safety benefits, since now Q can be misused anywhere a Value can go. pretty bad
<whitequark> - for second solution, implementing ArrayProxy through ValueCastable is inherently inefficient^W^W actually just not possible right now
<pepijndevos> What if Array had an overridable method that allows modifying the returned ArrayProxy?
<whitequark> modifying how?
<pepijndevos> More like wrapping
<whitequark> ... well
<whitequark> that... would certainly work
<pepijndevos> just spewing more ideas... not sure what the implications are
<pepijndevos> And if you *then* subclass ArrayProxy to have special cased methods for your custom type, you can feed that to Array and it'll return wrappers that look like your type
<whitequark> yeah, that's the classic OO solution: just add more inheritance
<pepijndevos> lol
<whitequark> my counter-proposal is to add more composition
<whitequark> the way i see the core of the problem is
<pepijndevos> composition is always good
<whitequark> there is a language *primitive* inside Array that's much smaller than Array itself. the primitive is basically "Mux() but it can be used on LHS"
<pepijndevos> hm
<pepijndevos> I see
<whitequark> you've seen Switch, right?
<pepijndevos> yea yea it makes sense go on
<whitequark> Switch works on statements. this hypothetical primitive would work on values.
<pepijndevos> So you're saying, expose the primitive and build your own array around it?
<whitequark> basically.
<pepijndevos> Sounds good
<whitequark> this is more of a medium term solution though
<whitequark> on one hand, it would be a really nice cleanup for some nmigen internals
<whitequark> there was also uh...
<pepijndevos> As long as I don't need to assign to my array I could actually just use Mux I guess
<_whitenotifier-3> [nmigen] whitequark commented on issue #73: Expand semantics of Array from MutableSequence to MutableMapping -
<_whitenotifier-3> [nmigen] whitequark reopened issue #73: Expand semantics of Array from MutableSequence to MutableMapping -
<whitequark> there was this issue:
<whitequark> if we had a multiplexer primitive, it would be super simple to build whatever containers and proxies we want on top of that, without touching the nMigen core
<awygle> that sounds quite nice to me, given how many questions we get about, like, Array.any()
<whitequark> ... do we?
<lkcl__> reading / following the discussion: one of the long-term things that we would like to do with libre-soc is to be able to use PartitionedSignal in exactly the same way as Signal is used right now
<whitequark> lists don't have .any() either
<whitequark> what is PartitionedSignal?
<lkcl__> including in Mux()
<lkcl__> it's a dynamic SIMD variant of Signal
<awygle> every time somebody asks about extending Array's semantics you say "why do people keep wanting to extend Array's semantics, list() doesn't have those semantics" lol. it's happened at least three times
<whitequark> awygle: point taken
<awygle> i do get your point ofc, but it does come up pretty often
<lkcl__> associated with every PartitionedSignal is a "mask / gate".
<lkcl__> we have __gt__, __lt__, __add__ etc. implemented (__div__ and more complex ones still TODO)
<lkcl__> however where it all goes pear-shaped is Mux(), and in m.If() and m.Switch()
<whitequark> do __gt__ etc just delegate to nmigen < etc directed to the right part of the signal?
<lkcl__> we had to implement it at the bit-level, i think
<lkcl__> 1 sec
<lkcl__> or it was compounded.
jaseg has quit [Ping timeout: 246 seconds]
<whitequark> i can't say i understand how it works
Sarayan has joined #nmigen
<lkcl__> the reason i bring it up is because we kinda have the same issue as pepijn
<pepijndevos> So... can I implement a read-only array with Switch?
<whitequark> pepijndevos: you can only put statements into Switch, unfortunately
<whitequark> you *can* implement a read-only array with Mux
<whitequark> at the cost of producing some really ugly verilog
<pepijndevos> Yea I looked at Mux and it's only two-way. If it were N-way that would be something heh
<awygle> (OT: i'm heading home for lunch, but i do have something i want to talk about, so please ping me when this discussion is wrapped assuming folks aren't too worn out)
<pepijndevos> Not sure what it means that I can only put statement into a switch
<lkcl__> there are partition points that, if they are entirely "open", PartitionedSignal behaves exactly like Signal
<whitequark> pepijndevos: basically, you can only put .eq() in a Switch
<whitequark> and a Switch doesn't have a value
jaseg has joined #nmigen
<whitequark> it's similar to the If/Elif/Else construct in Python
<pepijndevos> hm I see...
<lkcl__> if the ppts are "split in half", it behaves exactly like a pair of Signals of half the width, as if you had a for-loop (of size 2) around absolutely everything
<whitequark> pepijndevos: let me write an issue for the multiplexer feature
<whitequark> i think you have some really valuable insight here, thanks for raising it
<pepijndevos> more than welcome :)))
<whitequark> it fills a hole in the language i've been looking at with dissatisfaction for quite a while, and in a rather elegant way
<pepijndevos> It's getting a bit late here, so I'll leave you to the rest of your meeting
* lkcl__ is glad to see MutableMapping reopened
<whitequark> lkcl__: oh, I simply forgot to reopen it at 3rd. I did tell you that I'll reconsider it, that kinda takes priority over the GH issue status
<lkcl__> it means being able to express lookup tables in a one-liner
<lkcl__> oh! :)
<jeanthom-mobile> Can we have a look at #427 (Assert in simulations)?
<whitequark> yes. give me a moment to write down the issue we just discussed
<_whitenotifier-3> [nmigen] whitequark commented on issue #476: Possible bug in ArrayProxy for signed values -
<_whitenotifier-3> [nmigen] whitequark edited issue #476: ArrayProxy shape does not equal element shape for a homogeneous array of signed values -
<whitequark> ... two issues we just discussed
<jeanthom-mobile> Ok so I started implementing assert in #465
Asuu has joined #nmigen
<whitequark> yeah, please just go ahead discussing it
<whitequark> i'll join in a minute
<jeanthom-mobile> I'm not sure what behaviour we should have when it fails
<whitequark> ah yes
<whitequark> this is a bit complicated
<jeanthom-mobile> because throwing an exceptions breaks the VCD generation
<jeanthom-mobile> also we have to decide what we show to the user when an assertion fails
<awygle> (OT: back mostly)
<jeanthom-mobile> and how should we handle Assume statements?
<awygle> i agree with the previous resolution, nice job team
<awygle> position: violating assumptions should fail
Asu has quit [Ping timeout: 256 seconds]
<whitequark> i agree that violating assumptions should fail
<whitequark> Assert/Assume only differ in property testing
<jeanthom-mobile> ok
<whitequark> regarding failing asserts
<whitequark> we should definitely show the actual location of the assert in the source code (which is recorded just fine in src_loc)
<whitequark> can you append items to Python tracebacks yet?
<whitequark> like, without horrible ctypes hacks
<jeanthom-mobile> I have to check that
<daveshah> If you want to mirror Verilog, you could also have Restrict which is Assume but doesn't fail in sim
<whitequark> our property testing support is essentially all cribbed from SVA
<whitequark> intentionally; I think SVA is pretty nice
<whitequark> it's also really minimal at the moment, and i think i'd like to keep it that way for at least a bit of time
<whitequark> i'd rather have an incomplete API than a poorly thought out complete-looking API
<whitequark> that said Restrict doesn't seem like it would pose a hazard
<daveshah> The only problem is Yosys doesn't have $restrict
<daveshah> afaik the frontend turns restrict into $assume because it is written for FV
<awygle> yosys doesn't have restrict? weird, i swear i read about it first in a yosys formal blog post
<whitequark> it doesn't have a $restrict cell
<whitequark> which is different from the keyword
<awygle> right
<_whitenotifier-3> [nmigen] whitequark opened issue #480: Add a minimal value-addressable multiplexer primitive valid on LHS and RHS -
<_whitenotifier-3> [nmigen] whitequark edited issue #480: Add a minimal value-addressable multiplexer primitive valid on LHS and RHS -
<whitequark> done with issues, paying more attention now
<whitequark> ok, so there are two problems there
<whitequark> the first problem (the one we're discussing) is the python-side interface of Assert/Display/etc
<whitequark> (is it ok to have Display just print()? dunno... probably? people will likely want to redirect it pretty quickly)
<whitequark> i almost think that the reasonable way to handle this is to define some sort of event handler class
<jeanthom-mobile> that seems like a good idea
<whitequark> def on_Assert(self, stmt): [_tripped implied], def on_Display(self, stmt, string):, etc
<whitequark> for now, i suggest that this class be made internal
<whitequark> with the understanding that people can try using it, but no guarantees are made for now
<whitequark> if it turns out to work well, we'll make it a part of public API
<whitequark> the second problem is cxxrtl
<whitequark> the obvious way to translate a $assert cell in cxxrtl is, well, assert().
<whitequark> that should probably be... possible, actually
<whitequark> (same with $display)
<whitequark> but for embedding cxxrtl, that's a no-no, since it'll just crash the entire process, and everyone will be very sad
<awygle> throw new AssertException("o no")?
<whitequark> awygle: do you *really* want to compile the high-performance simulator core with exceptions?
<whitequark> or rather, make exceptions mandatory
<awygle> prolly not no
<whitequark> also, suppose you're fuzzing something
<whitequark> if you're reducing a testcase, you'll be tripping many thousands of assertions per second
<whitequark> this isn't software, where the deliverable isn't supposed to raise exceptions a lot
<jeanthom-mobile> btw how should pysim handle the assert failure event?
<whitequark> so the usual assumptions behind "zero-cost" EH don't apply
<jeanthom-mobile> should pysim raise an Exception? if so, which exception?
<awygle> hm, interesting point. not sure how different the percentage of taken exceptions is actually (assuming you're fuzzing or reducing in both cases0 but i'll take your word for it.
<whitequark> jeanthom-mobile: well, if you can modify the traceback, AssertionError is a natural choice
<awygle> raise(SIGINT) has the same problems, and also, it was a joke suggestion i was gonna make
<whitequark> jeanthom-mobile: apparently since 3.7 :/
<whitequark> i... guess we can make that specific part of nmigen require 3.7
<whitequark> but it's not super great
<whitequark> (so on 3.6 you'd get uglier tracebacks)
<awygle> is there a 3.6 polyfill we could do via Violence?
<whitequark> well, ... yes there is
<whitequark> i *guess* we *could* use that horrifying piece of code
<awygle> alternately we could base it on instead but i don't think that'd give us quite the desired semantics
<cr1901_modern> Was anyone besides me using Python 3.6?
* cr1901_modern isn't anymore
<whitequark> i don't think PEP3134 gives us anything
<whitequark> cr1901_modern: our MSPV is still 3.6
<awygle> yeah that's definitely a breaking change (fite me rust ecosystem)
<cr1901_modern> Right, and I seem to recall that one reason it's 3.6 is because I asked it to be back then
<awygle> eyyy violence wins again
<whitequark> jeanthom-mobile: so. i guess what we can do is use AssertionError and rewrite the traceback nicely (if we can) or with violence (if we're forced to)
<whitequark> oh yeah, VCD file
<jeanthom-mobile> whitequark, I'm not sure AssertionError would be an appropriate choice since that would mix assertions failures coming from Python code execution and assertion failures triggered by the gateware
<jeanthom-mobile> jfng suggested that, and I think he's right
<whitequark> suggested what?
<jeanthom-mobile> that using AssertionError for Assert() is bad a idea
<jeanthom-mobile> imagine you use both python asserts in your elaborate function and nmigen asserts
<whitequark> well... we already use Python SyntaxError for nMigen syntax errors (inconsistently)
<whitequark> sure
<whitequark> where would this actually cause problems?
jeanthom-notmobi has joined #nmigen
<_whitenotifier-3> [nmigen-soc] whitequark reviewed pull request #25 commit -
<jeanthom-notmobi> whitequark: that would be problematic in unittests, when you want to trigger a specific exception (eg. testing your elaboratable with the wrong parameter type or size)
<whitequark> I'm confused
<jeanthom-notmobi> let me rephrase this
<whitequark> why would you ever test for an assertion? (outside of very specific circumstances)
<whitequark> you test parts of your user interface. if it's a part of your UI/API, it shouldn't be an `assert`, it should be an explicit raise, like what nmigen does
jeanthom-mobile has quit [Ping timeout: 256 seconds]
<whitequark> I mean, I'm not strongly opposed to making a new exception type, not the hill I'll die on, I just genuinely don't understand the benefit
<whitequark> awygle: can we discuss what you had in mind in the meantime?
<whitequark> would probably the last item for today, besides the assert stuff
<awygle> whitequark: sure, i wanted to chat briefly about, the full and unique case thing
<awygle> just because i ran into it a few days ago
<whitequark> oh, yeah, go ahead
<awygle> i'm trying to keep my DDR2 controller at 200 MHz on my EPC5 -6, and i kept failing that timing. turned out that i had assigned two signals which were inputs to a Switch to the same source (oops) which turned it into a priority encoder and tanked my fmax
<awygle> if i had the unique case option i would have caught that earlier, and i think the semantics of it are _relatively_ uncontroversial, so i wanted to bump it and get your take
<whitequark> so... from this description of an issue, it sounds like you are looking for a lint
<whitequark> do you agree?
<awygle> mm. i agree that a lint could solve my problem, how about that?
<whitequark> i mean
<whitequark> that's good to know, but if making it a lint is suboptimal, i want to know that too
<awygle> i think it kinda depends how you look at it
<whitequark> sure
<awygle> on the one hand yes, a lint would have caught my bug
<awygle> on the other hand, fundamentally i wanted a non-priority mux
<whitequark> i see
<awygle> so i'm expressing my desire incorrectly
<whitequark> yes, i think this is actually a great argument
<whitequark> here lies the problem
<whitequark> i'm sure people will say "i want every switch in my codebase to be full/unique"
<whitequark> and they won't be happy with having to manually insert those qualifies each time
<awygle> i agree with that
<whitequark> scope inheritance is one of the usefulness of lints
<whitequark> the other being that you can turn them into warnings, which in this case is probably not important
<whitequark> i mean, i can imagine cases where i want to be warned about non-full cases rather than have it as an outright error
<whitequark> but they're not super important
<awygle> i kind of like doubling up, and having a Switch(mode="unique") and also a with Lint("unique-switches"), and letting the user choose which they want
<awygle> but it does admit confusion
<awygle> actually let me un-weasel that - i like the idea of doubling up, and i don't think the potential confusion is that large.
<whitequark> i... agree
<whitequark> we can just have both, they express different concepts
<whitequark> "i want this switch specifically to be a non-priority mux" vs "i've heard non-priority muxes are slow, do i have any"
<awygle> yes
<whitequark> great. write a (small) RFC for it then?
<awygle> heh, sure. i still owe you two from last week(?) tho
<whitequark> - bikeshed the syntax
<whitequark> - it's not trivial to display good errors in presence of wildcards
<whitequark> mostly the latter needs discussion
<awygle> yep
<awygle> and also, is there a case where a lint and a keyword argument would conflict, and what do we do if there is
<jeanthom-notmobi> whitequark: I had second thoughts about creating a new exception type for asserts. I can't think for now of a situation where we would have to check for an nmigen assertion failure, let's use AssertionError then
<whitequark> jeanthom-notmobi: yup. and if such a situation arises, we can make our own exception that inherits from AssertionError
<jeanthom-notmobi> yep
<whitequark> awygle: hm, good question
<awygle> whitequark: one last thing, does this decision also apply to "full"? full feels much more optimization-focused than unique, which is fundamentally a different thing, to me, but i also like having them be symmetrical
<awygle> (or well, pre-decision)
<whitequark> i think that the keyword argument should always take precedence
<awygle> i agree with that
jeanthom-mobile has joined #nmigen
<whitequark> because, well, you're describing what kind of switch you want *right there*
<whitequark> moreover, it should be silent, in other words, a valid way to temporarily override whatever lint is active globally
<whitequark> because, sure, you can do `with Lint()`, but Switch() already has hella rightward drift
<awygle> i actually can't think of a reason you'd lint "warn me if i accidentally have a switch with unique cases, i want them all to be priority", so it may not actually come up
<awygle> but if it does, i agree the kwarg should win
jeanthom-notmobi has quit [Ping timeout: 256 seconds]
<_whitenotifier-3> [nmigen] whitequark commented on issue #451: `Switch` attribute for unique and/or full `Case`s -
<whitequark> phew, done for today
<awygle> nice job :)
<whitequark> :)
<whitequark> yeah, we went through quite a lot
<awygle> and i'm quite happy with at least two of the decisions we made (and unhappy with 0)
* cr1901_modern looks at the date
<cr1901_modern> hooooly crap I forgot there was a meeting today ._.
jeanthom-mobile has quit [Quit: AndroIRC - Android IRC Client ( )]
<Degi> Is there any news to #398 yet?
emeb_mac has quit [Ping timeout: 256 seconds]
<_whitenotifier-3> [nmigen-soc] jfng synchronize pull request #25: periph: add a ConstantMap container for configuration constants. -
<_whitenotifier-3> [nmigen-soc] jfng closed issue #24: Communicating constants from the peripheral to the BSP generator -
<_whitenotifier-3> [nmigen/nmigen-soc] jfng pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-3> [nmigen/nmigen-soc] jfng b405880 - periph: add a ConstantMap container for configuration constants.
<_whitenotifier-3> [nmigen-soc] jfng closed pull request #25: periph: add a ConstantMap container for configuration constants. -
emeb_mac has joined #nmigen
<_whitenotifier-3> [nmigen-soc] jfng commented on pull request #25: periph: add a ConstantMap container for configuration constants. -
Asuu has quit [Read error: Connection reset by peer]
Asu has joined #nmigen
Asu has quit [Client Quit]
emeb_mac has quit [Ping timeout: 264 seconds]
emeb_mac has joined #nmigen
<miek> doh, i just found the difference between << and `shift_left`. len(C(0, 14) << 2) does not equal 16 :p (which, to be fair, is documented, but i hadn't read closely enough)
<lkcl__> whitequark, jeanthom... oh, jeanthom's offline - about Display() redirecting to print() or to an event handler class, i'd advocate definitely an event handler class
<lkcl__> one option worth considering is the standard python logger system
<whitequark> i mean, it should clearly print *by default*
<lkcl__> defaulting to stdout... yes
<lkcl__> one of the advantages of hooking into the standard python logging system is that it brings the concept of reporting levels, without that having to be reinvented
<whitequark> except we don't have reporting levels, we just have Display
<lkcl__> indeed. i was thinking, "what would the implications be if Display had a reporting level argument"
<lkcl__> would it be possible, what would the implications be?
<whitequark> well, cxxrtl supports the $display Yosys cell, so it would not support this unless yosys gained a reporting level argument
<lkcl__> and would it break anything / break expectations? in particular, if someone sets the debug level to "critical" (minimal reporting) ...
<lkcl__> right. so _all_ logging would be sent out (regardless of the requested level), which would mean it would need filtering somehow
<whitequark> frankly, i don't see a particular need for this feature
<lkcl__> and, thinking it through, i'm not seeing that it's practical, either
<whitequark> if you wanted to add loglevels, you could always do it in python
<lkcl__> "nice-to-have" and "fits python paradigm" however...
<whitequark> i.e. `if loglevel >= logging.INFO: m.d.sync += Display(...)`
<lkcl__> something like that, yeah.
<whitequark> this even works for verilog export
<lkcl__> yeah
<whitequark> interestingly, SVA actually does include a feature similar to what you propose
<lkcl__> my initial thought was, it'd be nice to hook into a readily-available system which has redirection
<lkcl__> oh?
<whitequark> for some reason it is only for assertions
<lkcl__> system verilog assertions
<lkcl__> oh, quick question: i've a 64 bit wishbone slave device that needs to be converted to 32-bit (without changing the bus width)
<lkcl__> is there a recipe anywhere that does that?
<whitequark> without changing the bus width?
<lkcl__> i've started trying to use nmigen-soc InterconnectShared however i'm running into confusion over what's master and what's slave
<whitequark> do you want something that would take two 32-bit writes and combine them into a single 64-bit write, for example?
<lkcl__> as in, i can't change the size of the actual wishbone slave Record of the CPU
<lkcl__> yes.
<lkcl__> the CPU has to remain at 64-bit
<whitequark> misoc has an UpConverter module
<lkcl__> but has to interface to a 32-bit-wide RAM (actually, litex)
<lkcl__> ahh
<whitequark> you can try porting that
<lkcl__> that's what i was looking for, thank you
<whitequark> np
<lkcl__> i'm running into difficulties with litex, i wanted to try to eliminate its upconversion as a possible source of problems by eliminating upconversion in nmigen
* lkcl__ has a copy of misoc somewhere
emeb has quit [Quit: Leaving.]