*** tpb has joined #yosys | 00:00 | |
*** gnufan_home has quit IRC | 00:30 | |
*** vid has joined #yosys | 01:11 | |
*** gsi__ has joined #yosys | 01:14 | |
*** vidbina has quit IRC | 01:14 | |
*** gsi_ has quit IRC | 01:17 | |
*** emeb_mac has quit IRC | 01:31 | |
*** vidbina has joined #yosys | 02:09 | |
*** vid has quit IRC | 02:13 | |
*** flaviusb has quit IRC | 02:19 | |
*** futarisIRCcloud has joined #yosys | 02:35 | |
*** emeb_mac has joined #yosys | 02:46 | |
*** PyroPeter has quit IRC | 02:57 | |
*** vidbina has quit IRC | 03:05 | |
*** vidbina has joined #yosys | 03:09 | |
*** citypw has joined #yosys | 03:10 | |
*** PyroPeter has joined #yosys | 03:10 | |
*** vidbina has quit IRC | 03:14 | |
*** flaviusb has joined #yosys | 05:16 | |
*** citypw has quit IRC | 05:25 | |
*** dys has quit IRC | 05:31 | |
*** dys has joined #yosys | 05:35 | |
*** rohitksingh has joined #yosys | 06:00 | |
*** dys has quit IRC | 06:18 | |
*** dys has joined #yosys | 06:19 | |
*** citypw has joined #yosys | 06:50 | |
*** rohitksingh_ has joined #yosys | 07:08 | |
*** rohitksingh has quit IRC | 07:08 | |
*** emeb_mac has quit IRC | 07:17 | |
*** gnufan_home has joined #yosys | 08:29 | |
*** rohitksingh_ has quit IRC | 08:51 | |
*** citypw has quit IRC | 08:53 | |
*** rohitksingh has joined #yosys | 09:00 | |
*** futarisIRCcloud has quit IRC | 10:13 | |
*** rohitksingh has quit IRC | 10:14 | |
*** rohitksingh has joined #yosys | 10:26 | |
*** futarisIRCcloud has joined #yosys | 10:54 | |
*** Laksen has joined #yosys | 11:09 | |
*** rohitksingh has quit IRC | 11:11 | |
*** AlexDaniel has quit IRC | 12:13 | |
ZirconiumX | Is there any way of redirecting output of a single Yosys command in a script to a file? | 12:29 |
---|---|---|
ZirconiumX | For example, printing `stat` to a file | 12:29 |
daveshah | ZirconiumX: Yes there is `tee -o` | 12:31 |
ZirconiumX | Thank you! | 12:32 |
*** dys has quit IRC | 12:54 | |
ZipCPU | Oh wow, thanks daveshah! I wasn't aware of that. That will be quite useful to me as I measure component usage! | 12:55 |
*** futarisIRCcloud has quit IRC | 13:03 | |
*** s_frit has quit IRC | 13:23 | |
*** s_frit has joined #yosys | 13:23 | |
*** dys has joined #yosys | 13:32 | |
*** fsasm_ has joined #yosys | 13:48 | |
*** rohitksingh has joined #yosys | 13:50 | |
*** rohitksingh has quit IRC | 14:09 | |
*** rohitksingh has joined #yosys | 14:21 | |
*** lutsabound has joined #yosys | 14:21 | |
ZirconiumX | If I wanted to collect stats on which gates are connected to each other, how would I go about that? | 14:22 |
daveshah | ZirconiumX: there is the edgetypes command but I don't think it tells you how many times each connection type appears | 14:25 |
ZirconiumX | edgetypes seems confusing to use | 14:30 |
ZirconiumX | daveshah: If I get Yosys to hit a log_abort(), should that be reported as a bug? | 14:37 |
daveshah | Yes | 14:38 |
ZirconiumX | Even if I'm doing dumb things? | 14:38 |
daveshah | I'd say so, unless you're messing with the code or something | 14:39 |
ZirconiumX | I'm not, so I'll report it | 14:39 |
*** AlexDaniel has joined #yosys | 14:47 | |
*** gsi__ is now known as gsi_ | 14:52 | |
ZirconiumX | daveshah: https://github.com/YosysHQ/yosys/issues/1099 | 14:55 |
tpb | Title: ERROR: Abort in passes/techmap/extract_fa.cc:218 · Issue #1099 · YosysHQ/yosys · GitHub (at github.com) | 14:55 |
*** cr1901_modern has quit IRC | 15:04 | |
*** vidbina has joined #yosys | 15:52 | |
*** emeb has joined #yosys | 15:55 | |
*** cr1901_modern has joined #yosys | 15:59 | |
ZirconiumX | daveshah: I want to say thank you for being so friendly and welcoming to me being an idiot. | 16:20 |
daveshah | Heh, no problem, it's always nice to see interesting uses of Yosys | 16:21 |
ZirconiumX | I think this is less of a use and more of an abuse | 16:22 |
ZirconiumX | Something which is curious to me is that abc doesn't seem to know how to use a mux8 (lut3?) | 16:23 |
daveshah | Yes, that is a known issue iirc | 16:23 |
daveshah | https://github.com/YosysHQ/yosys/issues/908 | 16:24 |
daveshah | I don't think anyone knows why | 16:24 |
daveshah | btw, ad full adders - probably be better doing what the FPGA flows do; which is `synth -run :fine; techmap -map +/techmap.v -map <custom adder rules.v>; opt`, followed by abc | 16:25 |
daveshah | rather than trying to extract them after doing synthesis to gates | 16:25 |
ZirconiumX | Yeah, I figured I'd need to do something like that | 16:25 |
ZirconiumX | I'm wondering what other MSI chips I could add; the 74xx series has synchronous counters, for example, | 16:26 |
ZirconiumX | But I'm not sure what kinds of things Verilog usually emits | 16:26 |
daveshah | I believe Yosys has some support for mapping counters, it's used in the Greenpak4 pass | 16:27 |
ZirconiumX | I guess the best way of testing the impact of this kind of thing is a large Verilog library that Yosys can synthesize | 16:28 |
daveshah | https://github.com/YosysHQ/yosys-bench/tree/master/verilog/benchmarks_large has a bit of a range of things | 16:28 |
tpb | Title: yosys-bench/verilog/benchmarks_large at master · YosysHQ/yosys-bench · GitHub (at github.com) | 16:28 |
ZirconiumX | daveshah: Does Yosys not handle `$error`? | 16:44 |
*** proteus-guy has quit IRC | 16:45 | |
daveshah | ZirconiumX: I think https://github.com/YosysHQ/yosys/pull/1077 should have added support for that | 16:45 |
tpb | Title: elaboration system tasks by cliffordwolf · Pull Request #1077 · YosysHQ/yosys · GitHub (at github.com) | 16:45 |
ZirconiumX | `yosys -V | 16:46 |
ZirconiumX | ` gives Yosys 0.8+531 (git sha1 d4f77d40, clang 6.0.0-1ubuntu2 -fPIC -Os) | 16:46 |
ZirconiumX | I'm getting a lot of `ERROR: syntax error, unexpected TOK_ELAB_TASK` while trying to parse the ethernet benchmark though | 16:47 |
daveshah | I think this is a recent regression, Yosys used to ignore them in this context (as is correct for a synthesis tool), but now tokenises them and then fails to ignore them in the parser (because it supports them in `generate` contexts now) | 16:50 |
ZirconiumX | Bug report? | 16:50 |
daveshah | Looks like https://github.com/YosysHQ/yosys/pull/1086 should fix it | 16:50 |
tpb | Title: Fixed broken $error()/$info/$warning() on non-generate blocks (within always/initial blocks) by udif · Pull Request #1086 · YosysHQ/yosys · GitHub (at github.com) | 16:50 |
ZirconiumX | Guess we'll have to wait for Clifford to get round to reviewing it | 16:51 |
daveshah | I've added a comment to try and speed that up... | 16:54 |
*** rohitksingh has quit IRC | 17:00 | |
*** proteusguy has joined #yosys | 17:04 | |
*** maikmerten has joined #yosys | 17:27 | |
*** dys has quit IRC | 18:17 | |
*** dys has joined #yosys | 18:32 | |
*** proteusguy has quit IRC | 18:33 | |
*** proteusguy has joined #yosys | 18:45 | |
*** vidbina has quit IRC | 19:15 | |
*** sammylin has joined #yosys | 19:24 | |
ZirconiumX | daveshah: So, I've been reading the techmap documentation, and the example techmap implementations. If I want to insert a full adder, do I use (* techmap_celltype = "$add" *} | 19:28 |
ZirconiumX | ? | 19:28 |
*** Laksen has quit IRC | 19:37 | |
daveshah | ZirconiumX: Yes, however, you'll have to make sure you run techmap before alumacc in that case | 19:41 |
daveshah | alumacc converts arithmetic to more flexible, but more complicated `$macc` amd `$alu` cells (which are probably better suited to mapping things like FPGA carries than discrete chips) | 19:42 |
ZirconiumX | Is a $macc a multiply-accumulate unit? | 19:42 |
*** emeb has quit IRC | 19:44 | |
daveshah | I think so, although I've never worked out it's exact semantics | 19:44 |
*** emeb_mac has joined #yosys | 19:47 | |
ZirconiumX | daveshah: Is it worth having an early and late techmap pass? It seems useful to early-convert $add (74283) and $eq/$ne (7485/7485 with inverter), but late-convert things like counters etc? | 19:50 |
daveshah | Yes, definitely | 19:50 |
ZirconiumX | "early" and "late" being "before synth" and "after synth" | 19:50 |
ZirconiumX | Can techmap synthesize a $ne out of a $eq? | 19:51 |
ZirconiumX | (assuming they are what I think they are) | 19:51 |
daveshah | You might need to play around a bit, but I think that should be possible | 19:51 |
daveshah | Best route might be to take advantage of techmapping being recursive | 19:52 |
daveshah | So you write one rule that maps $ne to $eq, and another that maps $eq to logic | 19:52 |
daveshah | *to chips | 19:52 |
ZirconiumX | The 7485 is actually quite versatile; you can use it as a comparator too | 19:53 |
ZirconiumX | Presumably you'd need to infer that though | 19:53 |
daveshah | Might be able to map $lt and $gt | 19:55 |
daveshah | If you haven't found it already, https://github.com/YosysHQ/yosys/blob/master/techlibs/common/simlib.v contains models for all the built in high level cells | 19:55 |
tpb | Title: yosys/simlib.v at master · YosysHQ/yosys · GitHub (at github.com) | 19:55 |
ZirconiumX | daveshah: So to get this to work, I should build a model of the 7485 and then use a _TECHMAP_REPLACE_ for it? | 20:00 |
ZirconiumX | My verilog skills feel quite weak at the moment | 20:00 |
*** emeb_mac has quit IRC | 20:01 | |
daveshah | No, with techmapping you don't build a model of the thing you want to map to - instead you describe how to go from a Yosys cell type to the cell type you want to map to | 20:01 |
daveshah | This, for example, is an example of techmapping an `$alu` to a mix of soft logic and the hard Xilinx lookahead carry primitives: https://github.com/YosysHQ/yosys/blob/master/techlibs/xilinx/arith_map.v#L336-L353 | 20:03 |
tpb | Title: yosys/arith_map.v at master · YosysHQ/yosys · GitHub (at github.com) | 20:03 |
daveshah | or, from a LUT7 to two LUT6s and a MUX2: https://github.com/YosysHQ/yosys/blob/master/techlibs/xilinx/lut_map.v#L60-L68 | 20:04 |
tpb | Title: yosys/lut_map.v at master · YosysHQ/yosys · GitHub (at github.com) | 20:04 |
ZirconiumX | So I'm allowed to pretend that a 74283 exists, even when I don't define it? | 20:05 |
ZirconiumX | Or whatever | 20:05 |
daveshah | You should probably have at least a "black box" - an empty model just specifying what pins are are inputs and what are outputs | 20:06 |
ZirconiumX | daveshah: So I just need my transformations to match the API of the equivalent simlib cell? | 20:17 |
daveshah | Yes | 20:17 |
daveshah | You don't have to handle all cases though, if you set a wire named _TECHMAP_FAIL_ to 1 then Yosys will fall back to its default implementation | 20:18 |
daveshah | e.g. https://github.com/YosysHQ/yosys/blob/master/techlibs/ecp5/arith_map.v#L36 tells Yosys not to use dedicated logic for adders smaller than four bits (in this case soft logic is more suitable) | 20:19 |
tpb | Title: yosys/arith_map.v at master · YosysHQ/yosys · GitHub (at github.com) | 20:19 |
ZirconiumX | So, for a 74283 (kinda thinking out loud), the maximum per-chip is 4 bit A + 4 bit B + carry in = 4 bit result + carry out | 20:20 |
ZirconiumX | So that would expand to recursion of some kind for greater widths, I'd imagine | 20:21 |
daveshah | Yes | 20:22 |
daveshah | The simplest way would probably be scaling both inputs to a common size, then using a generate for loop to instantiate the adders | 20:23 |
ZirconiumX | How would I chain carries between generate for iterations? | 20:34 |
daveshah | You can a wire for the intermediate signals | 20:35 |
daveshah | Sort of like how C and CO are used here: https://github.com/YosysHQ/yosys/blob/master/techlibs/ice40/arith_map.v#L43 | 20:38 |
tpb | Title: yosys/arith_map.v at master · YosysHQ/yosys · GitHub (at github.com) | 20:38 |
*** maikmerten has quit IRC | 20:49 | |
ZirconiumX | Verilator is being helpful as ever >.> | 20:49 |
ZirconiumX | https://pastebin.com/Q8VLa7nb | 20:51 |
tpb | Title: [SystemVerilog] module \74283 (A, B, CI, S, CO); input [3:0] A; input [3:0] B; input CI; o - Pastebin.com (at pastebin.com) | 20:51 |
ZirconiumX | Verilator complains here | 20:51 |
ZirconiumX | And using techmap on it infinite loops | 20:51 |
ZirconiumX | Though I realise there's obvious bugs | 20:51 |
ZirconiumX | I'm not sure how to pad the input and output buffers though | 20:52 |
ZirconiumX | Ah, a buffer | 20:53 |
ZirconiumX | I think | 20:53 |
*** fsasm_ has quit IRC | 20:54 | |
daveshah | ZirconiumX: you need to add `(* blackbox *)` to the 74283 model | 20:55 |
daveshah | Otherwise Yosys looks inside it, which you don't want in this context (because it will recursively techmap the add inside it) | 20:56 |
ZirconiumX | That makes sense | 20:56 |
daveshah | Normally, the idiom is to put all the sim models in a separate Verilog file to the techmap rules, and read that file in Yosys with read_verilog -lib | 20:57 |
daveshah | That implies blackbox on all the sim models | 20:57 |
daveshah | I'm also not sure if _TECHMAP_REPLACE_ will work here | 20:58 |
daveshah | It's intended for 1:1 techmapping, might cause problems when you map to more than one cell | 20:58 |
daveshah | I'd name the instance something else meaningful like adder_i | 20:59 |
*** gnufan_home has quit IRC | 21:01 | |
*** gnufan_home has joined #yosys | 21:03 | |
ZirconiumX | https://pastebin.com/zPxESRS8 | 21:04 |
tpb | Title: (* techmap_celltype = "$add" *) module _80_74283_add (A, B, Y); parameter A_ - Pastebin.com (at pastebin.com) | 21:04 |
ZirconiumX | daveshah: How does this look? | 21:04 |
ZirconiumX | (I just noticed CARRY; I'll remove it) | 21:04 |
ZirconiumX | This should have a carry-in, but I don't know what to set it to | 21:05 |
ZirconiumX | A_SIGNED ^ B_SIGNED? | 21:05 |
daveshah | Yes, that makes sense | 21:06 |
ZirconiumX | Though, a value being signed or not does not imply whether it's positive or negative | 21:06 |
daveshah | Hmm | 21:07 |
daveshah | Actually, I think just leave CIN at zero | 21:07 |
daveshah | Also, might need a temporary signal for Y, otherwise it will go out of bounds | 21:07 |
ZirconiumX | Hm? | 21:08 |
ZirconiumX | I'm mostly just translating from the iCE40 arith_map.v | 21:08 |
daveshah | eg. have a YY signal of width WIDTH, then do `assign Y = YY[Y_WIDTH-1:0];` | 21:08 |
daveshah | Line 32 might go out of the bounds of Y when width isn't a multiple of four otherwise | 21:09 |
ZirconiumX | Should A_conv and B_conv be WIDTH instead of Y_WIDTH too? | 21:10 |
daveshah | No, that doesn't matter, the upper bits of A and B don't matter | 21:10 |
*** gnufan_home has quit IRC | 21:11 | |
ZirconiumX | daveshah: https://pastebin.com/UcPqn0T8 | 21:16 |
tpb | Title: [SystemVerilog] (* techmap_celltype = "$add" *) module _80_74283_add (A, B, Y); parameter A_ - Pastebin.com (at pastebin.com) | 21:16 |
ZirconiumX | Yosys is complaining about line 42 | 21:17 |
daveshah | wire [WIDTH-1:0] YY = Y_buf; should be the other way round | 21:18 |
daveshah | Y_buf = YY; | 21:18 |
*** sammylin has quit IRC | 21:19 | |
ZirconiumX | daveshah: But then YY isn't defined, right? | 21:23 |
daveshah | Ah yes, you'll also need to change the definition of Y_buf to define YY instead | 21:23 |
ZirconiumX | https://pastebin.com/C1EJx0ZC <-- I fixed the assign Y = Y_buf line instead | 21:25 |
tpb | Title: [SystemVerilog] (* techmap_celltype = "$add" *) module _80_74283_add (A, B, Y); parameter A_ - Pastebin.com (at pastebin.com) | 21:25 |
ZirconiumX | Yosys no longer complains at least | 21:25 |
daveshah | You can get rid of Y_buf altogether, as you're now just using YY and Y, which is fine | 21:29 |
daveshah | Remove Y_buf and just do wire [WIDTH-1:0] YY; | 21:30 |
ZirconiumX | What about A_buf and B_buf? | 21:31 |
ZirconiumX | Some stats, if you want a laugh | 21:32 |
daveshah | If you drive AA and BB from the `$pos` looks like they can be removed too | 21:32 |
ZirconiumX | Before, to go through my benchmark of various things, you'd need 7,340 ICs | 21:32 |
ZirconiumX | Now that Yosys recognises the 74283, you now need only 4,237 | 21:32 |
daveshah | Very nice! | 21:32 |
daveshah | What is your synthesis script? | 21:33 |
ZirconiumX | read_verilog $<; hierarchy -auto-top; read_verilog -lib ../74_models.v; techmap -map ../74283.v; s ynth -run :fine; techmap -map +/techmap.v; opt; dfflibmap -liberty ../74series.lib; abc -liberty ../74series.lib; te e -o $@ stat | 21:33 |
ZirconiumX | Plus or minus awkward formatting (thanks Vim) | 21:33 |
daveshah | Try running `proc; opt; wreduce; opt` before mapping the 74283 | 21:34 |
daveshah | It might reduce the width and number of adders slightly | 21:34 |
ZirconiumX | I appear to be leaking some $mem cells | 21:36 |
ZirconiumX | Your pre-map optimisation seems to bring the number of ICs way back up to 6,231 | 21:38 |
ZirconiumX | (still less than before, at least) | 21:38 |
ZirconiumX | Yeah, your optimisation leaks $mem cells | 21:39 |
*** vidbina has joined #yosys | 21:39 | |
daveshah | Oh, that's odd | 21:39 |
daveshah | What if you add `flatten` between `proc` and `opt` | 21:41 |
ZirconiumX | Still leaking $mem cells, but now we're down to 3,010 ICs | 21:42 |
*** futarisIRCcloud has joined #yosys | 21:43 | |
ZirconiumX | (PicoRV32 is now 1,018 ICs; it was 2,003 yesterday) | 21:43 |
daveshah | Try running `opt - full; memory_map; opt -full` after `synth -run :fine` | 21:44 |
daveshah | Right now nothing in that script is actually mapping memory to logic | 21:44 |
daveshah | *`opt -full`, no space between - and full in either case | 21:45 |
ZirconiumX | No more leaking $mem cells | 21:45 |
ZirconiumX | But one of the example benchmarks doesn't synthesize | 21:46 |
ZirconiumX | Looks like I messed up the adder? | 21:46 |
ZirconiumX | ERROR: Output port smartbextdep.$techmap\smartbextdep_direct_inst.decoder.pps_core.$add$../benchmarks/smartbextdep.v:245$1677.slice[0].adder_i.CO (\74283_1x1ADD4) is connected to constants: 1'x | 21:48 |
daveshah | ZirconiumX: Make C `WIDTH:0` rather than `Y_WIDTH:0` | 21:49 |
daveshah | in the techmap rule | 21:49 |
ZirconiumX | Yep, that fixes it, thank you once again | 21:50 |
ZirconiumX | 5,051 ICs for the benchmark here | 21:51 |
ZirconiumX | But all of the benches build at least | 21:51 |
ZirconiumX | And we're still doing better than before | 21:51 |
ZirconiumX | Have I thanked you enough, daveshah? I'm not sure I have. | 21:59 |
*** vidbina has quit IRC | 22:09 | |
*** gnufan_home has joined #yosys | 22:26 | |
*** s_frit has quit IRC | 23:38 | |
*** s_frit has joined #yosys | 23:39 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!