ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting July 27th
kernelmethod has quit [Quit: leaving]
<_whitenotifier-b> [YoWASP/yosys] github-actions[bot] pushed 1 commit to update-deps [+0/-0/±1]
<_whitenotifier-b> [YoWASP/yosys] github-actions[bot] e5e262c - Update upstream code
<_whitenotifier-b> [yosys] github-actions[bot] opened pull request #10: Auto-update -
<_whitenotifier-b> [yosys] github-actions[bot] created branch update-deps -
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
emeb has quit [Quit: Leaving.]
jaseg has quit [Ping timeout: 240 seconds]
jaseg has joined #nmigen
<_whitenotifier-b> [yosys] whitequark closed pull request #10: Auto-update -
<_whitenotifier-b> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1]
<_whitenotifier-b> [YoWASP/yosys] github-actions[bot] 4da546f - Update upstream code
<_whitenotifier-b> [YoWASP/yosys] whitequark deleted branch update-deps
<_whitenotifier-b> [yosys] whitequark deleted branch update-deps -
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
levi has joined #nmigen
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter_ is now known as PyroPeter
jeanthom has joined #nmigen
Asu has joined #nmigen
<DaKnig> how would I integrate parts from other langs, like verilog/vhdl? compile the nmigen to verilog then use the gui tools of vivado to include this as part of the project?
<DaKnig> is there a better way?
<whitequark> with open("foo.v") as f: platform.add_file("foo.v", f)
<trabucayre> for vhdl it's possible to use
<trabucayre> vhdl -> yosys -> output verilog
<whitequark> yes, it depends on the toolchain you're using
<DaKnig> ah I see, for now my top level is not in nmigen, I guess I'll stick to converting it to verilog and using the gui
<whitequark> yep, then the gui is your best bet
<DaKnig> I get this error when following the tutorial: `ModuleNotFoundError: No module named 'nmigen.back'`
<DaKnig> tried to import `verilog` from there
<whitequark> that seems really strange
<whitequark> i think there's a problem with your installation, but i have no idea, which
<DaKnig> the weird thing is I am able to import `nmigen`
<miek> have you named a file by any chance?
<DaKnig> nope
<DaKnig> I uninstalled my local git version of nmigen and reinstalled the stable and it seems to work
<DaKnig> what does this one mean? TypeError: Reset value has to be an int or an integral Enum
<DaKnig> I dont have any reset signal I explicitly declared, but some signals do have a value for reset
<whitequark> it's talking about a reset value
<whitequark> it's a bad error message, i have a TODO about fixing it
<DaKnig> waht should I do? what did I do wrong?
<whitequark> can you show the line it's talkign about?
<DaKnig> it points to the line where I call verilog.convert
<DaKnig> nvm I think I found it
<DaKnig> I am used to VHDL so I used '0' somewhere
<DaKnig> `'Array' object has no attribute 'eq'` - is this intended?
<DaKnig> I have an array that I use as a wide shift reg, should I use something else?
<miek> a Signal?
<DaKnig> can a signal be multidimensional?
<miek> no, but i don't understand why a shift register needs to be?
<whitequark> DaKnig: you can't assign the entire array, but you can do something like `Cat(*array).eq` if you want
<DaKnig> guess I would do this...
<whitequark> if you want something like a shift register, try .word_select
<whitequark> it's somewhat more idiomatic
<DaKnig> to select the whole array?
<whitequark> no, ditch the array, use a single signal, choose parts of it with .word_select rather than []
<DaKnig> I'll try this later.
<DaKnig> would have been nice to have a homogenous array type, or some sort of multidimensional signal.
<whitequark> you can use arrays for that
<whitequark> well
<DaKnig> I am :)
<DaKnig> since I reinstalled nmigen , it cant find yosys, even though I installed it with `nmigen[builtin-yosys]`... what could be the problem?
<DaKnig> it says yosys is not in the PATH and I have to either add it or chane the YOSYS variable, I thought adding the brackets would solve it..?
<whitequark> it should have
<whitequark> hm
<whitequark> how are you installing nmigen?
<DaKnig> `pip install --user --upgrade 'nmigen[builtin-yosys]'`
<DaKnig> I tried again, with the `''` and now it says that ` nmigen 0.2 does not provide the extra 'builtin-yosys'
<whitequark> yeah, you need nmigen from master for that
<DaKnig> the tutorial says that this should be used for the "latest release", and I tried not to bother people here so I followed it
<whitequark> so normally that would be better, but 0.2 has been very long ago, and master has lots of improvements for 0.3
<DaKnig> lol this happens quite often in open source projects :)
_whitelogger has joined #nmigen
proteus-guy has quit [Ping timeout: 256 seconds]
proteus-guy has joined #nmigen
<_whitenotifier-b> [nmigen-boards] ktemkin opened pull request #90: Add ULX3S. -
<ktemkin> whitequark: I have a handful of board definitions to dump into nmigen_boards; I'm going to PR the first couple one-at-a-time before I PR the rest so if there are things wrong with the first ones, I can change the rest before making them your problem =P
<trabucayre> ktemkin: I like your PR, especially the first point in the message and toolchain_program :)
<_whitenotifier-b> [nmigen-boards] ktemkin edited pull request #90: Add ULX3S. -
<ktemkin> ;)
_whitelogger has joined #nmigen
<FL4SHK> considering whether or not to include a `defer` statement in my assembler
<FL4SHK> I think I want to include that later
<FL4SHK> I'd certainly like to include stuff for function calls
<FL4SHK> Honestly what may make the most sense is to just build a Binutils port
<FL4SHK> I need practice with that, anyway
emeb has joined #nmigen
awe00 has joined #nmigen
xax37 has joined #nmigen
<xax37> hello, I am having trouble getting an fsm state from the simulation. anyone have any pointers?
<Lofty> xax37: It'll be in the VCD at least
<DaKnig> how can I change the name of a Module (or an instance of such a Module) in the verilog output?
<xax37> yes, I have that already and its good, but I want to do tests in the simulation without the vcd
<awygle> This can be done but it's somewhat obtuse
<awygle> You can see an example in the nmigen test suite
<vup> DaKnig: for submodules you can use `m.submodules.your_name = SomeModule(...)`, for the toplevel module, `verilog.convert(Top(), name="YourName")`
<vup> (or `m.submodules["your_name"] = SomeModule(...)`, which can be handy for example for loops that generated submodules)
awe00 has quit [Ping timeout: 240 seconds]
xax37 has quit [Ping timeout: 245 seconds]
awe00 has joined #nmigen
cr1901_modern has quit [Read error: Connection reset by peer]
awe00 has quit [Quit: WeeChat 2.9]
xax37 has joined #nmigen
cr1901_modern has joined #nmigen
<xax37> awygle: the closest example I could find is in, but it uses FSM() instead of m.FSM() which gives me AttributeError: __enter_ when i do with ...:
<xax37> awygle: I can't find an exmple or a way to use FSM as documented "with m.FSM():" and yield fsm.state (and fsm.decoding[state]) in simulation
<awygle> tbh whitequark explained this to me a while back but I gave up on it
<awygle> But if you look at test_fsm_basic in test/ you'll see the "find_generated" call that gets you access to the state signal
<awygle> It just wasn't clear to me how to get at the fragment while also using the elaborated module
<awygle> Doubt it's that hard I just didn't feel like spending time on it that day
<xax37> awygle: ok, thanks, I'll need to dig deeper in the code I guess
<lkcl> i believe the discussion was that people expected to be able to access the state but that this was not possible.
<lkcl> for now, therefore, inside each state block, a Signal must be combinatorially set
<awygle> that is the easy way, yeah
<awygle> "make FSMs better" is On The List but of course The List is a long one
<lkcl> :)
<awygle> (please leave comments on the relevant issue documenting your use case so we make sure we support it when we get there)
<xax37> lkcl: vcd gives the state, so I guess expecting access to state is not far fetched
<xax37> I'll have some more tries and then probably create an issue to capture this
<whitequark> xax37: lemme explain how to do this
<awygle> the fsm enhancement issue is here
<whitequark> xax37: you have some sort of toplevel module, inside it maybe some other submodules, then your FSM, right?
<whitequark> so you run a simulator as Simulator(top)
<whitequark> you have to rewrite this as:
<xax37> whitequark: yes
<whitequark> frag = Fragment.get(top, platform=None)
<whitequark> fsm = frag.find_generated("submodule", "nested_submodule", "fsm")
<whitequark> sim = Simulator(frag)
<whitequark> then you can use `fsm.state`
<whitequark> the path you pass to .find_generate is the name (or index, for unnamed ones) of every module that contains the FSM, from outermost to innermost
<whitequark> does this make sense?
<xax37> whitequark: I'll give it a try, thx
<awygle> whitequark: a question of intent - am I correct that the Fragment infrastructure would not, in an ideal world, be interacted with by users? or is it a public API? Z
<whitequark> generally former
<whitequark> one day, when it is no longer awful, it might become latter
<whitequark> long ago, i thought it is not awful. i was wrong
<xax37> whitequark: works perfectly! thank you.
<awygle> OK, cool, that's what I figured (except the last bit lol)
<awygle> What would it be used for as a public API?
<whitequark> things like external linters
<awygle> ah yes
<awygle> how's your eeprom-ing going?
<FL4SHK> I need to get like, a parallel EEPROM at some point
<tpw_rules> are records still the thing for passing around related groups of signals? i seem to remember something about how they weren't great?
<FL4SHK> tpw_rules: only for a little while longer
emeb has quit [Quit: Leaving.]
<FL4SHK> switch to PackedStruct once that becomes a thing
<whitequark> awygle: i think i'm getting some idea of how this works
<whitequark> not enough to write a published lab note
jeanthom has quit [Ping timeout: 256 seconds]
<awygle> Well I look forward to reading it when it's done
xax37 has quit [Remote host closed the connection]
<whitequark> :)
<whitequark> right now i'm a bit confused by different behavior of EPROM vs EEPROM
<FL4SHK> EPROMs, tmk, are not erasable besides with a UV light
<whitequark> sorry, you didn't have context for this
<FL4SHK> ah
<whitequark> what i mean is that i'm investigating bitrotted EPROMs/EEPROMs and they bitrot differently
<FL4SHK> ahhhh
<whitequark> EEPROMs bitrot like you'd normally expect
<whitequark> you lower Vcc (thus Vth) and they start reading fine
<whitequark> EPROMs... i don't even know
<FL4SHK> I'm trying to make a Binutils port for my newest CPU
<FL4SHK> going to port GCC also... eventually
<FL4SHK> I'm back into using C
<FL4SHK> I'd rather write C++
<awygle> "more like eeh-proms, amirite" no shut up Bad Joke Brain
<Lofty> "Things were simpler in the past"
<Lofty> E[E]PROMS: "yeah, no"
<FL4SHK> the "EE" in "EEPROM" stands for "Electrical Engineer"
<FL4SHK> Electrical Engineer Programmable Read Only Memory
<tpw_rules> i guess light leaking in would have the same effect as age?
<whitequark> tpw_rules: not necessarily
<whitequark> though i do think it's plausible
<tpw_rules> then is that the difference?
<tpw_rules> like i thought both caused loss of trapped electrons
<whitequark> the difference is in the specific ways unstable reads manifest
<tpw_rules> where are these decaying memories coming from out of curiosity
<whitequark> literal garbage my roommate brought home
<whitequark> some sort of... industrial pc control thingy from 1995
<tpw_rules> i should have figured
<whitequark> with a z8018008
<whitequark> i have no idea
<whitequark> it runs basic
<whitequark> only one of them even boots, the other had a bitrotten *GAL*
<whitequark> which is how this all started
<tpw_rules> a what
<tpw_rules> z180>?
<whitequark> GAL/PAL
<tpw_rules> no the microprocessor
<whitequark> like... you know CPLD? that but without the C
<whitequark> oh
<whitequark> oh yeah it's a z80
<tpw_rules> i find it funny how far zilog fell
<awygle> i was wondering if you had a specific goal for this or if this was "brain grabbed a thing won't let go"
<tpw_rules> if it's industrial, i wonder if severe heat contributed
<whitequark> it's not very industrial
<tpw_rules> i wouldn't have expected a 1995 thing to rot yet
<whitequark> in this case it was used in a distinctly commercial setting
<whitequark> it has a GPS, a commercial radio connector, and a panic button (?)
<awygle> how can there be so much shit in my lab notebook that i have zero memory of writing/drawing
<whitequark> awygle: that's what it's for!!
<awygle> .. ok, fair
<tpw_rules> do you have tips on getting into lab notebooks
<whitequark> tpw_rules: ... yeah lol sorry i somehow assumed you don't know what a CPLD is, my bad
<awygle> i mostly think of it as a kind of externalized working memory tbh
<awygle> i have a hard time thinking without a pen in my hand
<whitequark> lab notebooks, i think of mine as a relatively low effort thing where i just record stuff i feel like recording (but it's online)
<whitequark> it used to be just zero effort
<whitequark> but then people got like, all interested in it
<tpw_rules> i never really record anything but i probably should
<tpw_rules> i kind of want that as a bit of a resume
<awygle> you're too interesting wq, it's your curse
<whitequark> it can be draining at time
<whitequark> *times
<tpw_rules> i haven't worked out how to extend my head capacity i guess is the problem
<tpw_rules> i just swap like mad
<awygle> meanwhile mine is a physical notebook that i draw diagrams and stuff in, and sometimes i'll think "huh i should make this a blog post" but then i'd have to finish setting up a blog so i don't
<FL4SHK> I haven't finished setting up my blog, either
<tpw_rules> part of the problem is my handwriting is so bad the physical notes are unintelligible without at least a little bit of the short term memory
<whitequark> awygle: tpw_rules: for example, one thing that EEPROMs do is have the outputs oscillate or be unstable, and this seems to be very nicely explained by a theory of "output buffers have input near Vth, are metastable, either resolve one way or around or ... start oscillating"
<whitequark> but EPROMs? those don't do that
<whitequark> by which i mean, EEPROMs seem to be completely stochastic in nature
<FL4SHK> I wish my EE foo were as good as yours, whitequark
<FL4SHK> I don't know what Vth is
<awygle> V threshold
<awygle> the transition point
<FL4SHK> I only vaguely recall what that means
<whitequark> ^
<FL4SHK> transition from low to high?
<awygle> yup
<FL4SHK> ah
<FL4SHK> I don't have a clue how to deal with like, setup time and hold time
<whitequark> i read the datasheet
<tpw_rules> i don't know that much about the internals of either type. i guess for some reason they must have schmitt trigger buffers
<awygle> just takes learning. fuck it up a few dozen times.
<FL4SHK> I did recently learn how to solder
<tpw_rules> but that doesn't make much sense for the main array
<FL4SHK> it's so much easier than I was expecting
<whitequark> tpw_rules: the atmel EEPROMs definitely do *not* have schmitt trigger buffers because their output buffers will happily start oscillating in the right conditions
<FL4SHK> I had to solder a headphone jack to a breakout board
<awygle> yeah i was gonna say i don't know enough about EEPROMs or EPROMs to say for sure but i wouldn't be at all surprised to learn they were quite different internally
<FL4SHK> EEPROMs are like... flash memory
<tpw_rules> poor talking skills again: the eproms must have them
<FL4SHK> maybe I should adopt them
<whitequark> hang on. i made a dumb mistake. please do s/EEPROM/Flash/ everywhere above
<whitequark> i keep forgetting that this chip i'm poking is 29x and not 28x
<tpw_rules> there goes my other theory that the erase mechanism required different buffers then
<whitequark> i don't actually know how EEPROMs behave
<tpw_rules> because it's much less discriminatory in flash so i don't think the regular array lines are exposed to it
<whitequark> i only have UV EPROMs and Flash
<awygle> are the eproms you have cmos, nmos, or pmos?
* whitequark stares at the docs for the board
<whitequark> you know, it's not my fault that i keep calling it "EEPROM", the vendor of the device calls the flash chip "EEPROM"
<awygle> yeah they do that a lot
<awygle> it's not technically untrue but it sure is misleading
<tpw_rules> wasn't it a trademark almost back then?
<awygle> seems like NOR Flash == EEPROM these days
<whitequark> awygle: lemme get the label off this one
<whitequark> one is m27c256b
<whitequark> this one is CMOS
<awygle> yeah, 27C is almost certainly cmos
<whitequark> i'm like 80% sure the other is also CMOS
<whitequark> it's AMD
<whitequark> but the marking is obscured
<whitequark> AMD©1991
<awygle> chip as old as meeeeeeeeee
<whitequark> am27c256
<awygle> well so much for the "nmos acts differently under decay than cmos does"
<awygle> theory
<d1b2> <286Tech> I'm literally holding an AMD 27C512 in my hand right now, and I see talk about an AMD 27C256 here...
<d1b2> <286Tech> Wow, timing
<whitequark> username checks out :p
<whitequark> so the thing about the UV EPROM is that the fault pattern is very different
<whitequark> it seems that most bytes read either 0x00 or 0xff
<whitequark> though there are some outliers
<d1b2> <emeb> Would be an interesting experiment to program an EPROM with a known pattern, then expose it to UV while continuously reading it - see what the decay looks like.
<whitequark> the other thing is that i can get a flash to give me an indeterminate value "in the act"
<whitequark> very easily
<whitequark> but i have so far not managed to get an EPROM to give me an indeterminate value based on an earlier search
<whitequark> oh! caught it
chipmuenk has joined #nmigen
<whitequark> ... it seems to require a long burst of reads
* awygle hits issue #381 again
<whitequark> okay, we can discuss that tomorrow
<whitequark> i mean, i tried to discuss it on the previous meeting
<awygle> you did, you tried so hard in fact that you referred to a different issue by that number :p
<whitequark> :/
<awygle> s'all good wq, there's no hurry
<whitequark> alrighty
<awygle> are we still doing the "devs only" meeting tomorrow?
<awygle> speaking of meetings
<whitequark> yep
<awygle> (i cannot _believe_ tomorrow is monday already. criminy.)
<whitequark> awygle: okay, it seems that the "bitrotten EPROMs" i had were just bad decoupling
<whitequark> i lowered the address shift frequency and those failures went away
<whitequark> plus they made no sense statistically in first place
<awygle> time to shine a very weak UV light on it?
<whitequark> ehhh, i can leave that until some later time
<whitequark> i feel like i don't understand flash rot yet
<awygle> it's pretty impressive that a chip as old as i am hasn't lost data tbh
<awygle> i've lost tons of data :p (tho admittedly i have several other functions)
<awygle> wow i completely forgot FSM.ongoing was a thing
<awygle> whitequark: Assert is a no-op if you're not in either simulation or formal, right?
<whitequark> no
<whitequark> it's a synthesis error and simulation error
<whitequark> this is ... probably not the best way to handle it
<whitequark> in general, nmigen formal is very immature
<whitequark> i would consider it a preview
<awygle> ah, ok
<ktemkin> now you’re tempting me to babble about flash and EPROMs
<whitequark> pls do!!
<ktemkin> when I’m not supposed to be napping, I totally will
<awygle> (gene wilder voice) no. stop. don't. come back.
<whitequark> awygle: okay, so! i think i managed to significantly or fully recover the data flash from one of the cursed devices
<whitequark> at least all of the things that look like they ought to be english ascii strings do look like english ascii strings now
<whitequark> and the bit statistics, at first glance, seems rigt
<whitequark> (i gotta compute that at some point)
<awygle> nice!
<whitequark> plot twist
<whitequark> i had to read this 5V flash at 3V6
* awygle is now trapped watching gene wilder videos on youtube
<ktemkin> tired brain vaguely wonders if leakage currents result in trapped carriers over a long period of disuse
<whitequark> awygle: ... huh
<ktemkin> I should never check IRC from my phone; it’s the enemy of sleep and the source of stupid ideas
<whitequark> so remember i mentioned signal integrity issues?
<whitequark> the ST EPROM doesn't have them. the AMD one does
<whitequark> the data is exactly same, too
<awygle> Interesting
<awygle> You can't really complain, they must be well past their service life lol
<whitequark> i can't tell if this is just my crappy circuitry or if it's a real difference
<whitequark> i *think* the former
<awygle> I think I am finally done rewriting my DDR2 controller
<whitequark> niiiice
<awygle> Third design iteration always seems to be the charm lol
<whitequark> awygle: so, one of the data flashes reads fine at 3.40V (with more confidence than previous 3.6V number), the other at 3.25V
<whitequark> i'm not entirely sure how old are these exactly (or at least, when were they last programmed)
Asu has quit [Remote host closed the connection]
<ktemkin> oh, by the way, I don’t know if you postulated a good theory for why the outputs wound up oscillating in lockstep during your astable reads
<whitequark> ktemkin: oh, i have two possible reasons
<whitequark> the first one is that they're just physically close
<whitequark> the second one is that given the massive inductance of my awful wiring, vcc appreciably oscillates, too, and the buffers end up resonant with some passives on the board
<whitequark> i think the second one is at least a significant contributor because when i added a small decoupling cap, oscillations got a whole lot worse
<whitequark> like an order of magnitude
<ktemkin> but it strikes me as likely coupling via the supplies; since during the astable states you’re effectively turning on both logic network partially, drawing more than typical stable-state current; this in turn would cause threshold oscillations for the other signals
<whitequark> right, so my question is basically "is it coupling on chip or off chip"
<whitequark> as in "would they still oscillate if my board wasn't awful or not"
<ktemkin> (typing slowly from phone)
* whitequark nods
<ktemkin> I’m going to guess the supply input impedance is significant enough that you’d still see appreciable internal VCC swings when the buffer’s pull-up and pull-down transistors are on
<whitequark> mhm, so you're saying that i would still observe this with a better laid out board, right?
<ktemkin> I’d think
<whitequark> yeah, makes sense; i should check that at some point
<ktemkin> I’m guessing that your single-signal oscillation stays around without settling as well as it does because the threshold of the signal itself is being modulated
<whitequark> yeah
<whitequark> fwiw, i took some new captures, and for some reason (i moved things around?) the oscillation is really pronounced there
<whitequark> i get actual rail to rail 26-28 MHz oscillation
<whitequark> instead of Voh
<ktemkin> huh
<whitequark> not on every word
<whitequark> but on a significant proportion of
<whitequark> what i also found amusing is that apparently the oscillator has enough short-term stability that glasgow sampling it with an xtal derived clock actually usually samples it in the same point
<whitequark> well, enough to make me wonder why i get stable reads when i *clearly see the huge sine wave on the scope*
<whitequark> (i think that changing address pins resets its phase or something like that?)
<ktemkin> you’re probing at the Glasgow side?
<whitequark> at the flash pin
<d1b2> <Hardkrash> Can you get 5 to 10 turn to fine magnet wire around the pin
<ktemkin> I mean, chances are the oscillations you’re seeing are getting smoothed out a bit by the mass of wiring on their way over to the glasgow
<whitequark> ah, also possible
<whitequark> i did observe glasgow sampling at weird points with different gateware thoug
<ktemkin> dunno if they’d be smoothed our enough, but if the setup is the one I saw on twitter a bit ago it looked very capacitive and inductive =P
<ktemkin> *out
<whitequark> right, yeah
<whitequark> i should check more carefully
<ktemkin> (anyways, I should actually nap; I’m pretty sure $girlfriend is rolling her eyes at me for doing the whole “Kate checks her phone repeatedly in bed” thing)
<lkcl> ktemkin: lol
<whitequark> good night!
<lkcl> always amazes me, online communities being in different timezones
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
<awygle> whitequark: nmigen Switch/Case makes a priority encoder right? which cases take precedence if multiple match?
<whitequark> yes, first one does
<whitequark> the same as most other pattern matching constructs, eg rust
<awygle> ok, cool
<awygle> (it could easily have been last-wins, since that's how e.g. multiple assignments work)
<whitequark> mhm, that's true
<tpw_rules> but not if-elseif
<awygle> if/else ladders are inherently unambiguous though
<tpw_rules> as a software person and chronic python addict i've always treated switch/case as just a different flavor of if-elseif
<awygle> i have always thought of switch as the non-priority version of if-else, personally
<awygle> i think conflicting case statements should be a hard error
<hell__> see Ada
<whitequark> Switch is a way of writing If match/Elif match/Else concisely
<hell__> IIRC in Ada not handling some case is an error
<whitequark> i think it is not unreasonable to add some sort of an attribute that requires the switch to be either full or with no overlapping cases
<whitequark> hell__: rust too, that's common. ocaml gives you a warning that most people (i think) convert to error
<awygle> oh no lol full_case parallel_case
<whitequark> awygle: no, that's the *opposite* of those attributes
<hell__> hrm
<awygle> i'm mostly being sarcastic
<whitequark> right okay
<whitequark> i consider those lints
<whitequark> semantically meaningless
Stary has quit [Quit: ZNC -]
<awygle> it's actually "unique" and maybe "full_case" as intended if not as ipmlemented
<whitequark> yes
<awygle> and what we currently do is "priority"
<awygle> hm i guess i should maybe file an issue for discussion of such an attribute
<whitequark> yup sure
<_whitenotifier-b> [nmigen] awygle opened issue #451: `Switch` attribute for unique and/or full `Case`s -
Stary has joined #nmigen
<awygle> hm, it would be nice to have `Array.any()` or similar
<whitequark> i don't quite understand the desire to extend the capabilities of Array
<whitequark> it's a container that mimics list()
<whitequark> you could argue that values mimic ints, yet they have .reduce_xor(), but that's just because they're fixed width ints
<whitequark> anyway
<whitequark> it's not out of question, but it seems somewhat inconsistent
<awygle> yeah i can see why you wouldn't want it necessarily
<awygle> and it's not that hard to say "if any of these array members is not 0 return true"
<whitequark> the obnoxious part is the inability to override __bool__ in a useful way
<awygle> is there a difference between >> and shift_right?
<Lofty> awygle: x.shift_right(-1) does x << 1 for example
<whitequark> yeah. >> follows python behavior exactly
<whitequark> shift_right can be more flexible
<awygle> is there a version of shift_right where sig_32.shift_right(4) (where sig_32 is a 32-bit unsigned signal) gives a 28-bit signal as result?
<whitequark> that's just shift_right
<whitequark> since the amount must be constant, the domain is reduced
<awygle> sweet, thank you
<FL4SHK> anyone here ever made a Binutils port?