<dcarr>
Curious if anyone has done thinking/work on adding external IO timing constraints to nextpnr?
<dcarr>
(something along the lines of set_input_delay, set_output_delay in SDC files)
nelgau has quit [Remote host closed the connection]
dcarr has quit [Quit: Client closed]
<tnt>
and ... he waited a whole 14 min for an answer ...
dcarr has joined #yosys
dcarr has quit [Ping timeout: 256 seconds]
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined #yosys
dcarr has joined #yosys
dcarr has quit [Ping timeout: 256 seconds]
vidbina has joined #yosys
vidbina has quit [Ping timeout: 240 seconds]
vidbina has joined #yosys
vidbina has quit [Ping timeout: 256 seconds]
uis has joined #yosys
<uis>
How chipdb compression works?
nak has quit [Ping timeout: 260 seconds]
AdamHorden has quit [Quit: Adam Horden]
AdamHorden has joined #yosys
vidbina has joined #yosys
vidbina has quit [Ping timeout: 240 seconds]
kraiskil has joined #yosys
gsmecher has joined #yosys
nelgau has joined #yosys
dcarr has joined #yosys
<dcarr>
tnt: Sorry, got booted off last night and didn't realize it. Glad to hear about anyone's present thinking (if any) about IO timing constraints in nextpnr.
<tnt>
I'm not sure about ECP5, but at least for ice40 those timing info haven't been extracted, so the first step would be to do that.
<dcarr>
That makes sense. I was digging into the ICE40 timing data and it looked to me like the "timing netlist" ended short of the actual IO pad.
<dcarr>
I haven
<dcarr>
*haven't messed with the fuzzer previously, but it seems like it could be extended to capture that
<dcarr>
tnt: Recently watched your stream from April 2020 on ICE40 IO timing. It was really well done, thanks!
vidbina has joined #yosys
<tnt>
Tx.
vidbina has quit [Ping timeout: 268 seconds]
kraiskil has quit [Remote host closed the connection]