<Sarayan>
I'm very intrigued by the way you using nmigen
<Sarayan>
very nice
<Sarayan>
not sure I get the point of conditional = m.If, but I love the lambda reductions
<ktemkin>
it's just metaprogramming that strums along nmigen's context managers
<ktemkin>
it'll loop over priority-encoder conditions and go m.If, m.Elif, m.Elif
<ktemkin>
and thanks; I'm gradually refining my sense of how-I-want-to-use-nmigen :)
<Sarayan>
Yeah, I'm using it to translate mosfet-level schematics to hdl code, so that's entirely different constraints
lkcl has joined #nmigen
_whitelogger has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Ping timeout: 256 seconds]
Asu has joined #nmigen
Asuu has quit [Ping timeout: 264 seconds]
lkcl has quit [Ping timeout: 250 seconds]
lkcl has joined #nmigen
<whitequark>
ZirconiumX: that's definitely an off by one error
<whitequark>
mithro: pydeps probably won't be very useful. with simple projects it's easier to read the code, with complex ones it produces a mess of a graph
<awygle>
hi wq
<whitequark>
hi
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
Vinalon has joined #nmigen
<_whitenotifier-3>
[nmigen] whitequark commented on issue #181: Reconsidering AsyncFIFO and resets - https://git.io/JvpCK
alexhw has quit [Ping timeout: 250 seconds]
alexhw has joined #nmigen
<_whitenotifier-3>
[nmigen] awygle commented on issue #181: Reconsidering AsyncFIFO and resets - https://git.io/JvpWd
Vinalon has quit [Remote host closed the connection]
<Vinalon>
I have a question about timing optimization: I have a design which reads words of data over SPI, and from the timing report, it looks like the (fairly long) critical path boils down to the logic which reads the MISO pin, which is basically:
<Vinalon>
I'm guessing that the left-shift operation is causing some sort of chain of logic, but I don't quite understand why; is there a better way to handle this sort of logic?
<tpw_rules>
what is 5 bit counter?
<tpw_rules>
it looks like a barrel shifter, which is large and expensive
<Vinalon>
It's a Signal(5) which gets decremented every clock cycle
<tpw_rules>
then you probably just want data[counter].eq(miso)
<tpw_rules>
you're thinking in software
<Vinalon>
oh. I didn't realize you could use bit-selects for left-hand values, cool
<Vinalon>
yeah, it's a bad habit :P
<Vinalon>
thanks!
<tpw_rules>
even if you couldn't, (and i'm fairly certain you can), you should say like data = (data >> 1) | miso
<Vinalon>
oh, to minimize the number of shifts it needs to perform? Makes sense, thanks
<tpw_rules>
a shift by a constant is just rewiring. it's completely free
<tpw_rules>
shifting by a varying amount requires large numbers of large muxes
<Vinalon>
ah. Yeah, the `data[ variable ].eq(...)` syntax isn't allowed, but I think I get the idea.
<tpw_rules>
it's not? huh
<Vinalon>
"TypeError: Cannot index value with (sig <name>)"
<tpw_rules>
i mean you're probably right i just thought it was. data may need to be an Array
<Degi>
Ohh I did implement a similar thing once
<Degi>
You need a Cat()
<Degi>
Like Cat(data[variable]).eq(...)
<Degi>
In my specific case I change part of databuf like this: m.d.sync += Cat(databuf[step * i:step * (i+1)]).eq(datain)
<tpw_rules>
Degi: that doesn't sound like it would help. the exception came from data[variable]
<Degi>
data is a signal, right?
<Vinalon>
yeah, I still get a type error from that, but I might be calling it wrong...`data.eq((data << 1) | miso)` seems to work though, thanks
<Degi>
I use a for loop to scan over all possible cases and then use m.Case() to create a switch statement. Not sure how efficient that is in gateware to be honest...
<Vinalon>
yeah - it sounds like that might be because of the same 'constants are much faster' constraint?
Asuu has quit [Quit: Konversation terminated!]
<Degi>
But yeah what you wrote should work just fine too
<tpw_rules>
Vinalon: that could also be Cat(miso, data). it would probably be clearer that way
<Degi>
Maybe even more efficient in terms of gate ware
<Vinalon>
oh yeah, that's a great idea
<Vinalon>
thanks for the help - I've probably got a lot of variable-length bit shifts to prune out now :)
<Vinalon>
would I be right to assume that arithmetic operations between Signals are also larger/slower than bitwise logic because of the carry logic and stuff?
lkcl has joined #nmigen
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined #nmigen
<Degi>
The larger an adder is the slower it is, yes
<awygle>
Vinalon: you needed "bit_select" to do that indexing (instead of the [] operators)
<Vinalon>
ah, thanks; good to know
<Vinalon>
yeah, `data.bit_select( count, 1 ).eq( miso )` seems to work
<Degi>
Oh neat. I can probably replace my code with that
<ZirconiumX>
Vinalon: The carry logic is fast for what it is, but in general you want stuff to be as parallel as possible.