<janrinze>
nextpnr-ecp5 gives me results from 55 MHz up to 74 Mhz for the same design in different runs with -r enabled
<janrinze>
any clue on how to get the most out of nextpnr?
<ZirconiumX>
janrinze: The thing about basically all PnR algorithms is that they're probabilistic
<ZirconiumX>
There is no way to "get the most out of nextpnr" other than to keep rolling the dice until you get lucky
<whitequark>
that's not entirely true
<whitequark>
you could make a fully analytical pnr
<ZirconiumX>
I'm pretty sure PnR is NP though, right?
<whitequark>
if you want to do it optimally, yes
<emily>
there are two wolves in my brain. one of them thinks placing should be entirely analytic. the other is mumbling something about neural net pnr
<whitequark>
but you don't need to do it optimally, do you? e.g. you can compute a series of approximate solutions that would converge to the optimal one at some point, and just never actually do it
<janrinze>
I'm thinking about a loop that reruns nextpnr several times until it gets a good result. It might be interesting to optimize that method by only keeping the fastest result
<whitequark>
interestingly, nextpnr became much faster with a semi-analytical placer
<janrinze>
i just had two hits in a row where the results are >72 MHz. lucky streak?
<sorear>
there’s no reason in principle for a deterministic approximation algorithm to be impossible
<janrinze>
sorear: but there is also no reason for that algorithm to produce the most optimal result..
<janrinze>
sorear: it's about having a deteministic algorthm that also finds the optimal result.
<whitequark>
janrinze: it's not possible to have optimal pnr
<whitequark>
(for any realistic fpga and design)
<whitequark>
just like it's not possible to emit optimal machine code
<whitequark>
(for any realistic cpu and program)
<janrinze>
whitequark: optimal != perfect
<whitequark>
i'm not sure what you mean by "perfect" but if the goal of a pnr algorithm is to optimize your design for speed, "optimal" means "highest possible fmax"
<janrinze>
whitequark: optimal means the configuration that is the best fit within the possible solutions the system can provide.
<whitequark>
yes. that's the same thing.
<janrinze>
highest possible fmax could be achieved in many ways we don't even have knowledge of today.
<whitequark>
for many of my designs i don't even care what fmax is as long as it meets the constraints
<ZirconiumX>
Generally there's a "fast enough" point, yeah.
<whitequark>
if the constraints are external and static, i actually *don't* want pnr to try harder. i just want it to meet my 48 MHz or whatever as quickly as possible
<ZirconiumX>
For all the shit I give Quartus, it's pretty good at that
<janrinze>
true, that. But it's a bit of a Pita if that fmax is only achieved 1 out of 10 runs.
<whitequark>
that's certainly true
<whitequark>
maybe there should be some sort of flag for nextpnr that says "if you didn't meet constraints, rip up and try again"
<janrinze>
I have 3 results that are >74 MHz. constraint is 72 Mhz. but often it only reaches 56 or 58 MHz. The variation is quite a lot. ( 18/56 => 32% )
<whitequark>
isn't it 22%
<whitequark>
still a lot
<whitequark>
probably stuck in a local minimum of some sort
pepijndevos has quit [Ping timeout: 246 seconds]
gnufan_home has quit [Quit: Leaving.]
attie has quit [Read error: Connection reset by peer]
pepijndevos has joined #yosys
attie has joined #yosys
<janrinze>
I do think that it's doing a great job though.
Ekho has joined #yosys
<promach>
For nextPnR-ice40 , How to generate the json file for a particular verilog code design ?