<maikmerten>
hi there, does anybody know if icetime has an option to display something like "the top 10 most critical paths"?
<maikmerten>
(in my design the critical path reported is a multi-cycle path and I'm curious what the first "proper" critical path is)
cemerick has quit [Ping timeout: 245 seconds]
fsasm has quit [Ping timeout: 256 seconds]
sklv has joined #yosys
dys has quit [Ping timeout: 252 seconds]
fsasm_ has joined #yosys
leviathan has quit [Ping timeout: 256 seconds]
leviathan has joined #yosys
jeandet has quit [Read error: Connection reset by peer]
jeandet has joined #yosys
sklv has quit [Remote host closed the connection]
sklv has joined #yosys
jkiv has joined #yosys
jkiv has quit [Max SendQ exceeded]
jkiv has joined #yosys
jkiv has quit [Max SendQ exceeded]
jkiv has joined #yosys
* ZipCPU
starts looking into maikmerten's query
<ZipCPU>
maikmerten: Have you looked at the icetime help function? "icetime -h"
leviathan has quit [Ping timeout: 268 seconds]
leviathan has joined #yosys
tpb has joined #yosys
leviathan has quit [Remote host closed the connection]
quigonjinn has joined #yosys
jkiv has quit [Remote host closed the connection]
jkiv has joined #yosys
seldridge has quit [Ping timeout: 245 seconds]
seldridge has joined #yosys
<maikmerten>
ZipCPU, yup, I have :)
<ZipCPU>
Does the -r filename option solve your problem?
<maikmerten>
nah, that'll generate the usual timing report naming "the" critical path - but will write it into a file instead of dumping it to stdout
<maikmerten>
(just tried this)
<maikmerten>
but thanks for the suggestion!
<ZipCPU>
Here ... let me ask someone else ...
<ZipCPU>
Ok, so ... the answer then is that you cannot do it. You can get the timing for the critical path, or a specified net, just not for a "top 10" critical path set.
<maikmerten>
ah, thanks for researching!
<maikmerten>
(having a sorted list of "the worst" paths is something I quite like in Quartus and I wondered if icetime happens to have that feature, too)
<maikmerten>
thanks for the help --> off to bed :-)
maikmerten has quit [Quit: bye!]
jkiv has quit [Quit: Leaving]
fsasm__ has joined #yosys
fsasm_ has quit [Ping timeout: 240 seconds]
cemerick has joined #yosys
jkiv has joined #yosys
fsasm_ has joined #yosys
jkiv has quit [Max SendQ exceeded]
jkiv has joined #yosys
jkiv has quit [Max SendQ exceeded]
jkiv has joined #yosys
fsasm__ has quit [Ping timeout: 252 seconds]
sklv has quit [Remote host closed the connection]
sklv has joined #yosys
seldridge has quit [Ping timeout: 265 seconds]
seldridge has joined #yosys
promach_ has joined #yosys
cr1901_modern has quit [Read error: Connection reset by peer]
nonlinear has joined #yosys
cr1901_modern has joined #yosys
seldridge has quit [Ping timeout: 240 seconds]
<ZipCPU>
Ok, so ... I can prove that Cluff Cummings' asynchronous FIFO will properly flag overflows and underflows.
<ZipCPU>
Just not quite certain how to get the "two transaction abstraction" through induction ...
dxld has quit [Ping timeout: 256 seconds]
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
<promach_>
ZipCPU: you are done with asynchronous FIFO and UART ?
<promach_>
I mean formally verifiying
<ZipCPU>
Not quite on either account. I'm trying to figure out how to do the two-transaction abstraction on the asynchronous FIFO right now. I'm done with the control signals, though.
<promach_>
abstraction ..???
<ZipCPU>
So, the issue is how do you prove that the FIFO actually acts like a, well, a FIFO.
<ZipCPU>
To prove that, you need to place two values into the FIFO, and make certain that you can get those same two values out in the proper order.
<promach_>
with some latency
<ZipCPU>
Yes ... and it has to get past induction too ... ;)