@lofty huh, yeah that sounds like a pain to deal with. I've not observed that myself, but aside from high EBR utilization nextpnr tells me I'm using ~0% of the logic tiles so I guess I'm not giving it much of a workout.
-
@lofty huh, yeah that sounds like a pain to deal with. I've not observed that myself, but aside from high EBR utilization nextpnr tells me I'm using ~0% of the logic tiles so I guess I'm not giving it much of a workout.
Either way I'm sticking to the defaults for now, I just have it parked in my head that static@HEAD seems to manage to extract ~5-10MHz more Fmax on average, if I ever need it. But right now I can get more improvement than that by making better designs still.
-
big awoo notationreplied to Dave Anderson last edited by
@[email protected] it's a little funny to think about how nextpnr kinda differs compared to the classical academic flow.
classically, LUTs and flops get packed into what the ECP5 calls slices, and these slices get placed in physical locations on the FPGA ("bels").
nextpnr used to do that for ECP5 (if you feel like some nextpnr archaeology I can point you to what you need to do to build that), but at some amount of my nagging, Myrtle changed the ECP5 representation to make nextpnr directly place LUTs and flops into physical locations, without a packing pass. -
Dave Andersonreplied to big awoo notation last edited by
@lofty Knowing nothing about how this works, that strategy feels like it's quite a bit harder to solve, no? I assume the purpose of separate packing is to reduce the size of the placing problem, and eliminate invalid packing configurations upfront?
But then I presume to get to the next level of place/route quality, you need a bunch of compensating heuristics for "hmm place made a mistake, if I swap parts between these two slices that ends up better", whereas nextpnr gets that for "free"?...