| *** tpb has joined #yosys | 00:00 | |
| *** xtro has joined #yosys | 01:07 | |
| *** Degi has quit IRC | 01:29 | |
| *** Degi has joined #yosys | 01:30 | |
| *** craigo has quit IRC | 01:45 | |
| *** craigo has joined #yosys | 02:04 | |
| *** gregdavill_ has quit IRC | 03:09 | |
| *** tlwoerner has joined #yosys | 03:31 | |
| *** citypw has joined #yosys | 05:29 | |
| *** xtro has quit IRC | 06:47 | |
| *** xtro has joined #yosys | 06:48 | |
| *** emeb_mac has quit IRC | 06:55 | |
| *** emeb has quit IRC | 07:03 | |
| *** xtro_ has joined #yosys | 07:15 | |
| *** xtro has quit IRC | 07:16 | |
| *** xtro has joined #yosys | 07:23 | |
| *** xtro has quit IRC | 07:25 | |
| *** Asu has joined #yosys | 07:30 | |
| *** scientes has joined #yosys | 07:58 | |
| *** xtro has joined #yosys | 08:02 | |
| *** xtro has joined #yosys | 08:11 | |
| *** kraiskil has joined #yosys | 08:20 | |
| *** xtro has quit IRC | 08:28 | |
| *** xtro has joined #yosys | 08:38 | |
| *** _whitelogger has quit IRC | 08:48 | |
| *** _whitelogger has joined #yosys | 08:50 | |
| *** xtro has quit IRC | 08:56 | |
| *** ayazar has joined #yosys | 09:35 | |
| *** ayazar has quit IRC | 09:38 | |
| *** craigo has quit IRC | 09:57 | |
| *** N2TOH has joined #yosys | 10:05 | |
| *** N2TOH_ has quit IRC | 10:09 | |
| *** N2TOH_ has joined #yosys | 10:19 | |
| *** N2TOH__ has joined #yosys | 10:20 | |
| *** N2TOH has quit IRC | 10:22 | |
| *** N2TOH_ has quit IRC | 10:24 | |
| *** AdamHorden has left #yosys | 12:16 | |
| *** craigo has joined #yosys | 12:55 | |
| mwk | ... can someone who knows systemverilog explain just what on earth is supposed to happen here: https://github.com/YosysHQ/yosys/pull/2188/files#diff-949405f5af9e4c6e27a18ef0ef34764cR2-R9 | 14:00 |
|---|---|---|
| tpb | Title: Add logic-assignments operators by kgugala · Pull Request #2188 · YosysHQ/yosys · GitHub (at github.com) | 14:00 |
| daveshah | I'm not convinced that initial on a wire is legal at all | 14:08 |
| mwk | I'm tempted to just revert the damn PR | 14:09 |
| mwk | whatever this is supposed to do, the result is that yosys treats the 'wire ... = const' line as a continuous assignment (reasonable), and the 'initial' block as if it was a combinatorial always block (not reasonable), resulting in multiple-drivers situation | 14:10 |
| daveshah | I think it would be valid if it was reg instead of wire | 14:10 |
| daveshah | and always instead of initial | 14:11 |
| mwk | yes, because then the line would just set the *initial* value | 14:11 |
| mwk | ... except then it'd be a latch | 14:11 |
| daveshah | Yeah for some reason I thought i and j were constants | 14:11 |
| daveshah | then initial might have made sense | 14:11 |
| daveshah | Yeah its just nonsense | 14:12 |
| *** kraiskil has quit IRC | 14:41 | |
| *** citypw has quit IRC | 14:51 | |
| *** kraiskil has joined #yosys | 14:55 | |
| *** citypw has joined #yosys | 14:58 | |
| *** emeb has joined #yosys | 15:00 | |
| *** citypw has quit IRC | 15:03 | |
| *** Forty-Bot has joined #yosys | 15:15 | |
| *** evil_chuck has joined #yosys | 15:24 | |
| evil_chuck | Hi all, I'm working on a basic PS/2 mouse design for ice40 FPGA. icetime gives me a timing estimate of 1000006.33 ns. How can I fix this? | 15:51 |
| Lofty | Trust the timing estimates from nextpnr, I think | 15:51 |
| Lofty | That will give the longest combinational path for your design anyway | 15:52 |
| evil_chuck | The default makefile uses arache-pnr, should I switch to nextpnr? | 15:52 |
| Lofty | Yes, arachne-pnr has been dead for a while | 15:52 |
| Lofty | Yeah, for about a year arachne-pnr has been replaced by nextpnr-ice40 | 15:54 |
| evil_chuck | Ok, nextpnr gives me the following: ERROR: timing analysis failed due to presence of combinatorial loops, incomplete specification of timing ports, etc. | 16:06 |
| Lofty | Do you have latches in your design? That would probably break icetime too | 16:07 |
| evil_chuck | How do I tell? I don't have much experience. | 16:09 |
| Lofty | Can you upload the log somewhere? I can't remember exactly what it is, but Yosys will probably warn on it | 16:11 |
| Lofty | Since latches are something to be avoided as much as possible | 16:11 |
| Lofty | You most often get them from an incomplete case specification | 16:11 |
| Lofty | In that situation it needs to preserve the original value, since reaching an unspecified case is a no-op | 16:12 |
| Lofty | evil_chuck: ^ | 16:13 |
| *** emeb_mac has joined #yosys | 16:15 | |
| *** Jybz has joined #yosys | 16:15 | |
| evil_chuck | https://pastebin.com/RFPLHF1X here is the log | 16:15 |
| tpb | Title: yosys -p 'synth_ice40 -top top -json top.json' debouncer.v odd_parity.v ps2_bit_ - Pastebin.com (at pastebin.com) | 16:15 |
| Lofty | ps2_byte_writer.v:37: Warning: Identifier `\parity' is implicitly declared. | 16:16 |
| Lofty | ps2_byte_writer.v:52: Warning: Identifier `\done_bit' is implicitly declared. | 16:16 |
| Lofty | Even ignoring the possible presence of latches, this is something you need to fix | 16:16 |
| Lofty | If you add "`default_nettype none" to the top of your source files, Yosys will error if you implicitly declare a variable | 16:17 |
| *** dys has quit IRC | 16:17 | |
| evil_chuck | by default they are wires though, which is fine | 16:17 |
| *** dys has joined #yosys | 16:17 | |
| Lofty | Correct, but it's a bad habit to rely on implicit declaration of wires | 16:17 |
| Lofty | Warning: multiple conflicting drivers for top.\DUT.write_count [3]: | 16:18 |
| Lofty | port Q[3] of cell $techmap\DUT.$auto$proc_dlatch.cc:417:proc_dlatch$598 ($dlatch) | 16:18 |
| Lofty | port Q[3] of cell $techmap\DUT.$auto$proc_dlatch.cc:417:proc_dlatch$627 ($dlatch) | 16:18 |
| Lofty | Yes, you have latches | 16:18 |
| Lofty | And multiple signal drivers | 16:18 |
| Lofty | Latch inferred for signal `$paramod\ps2_bit_writer\clock_divider=10.\read_bit' from process `$paramod\ps2_bit_writer\clock_divider=10.$proc$ps2_bit_writer.v:57$427': $auto$proc_dlatch.cc:417:proc_dlatch$581 | 16:18 |
| evil_chuck | I see. I think I know where the issue is. I'm setting that net from two combinational processes | 16:19 |
| Lofty | Anyway, here's the direct answer to your question: you have latches in your design, and timing analysis on latches is really difficult | 16:19 |
| evil_chuck | I should be incrementing in a sequential block | 16:19 |
| evil_chuck | Thanks, I'll try fixing that. | 16:20 |
| evil_chuck | The simulator (iverilog) doesn't care about it at all. Should I be running synthesis alongside simulation all the time? | 16:21 |
| Lofty | It is *valid* to have latches in your design | 16:21 |
| Lofty | That doesn't make it a good idea | 16:21 |
| Lofty | So, as far as iverilog is concerned, your design is valid, and its job is to simulate that | 16:21 |
| Lofty | I'm not sure how Verilator handles latches, but it probably lints them at least | 16:22 |
| *** xtro has joined #yosys | 16:38 | |
| *** Jybz has quit IRC | 16:46 | |
| *** Jybz has joined #yosys | 16:48 | |
| *** qu1j0t3 has quit IRC | 17:02 | |
| *** Jybz has quit IRC | 17:03 | |
| *** Jybz has joined #yosys | 17:04 | |
| *** qu1j0t3 has joined #yosys | 17:07 | |
| *** Jybz has quit IRC | 17:41 | |
| *** kraiskil has quit IRC | 17:54 | |
| *** xtro has quit IRC | 17:57 | |
| *** X-Scale` has joined #yosys | 18:14 | |
| *** X-Scale has quit IRC | 18:15 | |
| *** X-Scale` is now known as X-Scale | 18:15 | |
| *** Asuu has joined #yosys | 19:26 | |
| *** Asu has quit IRC | 19:30 | |
| *** xtro has joined #yosys | 20:20 | |
| *** Asuu has quit IRC | 21:06 | |
| *** evil_chuck has left #yosys | 21:31 | |
| *** Cerpin has quit IRC | 21:47 | |
| *** Cerpin has joined #yosys | 22:11 | |
| *** X-Scale has quit IRC | 22:15 | |
| *** X-Scale` has joined #yosys | 22:15 | |
| *** X-Scale` is now known as X-Scale | 22:16 | |
| *** xtro has quit IRC | 22:44 | |
| *** xtro has joined #yosys | 22:46 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!