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
Degi_ has joined #yosys
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
<agg> gatecat: in https://github.com/YosysHQ/yosys/pull/677/commits/b65932edc4a00860cafc04f962f2a08dd782b075 a bunch of seemingly-valid parameters for mult18x18d and alu54b were removed, can you remember why? as far as I can tell they're all accepted by diamond for synthesis (and are described in the documentation)
<agg> did it just turn out they don't have any effect on synthesis or something? could it still make sense to accept them so that code which targets diamond and specifies them continues to work on yosys?
danvet has joined #yosys
srk has joined #yosys
m4ssi has joined #yosys
m4ssi has quit [Remote host closed the connection]
<gatecat> agg: iirc they might not have actually changed something?
srk has quit [Quit: ZNC 1.8.2 - https://znc.in]
<agg> gatecat: as far as I can tell most of them do _something_, e.g. MULT_BYPASS on the MULT18 errors if the associated ALU MUX bits in the opcode aren't set to the right input and otherwise it changes a bunch of CIB_DSP bits, most of the register bits also change some number of CE/RST bits but not in quite the same way they do for some other registers, that sort of thing
<agg> a lot of them seem to depend on other attributes, including between connected mult+alu, or they error which might have screwed up fuzzing?
<agg> i couldn't hand-on-heart promise they all do anything meaningful yet though :p
<agg> except maybe REG_OPCODEOP1_1_CLK which I think was just missing all along
vidbina has joined #yosys
forrestv has quit [Quit: ZNC - http://znc.sourceforge.net]
forrestv has joined #yosys
adjtm_ has joined #yosys
adjtm has quit [Remote host closed the connection]
m4ssi has joined #yosys
X-Scale` has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Now with extra fish!]
AdamHorden has quit [Ping timeout: 240 seconds]
AdamHorden has joined #yosys
X-Scale has joined #yosys
m4ssi has quit [Remote host closed the connection]
forrestv has quit [Quit: ZNC - http://znc.sourceforge.net]
vidbina has quit [Ping timeout: 252 seconds]
vidbina has joined #yosys
Raito_Bezarius has quit [Ping timeout: 260 seconds]
Raito_Bezarius has joined #yosys
vup has quit [Ping timeout: 245 seconds]
vup has joined #yosys
peepsalot has joined #yosys
peepsalot has quit [Ping timeout: 240 seconds]
<agg> gatecat: do you think it would be worth re-adding them to yosys, at least so it matches the docs, even if nextpnr was just set to error on non-default settings? at the least i want to add opcodeop1_1_clk, but could restore the rest, and it seems like eventually some of them could be supported in nextpnr too
<agg> happy to pr, i have a branch ready either way :p
<gatecat> Yes, that seems reasonable to me
<agg> thanks, will pr today
<agg> btw, placement of mult+alu seems to be all working in every situation now
<agg> but I still need to figure out a bunch of cib_dsp bits to get it to work properly
<agg> (well, except if you manually constrain the alu but not the mult heap fails, or if you manually constrain the mult but not the alu, it places the alu itself and moves the mult, ignoring the constraint, so I added a specific error for that, but doesn't seem like a problem)
m4ssi has joined #yosys
vidbina has quit [Ping timeout: 240 seconds]
ZipCPU has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
ZipCPU has joined #yosys
danvet has quit [Ping timeout: 260 seconds]
peepsalot has joined #yosys
m4ssi has quit [Remote host closed the connection]
lf has quit [Ping timeout: 250 seconds]
lf has joined #yosys