clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
Cerpin has quit [Remote host closed the connection]
Cerpin has joined #yosys
alexhw has quit [Ping timeout: 260 seconds]
alexhw has joined #yosys
<jjjaaaccckkk> Or anyone know Mathias and can ask if he is open to sharing them?
citypw has joined #yosys
QK_b00m3r is now known as OK_b00m3r
develonepi3 has quit [Remote host closed the connection]
_whitelogger has joined #yosys
ric96 has quit [Ping timeout: 245 seconds]
daveshah has quit [Ping timeout: 245 seconds]
_florent_ has quit [Ping timeout: 245 seconds]
bubble_buster has quit [Ping timeout: 245 seconds]
ric96 has joined #yosys
daveshah has joined #yosys
bubble_buster has joined #yosys
_florent_ has joined #yosys
phire has quit [*.net *.split]
_whitelogger has joined #yosys
emeb_mac has quit [Quit: Leaving.]
dys has quit [Ping timeout: 268 seconds]
_whitelogger has joined #yosys
<az0re> No, unfortunately, I've never met him. But it sounds like Clifford knows him reasonably well. Maybe you can ask him to ask Mathias to post them publicly/more prominently?
dys has joined #yosys
adjtm_ has joined #yosys
adjtm has quit [Ping timeout: 258 seconds]
<plaes> jjjaaaccckkk: there's prjxray for xilinx7
vidbina_ has joined #yosys
vidbina_ has quit [Ping timeout: 260 seconds]
citypw has quit [Ping timeout: 268 seconds]
fsasm has joined #yosys
lutsabound has joined #yosys
<ZirconiumX> daveshah: Is there a way to get nextpnr to output longest combinational path in out-of-context mode?
<daveshah> I don't know
<daveshah> The current timing analysis code is a bit crap
<daveshah> You could always just wrap you combinational logic in two registers
<daveshah> That should make it actually optimise for timing too
<ZirconiumX> Ah, yes, that works, thank you
<ZirconiumX> Unfortunately the critical path report is...unhelpful.
<daveshah> I suspect the problem is more abc than anything nextpnr
<ZirconiumX> autoname at least is giving very painful names
<ZirconiumX> Source \$4560_LUT4_Z_53_A_LUT4_Z_D_LUT4_Z_B_LUT4_Z_D_LUT4_C_Z_LUT4_D_B_LUT4_Z_SLICE.F1
<ZirconiumX> ERROR: Assert `existing_cell' failed in passes/techmap/abc9.cc:510
<ZirconiumX> Oh goody.
<daveshah> I think there were some changes to abc9 recently, they may well have broken something
<ZirconiumX> Bugpointing
_whitelogger has joined #yosys
GenTooMan has quit [Ping timeout: 260 seconds]
show1 has quit [Quit: WeeChat 2.6]
GenTooMan has joined #yosys
phire has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale` is now known as X-Scale
dys has quit [Ping timeout: 268 seconds]
vidbina_ has joined #yosys
dys has joined #yosys
GenTooMan has quit [Quit: Leaving]
emeb_mac has joined #yosys
thasti has quit [Remote host closed the connection]
gmc has quit [Ping timeout: 260 seconds]
gmc has joined #yosys
Laksen has joined #yosys
rjo has joined #yosys
fsasm has quit [Ping timeout: 240 seconds]
<rjo> on iCE40, SB_IO, from the silicon blue schematics: if CLOCK_ENABLE goes high while the clock is already high, that would create a spurious late clock edge for the FFs in the SB_IO. I.e. That spurious clock edge could easily violate timing. Is that correct?
<daveshah> This was discussed a few months ago
<whitequark> rjo: the siliconblue schematics for SB_IO are blatantly wrong
<daveshah> The conclusion was the diagram is wrong
<daveshah> Yup
vidbina_ has quit [Ping timeout: 258 seconds]
<whitequark> it does not match common sense or silicon behavior
rombik_su has quit [Quit: Leaving]
Jybz has quit [Quit: Konversation terminated!]
vidbina_ has joined #yosys
Laksen has quit [Quit: Leaving]
show1 has joined #yosys
jjjaaaccckkk has quit [Ping timeout: 240 seconds]
GenTooMan has joined #yosys
tpb has quit [Remote host closed the connection]
tpb has joined #yosys