<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?
<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`?
<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: but...it'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>
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 - https://git.io/JTlBh
<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 - https://git.io/JTlu6
<_whitenotifier-f>
[nmigen] whitequark commented on issue #507: How to implement support for arrays on ports - https://git.io/JTlzk
<_whitenotifier-f>
[nmigen] fl4shk commented on issue #507: How to implement support for arrays on ports - https://git.io/JTlz8
<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