| *** tpb has joined #yosys | 00:00 | |
| *** rohitksingh has joined #yosys | 00:11 | |
| *** X-Scale` has joined #yosys | 00:28 | |
| *** X-Scale has quit IRC | 00:31 | |
| *** X-Scale` is now known as X-Scale | 00:31 | |
| *** rohitksingh has quit IRC | 01:37 | |
| *** PyroPeter has quit IRC | 02:13 | |
| *** ZipCPU has quit IRC | 02:51 | |
| *** ZipCPU has joined #yosys | 03:04 | |
| *** pie__ has quit IRC | 03:37 | |
| *** rohitksingh has joined #yosys | 03:48 | |
| *** citypw has joined #yosys | 03:55 | |
| *** pie_ has joined #yosys | 04:01 | |
| *** rohitksingh has quit IRC | 04:22 | |
| *** _whitelogger has quit IRC | 04:27 | |
| *** _whitelogger has joined #yosys | 04:29 | |
| *** Jybz has joined #yosys | 04:56 | |
| *** citypw has quit IRC | 05:14 | |
| *** pie_ has quit IRC | 05:19 | |
| *** MrBismuth has quit IRC | 05:19 | |
| *** MrBismuth has joined #yosys | 05:25 | |
| *** Jybz has quit IRC | 05:30 | |
| *** dys has quit IRC | 06:35 | |
| *** pie_ has joined #yosys | 07:31 | |
| *** smarter has quit IRC | 08:43 | |
| *** vup2 has quit IRC | 08:43 | |
| *** TD-Linux has quit IRC | 08:44 | |
| *** smarter has joined #yosys | 08:45 | |
| *** Kokjo has quit IRC | 08:45 | |
| *** vup has joined #yosys | 08:45 | |
| *** gmc has quit IRC | 08:45 | |
| *** TD-Linux has joined #yosys | 08:45 | |
| *** Spida has quit IRC | 08:45 | |
| *** gmc has joined #yosys | 08:45 | |
| *** Spida has joined #yosys | 08:46 | |
| *** pepijndevos has quit IRC | 08:47 | |
| *** pepijndevos has joined #yosys | 08:49 | |
| *** craigo has quit IRC | 10:21 | |
| *** cr1901_modern has quit IRC | 13:41 | |
| *** daveshah has quit IRC | 14:38 | |
| *** daveshah has joined #yosys | 14:38 | |
| *** emeb has joined #yosys | 15:28 | |
| *** whitequark has joined #yosys | 15:53 | |
| whitequark | 18:23 <rjo> Well. It doesn't do anything on ice40 because the parameter is ignored by nextpnr... | 15:53 |
|---|---|---|
| whitequark | i would suggest filing a nextpnr bug | 15:53 |
| daveshah | A bug was filed and the issue was fixed :) | 15:53 |
| whitequark | oh oops, i should've checked. | 15:54 |
| emily | daveshah: your latency-to-merged-fix is truly impressive | 15:54 |
| emily | I felt guilty throwing up a 10k line RTLIL tarball | 15:54 |
| whitequark | ZirconiumX: re: flowmap crash | 15:54 |
| whitequark | have you seen the bugpoint pass? | 15:54 |
| daveshah | These small things are usually easier to fix there and then rather than put on the todo list | 15:54 |
| ZirconiumX | whitequark: I was using that very pass to try to find it | 15:55 |
| ZirconiumX | Unfortunately because flowmap -relax takes forever I didn't get very far with it before turning my computer off for the night | 15:55 |
| whitequark | hm | 15:55 |
| whitequark | it should not take forever | 15:55 |
| ZirconiumX | (metaphorically) | 15:55 |
| whitequark | it's polynomial complexity in theory, and should be pretty fast in practice | 15:55 |
| whitequark | ah | 15:55 |
| ZirconiumX | It's "I just turned Yosys into Quartus" speed | 15:56 |
| whitequark | hmmm | 15:56 |
| whitequark | still seems like a problem | 15:56 |
| whitequark | flowmap *ought* to be fast. faster than abc in some cases, even | 15:56 |
| ZirconiumX | My experience has been the very opposite, sadly. | 15:56 |
| whitequark | then that seems like a bug | 15:57 |
| whitequark | that said, i haven't had time to work on flowmap much | 15:57 |
| ZirconiumX | So, my benchmark here is aoR3000 | 15:59 |
| ZirconiumX | Which is a MIPS R3000 softcore | 15:59 |
| whitequark | that's pretty huge | 16:00 |
| whitequark | i've never tested flowmap on anything larger than picorv32 | 16:00 |
| ZirconiumX | Using my experimental Cyclone synthesis script, Yosys takes 35.87 seconds clock time to build it | 16:01 |
| ZirconiumX | s/build/synthesise/ | 16:01 |
| ZirconiumX | Yosys says most of the CPU time is spent in techmap there | 16:02 |
| daveshah | Often the case | 16:02 |
| ZirconiumX | Well I've got to spend a lot of time renaming cells, but that's just life | 16:03 |
| ZirconiumX | Yaaay Quartus... | 16:03 |
| ZirconiumX | whitequark: It spends a very long time labelling cells | 16:04 |
| whitequark | labelling? | 16:04 |
| whitequark | oh, interesting | 16:04 |
| whitequark | that seems like a clear bug | 16:04 |
| ZirconiumX | So, that was 2m57.914s to build the same code | 16:04 |
| ZirconiumX | Yosys says 154 seconds of the 165 seconds of CPU time was spent in flowmap | 16:05 |
| ZirconiumX | And it leaks cells to boot. | 16:05 |
| whitequark | leaks cells? | 16:05 |
| ZirconiumX | When it fails to map a cell I ask it to map | 16:06 |
| ZirconiumX | I call that a cell leak | 16:06 |
| whitequark | ah | 16:06 |
| ZirconiumX | https://pastebin.com/vaRCJ1fv <-- e.g. these $_AND_ cells should be LUTs | 16:07 |
| whitequark | which cells specifically? | 16:07 |
| whitequark | aha | 16:07 |
| whitequark | seems clearly broken | 16:07 |
| ZirconiumX | flowmap -maxlut 6 -cells $_AND_,$_MUX_,$_NOT_,$_OR_,$_XOR_ | 16:07 |
| whitequark | yeah that should work | 16:07 |
| ZirconiumX | And then if I specify -relax, well | 16:08 |
| ZirconiumX | Just hit enter | 16:08 |
| ZirconiumX | I'll let you know the error message in about fifteen minutes or so | 16:09 |
| whitequark | right, i suspect one problem is that it doesn't partition the graph currently | 16:09 |
| ZirconiumX | While this runs I guess I'll add differential I/O for vendor.altera | 16:10 |
| ZirconiumX | whitequark: ERROR: Assert `(int)lut_edges_bw[succ].size() < order' failed in passes/techmap/flowmap.cc:829. | 16:11 |
| ZirconiumX | 2m47.232s | 16:11 |
| whitequark | interesting | 16:12 |
| Ultrasauce | <ZirconiumX> It's "I just turned Yosys into Quartus" speed | 16:17 |
| Ultrasauce | ah yes this will go well with the license server PR im writing | 16:17 |
| ZirconiumX | You're welcome, Ultrasauce :P | 16:17 |
| daveshah | Well, there's a version of Yosys with a license manager already | 16:17 |
| daveshah | albeit somewhat nicer than flexlm | 16:17 |
| * whitequark senses a conflict of interest within | 16:20 | |
| ZirconiumX | As a side note I'm still highly confused about Yosys BRAM parameters, which is why there's a $__MISTRAL_MLAB leaking too | 16:24 |
| *** cr1901_modern has joined #yosys | 16:32 | |
| ZirconiumX | Well, bugpoint is slowly progressing | 16:53 |
| ZirconiumX | Would be nice if the crash didn't take yonks to occur | 16:54 |
| whitequark | the idea behind bugpoint (the LLVM pass) is that CPU time is much cheaper than engineer time | 16:56 |
| whitequark | it was written by Google originally I think. | 16:56 |
| whitequark | so they can just throw stuff at some compute and forget about it. | 16:56 |
| *** alexhw has quit IRC | 16:57 | |
| *** alexhw has joined #yosys | 17:01 | |
| emily | unfortunately, people have to pay the same amount for all our time | 17:02 |
| *** promach has joined #yosys | 17:16 | |
| ZirconiumX | whitequark: So I wasn't specific enough with my grep | 17:40 |
| ZirconiumX | ERROR: Assert `lut_edges_fw[maybe_mergeable_pair.first][maybe_mergeable_pair.second]' failed in passes/techmap/flowmap.cc:1131 | 17:40 |
| ZirconiumX | Assert `current_val[i].wire != NULL || current_val[i] == value.bits[i]' failed in ./kernel/consteval.h:79 | 17:40 |
| whitequark | hm | 17:40 |
| ZirconiumX | So, I was kinda dumb, but oh well | 17:41 |
| ZirconiumX | I found a completely unrelated bug | 17:41 |
| ZirconiumX | yay | 17:41 |
| *** rohitksingh has joined #yosys | 17:46 | |
| *** Jybz has joined #yosys | 17:49 | |
| *** rohitksingh has quit IRC | 18:04 | |
| *** rohitksingh has joined #yosys | 18:05 | |
| *** pie_ has quit IRC | 18:21 | |
| *** Jybz has quit IRC | 18:21 | |
| *** rohitksingh has quit IRC | 18:44 | |
| *** attie has joined #yosys | 19:03 | |
| *** attie has quit IRC | 19:06 | |
| *** pie_ has joined #yosys | 19:13 | |
| *** rohitksingh has joined #yosys | 19:17 | |
| *** attie has joined #yosys | 19:18 | |
| *** rohitksingh has quit IRC | 20:21 | |
| *** rohitksingh has joined #yosys | 20:26 | |
| *** emeb_mac has joined #yosys | 20:48 | |
| *** gnufan_home has joined #yosys | 21:07 | |
| *** rohitksingh has quit IRC | 21:42 | |
| *** attie has quit IRC | 22:07 | |
| *** attie has joined #yosys | 22:08 | |
| janrinze | nextpnr-ecp5 gives me results from 55 MHz up to 74 Mhz for the same design in different runs with -r enabled | 22:11 |
| janrinze | any clue on how to get the most out of nextpnr? | 22:11 |
| ZirconiumX | janrinze: The thing about basically all PnR algorithms is that they're probabilistic | 22:17 |
| ZirconiumX | There is no way to "get the most out of nextpnr" other than to keep rolling the dice until you get lucky | 22:17 |
| whitequark | that's not entirely true | 22:20 |
| whitequark | you could make a fully analytical pnr | 22:20 |
| ZirconiumX | I'm pretty sure PnR is NP though, right? | 22:21 |
| whitequark | if you want to do it optimally, yes | 22:21 |
| 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 | 22:22 |
| 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 | 22:23 |
| 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 | 22:23 |
| whitequark | interestingly, nextpnr became much faster with a semi-analytical placer | 22:23 |
| janrinze | i just had two hits in a row where the results are >72 MHz. lucky streak? | 22:24 |
| sorear | there’s no reason in principle for a deterministic approximation algorithm to be impossible | 22:28 |
| janrinze | sorear: but there is also no reason for that algorithm to produce the most optimal result.. | 22:29 |
| janrinze | sorear: it's about having a deteministic algorthm that also finds the optimal result. | 22:30 |
| whitequark | janrinze: it's not possible to have optimal pnr | 22:31 |
| whitequark | (for any realistic fpga and design) | 22:31 |
| whitequark | just like it's not possible to emit optimal machine code | 22:32 |
| whitequark | (for any realistic cpu and program) | 22:32 |
| janrinze | whitequark: optimal != perfect | 22:32 |
| 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" | 22:32 |
| janrinze | whitequark: optimal means the configuration that is the best fit within the possible solutions the system can provide. | 22:33 |
| whitequark | yes. that's the same thing. | 22:33 |
| janrinze | highest possible fmax could be achieved in many ways we don't even have knowledge of today. | 22:33 |
| whitequark | for many of my designs i don't even care what fmax is as long as it meets the constraints | 22:36 |
| ZirconiumX | Generally there's a "fast enough" point, yeah. | 22:37 |
| 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 | 22:37 |
| ZirconiumX | For all the shit I give Quartus, it's pretty good at that | 22:38 |
| janrinze | true, that. But it's a bit of a Pita if that fmax is only achieved 1 out of 10 runs. | 22:38 |
| whitequark | that's certainly true | 22:38 |
| whitequark | maybe there should be some sort of flag for nextpnr that says "if you didn't meet constraints, rip up and try again" | 22:38 |
| 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% ) | 22:41 |
| whitequark | isn't it 22% | 22:44 |
| whitequark | still a lot | 22:44 |
| whitequark | probably stuck in a local minimum of some sort | 22:44 |
| *** pepijndevos has quit IRC | 22:46 | |
| *** gnufan_home has quit IRC | 22:46 | |
| *** attie has quit IRC | 22:47 | |
| *** pepijndevos has joined #yosys | 22:47 | |
| *** attie has joined #yosys | 22:48 | |
| janrinze | I do think that it's doing a great job though. | 22:53 |
| *** Ekho has joined #yosys | 23:30 | |
| promach | For nextPnR-ice40 , How to generate the json file for a particular verilog code design ? | 23:52 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!