| *** tpb has joined #yosys | 00:00 | |
| *** rohitksingh has joined #yosys | 00:12 | |
| *** janrinze has quit IRC | 00:17 | |
| *** janrinze has joined #yosys | 01:14 | |
| *** rohitksingh has quit IRC | 01:25 | |
| *** citypw has joined #yosys | 02:25 | |
| *** citypw has quit IRC | 02:43 | |
| *** citypw has joined #yosys | 02:48 | |
| *** lutsabound has quit IRC | 03:19 | |
| *** dh73 has quit IRC | 04:46 | |
| *** dh73 has joined #yosys | 04:46 | |
| *** dh73 has quit IRC | 04:48 | |
| *** nrossi has joined #yosys | 05:35 | |
| *** Jybz has joined #yosys | 06:19 | |
| *** Jybz has quit IRC | 06:25 | |
| *** tannewt has joined #yosys | 06:44 | |
| *** rohitksingh has joined #yosys | 06:47 | |
| *** FabM_cave has joined #yosys | 07:33 | |
| *** acdimalev has joined #yosys | 08:46 | |
| *** kraiskil has joined #yosys | 09:14 | |
| *** promach3 has quit IRC | 09:27 | |
| *** fevv8[m] has quit IRC | 09:28 | |
| *** pepijndevos[m] has quit IRC | 09:28 | |
| *** m4ssi has joined #yosys | 09:32 | |
| *** fevv8[m] has joined #yosys | 10:39 | |
| *** pepijndevos[m] has joined #yosys | 10:39 | |
| *** promach3 has joined #yosys | 10:39 | |
| *** jakobwenzel has quit IRC | 10:44 | |
| *** jakobwenzel has joined #yosys | 10:44 | |
| *** acdimalev has quit IRC | 11:10 | |
| *** d0nker5 has quit IRC | 11:18 | |
| *** d0nker5 has joined #yosys | 11:18 | |
| *** d0nker5 has quit IRC | 11:22 | |
| *** d0nker5 has joined #yosys | 11:23 | |
| *** rohitksingh has quit IRC | 11:51 | |
| *** rohitksingh has joined #yosys | 12:21 | |
| *** anon93 has joined #yosys | 13:11 | |
| *** pie_ has quit IRC | 13:18 | |
| *** rohitksingh has quit IRC | 13:57 | |
| *** citypw has quit IRC | 14:28 | |
| *** anon93 has quit IRC | 14:36 | |
| *** develonepi3 has joined #yosys | 15:47 | |
| develonepi3 | Hello all Has anyone tried to use docker, to build yosys tools (archne-pnr, icestorm, yosys and nextpnr), for raspberry pi or for Ubuntu? | 16:08 |
|---|---|---|
| ZirconiumX | develonepi3: I think everything builds natively. | 16:19 |
| ZirconiumX | Though, don't use arachne-pnr anymore; nextpnr is superior. | 16:19 |
| develonepi3 | Zirconiumx: Yes, I have built on both Rpi3B+ & Rpi4B but it still takes a long time. Was just wondering since I have older versions of nextpnr. | 16:24 |
| ZirconiumX | develonepi3: Are you using HeAP or SA? | 16:28 |
| ZirconiumX | develonepi3: It's a very memory-intensive build because it's creating binary blob databases containing all the routing information it needs | 16:29 |
| develonepi3 | Zirconiumx: Don't think so. | 16:30 |
| ZirconiumX | `nextpnr-ecp5 --help` should say what the default choice is for `--placer`. | 16:31 |
| develonepi3 | Zirconiumx: I am using nextpnr-ice40, no --placer option fairly old. Last update in Aug 4. | 16:49 |
| ZirconiumX | develonepi3: Definitely update it, then. | 16:50 |
| ZirconiumX | Plus, consider that place and route is a slow operation anyway. | 16:51 |
| *** m4ssi has quit IRC | 17:04 | |
| *** emeb has joined #yosys | 17:04 | |
| *** pie_ has joined #yosys | 17:17 | |
| *** develonepi3 has quit IRC | 17:25 | |
| *** pie_ has quit IRC | 17:32 | |
| tnt | Is it possible after doing a 'read' of all the input files to get yosys to write a single file that contains all it needs to pursue the synth without neededing any other files ? Goal is to real all sources (including any includes and init files for memories) on one machine, then ship that file to a build server that will do most of the work and just spit out the resulting .json. | 17:41 |
| *** pie_ has joined #yosys | 17:46 | |
| *** FL4SHK has quit IRC | 17:57 | |
| *** captain_morgan20 has quit IRC | 17:59 | |
| *** captain_morgan20 has joined #yosys | 18:01 | |
| daveshah | tnt: that is the aim of -E | 18:03 |
| daveshah | I don't know if it handles init files correctly | 18:03 |
| *** FL4SHK has joined #yosys | 18:12 | |
| *** gorbak25 has quit IRC | 18:24 | |
| whitequark | -E seems orthogonal | 18:25 |
| *** gorbak25 has joined #yosys | 18:25 | |
| whitequark | I think doing read;hierarchy;write_ilang would work? | 18:25 |
| tnt | Yeah reading the description of -E it seems like it would just list all the files rather than make a single file containing everything. | 18:30 |
| tnt | whitequark: the ilang only contains a bunch of modules with "attribute \src "misc/xclk_strobe.v:36"" pointing to the actual sources :/ | 18:31 |
| *** pie_ has quit IRC | 18:32 | |
| tnt | Oh wait, seems hierarchy needs the -top option to really do anything and then it might do what I want. | 18:34 |
| tnt | I need to add read_verilog -D_ABC -lib +/ecp5/cells_sim.v +/ecp5/cells_bb.v as well for all the blackbox, but that might work. | 18:34 |
| whitequark | tnt: yep, need -top or -auto-top | 18:37 |
| whitequark | the \src attribute is purely for debug info | 18:37 |
| whitequark | yosys never reads those paths | 18:37 |
| tnt | Not sure mem init are handled properly though :/ | 18:41 |
| whitequark | they are | 18:42 |
| whitequark | there is no way to read an external init file from rtlil | 18:42 |
| whitequark | which is actually kind of unfortunate | 18:43 |
| tnt | Oh yeah, I see indeed they are my bad. | 18:43 |
| *** pie_ has joined #yosys | 18:58 | |
| *** FabM_cave has quit IRC | 19:42 | |
| *** dys has joined #yosys | 20:01 | |
| *** pie_ has quit IRC | 20:06 | |
| *** pie_ has joined #yosys | 20:39 | |
| *** rohitksingh has joined #yosys | 20:42 | |
| *** nrossi has quit IRC | 21:28 | |
| janrinze | does nextpnr / yosys slice large memory into dp16kd per bit or does it do it 'wide'? i noticed that larger memory has a big amount of muxes.. | 22:13 |
| tnt | it tries different things | 22:13 |
| tnt | in the yosys output log you'll see the different config/layout it considered and the score it attributed to each and why it picked the one it did. | 22:14 |
| janrinze | I can use a block of 64Kx16 made of dp16kd at 140 MHz but the same amount with reg [15:0] memory[0:65535] will max out at 70 Mhz.. | 22:15 |
| ZirconiumX | Unfortunately memory_bram sucks. | 22:19 |
| ZirconiumX | This is one of the reasons why: at present it has no concept of RAM speeds. | 22:20 |
| janrinze | I'm trying to get my head wrapped around how the reg [15:0] memory[0:65535] gets converted to dp16kd. The code in nextpnr looks pretty obscure to me (forgive me my ignorance.) | 22:22 |
| *** dys has quit IRC | 22:22 | |
| ZirconiumX | janrinze: the conversion is done in Yosys | 22:29 |
| ZirconiumX | In memory_bram | 22:29 |
| daveshah | Yosys does tend to prefer bit slicing large RAMs | 22:30 |
| daveshah | This should improve timing as it reduces the need for read decode muxes | 22:30 |
| janrinze | daveshah: that's precisely what i hoped. Unfortunately in the timing analysis I see that is has around 9 muxes. When using bit slicing it would only need 3, i.i.r.c. | 22:44 |
| janrinze | 64K can be done with 4xDP16KD per bit. Since we have 4bit LUT it will require 3 LUT to select the correct output bit. | 22:46 |
| tnt | look at the yosys output log ... | 22:50 |
| tnt | that might give a clue | 22:50 |
| tnt | It definitely picks 16k x 1 geometry, but there is still a lot of LUTs. Probably the semantic of DP16K doesn't perfectly match what it wants and it needs a bunhc of external logic ... | 22:58 |
| tnt | One of the reason I don't like inference. How do I express _i_don_t_care_ how r/w conflict are handled for instance ? | 22:58 |
| janrinze | yes, it does pick 16kx1. but a lot of glue around it apparently. | 22:59 |
| ZirconiumX | janrinze: do the two sides of your RAM use different clocks? | 23:00 |
| janrinze | tnt: when both reading and writing is clocked then it's easy to use DP16KD | 23:00 |
| janrinze | ZirconiumX: In the VGA I use DP16KD directly since it doesn't require any init values. Also the VGA side is read-only. | 23:02 |
| janrinze | for the CPU i like to setup memory so it will run the bootloader or bare metal code out-of-the-box. | 23:03 |
| tnt | interestingly 32kx16 looks fine. but 64kx16 the lut goes from 21 to 139 ... | 23:07 |
| janrinze | hmm.. perhaps i should try to split it in two 32 KB blocks :D | 23:10 |
| janrinze | eehhr.. 32kx16 blocks x2 of course. | 23:10 |
| tnt | First thing it generates a CE signal independently for each RAM which is useless, it doesn't matter if the CE of the 'unused' RAM is enabled. | 23:20 |
| tnt | And then the 4:1 MUX structure is ... insane. | 23:21 |
| tnt | https://i.imgur.com/TvWJCcr.png | 23:22 |
| tnt | That's what it uses to mux the output of 4 RAM into the output bit ... | 23:23 |
| daveshah | Yes, the problem is that ABC can't use the slice mux structures properly | 23:25 |
| tnt | -nowidelut seems to "fix" it | 23:27 |
| daveshah | Particularly with ABC9 in a real design this will only be a big problem if the structure is on the critical path | 23:29 |
| daveshah | Otherwise it will likely be relaxed | 23:29 |
| daveshah | It also seems like the CE issue could be improved in memory_bram by registering the address MSBs rather than the decoded signals | 23:32 |
| *** kraiskil has quit IRC | 23:37 | |
| janrinze | daveshah: that's exactly how i use it with the VGA memory. The latched address MSBs are used to select the appropriate bit for reading. | 23:39 |
| tnt | Just tried -nowidelut on the supercon badge design. Hurts timing a bit it seems (on the super representative sample of 3 seeds ...) but reduces the pnr time by 15% and the slice count by 10%. | 23:40 |
| daveshah | Yes, nowidelut is effectively an area/timing tradeoff | 23:47 |
| ZirconiumX | I've been wondering about nowidelut on the Cyclone V. Since it's natively a LUT6 without being able to mux it higher, what would it even do? | 23:51 |
| ZirconiumX | There's the option of using LUT4s only, of which two can be packed into an ALM. Guess I'd have to conduct experiments | 23:56 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
