| *** tpb <[email protected]> has joined #yosys | 00:00 | |
| *** strobo <[email protected]> has quit IRC (Ping timeout: 245 seconds) | 02:30 | |
| *** strobo <[email protected]> has joined #yosys | 02:32 | |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #yosys | 03:18 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 264 seconds) | 03:19 | |
| *** indy <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 06:49 | |
| *** indy <[email protected]> has joined #yosys | 06:55 | |
| *** kristianpaul <kristianpaul!~paul@user/kristianpaul> has quit IRC (Read error: Connection reset by peer) | 07:02 | |
| *** kristianpaul <kristianpaul!~paul@user/kristianpaul> has joined #yosys | 07:06 | |
| *** kraiskil <[email protected]> has joined #yosys | 08:48 | |
| *** kraiskil <[email protected]> has quit IRC (Ping timeout: 264 seconds) | 09:06 | |
| *** kraiskil <[email protected]> has joined #yosys | 10:03 | |
| *** kraiskil <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 10:10 | |
| cr1901 | I'm guessing the answer is "no", but is it possible to get yosys to give more precise src information than "where the beginning of the always block the signal is used in is located"? | 14:10 |
|---|---|---|
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 260 seconds) | 14:42 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #yosys | 14:58 | |
| *** dlobato <[email protected]> has joined #yosys | 16:20 | |
| mwk | not really, src information is kept on a kind-of best-effort basis | 16:24 |
| mwk | (without all that much effort in the first place) | 16:24 |
| mwk | but, could you describe your usecase a little more? | 16:24 |
| cr1901 | mwk: Sure. I have a bitstream that nextpnr-machxo2 creates successfully, but the behavior on FPGA does not match simulation behavior. 1/2 | 16:31 |
| cr1901 | And I have done a, pre-yosys, post-yosys/pre-pnr, and post-pnr simulation of an input stimulus that fails on FPGA | 16:31 |
| cr1901 | All three simulations agree w/ each other in iverilog | 16:31 |
| cr1901 | I've isolated at least _one_ signal in the original verilog whose behavior on the FPGA isn't matching (it's stuck low) | 16:32 |
| cr1901 | and I want to trace this signal from which slice it's stored in backwards to isolate why the signal is stuck low | 16:33 |
| mwk | can you match the name of the signal to something? | 16:34 |
| cr1901 | I can't add an internal LA to probe the signals because disturbing the original Verilog file moves the design around too much and makes the offending signal unstuck | 16:34 |
| cr1901 | Yes, at the post-yosys/pre-pnr level, I've matched the signal, or at least "the signal after ABC has potentially merged it w/ other crap" | 16:35 |
| cr1901 | Would you like the v file and the json yosys produces? | 16:36 |
| mwk | ... huh, the yosys backend involved really only supports a LUT4 and the plainest DFF possible? | 16:37 |
| cr1901 | mwk: Yes, I've not had a good year | 16:37 |
| mwk | well | 16:37 |
| cr1901 | And I don't think I should add more until I make sure the absolute basics are working | 16:38 |
| mwk | first thing I'd try is to approach this from the flow feature side, not test design side | 16:38 |
| mwk | ie. disable flow features until it stops breaking | 16:38 |
| mwk | but it seems you can't really simplify the yosys side, LUT4+DFF is as simple as it gets | 16:38 |
| mwk | is there some non-trivial logic in the packer? | 16:39 |
| cr1901 | No, but there's a caveat I haven't mentioned yet: | 16:39 |
| cr1901 | I'm testing against an old nextpnr version from February (long story). The bug isn't in nextpnr HEAD- nextpnr HEAD generates a proper bitstream. Problem solved, right? | 16:40 |
| cr1901 | What if the bug is just masked b/c the PRNG state changed? | 16:40 |
| cr1901 | There _was_ a bug in the packer I fixed in July | 16:40 |
| mwk | retry with lots of seeds, then | 16:41 |
| mwk | get some idea of how likely the bug is to occur | 16:41 |
| * cr1901 nods | 16:41 | |
| cr1901 | I'll do that now | 16:41 |
| cr1901 | >(12:38:33 PM) mwk: ie. disable flow features until it stops breaking | 16:44 |
| cr1901 | (Oh... duh... I could've added other features and then disabled them. Although that wouldn't help here, that's a shitty excuse for not adding more DFF types) | 16:44 |
| mwk | *shrug* you had your priorities | 16:45 |
| *** lambda <[email protected]> has quit IRC (Quit: WeeChat 3.2) | 16:58 | |
| *** lambda <[email protected]> has joined #yosys | 16:58 | |
| *** dlobato <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 17:00 | |
| cr1901 | With seeds 0-10 on the bad nextpnr, only 2 of them work properly. I just realized I could automate this too | 17:02 |
| * cr1901 tries the good nextpnr next | 17:03 | |
| cr1901 | And with the good nextpnr, all seeds 0-10 work | 17:07 |
| cr1901 | Guess the bug was fixed... I'll need to test more than seed 0 (or whatever the default is) when making changes | 17:08 |
| mwk | this resolves the original issue, right? | 17:24 |
| cr1901 | Yes, but I'd like to understand why for future-me. Up until this point, I've done bugfixes for assertion failures. And earlier I isolated the commit where seed "0" stopped breaking and thought to myself "that can't be right" | 17:25 |
| cr1901 | https://github.com/YosysHQ/nextpnr/commit/b1f25d4b33a40666a2f483ee3875074c65c2ac68 Commit that supposedly fixes it, and I don't remember why I needed this commit (Feb 22, ignore date) | 17:26 |
| mwk | hmm | 17:27 |
| mwk | well you can test before/after with more seeds, right? | 17:27 |
| mwk | timing changes leading to corectness changes are not impossible | 17:28 |
| mwk | don't know that much about how router works, but presumably if pips are 0-cost, there's no need to optimize the length of the path at all | 17:28 |
| cr1901 | Sure, I could even automate the testing. This particular commit did not make it into my initial PR. So I found out it was needed as part of a bug fix | 17:28 |
| cr1901 | (Unless gatecat asked me to make this change, which is possible- I'll have to look at logs) | 17:29 |
| mwk | (and the real fun part is when you get hold time violations and cannot even see them because you have no timing data!) | 17:29 |
| cr1901 | Yes indeed. My assumption throughout this is: It's a f***ing UART, you have bigger problems if you have a timing violation at 12MHz | 17:30 |
| mwk | hmm, how fast is the Mach-XO2 fabric anyway? | 17:30 |
| mwk | also: do you have dedicated clock routing in nextpnr already? | 17:31 |
| mwk | because if not... it's really easy to fuck up and get a hold violation | 17:31 |
| cr1901 | It's in the database, it's not routed | 17:31 |
| mwk | uhoh. | 17:31 |
| mwk | yeah, non-dedicated clock routes without good timing analysis == you will die by hold time violation | 17:32 |
| mwk | and those don't care about clock frequencies | 17:32 |
| mwk | I've been there... | 17:32 |
| cr1901 | Well, I'm satisfied w/ that explanation, tbh | 17:33 |
| cr1901 | mwk: the "bad" nextpnr I'm testing is one commit away from the commit I linked, plus another commit that fixed a txt cfg generation problem | 17:35 |
| cr1901 | in other words, they're effectively one commit away from each other, so if 10 seeds work on the linked commit, and they didn't work just before that commit, I'm confident that the linked commit actually did fix the problem | 17:35 |
| mwk | mhm | 17:36 |
| mwk | *whispers* it's timiiiiing | 17:36 |
| cr1901 | (I would be very worried if fixing a txt cfg bug affected pnr) | 17:36 |
| * cr1901 nods | 17:36 | |
| cr1901 | All of this crap happened by chance T_T. I accidentally checked out an old branch w/o realizing how old it was for a demo. | 17:37 |
| mwk | oops | 17:37 |
| cr1901 | Built the UART demo, got an assert failure. That was txt cfg bug. | 17:38 |
| cr1901 | That's a legitimate bug that's not patched in HEAD yet. | 17:38 |
| cr1901 | Ironically probably only found b/c seed 0 generated _just_ the correct routing w/ the _very_ bad timing info | 17:38 |
| cr1901 | Then I fix the txt cfg bug, and I can't get any of my bitstreams to work T_T | 17:39 |
| cr1901 | I figured "well I already found one legit bug using this old commit, what if I find another?!" | 17:39 |
| cr1901 | And I wasted half this weekend. The end! | 17:39 |
| cr1901 | Thanks for the help, I probably would've wasted my whole weekend and then some w/o your help | 17:40 |
| *** vidbina <[email protected]> has joined #yosys | 17:44 | |
| *** vidbina <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 19:00 | |
| *** dlobato <[email protected]> has joined #yosys | 20:08 | |
| *** dlobato <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 20:23 | |
| *** vidbina <[email protected]> has joined #yosys | 20:44 | |
| *** vidbina <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 21:39 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!