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>
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