ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting October 12th
<cr1901_modern> Do you mean "making 'm' explicit*"?
<whitequark> yes
<DaKnig> but how does nmigen keep track of the active contexts in a module? for stuff like relating a `Case` to a `Switch` etc
<DaKnig> is that something saved inside the module?
<cr1901_modern> >Signals assigned in a combinatorial domain assume their initial value when none of the assignments are active.
<cr1901_modern> This has saved my rear end a few times tonight
<whitequark> DaKnig: yes
<cr1901_modern> whitequark: Does nmigen expose rose/fell yet outside of formal (to abstract away the idiom for edge-triggered signals)?
<cr1901_modern> Doesn't have to be called Rose/Fell, just wondering if I have to write that manually
<whitequark> cr1901_modern: no, and it likely won't
<whitequark> people importing it from nmigen.formal to use in synthesizable designs typically regret tht
<whitequark> the last time this happened was with ktemkin, i think awygle hit it before that
<cr1901_modern> I wasn't going to import it from formal
<cr1901_modern> I thought maybe it could be a maybe a utility function
<whitequark> i mean, you can import it from formal
<whitequark> it works
<whitequark> it's just that the semantics has a high chance of making you regret that
<d1b2> <marble> Quick question. Instead of yield Settle() it's now just yield, right?
<whitequark> not yet, unfortunately
<whitequark> plain `yield` means `yield Tick(domain)` for sync processes
<whitequark> and nothing (an error) for other ones
Degi has quit [Ping timeout: 258 seconds]
<d1b2> <marble> What do I do instead of Settle then? I get a NameError: name 'Settle' is not defined
Degi has joined #nmigen
<whitequark> uh, Settle is still a thing
<whitequark> how do your imports look like?
<d1b2> <marble> the code: I pasted the two listings from this page into one file
<d1b2> <marble> My requirements.txt
<d1b2> <marble> I guess the part you mean is from nmigen.back.pysim import *
<whitequark> yeah
<whitequark> your requirements.txt is for nmigen==0.1
<whitequark> that's pretty old, older than what the tutorial is written against, i believe
<whitequark> use 0.2 or master
<d1b2> <marble> 👍 thanks 🙂
<whitequark> i really gotta fix emoji rendering in my terminal
<d1b2> <marble> What to you see?
<whitequark> replacement character
<whitequark> well, two of them
electronic_eel has quit [Ping timeout: 264 seconds]
electronic_eel has joined #nmigen
<DaKnig> lkcl: sorry to bother you again. I feel like asking for help again would be too much. but can you at least please remind me what the problem was last time and how you detected it?
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
<cr1901_modern> Does this mean _toolchain is exposed to the user?
<cr1901_modern> (I'm doing code golf- running my own yosys script using nmigen facilities would be helpful. But obviously not required)
<DaKnig> lkcl nvm. sorry to bother ya. testbench issue 🤬
<DaKnig> nice
emeb_mac has quit [Quit: Leaving.]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 272 seconds]
<DaKnig> does a MUX return a Signal?
<DaKnig> I want to compare two Arrays by their first member and choose the array that "wins"
<DaKnig> and do this in a tree
<DaKnig> if it'd just return a signal, the next stage would work with the first member of the signal and not the Array, meaning I'd get the first bit and not the whole value
chipmuenk has joined #nmigen
<DaKnig> how can I indicate that a certain `if` chain has no priority?
<DaKnig> so I dont care which of them wins if htere's a tie
Asu has joined #nmigen
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 272 seconds]
jeanthom has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
jeanthom has quit [Ping timeout: 256 seconds]
<lkcl> DaKnig: :)
<lkcl> DaKnig: it returns one or the other of whatever-it-was-you-put-in-each
<lkcl> oo, you'd have to do a for-loop on each of the individual signals in the array
<lkcl> i'd recommend assigning the test to a single signal
<lkcl> comb += test.eq(x[0] > y[0])
<lkcl> for i in range(len(z):
<lkcl> comb += z[i].eq(Mux(test, x[i], y[i]))
<lkcl> DaKnig: i am toootally confused by the mention of trees, Arrays, and "if chains having priorities" :)
DaKnig has quit [Ping timeout: 240 seconds]
<lkcl> if you can either draw it out or do "best alpha prototype" with some clear code-comments then people can take a look
chipmuenk has joined #nmigen
Chips4Makers has quit [Ping timeout: 240 seconds]
Chips4Makers has joined #nmigen
jeanthom has joined #nmigen
<FL4SHK> whitequark: so how can I stick an `Array` into a `Record`?
Asu has quit [Remote host closed the connection]
<FL4SHK> I'm thinking `Value.cast(some_array).shape()`
jeanthom has quit [Ping timeout: 265 seconds]
Asu has joined #nmigen
<lkcl> FL4SHK: array you have to access the elements individually.
<lkcl> i'd recommend Cat'ing all the elements of the array together (in a for-loop, into a Signal of the full size)
<lkcl> then eq that into the Record
<lkcl> x = Signal(len(array)*len(array[0]))
<FL4SHK> uh
<lkcl> for i in range(len(arrah)):
<FL4SHK> I'm referring to having one of the record elements being an array
<lkcl> ah i thought by "stick" you meant, "copy contents into"
<FL4SHK> ahhhh
<FL4SHK> I see
<FL4SHK> can it be done?
<FL4SHK> surely it can
<FL4SHK> this is a common operation, viable in both SV and VHDL
<lkcl> how can a record _contain_ an Array? mmm..... you might have to do it with a Layout that is constructed manually
<lkcl> Layout = ()
<FL4SHK> I mean, it works in both VHDL and SV
<lkcl> for i in range(array_len):
<FL4SHK> it working in those languages but not nMigen is concerning
<lkcl> Layout.append("element%d" % i, 8)
<FL4SHK> that's really not good enough
<lkcl> FL4SHK: that's not really a nice thing to say when you can write yourself some python code in about 5 minutes flat
<lkcl> and i'm in the middle of taking my time to explain to you how it can be done
<lkcl> i leave it to you to work out, yes?
<FL4SHK> I'm sorry
<FL4SHK> I'm just a little upset
<FL4SHK> it's ridiculously easy to do this in SV or VHDL
<FL4SHK> I thought nMigen had no such limitations
* Lofty sighs
<Lofty> So, let me get this straight
<Lofty> You are expecting a language in its 0.3 release to compare to standards that have had years to mature
<Lofty> Decades, even
<Lofty> And you're getting upset over it not doing this one thing
<Lofty> You would use a Layout to do this, yes
<FL4SHK> Okay
<FL4SHK> well, seems easy enough
<Lofty> But consider that in the long term Record itself is deprecated
<FL4SHK> uh, right
<FL4SHK> I was just thinking about that
<FL4SHK> I didn't think about nMigen being early in development
<FL4SHK> It does seem that being made in Python basically covers the majority of stuff I'd want to do
<Lofty> Which is one of the strengths of the language, I think.
<FL4SHK> yes, definitely
<lkcl> FL4SHK: so here's the thing. what you could do is write the class that does the job, then present that during the monday meetings.
<lkcl> and say, "this is what i need, can it be included?"
<lkcl> instead you got stroppy *and you're not paying whitequark any money*, are you?
<FL4SHK> where can I go to pay whitequark money?
<FL4SHK> neat
<FL4SHK> I'll start that up
* lkcl is impressed
<lkcl> that's very cool, FL4SHK.
<Lofty> So, here's the question: are you using Record as in "an interface", or as in "a series of values packed together"?
<FL4SHK> the latter
<FL4SHK> I'd use a regular Python class for the former
<lkcl> FL4SHK: you can derive from Record. or, create a function that creates the Layout that goes *into* the Record.
<Lofty> Then consider that your array is...just a signal
<FL4SHK> the array is only one element
<FL4SHK> I can do this with just a Python class since I can just look at `.__dict__`
<Lofty> ...I'm really not sure I follow
<Lofty> In my experience Array is not very useful
<Lofty> You can't have it as a module port
<Lofty> So my own flavour of coding style simply does not use Array
<lkcl> Lofty: a Layout that's generated by a for-loop, with multiple identical Signals in it.
<FL4SHK> Lofty: that sounds like another limitation of nMigen
<Lofty> FL4SHK:'s not a limitation to me
<FL4SHK> Lofty: how do you do an array without `Array`?
<FL4SHK> I suppose you could use an `m.Switch`
<Lofty> Let's start off: an array of *what?*
<FL4SHK> Records, for example
<Lofty> That's... Just a python array
<Lofty> The beauty of nMigen to me is that you can use Python's language features to build abstractions
<Lofty> Arrays and Records are things that - to me - belong in the Python domain, not the nMigen domain
<Lofty> An interface between modules? Sure, that's useful for nMigen.
<Lofty> But you can either express an array as a Python array of Signals, or as a wide Signal that you can take slices of to give fields meaning.
<Lofty> Or in my personal preference, each field is its own Signal.
<tpw_rules> the annoying part that i think FL4SHK is trying to get at is that you can't use a Signal to index the array in either case
<tpw_rules> what i usually do is like out = Signal(); with m.Switch(idx): for i, s in enumerate(arr): with m.Case(i): m.d.comb += out.eq(s) but i think it's ugly frankly
<lkcl> yeah if Array was derived from Value it would be solved
<Lofty> tpw_rules: bit_select on the Signal does exactly this.
<Lofty> lkcl: nope nope nope get that idea away
<tpw_rules> oh, huh
<Lofty> What does it mean to multiply an Array by a Value?
<Lofty> What does it mean to rotate right an Array?
<FL4SHK> rotate right on an array is easy
<Lofty> What does it mean to cast an Array to boolean?
<FL4SHK> also easy
<FL4SHK> multiplying is hard
<Lofty> "easy", huh? There's no way it'll be easy to a beginner
<FL4SHK> what do you mean?
<FL4SHK> rotating an array is easy
<Lofty> Go on then.
<tpw_rules> vectorize it? :3
<FL4SHK> I'm not sure how to describe it
<FL4SHK> with words, that is
<tpw_rules> erm
<FL4SHK> so for an array of bits
<FL4SHK> the basic elements are bits
<FL4SHK> for an array of anything else
<FL4SHK> the basic elements are some other type
<FL4SHK> VHDL has array rotating
<FL4SHK> and array shifting
<Lofty> See, the problem there is already that you've got special cases
<FL4SHK> I don't see why you can't ban multiplying an Array by something
<FL4SHK> types in nMigen are all build time from the HDL's perspective
<Lofty> As far as I'm concerned that would be a type error
<FL4SHK> btw, I only use `Array` because I need to use the value of a `Signal` as the index
<FL4SHK> otherwise I'd use a Python list
<Lofty> Yeah, but there's bit_select or word_select for that
<FL4SHK> I think being able to put an array on a port isn't going to be hard to add into nMigen
<FL4SHK> As far as I'm concerned, those two things are for when you have a non-aggregate type.
<FL4SHK> though in nMigen you could definitely do that stuff on an aggregate type
<FL4SHK> er, assuming you implement it as a Python class
<FL4SHK> You are saying you like to encode all arrays into vectors
<FL4SHK> likely cutting out anything like an array of records in the process
<FL4SHK> that's not how I code
<FL4SHK> I could definitely get by with just `word_select`
<FL4SHK> still don't know what `bit_select` is for
<Lofty> The thing with #290 is that you can't convert an Array to Verilog
<FL4SHK> Sure you can. Just encode it into a vector.
<Lofty> Then file an RFC.
<FL4SHK> You just do that manually
<FL4SHK> how do I file an RFC?
<FL4SHK> Github issue?
<Lofty> Yeah
<lkcl> FL4SHK: bit_select is for when you want non-word-aligned selections.
<lkcl> word_select can only (obviously) do word-aligned sizes.
<FL4SHK> I see
<lkcl> whilst bit_select(i*5,5) is directly equivalent to word_select(i, 5)
<lkcl> you *cannot* do - with word_select - bit_select(i*5, 73)
<FL4SHK> lkcl: sorry about being rude to you twice
<FL4SHK> I really didn't intend on being rude
<lkcl> FL4SHK: it's ok. it's a context thing. Lofty explained it very well
<FL4SHK> whitequark: so, bump, but will the new `PackedStruct` thing support having some kind of `Array` inside of it?
<FL4SHK> I want to be able to do `my_record.eq(my_other_record)`
<FL4SHK> ooh
<Lofty> Congrats, that's an Interface
emeb_mac has joined #nmigen
<FL4SHK> Lofty: so maybe I should construct a new class called a `PackedArray`
<FL4SHK> it'd be really easy to support
<FL4SHK> can you do `len(shape)`?
<Lofty> FL4SHK: no, but you can do Shape.width
<FL4SHK> cool
<FL4SHK> so I think something like deriving the `PackedArray` from `Value`
<FL4SHK> I think that'd work out quite well
<FL4SHK> I'll put this into the issue
<FL4SHK> it'd prevent you from having to use `word_select`
<vup> FL4SHK: you probably want to implement using ValueCastable (
<FL4SHK> vup: I'll look at that
<FL4SHK> I think I might be able to make this class rather quickly
<_whitenotifier-f> [nmigen] fl4shk opened issue #507: How to implement support for arrays on ports -
<FL4SHK> this is really exciting
<FL4SHK> I might be able to help contribute
<FL4SHK> vup: are there any examples of using `ValueCastable`?
<vup> FL4SHK: ValueCastable is not merged yet, but the PR I linked contains a testcase
<FL4SHK> maybe I'll just wait until it gets merged!
<lkcl> FL4SHK: do join the irc meeting tomorrow (1800 UTC)
<FL4SHK> lkcl: I'm not sure I can because I've got work
<lkcl> ahh ok
<lkcl> understandable
<FL4SHK> is UTC the same as GMT?
<miek> yep
<FL4SHK> okay so I'm GMT -6
<FL4SHK> or maybe it's -7
<FL4SHK> might depend on DST
<vup> UTC is GMT without DST :)
<FL4SHK> ah
<miek> GMT doesn't change for DST either
<FL4SHK> I believe my time zone is GMT-6 or GMT-5
<FL4SHK> not -7
<_whitenotifier-f> [nmigen] fl4shk commented on issue #507: How to implement support for arrays on ports -
<_whitenotifier-f> [nmigen] whitequark commented on issue #507: How to implement support for arrays on ports -
<_whitenotifier-f> [nmigen] fl4shk commented on issue #507: How to implement support for arrays on ports -
<FL4SHK> is there any way I can use `ValueCastable` today?
<whitequark> ValueCastable, no
<FL4SHK> Oh.
<FL4SHK> That's too bad.
<whitequark> there's a predecessor of ValueCastable which will be removed soon
<FL4SHK> `UserValue`?
<whitequark> yeah
<whitequark> we can discuss merging ValueCastable on the next meeting
<whitequark> which is tomorrow
<awygle> I was wondering about that yeah
<awygle> That pr has been open a long time
<awygle> I wasn't sure if you were waiting on me to do something
<whitequark> I thought I was
<whitequark> but it seems like there weren't any outstanding comments
<FL4SHK> awygle: did you get a chance to look at my divider?
<FL4SHK> whitequark: did you catch that I become a Patron?
<awygle> I didn't, I'm busy this weekend. Remind me tomorrow and I'll do so
<FL4SHK> cool
<FL4SHK> How do I convert a slice of an `unsigned` `Signal` (which I'm assuming just produces another `unsigned` `Value` or something) to an arbitrary `Shape`?
<FL4SHK> I'm building an initial version of the `PackedArray`
<FL4SHK> wait, just remembered that I no longer need the `PackedArray` thing for now
<FL4SHK> I'll wait until `ValueCastable` is implemented
<FL4SHK> actually, hm, I still need to do this
<FL4SHK> I need to be able to cast a collection of bits to/from a Shape
<FL4SHK> whitequark: so I'm not expecting a size change
<FL4SHK> at least
<whitequark> hm
<whitequark> then just .as_signed()/.as_unsigned() ?
<FL4SHK> No, the problem is a little different
<FL4SHK> I think...
<FL4SHK> Wait, `PackedStruct` is probably going to act a lot like `Record`, right?
<FL4SHK> I'm trying to make a class that will take what *would* have been an `Array` and explicitly encode it into a vector
<FL4SHK> such that it could be placed on ports, for example
<FL4SHK> I want it to work with `unsigned`, `signed`, and `Record` (or `PackedStruct` once that's a thing)
<FL4SHK> so I'm storing every element in an `unsigned` right now, and I'm going to use `word_select()` to get or set a single element
<FL4SHK> for `Record`s being stored in a `PackedArray`, the goal would be to not need to cast the result of `__getitem__`
<FL4SHK> I don't currently know how to set that up
<FL4SHK> I think it's got a simple solution.
<whitequark> FL4SHK: `PackedStruct` would be purely a bit struct and would probably not allow interior Arrays
<whitequark> `Interface` should definitely allow interior arrays to be used in ports
<whitequark> what you're doing seems reasonable
<FL4SHK> Okay, that makes me happy
<FL4SHK> I often hear things like that from people, which gives me a warm fuzzy
<FL4SHK> every time
<whitequark> so, I missed one of your messages
<whitequark> I don't think it is currently feasible to put `Record`s in a `PackedArray`
<whitequark> the reason is that a `Record` is a collection of `Signal`s, but your `PackedArray` is backed by a single Signal
<FL4SHK> hmmm
<whitequark> the idea behind interfaces is that an `Interface` never packs anything
<whitequark> so it's just a nested collection of, eventually, `Signal`s
<whitequark> which is also why it is trivial to have an `Interface` as a port: it just gets exploded when lowering to RTL
<FL4SHK> do you have any plans for `Interface`s with `Array`s in them to be placed on ports?
<whitequark> I haven't had detailed plans but the way `Interface` works naturally makes it extensible to having `Array`s inside
<whitequark> so, yes, that should eventually work
<FL4SHK> cool
moony has quit [Quit: Bye!]
chipmuenk has quit [Quit: chipmuenk]
moony has joined #nmigen
_whitelogger has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Ping timeout: 264 seconds]
jeanthom has quit [Ping timeout: 260 seconds]
Asuu has quit [Quit: Konversation terminated!]
<_whitenotifier-f> [nmigen] Xiretza synchronize pull request #506: Update error message for Instance arguments -
<_whitenotifier-f> [nmigen] codecov[bot] commented on pull request #506: Update error message for Instance arguments -
<_whitenotifier-f> [nmigen] codecov[bot] edited a comment on pull request #506: Update error message for Instance arguments -
<_whitenotifier-f> [nmigen] codecov[bot] edited a comment on pull request #506: Update error message for Instance arguments -
<_whitenotifier-f> [nmigen] codecov[bot] edited a comment on pull request #506: Update error message for Instance arguments -
<_whitenotifier-f> [nmigen] whitequark closed pull request #506: Update error message for Instance arguments -
<_whitenotifier-f> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-f> [nmigen/nmigen] Xiretza eb152da - Update error message for Instance arguments
<_whitenotifier-f> [nmigen] whitequark commented on pull request #506: Update error message for Instance arguments -
<_whitenotifier-f> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13]
<_whitenotifier-f> [nmigen/nmigen] whitequark 720d076 - Deploying to gh-pages from @ eb152da59b02b2fd87ee46b7cf3714282a27c3d6 🚀