clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
lf has quit [Ping timeout: 250 seconds]
lf has joined #yosys
sm2n has joined #yosys
citypw has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
sm2n has quit [Ping timeout: 240 seconds]
citypw has joined #yosys
Degi_ has joined #yosys
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
roamingryan has joined #yosys
lansiir has joined #yosys
oldtopman has quit [Read error: Connection reset by peer]
roamingryan has quit [Ping timeout: 260 seconds]
danvet has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
kraiskil has joined #yosys
citypw has joined #yosys
citypw has quit [Remote host closed the connection]
citypw has joined #yosys
roamingryan has joined #yosys
vidbina has joined #yosys
emeb has joined #yosys
sm2n has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
roamingryan has quit [Ping timeout: 265 seconds]
kraiskil has quit [Ping timeout: 246 seconds]
roamingryan has joined #yosys
roamingryan has quit [Client Quit]
kraiskil has joined #yosys
danvet has quit [Ping timeout: 260 seconds]
danvet has joined #yosys
danvet has quit [Ping timeout: 260 seconds]
kraiskil has quit [Ping timeout: 240 seconds]
danvet has joined #yosys
kraiskil has joined #yosys
danvet has quit [Ping timeout: 260 seconds]
kraiskil has quit [Ping timeout: 246 seconds]
kraiskil has joined #yosys
kraiskil has quit [Excess Flood]
kraiskil has joined #yosys
kraiskil has quit [Excess Flood]
kraiskil has joined #yosys
vidbina has quit [Ping timeout: 240 seconds]
bluesceada has quit [*.net *.split]
Xark has quit [*.net *.split]
Xark has joined #yosys
bluesceada has joined #yosys
kraiskil has quit [Ping timeout: 260 seconds]
kraiskil has joined #yosys
chipdsgr has joined #yosys
kraiskil has quit [Ping timeout: 240 seconds]
<agg> gatecat: on ecp5 alu, the output of one can be the carry input of the next, but the position difference depends on where each alu is placed (it's alternatively 4 or 5 columns); am i right in thinking the legacy constr_x can't deal with this and the new cluster stuff in principle could, but would need more supporting work on ecp5?
<gatecat> agg: yes, that's correct, indeed this kind of thing was one of the use cases for the new API
<agg> any idea if this would be tricky or relatively simple?
<agg> i haven't looked at the cluster stuff in much detail yet, not sure if there's any examples to crib from for something like this
<gatecat> no, the lack of examples to implement from would be the main problem here
<gatecat> let me think about this over the weekend
<agg> thanks, no rush or anything, was just curious after someone asked in #nmigen
<agg> it turns out if you do set the bel locations for all the mults and alus, you can implement the 72x72 -> 144 wide multiply that diamond generates
<agg> (well you need to delete a couple of unused cin inputs that it doesn't like, but otherwise pretty much just worked)
<gatecat> oh nice
<agg> i have been slowly working on fuzzing and adding timing info for the alus, since atm it's just there for mults, but at some point want to go through all the various diamond-generated dsp verilogs and get them working in npnr
<agg> happy to have a go at adding alu-to-alu placement support some time though
<gatecat> that'd be really nice, thanks for your work on this!
<agg> no problem at all, thank you for all the rest of it!