| *** tpb has joined #yosys | 00:00 | |
| *** az0re has quit IRC | 00:00 | |
| *** Degi_ has joined #yosys | 00:11 | |
| *** Degi has quit IRC | 00:13 | |
| *** Degi_ is now known as Degi | 00:13 | |
| *** janrinze has quit IRC | 00:18 | |
| *** emeb_mac has joined #yosys | 00:27 | |
| *** az0re has joined #yosys | 00:33 | |
| *** futarisIRCcloud has joined #yosys | 01:48 | |
| *** citypw has joined #yosys | 01:52 | |
| *** emeb has quit IRC | 01:52 | |
| *** Cerpin has quit IRC | 01:54 | |
| *** Stary has quit IRC | 02:13 | |
| *** npe has joined #yosys | 02:17 | |
| *** Stary has joined #yosys | 02:22 | |
| *** Cerpin has joined #yosys | 03:29 | |
| *** npe has quit IRC | 03:51 | |
| *** npe has joined #yosys | 03:55 | |
| *** Cerpin has quit IRC | 04:29 | |
| *** Cerpin has joined #yosys | 04:37 | |
| *** vidbina_ has joined #yosys | 05:17 | |
| *** az0re has quit IRC | 05:30 | |
| *** npe has quit IRC | 05:44 | |
| *** craigo has joined #yosys | 05:55 | |
| *** _whitelogger has quit IRC | 06:03 | |
| *** _whitelogger has joined #yosys | 06:05 | |
| *** Vinalon has quit IRC | 06:05 | |
| *** Vinalon has joined #yosys | 06:32 | |
| *** emeb_mac has quit IRC | 06:59 | |
| *** jakobwenzel has joined #yosys | 07:55 | |
| *** ZipCPU has quit IRC | 08:05 | |
| *** ZipCPU has joined #yosys | 08:06 | |
| *** Asu has joined #yosys | 08:28 | |
| *** mirage335 has quit IRC | 09:12 | |
| *** mirage335 has joined #yosys | 09:21 | |
| *** futarisIRCcloud has quit IRC | 09:56 | |
| *** agg has joined #yosys | 10:27 | |
| *** Ekho has quit IRC | 10:31 | |
| *** Vinalon has quit IRC | 10:36 | |
| *** Ekho has joined #yosys | 10:53 | |
| agg | whitequark: as a data point, cxxrtl generates 1/7th the C++ code but takes 2.3x the execution time as verilator on my dsp design (and produces identical output, but also, caught an out of bounds bram read) | 10:56 |
|---|---|---|
| agg | can it/are there plans for it to output a vcd? | 10:56 |
| agg | i would also rate it as "easier to get working" although it took a little while to figure out the api for getting/setting port values | 10:57 |
| ZirconiumX | agg: Is this before or after the go-faster branch? | 10:59 |
| agg | sorry yes this is on the current pr branch | 10:59 |
| agg | yosys 1d5b6ac2 | 11:00 |
| agg | and write_cxxrtl at default -O6, g++ at -O2, I'll see if clang makes an appreciable difference | 11:00 |
| agg | clang actually gets it down to 1.83x though a slightly unfair comparison since verilator times are using gcc :p | 11:03 |
| ZirconiumX | What are you calling before write_cxxrtl? | 11:04 |
| agg | read_ilang; write_cxxrtl | 11:04 |
| agg | (I thought write_cxxrtl with -O6 takes care of any other passes that are useful?) | 11:05 |
| ZirconiumX | Try `read_ilang; proc; flatten; write_cxxrtl` | 11:05 |
| agg | doesn't seem to make any difference | 11:06 |
| agg | I believe write_cxxrtl -O6 does proc;flatten though, and -O6 is the default | 11:06 |
| ZirconiumX | Okay, yeah, sorry | 11:08 |
| agg | to be clear i'm not complaining about the current speed, it's still like 600ms cpu time to simulate 100ms of design clock time, which is more than enough | 11:08 |
| ZirconiumX | The copy of Yosys I have in front of me only has -O5 | 11:09 |
| agg | though the verilator vcd dump is very useful :p mostly i am very looking forward to this being integrated in nmigen | 11:09 |
| ZirconiumX | Oh yeah, definitely | 11:10 |
| agg | this module needs to do around 5M clocks to settle, so it's one of the only things in my design that pysim won't really cope with, and my current test strategy for it is "check the verilator vcd in gtkwave" | 11:10 |
| agg | mostly because i haven't faced writing c++ to properly test the outputs for it :P | 11:10 |
| Sarayan | What do you put in the vcd? | 11:14 |
| Sarayan | with verilator, that is | 11:15 |
| ZirconiumX | Also have you tried voiding your warranty? | 11:15 |
| Sarayan | everythng, like pysim? Everything starting at a point? A selection of signals or modules? | 11:15 |
| *** enigma has joined #yosys | 11:20 | |
| agg | I have verilator dump all signals to the vcd | 11:20 |
| agg | (not in the time benchmark above, I took out vcd writing for that) | 11:20 |
| agg | i find that's the most useful way of looking at it in gtkwave to see what's going on, rather than realising i wanna see something else and having to re-add that, rebuild, rerun, etc. doesn't take that long or produce especially huge vcds in this instance | 11:21 |
| agg | this design is annoying because i need to run for many clocks but it's not got that many moving parts | 11:21 |
| agg | (very high order decimator) | 11:21 |
| whitequark | agg: try using g++/clang++ -O3; also, clang++ -flto seems to produce better results depending on your exact use case | 11:23 |
| whitequark | there is also one thing i realized i did that might not be entirely optimal, i'll try to fix it soon | 11:24 |
| agg | with clang++ -O3 -march=native -flto I get to 1.6x verilator | 11:25 |
| Sarayan | whitequark: is there enough information left at the cxxrtl level to make every signal visible to a potential vcd writer? | 11:25 |
| Sarayan | lto can help even if everything is single-file? | 11:26 |
| whitequark | Sarayan: (every signal visible to vcd) not sure if "every", but the majority of them, yes. i will see exactly how well i can get it to work | 11:26 |
| whitequark | the current plan is to add debug info to cxxrtl output without sacrificing optimization, sort of like DWARF is supposed to work (but it usually just gives you <value optimized out> insead) | 11:27 |
| whitequark | (lto) cxxrtl has black boxes now | 11:27 |
| whitequark | among other things | 11:27 |
| whitequark | agg: so, there is one more thing you could do if you wanted every last drop of performance | 11:29 |
| whitequark | run yosys with CXXRTL_VOID_MY_WARRANTY=1 set in the envirnonment, and replace your *two* calls to .step() with *one* line like this: top.prev_p_clk = value<1>{0u}; top.p_clk = value<1>{1u}; top.step(); | 11:29 |
| agg | whitequark: using clang for the verilator build with the same flags actually makes verilator slightly slower :p | 11:31 |
| whitequark | agg: i find that with minerva sram soc, g++ works a bit better than clang++ | 11:32 |
| agg | so with clang++ -O3 -march=native -flto, verilator is 455ms and cxxrtl is 383ms | 11:36 |
| agg | but verilator with g++ -O3 gets 343ms | 11:36 |
| agg | whereas cxxrtl gets 648ms with g++ -O3, go figure | 11:37 |
| agg | (cxxrtl numbers there using VOID_MY_WARRANTY) | 11:37 |
| agg | with the best settings so far for each, verilator is 1.1x faster, but still generating 7x the amount of c++ faff and requiring its own makefile | 11:38 |
| Sarayan | pure sync design without comb loops? | 11:40 |
| agg | no deliberate comb loops :p | 11:40 |
| whitequark | Sarayan: the backend would complain if it would find comb loops | 11:41 |
| whitequark | also, it now automatically optimizes out useless delta cycles if it can schedule the entire thing statically | 11:42 |
| whitequark | so you can remove all the "optimized" versions of the code i gave you before, not necessary | 11:42 |
| *** vidbina_ has quit IRC | 12:01 | |
| *** vidbina_ has joined #yosys | 12:17 | |
| *** enigma has quit IRC | 12:18 | |
| *** strongsaxophone has joined #yosys | 12:21 | |
| *** enigma has joined #yosys | 12:23 | |
| Asu | whitequark: so i've been messing a bit with compile flags of the generated c++ for that SoC from that archive on the gas gas gas PR | 12:45 |
| Asu | > i find that with minerva sram soc, g++ works a bit better than clang++ | 12:45 |
| Asu | so that is interesting because i get absolutely the opposite | 12:46 |
| whitequark | agg: please try the latest commit from the PR again | 12:49 |
| Asu | all -O3, clang-9 w/ lto+pgo 0.8s, clang-9 w/ lto 0.9s, clang-9 without lto or pgo 1.2s, g++ 9.3 both with and without lto are around 1.35s~1.45s | 12:50 |
| whitequark | Asu: sorry, i misspoke | 12:50 |
| Asu | oh, right | 12:50 |
| whitequark | g++ works a bit better than clang++ *without LTO* | 12:50 |
| whitequark | with LTO, clang++ is absolutely much better | 12:50 |
| Asu | clang -O3 slightly outperforms gcc -O3 for me | 12:52 |
| Sarayan | which clang, 9, 10? | 12:52 |
| Asu | 9.0.1 | 12:52 |
| Sarayan | oh, you said before | 12:52 |
| Asu | i think wq tests with clang-7 so that might be it? that or a cpu difference | 12:53 |
| whitequark | yup | 12:53 |
| agg | whitequark: with g++ -O3, new commit 648ms->478ms, clang++ -flto -march=native -O3 is same as before at 385ms | 13:06 |
| agg | without -march=native actually a bit of a speedup to 376ms | 13:06 |
| whitequark | agg: oh fascinating, so clang could do my optimization on its own | 13:09 |
| agg | seems like it | 13:10 |
| whitequark | does -march=native use avx? | 13:10 |
| whitequark | that could bump down your multiplier, causing the slowdown | 13:10 |
| ZirconiumX | x86 vendors for the past 30 years: SIMD is great | 13:14 |
| ZirconiumX | x86 vendors now: actually don't use SIMD | 13:14 |
| agg | i think march=native will use all available features including avx | 13:15 |
| agg | this is a ryzen 7 2700x | 13:15 |
| whitequark | oh, not sure if ryzen has avx offset | 13:15 |
| Sarayan | power management is complicated | 13:17 |
| ZirconiumX | XFR will probably throttle things down with AVX, but that's mostly heat and power management | 13:17 |
| agg | still more than fast enough to replace verilator for me though, even without the warranty-voiding | 13:18 |
| whitequark | fun fact: i developed cxxrtl with a focus on correctness and flexibility, not performance | 13:18 |
| agg | and you started it what, a couple months ago? | 13:19 |
| whitequark | that it runs almost as fast as verilator is more of a side effect | 13:19 |
| agg | and now it's the same speed as verilator, more correct, easier to use, generates less code | 13:19 |
| whitequark | i think about a month of development time total went into it | 13:19 |
| whitequark | maybe two | 13:19 |
| agg | poor verilator | 13:19 |
| whitequark | no, less than a month, judging by commit logs | 13:19 |
| *** enigma has quit IRC | 13:23 | |
| *** enigma has joined #yosys | 13:24 | |
| *** vidbina_ has quit IRC | 13:43 | |
| *** mirage335 has quit IRC | 13:44 | |
| *** enigma has quit IRC | 13:45 | |
| *** strongsaxophone has quit IRC | 13:49 | |
| *** mirage335 has joined #yosys | 14:01 | |
| *** jfcaron has joined #yosys | 14:05 | |
| *** Thorn has quit IRC | 14:40 | |
| *** citypw has quit IRC | 14:46 | |
| *** Cerpin has quit IRC | 14:51 | |
| *** Cerpin has joined #yosys | 14:52 | |
| *** npe has joined #yosys | 15:05 | |
| *** Thorn has joined #yosys | 15:17 | |
| *** yosys-questions has joined #yosys | 15:32 | |
| Asu | whitequark: for this SoC i found merging most of the if (posedge_p_clk()) manually in the generated code improves run times by ~13% for me and the compile time of the cxxrtl by ~10% (results with clang -O3 -flto) | 15:33 |
| whitequark | Asu: that's already upstream in cxxrtl | 15:33 |
| Asu | not sure if that's helpful, i'm kind of curious why this improves performance though (is it unable to deduce that the expression remains constant or just doesn't know how to merge the branches?) | 15:33 |
| Asu | oh | 15:33 |
| whitequark | i also got 13-15% improvmement | 15:33 |
| yosys-questions | Hi, quick q: When I look at the output of write_json command, I don't see that the ports/nets have their "signed/unsigned"-ness prevailed. I understand that once RTL is fully understood, signed/unsigned doesn't matter, but at what stage is it possible to recover this information? I would like to have it for some automation that I am doing | 15:34 |
| *** vidbina_ has joined #yosys | 15:34 | |
| ZirconiumX | yosys-questions: you shouldn't use JSON as a Yosys parsing format, really | 15:36 |
| mwk | yosys-questions: the wire/register signedness is already lost by the time read_verilog is done | 15:37 |
| *** emeb has joined #yosys | 15:37 | |
| ZirconiumX | It should be in the cells though? | 15:37 |
| mwk | however, cell input/output signedness is preserved until actual synthesis | 15:37 |
| mwk | so you could look at the A_SIGNED/B_SIGNED/Y_SIGNED/... attributes of cells | 15:37 |
| yosys-questions | @mwk: Let me look | 15:37 |
| ZirconiumX | So basically "this wire is signed" becomes "this cell input is signed", right? | 15:37 |
| mwk | yeah | 15:38 |
| mwk | except, well, casts can happen | 15:38 |
| yosys-questions | ZirconiumX: what stage should I tap in to get access to the parse tree? | 15:42 |
| mwk | ast | 15:42 |
| ZirconiumX | ^ | 15:43 |
| daveshah | But there may well be better frameworks than Yosys if you just want the parse tree | 15:43 |
| mwk | read_verilog has a "dump ast" option, but it's not really intended for machine consumption, so perhaps your best bet would be to throw in some C++ code that walks the AST tree | 15:43 |
| yosys-questions | Ok. Let me take a look at that. It's a bummer for me, as I pretty much have EVERYthing else that I need :) | 15:44 |
| mwk | also I kind of wonder if we should just add preserving wire signedness information in yosys | 15:45 |
| daveshah | It might be useful during vcd generation | 15:45 |
| mwk | I mean, we already have the "upto" and "start_offset" attributes which are basically semanticless HDL leftovers | 15:45 |
| daveshah | as much as anything else | 15:45 |
| mwk | and yeah | 15:45 |
| mwk | vcd | 15:45 |
| daveshah | They are needed for correct pin constraints | 15:45 |
| yosys-questions | Let me know if you all are interested, I wouldn't mind making the modification and sending a PR | 15:46 |
| mwk | I'd say it sounds reasonable | 15:47 |
| yosys-questions | at least taking a stab at it | 15:47 |
| yosys-questions | I have used write_json for a little bit of automation in the past, and it is really powerful I think | 15:47 |
| ZirconiumX | It is, but it's not really a stable interface AIUI | 15:49 |
| daveshah | Most of the changes haven't actually been breaking if you language-lawyer the original spec | 15:49 |
| daveshah | The bigger problem is the spec has been fairly poor | 15:50 |
| *** citypw has joined #yosys | 15:53 | |
| *** Vinalon has joined #yosys | 15:55 | |
| *** cr1901_modern has quit IRC | 15:57 | |
| yosys-questions | ZirconiumX What you said worries me a little bit. Do you mind elaborating in what ways? Is it that the write_json "API" isn't always updated and is missing some tests? | 15:59 |
| *** citypw has quit IRC | 16:00 | |
| daveshah | It has seen some changes fairly recently that have broken some tools using it, partly correcting some original bad design decisions | 16:00 |
| daveshah | It should never be broken itself for long, given it is used for nextpnr | 16:00 |
| ZirconiumX | yosys-questions: daveshah says there's a poor specification for it, but my own understanding of write_json is that it's subject to change | 16:00 |
| ZirconiumX | Not stable as in "API stability" rather than "bugs" | 16:01 |
| *** anticw has quit IRC | 16:01 | |
| yosys-questions | Ok, thanks! | 16:01 |
| *** anticw has joined #yosys | 16:03 | |
| yosys-questions | To summarize here: API will exist, it's form may change, use with caution (?) | 16:03 |
| daveshah | Yes | 16:03 |
| daveshah | The most likely changes are new fields being added | 16:04 |
| daveshah | which it is important your application can gracefully ignore | 16:04 |
| daveshah | Changes in the format used to encode parameter/attribute values are still possible | 16:04 |
| daveshah | but hopefully have settled down | 16:04 |
| * mwk mutters something about floats | 16:08 | |
| daveshah | Oh yeah | 16:08 |
| whitequark | personally i would parse RTLIL | 16:09 |
| whitequark | but it's true that parsing JSON is easier for most people | 16:09 |
| yosys-questions | It really depends on the application: I mean for 200 lines of python that automates a register bus, my question was wheter it is worth it to parse RTLIL. But | 16:10 |
| yosys-questions | It really depends on the application: I mean for 200 lines of python that automates a register bus, my question was wheter it is worth it to parse RTLIL. But if it's worth parsing RTLIL for future benefits I will look into it | 16:11 |
| daveshah | Parsing RTLIL has the big advantage that you can support unelaborated processes | 16:11 |
| *** X-Scale` has joined #yosys | 16:11 | |
| daveshah | (ie always blocks before they become latches, FFs or mux trees, more or less) | 16:12 |
| mwk | ... RTLIL is also not entirely stable, and harder to extend in backwards-compatible way than JSON | 16:14 |
| *** X-Scale has quit IRC | 16:14 | |
| *** X-Scale` is now known as X-Scale | 16:14 | |
| whitequark | yosys-questions: well, personally, i find writing parsers easy and relaxing, but that's just me | 16:20 |
| whitequark | daveshah: speaking of which, any idea if we can extend write_verilog so it'd stop complaining about unelaborated processes? | 16:21 |
| whitequark | it whines because some processes are inexpressible in verilog, but i doubt that we can't juts detect which | 16:21 |
| whitequark | mwk: the syntax or the cells? | 16:22 |
| daveshah | Yeah, if you can detect the broken cases then that seems the best option | 16:22 |
| mwk | whitequark: syntax | 16:22 |
| daveshah | I don't know the Verilog backend well though | 16:22 |
| mwk | ... and the latest break is my fault | 16:22 |
| whitequark | mwk: hang on what | 16:22 |
| mwk | (default parameter values) | 16:22 |
| whitequark | i mean i did also break RTLIL | 16:22 |
| whitequark | oh | 16:22 |
| whitequark | link to diff? | 16:22 |
| mwk | https://github.com/YosysHQ/yosys/pull/1945 | 16:23 |
| tpb | Title: Add parameter positional and default value information. by mwkmwkmwk · Pull Request #1945 · YosysHQ/yosys · GitHub (at github.com) | 16:23 |
| mwk | or actually https://github.com/YosysHQ/yosys/pull/1945/commits/38db8749b1032bfa5685e4792fd1ea3110169589 | 16:23 |
| tpb | Title: Add parameter positional and default value information. by mwkmwkmwk · Pull Request #1945 · YosysHQ/yosys · GitHub (at github.com) | 16:23 |
| mwk | (also the same PR subtly changes RTLIL semantics by making parameter order actually meaningful) | 16:24 |
| whitequark | oh i see | 16:25 |
| yosys-questions | whitequark after I did a dump_rtilil, I notice that port signed information is already lost :-/ | 16:34 |
| whitequark | yosys-questions: do you mean on module ports? | 16:47 |
| whitequark | yosys does not preserve any signedness information for nets after the frontend; it only has signedness information in the netlist when it is required for arithmetics and that's it | 16:48 |
| whitequark | it sounds like you want a tooling grade parser rather than a compiler frontend | 16:48 |
| *** Vinalon has quit IRC | 16:51 | |
| *** Vinalon has joined #yosys | 16:52 | |
| *** jakobwenzel has quit IRC | 16:56 | |
| *** N2TOH_ has joined #yosys | 17:12 | |
| *** N2TOH has quit IRC | 17:14 | |
| *** npe has quit IRC | 17:32 | |
| *** npe has joined #yosys | 17:34 | |
| yosys-questions | daveshah whitequark I am looking into adding signedness as a field to RTLIL and make it a part of exports. Let me know if you think it's a bad idea! | 17:39 |
| mwk | tbh I think it shouldn't be a field | 17:39 |
| yosys-questions | mwk ZirconiumX ^ | 17:39 |
| mwk | it'd be perfectly servicable and much less work to just slap it as an attribute on the wire | 17:39 |
| ZirconiumX | ^ | 17:40 |
| mwk | the whole patch would probably be just a few lines of code in ast.cc | 17:40 |
| yosys-questions | that works as well .. | 17:40 |
| *** N2TOH has joined #yosys | 17:42 | |
| Asu | whitequark: might have found a ~+7% performance opportunity after a bit of profiling. i need to double check that my implementation is correct and make my benchmarking more robust but it seems that inserting the memory write in ::update() at the right position in the queue to keep the vector sorted is quite more efficient than performing a sort in ::commit(). do you want me to do a PR? | 17:42 |
| *** N2TOH_ has quit IRC | 17:43 | |
| *** emeb has quit IRC | 17:53 | |
| *** emeb has joined #yosys | 17:54 | |
| *** cr1901_modern has joined #yosys | 18:02 | |
| whitequark | Asu: absolutely | 18:08 |
| whitequark | I only wrote that memory code to be correct | 18:09 |
| *** futarisIRCcloud has joined #yosys | 18:11 | |
| Asu | alright | 18:14 |
| *** adjtm has quit IRC | 18:23 | |
| *** adjtm has joined #yosys | 18:25 | |
| anuejn | is there a way to disable the execution of the SHARE pass in synth_xilinx? | 19:36 |
| anuejn | it takes a long time for me (hasnt finished yet; started 5m ago) and I would rather get a less optimal synthesis result that waiting ;) | 19:37 |
| ZirconiumX | anuejn: That sounds like a bug, but I don't know how big your input design is | 19:38 |
| anuejn | it shouldnt be that big | 19:39 |
| ZirconiumX | How many lines of input source? | 19:39 |
| ZirconiumX | I'm inclined to assume you might have hit a bug in that pass | 19:40 |
| anuejn | about 20k lines of rtlil | 19:41 |
| ZirconiumX | That should be fine, then | 19:41 |
| daveshah | I've never seen that bad a case so this should definitely be looked at, but I think there is a general issue in Yosys that some of the SAT-based stuff can get stuck on difficult problems with minimal reward | 19:41 |
| daveshah | because there is no timeout at present, I think | 19:42 |
| daveshah | timeouts are slightly tricky to implement in a deterministic way | 19:42 |
| anuejn | maybe the problem is that i run the expose pass before? | 19:42 |
| daveshah | it would need to be based on some kind of iteration count inside the SAT solver, not a wall-clock timeout | 19:42 |
| daveshah | That shouldn't cause a major performance change afaik | 19:43 |
| daveshah | if it does, then it definitely sounds like a bug | 19:43 |
| anuejn | interesting, will try | 19:44 |
| daveshah | Otherwise, the way to disable it for test purposes (e.g. to make sure that the design isn't exploding for some other reason) is to comment out https://github.com/YosysHQ/yosys/blob/master/techlibs/xilinx/synth_xilinx.cc#L463 | 19:45 |
| tpb | Title: yosys/synth_xilinx.cc at master · YosysHQ/yosys · GitHub (at github.com) | 19:45 |
| anuejn | ok, thanks :) | 19:48 |
| anuejn | it works if i use expose correctly and let it only expose signals from the toplevel :) | 19:52 |
| anuejn | so it was mostly my thumbness | 19:52 |
| *** zkms has quit IRC | 19:54 | |
| *** zkms has joined #yosys | 19:56 | |
| ZirconiumX | 5000. Executing Verilog backend. | 20:26 |
| ZirconiumX | I managed it | 20:26 |
| *** Cerpin has quit IRC | 21:09 | |
| *** Cerpin has joined #yosys | 21:09 | |
| *** jfcaron has quit IRC | 21:39 | |
| *** Asu has quit IRC | 21:45 | |
| *** somlo has quit IRC | 21:47 | |
| *** vidbina_ has quit IRC | 21:47 | |
| *** vidbina_ has joined #yosys | 21:48 | |
| *** craigo has quit IRC | 21:58 | |
| ZirconiumX | mwk: you around | 22:38 |
| ZirconiumX | ? | 22:38 |
| mwk | yes | 22:38 |
| ZirconiumX | I have spent literally all day trying to bugpoint a Quartus ICE | 22:38 |
| ZirconiumX | I think I found the cause | 22:39 |
| ZirconiumX | wire [31:0] \cpu.cpuregs.regs[10] ; | 22:39 |
| ZirconiumX | And then later | 22:39 |
| ZirconiumX | .q(\cpu.cpuregs.regs[10] [31]), | 22:39 |
| ZirconiumX | And I'm *sure* that's not going to cause problems | 22:39 |
| mwk | so what, you're saying that their verilog^Wvqm parser is so shit, it cannot deal with [ in backslashed name? | 22:40 |
| ZirconiumX | Both, actually | 22:40 |
| ZirconiumX | I checked: it's not a parser bug, but an elaboration bug, I think | 22:40 |
| mwk | alright, but... is it about the name? | 22:41 |
| ZirconiumX | If I rename the variable I get a syntax error. Which I'm not sure if it's a good thing or bad thing | 22:41 |
| ZirconiumX | Equally I'm not sure if this is actually trying to represent a memory or something | 22:41 |
| * mwk is still not quite sure what you're saying | 22:43 | |
| ZirconiumX | "Quartus ICEs and I think it's because of the variable name, but I don't know Verilog enough to tell if this is a literal [10] or referring to a memory in this context" | 22:43 |
| ZirconiumX | Because for example, `reg [31:0] foo[10]` is a memory, right? | 22:44 |
| mwk | should be literal [10] | 22:44 |
| mwk | this is post-yosys-synthesis, right? | 22:44 |
| ZirconiumX | Yes | 22:44 |
| mwk | then I'd guess the wire is a result of yosys implementing a memory by flops | 22:45 |
| mwk | and it *was* a memory at some point, but is now just a plain wire | 22:45 |
| mwk | (with a strange-ish name) | 22:46 |
| whitequark | mwk: fun fact: yosys has similar issues, and i hate that it does | 22:46 |
| whitequark | https://github.com/YosysHQ/yosys/issues/1676 | 22:47 |
| tpb | Title: Preservation of escaped identifier · Issue #1676 · YosysHQ/yosys · GitHub (at github.com) | 22:47 |
| ZirconiumX | <mwk> then I'd guess the wire is a result of yosys implementing a memory by flops <-- yes, this is a case of memory inference being disabled | 22:47 |
| whitequark | actually, the exact same issue, i think | 22:47 |
| mwk | I mean, uhhh | 22:49 |
| mwk | isn't that just a problem with flatten having to call the flattened wires *something*? | 22:49 |
| whitequark | the problem in both cases is that the names are treated as having internal structure | 22:50 |
| whitequark | i.e. in-band signaling | 22:50 |
| whitequark | whereas in fact there is no way for them to have any self-consistent internal structure | 22:51 |
| mwk | .. right | 22:52 |
| ZirconiumX | Can we blacklist [] in variable names for write_verilog then? | 22:52 |
| mwk | ZirconiumX: blacklist and do what? | 22:52 |
| ZirconiumX | escape, presumably | 22:53 |
| whitequark | escape how? | 22:53 |
| ZirconiumX | wire [31:0] \foo_left_square_bracket_10_right_square_bracket; | 22:53 |
| whitequark | what happens when i have an identifier that's called that in first place? | 22:54 |
| ZirconiumX | It also gets escaped | 22:54 |
| whitequark | to what? | 22:54 |
| ZirconiumX | "left and right square brackets get renamed to something that does not contain a left or right square bracket" | 22:55 |
| ZirconiumX | "actual name to be bikeshedded later" | 22:55 |
| whitequark | what i'm trying to lead you to is that you have to choose another prefix you'll ban from names | 22:55 |
| ZirconiumX | write_verilog can already make names unique | 22:56 |
| whitequark | which means, among other things, that write_verilog will no longer roundtrip | 22:56 |
| ZirconiumX | And the alternative is, what, exactly? | 22:56 |
| ZirconiumX | "wontfix" and I sit here with a broken flow? | 22:56 |
| whitequark | you could make it an opt-in for broken toolchains | 22:56 |
| daveshah | Yeah | 22:56 |
| daveshah | I suspect write_verilog -vqm is inevitable | 22:57 |
| ZirconiumX | I wasn't expecting it to be made the default, just another workaround | 22:57 |
| mwk | ... actually write_verilog already has logic to rename cursed names | 22:57 |
| mwk | I can't quite figure out how it works right now, but the logic is there | 22:57 |
| mwk | (see reset_auto_counter_id) | 22:57 |
| mwk | probably could add an extra flag here for shit parsers to use it for more identifiers | 22:58 |
| whitequark | mwk: i *think* it's trying to make renames roundtrippable | 22:58 |
| mwk | ... it actually calls the renamed things "_123_" | 22:58 |
| whitequark | oh, right | 22:59 |
| whitequark | same as the $identifier | 22:59 |
| mwk | not the prettiest | 22:59 |
| mwk | but it should work | 22:59 |
| daveshah | I'm not convinced write_verilog should rename $identifiers by default at all | 22:59 |
| daveshah | But changing that now would be too much brokenness | 23:00 |
| whitequark | would it? | 23:00 |
| whitequark | wait, do you mean it should output them as \$identifier ? | 23:00 |
| whitequark | or something else? | 23:00 |
| daveshah | imo, yes | 23:00 |
| daveshah | I tend to have -norename whenever I use write_verilog | 23:01 |
| mwk | ... are we going to add -rename-harder | 23:01 |
| daveshah | But perhaps that's mostly because write_verilog usually means I'm debugging Yosys or nextpnr | 23:01 |
| whitequark | the use of \ and $ for basically unrelated things in the frontend and the middle end is more aggravating the more i encounter it | 23:01 |
| whitequark | hot take: net names shouldn't even be IdString | 23:02 |
| whitequark | struct NetName { bool public; vector<string> name; } // maybe IdString, not string | 23:03 |
| mwk | ZirconiumX: if you want a quick check whether it's names that cause problems for quartus, go to backends/verilog/verilog_backend.cc line 50 and change "if (*str == '$' && may_rename && !norename)" to "if (may_rename)" | 23:03 |
| mwk | ... not quite sure if that's correct yet though, let's see | 23:04 |
| whitequark | ZirconiumX: or try `rename -hide *[* *]*` | 23:04 |
| mwk | oh | 23:04 |
| mwk | nice pass | 23:04 |
| mwk | yeah, that's even better | 23:04 |
| ZirconiumX | https://twitter.com/ZirconiumX/status/1253098172660023296 <-- here's the testcase I narrowed it down to | 23:07 |
| ZirconiumX | whitequark: Warning: Selection "*[*" did not match any module. | 23:10 |
| whitequark | er, hang on | 23:12 |
| whitequark | w:*[* ? | 23:12 |
| ZirconiumX | whitequark: Yep, Quartus builds it with `rename -hide w:*[* w:*]*` | 23:13 |
| whitequark | yay, no need to patch write_verilog | 23:14 |
| whitequark | (well, unless you specifically want a patch that does better than mwk's) | 23:14 |
| mwk | hm | 23:14 |
| mwk | synth_intel_alm already has a "post-process for quartus" step | 23:15 |
| mwk | throwing the rename command in there would be quite natural | 23:15 |
| ZirconiumX | Indeed | 23:16 |
| ZirconiumX | It was suggested to me that the EDIF input is probably better tested because it's used by other third-party vendors | 23:16 |
| ZirconiumX | But, uh, I don't feel like touching *that* hornet's nest | 23:17 |
| * whitequark shudders | 23:17 | |
| ZirconiumX | *the Quartus EDIF input | 23:17 |
| ZirconiumX | And all it took was *twelve hours* of bugpoint | 23:18 |
| *** yosys-questions has quit IRC | 23:18 | |
| mwk | ... it was tested, nobody said it passed the test | 23:18 |
| *** vidbina_ has quit IRC | 23:34 | |
| *** emeb has quit IRC | 23:55 | |
| *** emeb_mac has joined #yosys | 23:57 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!