| *** tpb has joined #yosys | 00:00 | |
| *** Degi_ has joined #yosys | 00:03 | |
| *** Degi has quit IRC | 00:07 | |
| *** Degi_ is now known as Degi | 00:07 | |
| *** npe has joined #yosys | 00:50 | |
| *** npe has quit IRC | 00:55 | |
| *** npe has joined #yosys | 01:05 | |
| *** jfierro has quit IRC | 01:08 | |
| *** FFY00 has quit IRC | 01:48 | |
| *** FFY00 has joined #yosys | 01:50 | |
| *** citypw has joined #yosys | 01:54 | |
| *** Vinalon has quit IRC | 03:11 | |
| *** Vinalon has joined #yosys | 03:11 | |
| *** Vinalon has quit IRC | 03:42 | |
| *** Vinalon has joined #yosys | 03:44 | |
| *** Nazara has quit IRC | 04:11 | |
| *** Nazara has joined #yosys | 04:13 | |
| *** _whitelogger has quit IRC | 05:06 | |
| *** _whitelogger has joined #yosys | 05:08 | |
| *** dys has quit IRC | 05:19 | |
| *** cyberclown has joined #yosys | 06:01 | |
| *** npe has quit IRC | 06:25 | |
| *** emeb_mac has quit IRC | 06:28 | |
| *** az0re has quit IRC | 07:00 | |
| *** alexhw has joined #yosys | 07:22 | |
| *** vidbina_ has joined #yosys | 08:00 | |
| *** mirage335 has quit IRC | 08:53 | |
| *** mirage335 has joined #yosys | 08:57 | |
| *** az0re has joined #yosys | 09:03 | |
| *** Asu has joined #yosys | 09:06 | |
| pepijndevos | How much RAM do you need for a Yosys build? | 09:08 |
|---|---|---|
| az0re | Maybe 500MB free? | 09:12 |
| az0re | Most compilation units are maybe 200MB max | 09:13 |
| az0re | But some take more | 09:13 |
| az0re | Just run a build and watch `top` | 09:13 |
| pepijndevos | Hm, I'll just see how it goes... | 09:13 |
| *** jakobwenzel has quit IRC | 09:52 | |
| *** Vinalon has quit IRC | 10:29 | |
| *** cyberclown has quit IRC | 12:56 | |
| *** craigo has joined #yosys | 13:09 | |
| *** cyberclown has joined #yosys | 13:56 | |
| *** emeb has joined #yosys | 14:01 | |
| ZirconiumX | So, I'm reading the Cyclone V documentation, and they have a 27x27 multiplier, but I can't understand how they manage it... | 14:37 |
| ZirconiumX | https://puu.sh/FCkUT/52ea8426dd.png | 14:38 |
| ZirconiumX | This is like, (x0 * (y0 +/- z0)) + (x1 * (y1 +/- z1)) | 14:39 |
| *** npe has joined #yosys | 14:40 | |
| mwk | ... I'm going to guess this drawing is, in fact, a lie | 14:41 |
| mwk | (I mean that's usually a safe bet with intel docs) | 14:41 |
| ZirconiumX | Heh | 14:41 |
| ZirconiumX | The trick is finding out where the lie is | 14:42 |
| mwk | yeah | 14:42 |
| ZirconiumX | So they say they have an 18x18 and an 18x19 mode, but I'm pretty sure the "18x18" is "18x19 with a zero top bit" | 14:44 |
| ZirconiumX | https://puu.sh/FCl0I/9718f3cc4a.png | 14:45 |
| ZirconiumX | From this I'm pretty sure the 19-bit input is signed | 14:45 |
| *** ZirconiumX has quit IRC | 14:57 | |
| *** npe has quit IRC | 14:57 | |
| *** knielsen has quit IRC | 15:00 | |
| *** knielsen has joined #yosys | 15:01 | |
| *** ZirconiumX has joined #yosys | 15:01 | |
| *** tecepe has quit IRC | 15:06 | |
| *** noopwafel has quit IRC | 15:06 | |
| Sarayan | hmmm yeah, the 36 makes send, the 27 is stranger | 15:06 |
| Sarayan | sense | 15:06 |
| *** tecepe has joined #yosys | 15:06 | |
| ZirconiumX | For now I'm going to use what I can tell from the diagram: the DSP supports 18x19 multiplication | 15:15 |
| ZirconiumX | And since mul2dsp.v doesn't support a single parameter needing to be signed, the whole thing is marked as signed only | 15:15 |
| ZirconiumX | Which is perhaps a little inefficient, but oh well | 15:15 |
| FFY00 | backends/protobuf/protobuf.cc:29:10: fatal error: yosys.pb.h: No such file or directory | 15:24 |
| FFY00 | 29 | #include "yosys.pb.h" | 15:24 |
| FFY00 | | ^~~~~~~~~~~~ | 15:24 |
| FFY00 | can anyone reproduce when compiling with -j1? | 15:24 |
| FFY00 | I have isolated the issue, I build in a clean chroot with a reproducible environment | 15:24 |
| FFY00 | I don't think this is a environment issue but it doesn't hurt to check | 15:25 |
| FFY00 | forgot to say, you obviously need to compile with ENABLE_PROTOBUF=1 | 15:26 |
| *** Vinalon has joined #yosys | 15:42 | |
| *** citypw has quit IRC | 15:49 | |
| *** GenTooMan has quit IRC | 16:11 | |
| *** GenTooMan has joined #yosys | 16:12 | |
| *** noopwafel has joined #yosys | 16:18 | |
| *** ross_s has joined #yosys | 16:23 | |
| *** cr1901_modern has quit IRC | 16:35 | |
| *** cr1901_modern has joined #yosys | 16:46 | |
| *** npe has joined #yosys | 16:55 | |
| *** npe has quit IRC | 19:12 | |
| *** npe has joined #yosys | 19:19 | |
| *** adumont has joined #yosys | 19:29 | |
| adumont | Hi, I'm trying to understand why yosys won't infer BRAM for a ram. | 19:30 |
| ZirconiumX | adumont: Look at the log for MEMORY_BRAM; it'll usually tell you | 19:30 |
| adumont | (after I made some changes to the top module, but not the ram.v module) | 19:30 |
| ZirconiumX | Or else look for a "converting to registers" type warning | 19:31 |
| adumont | the 10.24. Executing MEMORY_BRAM pass (mapping $mem cells to block memories). block is empty | 19:31 |
| adumont | two commit earlier (in my design), it was infering BRAM fine | 19:31 |
| ZirconiumX | Are there any "converting to registers" warnings? | 19:31 |
| adumont | any tip of where/what to look before 10.24. Executing MEMORY_BRAM pass (mapping $mem cells to block memories). ? | 19:31 |
| adumont | nope, no "converting to registers" in the yosys.log | 19:32 |
| adumont | here's the faulty log https://termbin.com/ikp7 | 19:32 |
| adumont | two commit earlier, the same section showed it infered BRAM. but in this log it's empty :(, can't find why | 19:33 |
| adumont | (previous yosys log (OK) --> https://termbin.com/ee3c) | 19:33 |
| adumont | I've been looking at it all afternoon, can't find :( | 19:34 |
| ZirconiumX | adumont: So, I think what's happening here is it's decided fontRom and labelsRam both have no read ports | 19:36 |
| ZirconiumX | See MEMORY_COLLECT | 19:36 |
| ZirconiumX | In the good version, you do have read ports | 19:37 |
| ZirconiumX | So Yosys then optimises out the WOM | 19:37 |
| ZirconiumX | Also, are you still using arachne-pnr? You should move to nextpnr instead. | 19:41 |
| adumont | Does it make a difference in the yosys step? | 19:42 |
| ZirconiumX | Yes, nextpnr takes in JSON with -json instead of BLIF | 19:42 |
| ZirconiumX | But it's not strictly related to this | 19:42 |
| adumont | yes, ok, but besides the format, will the yosys synthesis be differnet? | 19:43 |
| ZirconiumX | No | 19:43 |
| adumont | you're right , in MEMORY_COLLECT it's missing two lines now, like this one: $techmap\font0.fontRom.$memrd$\mem$ram.v:32$546 ($memrd) | 19:43 |
| adumont | any reason why? | 19:44 |
| ZirconiumX | $memrd is a memory read port | 19:44 |
| adumont | at simulation (verilator), the design works fine, so port is definitely connected :( | 19:44 |
| ZirconiumX | Since I can't find any reference to it at all, I'm assuming it doesn't recognise whatever pattern you're using for a RAM | 19:45 |
| ZirconiumX | May I see? | 19:45 |
| adumont | sure, https://github.com/adumont/fpga-font/tree/stream | 19:47 |
| tpb | Title: GitHub - adumont/fpga-font at stream (at github.com) | 19:47 |
| adumont | stream branch is the broken one | 19:47 |
| adumont | ok branch is counter2 | 19:47 |
| adumont | same ram.v file (no change) | 19:47 |
| ZirconiumX | https://github.com/adumont/fpga-font/blob/stream/ram.v#L32 | 19:48 |
| tpb | Title: fpga-font/ram.v at stream · adumont/fpga-font · GitHub (at github.com) | 19:48 |
| ZirconiumX | adumont: Try replacing the = with a <= | 19:48 |
| adumont | I use always the same ram.v as in the "LATTICE, Memory Usage Guide for iCE40 Devices" Technical Note TN1250, June 2016, Appendix A. Standard HDL Code References, p20 | 19:48 |
| ZirconiumX | Yosys can't infer single-port RAMs | 19:49 |
| ZirconiumX | Either instantiate it directly or use a dual-port RAM. | 19:49 |
| daveshah | In this case I think it should be fine as it will just end up as a dual port RAM | 19:50 |
| daveshah | Which I think is what is desired | 19:50 |
| ZirconiumX | Given the "** Single-Port RAM **" comment, I disagree, daveshah | 19:50 |
| daveshah | But if this is on an iCE40 other than the UP5K then all the ram is dual port | 19:51 |
| daveshah | And given there is an initialisation, it coudd never map to SPRAM | 19:51 |
| daveshah | The = definitely looks dodgy though regardless of what Lattice say, that should be <= | 19:52 |
| adumont | ok will try to change | 19:53 |
| ZirconiumX | And since the = line is the read port, perhaps that's why Yosys is failing to infer? | 19:55 |
| daveshah | I don't think it should make a difference, but it is definitely not the expected pattern | 19:55 |
| adumont | doesn't make difference, still no BRAM infered. I'm worried about what ZirconiumX says above "it's decided fontRom and labelsRam both have no read ports" | 19:56 |
| daveshah | I will take a look, just rebuilding Yosys | 19:56 |
| daveshah | Looks like the RAMs are being optimised away for some reason | 20:03 |
| daveshah | You say the design works correctly in simulation? | 20:04 |
| adumont | yes it does. the design is simple, it write some labels (strings are in ram (more rom, as I don't use the write ports)., and the font is also in another rom. | 20:08 |
| adumont | that's weird it wouldn't detect the memrd ports, when what is not used in the design are the memwr ports) | 20:10 |
| daveshah | The problem isn't to do with the memrd ports at all | 20:10 |
| daveshah | It looks like something much further away is being optimised away | 20:10 |
| adumont | Do you believe it should appear in the yosys log before MEMORY_COLLECT then? | 20:12 |
| daveshah | Yes, but it is probably not that easy to spot | 20:12 |
| daveshah | as it is hard to know what is even being optimised away firsr | 20:12 |
| daveshah | *first | 20:12 |
| adumont | Is there any way in yosys to disable these optimizations and maybe enable them one by one and see where it start to fail? | 20:14 |
| ZirconiumX | You can run each step individually | 20:14 |
| ZirconiumX | If you manually copy and paste them in interactive mode | 20:15 |
| adumont | yes, but until the end I don't know if it will infer BRAM ? | 20:15 |
| adumont | no sure I follow you :( | 20:15 |
| ZirconiumX | Yosys is a series of passes on an internal representation of your code. | 20:16 |
| ZirconiumX | So you can run one pass at a time and then look around | 20:16 |
| ZirconiumX | For example, if you run `stat`, it will print statistics about your netlist at that point in time | 20:17 |
| ZirconiumX | So if you run a pass and then use `stat`, in the good path you should see a $memrd that becomes $mem and then SB_RAM_4K (IIRC) | 20:17 |
| ZirconiumX | In the bad path, either the $memrd disappears, or else never appears in the first place | 20:18 |
| daveshah | The problem seems to be vgaLabel3.out[23] being stuck low meaning that the if ( ab ) never activates so the $memrd is swept away as the value is never used | 20:19 |
| adumont | @dave | 20:20 |
| adumont | ups | 20:20 |
| adumont | do you see that in the yosys log?? | 20:21 |
| daveshah | Not directly, but by piecing together what was going on combined with tracing the ilang (internal Yosys representation) after `hierarchy -top top; proc; flatten; clean;` (i.e. elaboration but minimal optimisations) | 20:22 |
| adumont | you're looking at it or do you do that mentally??? | 20:22 |
| daveshah | Looking at it | 20:23 |
| daveshah | it needs a bit of following | 20:23 |
| daveshah | In this case, I can see the driver for \vgaLabel3.out is a register | 20:25 |
| daveshah | the input to that register is { $techmap\vgaLabel3.$0\out[43:0] [43:23] \vgaLabel2.out [22:0] } | 20:25 |
| daveshah | the upper bits are $techmap\vgaLabel3.$0\out[43:0] [43:23] | 20:25 |
| daveshah | oh wait | 20:25 |
| daveshah | it's not directly stuck low | 20:26 |
| daveshah | hmm | 20:26 |
| daveshah | it's tied to \vgaLabel2.out [43:23] | 20:26 |
| adumont | each of the vgaLabel take a 44 bit input and outputs a 44 bit output , it may have modified some bits in the way. | 20:27 |
| daveshah | It looks like in each three modules, none change bit 23 of out | 20:29 |
| daveshah | so it is ultimately driven to 1'b0 | 20:29 |
| daveshah | I trace it back to this mux | 20:29 |
| daveshah | cell $mux $techmap\vgaLabel1.$procmux$299 | 20:29 |
| daveshah | parameter \WIDTH 21 | 20:29 |
| daveshah | connect \A 21'000000000000000000000 | 20:29 |
| daveshah | connect \B $techmap\vgaLabel1.$or$vgaModule.v:88$264_Y | 20:29 |
| daveshah | connect \S 1'0 | 20:29 |
| daveshah | connect \Y $techmap\vgaLabel1.$0\out[43:0] [43:23] | 20:29 |
| daveshah | end | 20:29 |
| daveshah | which means that bits 43:23 of the vgaLabel1 register are always 0 (when S is 0 the mux output is A) | 20:29 |
| *** X-Scale` has joined #yosys | 20:30 | |
| daveshah | It looks like all three .active signals are ending up at 0 | 20:30 |
| *** X-Scale has quit IRC | 20:30 | |
| *** X-Scale` is now known as X-Scale | 20:30 | |
| * adumont is checking | 20:31 | |
| daveshah | Looks like you have a multiple assignment on tmp that is messing things up | 20:41 |
| daveshah | (you assign tmp both in the wire declaration and in an assign) | 20:42 |
| *** strobokopp has joined #yosys | 20:42 | |
| *** emeb_mac has joined #yosys | 20:42 | |
| daveshah | Fixing that (removing the assignment in the declaration) and memory is inferred fine | 20:42 |
| adumont | damn!! you're right. I wonder how it's possible verilator nor yosys warn me on that :D | 20:45 |
| adumont | that's an aweful mistake! :'( | 20:45 |
| daveshah | Yosys does warn, both of us just missed the warning | 20:45 |
| adumont | Thank you so much for the help | 20:45 |
| adumont | oh does it? | 20:45 |
| daveshah | I'm surprised Verilator allows this though | 20:45 |
| daveshah | Hmm, I thought I saw a warning | 20:46 |
| daveshah | Yeah, looks like the warning is lost when doing synth_ice40 | 20:46 |
| daveshah | I only saw the warning when I was doing some of the early commands manually | 20:47 |
| adumont | are the steps you took described somewhere? I'd love to be able to find out myself the next time (or learn something in that direction, even if I don't get to the same capacity ;) ) | 20:48 |
| daveshah | Not really. But I have a pretty standard procedure which is to do -p "read_verilog -lib +/ice40/cells_sim.v; hierarchy -top top; proc; flatten; clean; stat; write_ilang top.il" | 20:49 |
| daveshah | this then gets you a low level dump of what is going on inside Yosys just after initial processing of the input | 20:49 |
| daveshah | then steps can be added and removed as needed | 20:49 |
| *** npe has quit IRC | 21:02 | |
| adumont | thank you so much Dave (and also ZirconiumX) for the help. I'll try myself to get to the conclusion :D with you steps | 21:04 |
| *** npe has joined #yosys | 21:10 | |
| daveshah | fyi, I have filed https://github.com/YosysHQ/yosys/issues/2003 as I think the lack of a warning in synth_ice40 is a bug. | 21:17 |
| tpb | Title: opt_expr prevents driver/constant conflict warning · Issue #2003 · YosysHQ/yosys · GitHub (at github.com) | 21:17 |
| *** adumont has quit IRC | 21:19 | |
| *** npe has quit IRC | 21:25 | |
| *** anticw has quit IRC | 21:35 | |
| *** anticw has joined #yosys | 21:37 | |
| whitequark | daveshah: i think i filed an issue for this a long time ago and Claire's response was basically WONTFIX | 21:41 |
| whitequark | even had a branch with an attempt to resolve it partially | 21:42 |
| mwk | iirc one issue here is that `check` doesn't detect the case when something is driving a net connected to a constant as a driver-driver conflict? | 21:42 |
| whitequark | that was one of those things that convinced me that improving Yosys Verilog frontend is a dead end and frankly I would just be better off staying away from FOSS Verilog development altogether | 21:42 |
| whitequark | daveshah: https://github.com/YosysHQ/yosys/issues/545 | 21:44 |
| tpb | Title: `check` does not appear to detect many cases of multiple drivers · Issue #545 · YosysHQ/yosys · GitHub (at github.com) | 21:44 |
| daveshah | I don't think there is a multiple driver by the time check is reached | 21:44 |
| whitequark | actually there is a braindead clause in Verilog which *requires* you to prefer a constant driver | 21:45 |
| mwk | *whaT* | 21:45 |
| whitequark | let me see if i remember it correctly | 21:46 |
| az0re | I don't understand why you think that would be braindead | 21:46 |
| whitequark | az0re: because a driver conflict should be a compilation error | 21:47 |
| whitequark | in the same way, the SV LRM does not allow code that violates the requirements of always_ff to be an error, it has to be a warning, as written | 21:47 |
| whitequark | (so Yosys is not SV compliant here because it actually does make it an error) | 21:48 |
| mwk | ... because when you have more than one driver in the first place, you're already doing stuff you shouldn't be? | 21:48 |
| daveshah | My guess is that this was written from a simulation point of view | 21:48 |
| mwk | (with the exception of internal tristate logic but uhhh can we pretend that doesn't exist) | 21:48 |
| daveshah | where there are occasional cases where you do want to override a signal | 21:48 |
| az0re | whitequark: I agree that it is an error, of course | 21:48 |
| whitequark | daveshah: yes, and that should just use a separate keyword that's invalid in synthesis | 21:49 |
| az0re | But I don't understand why it's brain dead to say, "well, this is wrong, but let's be conservative and assign it the constant driver" | 21:49 |
| mwk | because if obvious errors are warnings and not errors, you end up with shit code | 21:50 |
| whitequark | ^ | 21:50 |
| daveshah | I suspect most of these cases effectively already do, because they use "assign" within a procedural block | 21:50 |
| az0re | mwk: totally agree there, it should be an error with some option to allow it with a warning | 21:50 |
| whitequark | good tools do not second-guess my intent when encountering questionable code. good tools fail loudly on it | 21:50 |
| az0re | sure, agreed | 21:50 |
| mwk | would you also like an option for invalid pointer access in C to be a warning? | 21:51 |
| az0re | I just don't think it's brain dead, *if you're not going to die*, to make that choice | 21:51 |
| daveshah | In fact there is a force keyword already | 21:51 |
| az0re | you misunderstand what I'm saying lol | 21:51 |
| whitequark | oh, you were nitpicking a literal interpretation of my words. nevermind then | 21:51 |
| az0re | huh? | 21:52 |
| az0re | I didn't understand why you thought it was braindead to prefer a constant driver | 21:52 |
| az0re | Turns out you really just have a problem with it not being an error. I agree there. | 21:52 |
| whitequark | right, so | 21:53 |
| whitequark | I hold my tools to a much higher standard than is considered normal in this industry | 21:53 |
| az0re | I don't see how I was nitpicking anything | 21:53 |
| whitequark | yes, I misunerstood your response, sorry | 21:53 |
| az0re | OK no problem I just don't want any lingering misunderstandings | 21:53 |
| whitequark | in general, I think that something like the missing diagnostic we discussed above, in a language specificaion--an unforced error--is completely unacceptable | 21:54 |
| whitequark | in the same sense that the situation we ended with in PCs where everything runs on memory-unsafe code that contains untold quantities of severe bugs is completely unacceptable | 21:54 |
| az0re | TBH I don't see a big problem with diverging from the official Verilog spec (ideally with an option for full spec compliance) to implement more sane behavior in Yosys | 21:55 |
| az0re | I mean, Yosys already picks and chooses things from SV to support, right? | 21:55 |
| whitequark | there is a particular point of view that IME many engineers hold that "Verilog is fine, you just need a linter and a year to learn every footgun it has", and I refuse to concede with it | 21:55 |
| az0re | totally agreed that is a garbage perspective :) | 21:56 |
| whitequark | yes, I agree that Yosys should diverge from the SV spec when it makes sense to do so | 21:56 |
| az0re | and also that Verilog is not ideal... | 21:56 |
| whitequark | I also find it really weird that there is no synthesis subset of SV | 21:57 |
| whitequark | sure, 1164.1 was to put it mildly not ideal (it *requires* you to have a sim/synth mismatch in one particular clause) | 21:57 |
| whitequark | but as it stands, no vendor implements the entirety of SV in synthesis (that wouldn't even make sense), and so you're stuck with N incompatible dialects whether you like it or not, and there isn't even any baseline you can claim conformance to | 21:58 |
| az0re | Since everybody seems to write generators and use Verilog primarily as a language backend, anyway, I wonder if RTLIL will largely supplant it in a few years | 21:58 |
| whitequark | I would hope not (at least, not as RTLIL exists today) | 21:58 |
| az0re | Write your RTL however you want: Bluespec, Chisel, Migen, etc. | 21:58 |
| whitequark | RTLIL is defined by its singular implementation that changes without notice | 21:58 |
| az0re | But those are all more sane HDLs than Verilog IMO | 21:59 |
| whitequark | RTLIL is quite nice, but it simply cannot become an industry standard without negatively impacting... well, everyone | 21:59 |
| whitequark | (Yosys because RTLIL would get effectively frozen, and everyone else who would now lack a formal specification they could adhere to) | 22:00 |
| whitequark | it's like how people keep trying to use LLVM IR for things | 22:00 |
| whitequark | first in PNaCl, then in some shader thing I forget the name of | 22:00 |
| az0re | I dunno if it would get effectively frozen, it would just need to be effectively versioned | 22:01 |
| whitequark | it works for exactly one LLVM release cycle and then you're left with a massive headache and a project you're probably going to deprecate | 22:01 |
| whitequark | why not just use FIRRTL? | 22:01 |
| az0re | Oh, sorry, that's what I meant | 22:01 |
| whitequark | it's conceptually very similar to RTLIL and it is explicitly designed as an interchange format | 22:01 |
| az0re | What Chisel uses on the backend | 22:01 |
| whitequark | oh | 22:01 |
| whitequark | oh yeah I want to add a FIRRTL backend to nMigen some day | 22:02 |
| az0re | So many RTLs and Rs and Is, I got lexically turned around... | 22:02 |
| daveshah | We need a FIRRTL frontend for Yosys at some point | 22:02 |
| whitequark | daveshah: I might write that along with the nMigen backend, possibly | 22:02 |
| whitequark | the current situation where I version-sniff Yosys is not ideal | 22:02 |
| daveshah | Yeah, that would be nice | 22:03 |
| whitequark | I might be stuck doing that to an extent depending on how bad FIRRTL-to-Verilog roundtrip is | 22:03 |
| whitequark | but also maybe not | 22:03 |
| sorear | the best part about SPIR-V is that everyone thinks it's related to RISC-V or vice versa | 22:03 |
| daveshah | Partly because I've been using some of the Chisel cores as large benchmarks, and their Verilog generation on those is pretty slow | 22:03 |
| daveshah | Not massively problematic in the scheme of synthesis of such big thingsi | 22:04 |
| daveshah | But 10 minutes or so for the bigger BOOM configs which seems quite a bit for a fairly simple transformation | 22:04 |
| whitequark | ouch | 22:05 |
| az0re | Oh I can tell you stories about long build times in Chisel... ;) | 22:05 |
| whitequark | i would start reconsidering my choices if i had to wait 10 minutes for *synthesis* | 22:05 |
| whitequark | much less verilog generation | 22:05 |
| az0re | I once had a design that took 40+m to elaborate in a frozen Chisel2 version | 22:06 |
| daveshah | I mean this is a design that will probably take a few hours to go through nextpnr atm | 22:06 |
| daveshah | to get an idea of the order of magnitude | 22:06 |
| whitequark | suddenly, the current nmigen elaboration times start to look not so ba | 22:06 |
| whitequark | *bad | 22:06 |
| whitequark | (i can improve them by an OOM, i think, with some significant but necessary effort) | 22:07 |
| az0re | on an empty dual Xeon E5-2698v4 with all cores being used | 22:07 |
| whitequark | wow | 22:07 |
| az0re | A big part of it for sure was my own code | 22:07 |
| whitequark | was it particularly large? | 22:07 |
| az0re | But at least 15+m was purely in Chisel code | 22:07 |
| az0re | I mean, yeah... | 22:07 |
| az0re | lol | 22:07 |
| az0re | The output Verilog was like 100M IIRC | 22:07 |
| *** vidbina_ has quit IRC | 22:08 | |
| whitequark | I see | 22:08 |
| whitequark | with attributes, comments, etc stripped? | 22:08 |
| az0re | But this was also a very old frozen version of Chisel2 with a very old frozen version of Scala | 22:08 |
| whitequark | (nmigen's verilog output is probably half (*src*)) | 22:08 |
| az0re | Nope, raw | 22:08 |
| az0re | But there weren't any attributes emitted at that point | 22:08 |
| whitequark | ah, makes sense | 22:08 |
| az0re | Lots and lots and lots of gunk, useless wires, etc. though | 22:08 |
| whitequark | yes, it's been somehting i've worked on in yosys' write_verilog backend | 22:09 |
| daveshah | Chisel/FIRRTL tends to generate a lot of source comments, ime | 22:09 |
| whitequark | sadly, the sheer complexity of verilog's width/signedness inference has defeated me | 22:09 |
| az0re | And comments, yeah | 22:09 |
| daveshah | similar to the number of nmigen src attributes | 22:09 |
| whitequark | it's tractable, but i spent so long on it, and would have to spend so much more time, that it is really hard to find motivation for it | 22:09 |
| az0re | I wonder if you could do a sort of SAT sweeping approach | 22:10 |
| whitequark | for someone who doesn't write any verilog code basically ever, i know *Way* too much about verilog | 22:10 |
| whitequark | and most of that knowledge is really depressing | 22:10 |
| az0re | Find other equivalent wires, replace all references to the one closest to the driver | 22:10 |
| whitequark | you don't need SAT | 22:10 |
| whitequark | at least for the thing i was doing | 22:10 |
| whitequark | you just need to reconstruct it back to an AST form first | 22:10 |
| whitequark | oh, *that* kind of useless wire | 22:11 |
| whitequark | shouldn't yosys be able to do it already? | 22:11 |
| az0re | Probably | 22:11 |
| whitequark | the share pass | 22:11 |
| daveshah | Yeah, good luck with that on that size design though | 22:11 |
| az0re | opt_share or opt_merge probably get a lot, if not all | 22:11 |
| daveshah | opt_merge should catch most of these cases | 22:12 |
| daveshah | freduce does full SAT equivalence sweeping | 22:12 |
| daveshah | But I've not had much luck with it above about 1000 LUTs | 22:12 |
| az0re | I see | 22:12 |
| whitequark | daveshah: oooh, that should work well for boneless | 22:12 |
| daveshah | it quickly takes way longer than the rest of synthesis | 22:12 |
| az0re | Lots to be tried there | 22:12 |
| whitequark | with the 300 LUT target | 22:12 |
| daveshah | A fast, whitebox aware version is on my TODO list but I don't know when I will get to that | 22:13 |
| az0re | Might be a good idea to try a window, where you look only at nearby (by some metric) cells up to some number | 22:13 |
| daveshah | The trick ABC does is to use random value simulation to find candidate equivalences | 22:14 |
| daveshah | I haven't quite figured out how freduce actually works yet | 22:14 |
| az0re | Yeah, Alan is probably the guy to talk to about this if anyone wants to get serious about improving that code... | 22:14 |
| daveshah | It's based on cones but it doesn't seem to do much to try and reduce the problem | 22:15 |
| daveshah | I plan to reimplement the random value simulation, as it is the most obvious way to filter out things that don't need to go to SAT | 22:15 |
| az0re | Makes sense | 22:15 |
| az0re | I'm sure it's way down on the TODO list though | 22:16 |
| daveshah | Yeah, very much in the "one day" category, nextpnr maintainence and R&D taking up most of my time atm | 22:16 |
| az0re | Yeah that's probably appropriate IMO | 22:17 |
| az0re | Honestly this would be a good semester project for some university student | 22:17 |
| *** Asuu has joined #yosys | 22:33 | |
| *** Asu has quit IRC | 22:33 | |
| *** npe has joined #yosys | 22:59 | |
| *** emeb has quit IRC | 23:04 | |
| *** Asuu has quit IRC | 23:24 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
