| *** tpb has joined #yosys | 00:00 | |
| *** emeb has quit IRC | 00:03 | |
| *** Degi has quit IRC | 00:23 | |
| *** Degi has joined #yosys | 00:24 | |
| *** elGamal has quit IRC | 01:40 | |
| *** elGamal has joined #yosys | 01:41 | |
| *** citypw has joined #yosys | 01:44 | |
| *** TFKyle has quit IRC | 02:03 | |
| *** _whitelogger has quit IRC | 02:15 | |
| *** _whitelogger has joined #yosys | 02:17 | |
| *** az0re has quit IRC | 02:54 | |
| *** az0re has joined #yosys | 02:54 | |
| *** _whitelogger has quit IRC | 05:48 | |
| *** _whitelogger has joined #yosys | 05:50 | |
| *** emeb_mac has quit IRC | 06:34 | |
| *** twnqx has joined #yosys | 06:58 | |
| *** dys has joined #yosys | 07:14 | |
| *** stroboko1p has joined #yosys | 07:40 | |
| twnqx | is there a rule of thumb at which point a design becomes too large to be placed, or is that too varying? | 07:53 |
|---|---|---|
| daveshah | In general <90% should be OK | 07:53 |
| daveshah | Above that it can become marginal but that depends on the specifics of the design | 07:53 |
| twnqx | i am at 81% (312/384) and nextpnr fails (lp384) :( | 07:53 |
| daveshah | On the iCE40 I've seen designs at 98% place and route fine | 07:54 |
| daveshah | Do you have a lot of different set/reset/ce signals? | 07:54 |
| twnqx | hm, i'd be tempted to say "no", but i guess i'll have to think about that | 07:55 |
| daveshah | You can try the Yosys option -dffe_min_ce_use 4 | 07:56 |
| daveshah | or -dffe_min_ce_use 8 | 07:56 |
| daveshah | to synth_ice40 | 07:56 |
| twnqx | fun, even 2 makes it work | 07:58 |
| twnqx | thank you! | 07:58 |
| *** jakobwenzel has joined #yosys | 08:11 | |
| az0re | In Makefile, is `msys2-64` the MinGW 64 bit compiler? | 08:25 |
| az0re | Looks like it | 08:35 |
| az0re | I'm having trouble building on Windows in cygwin, `msys2-64` config, tcl-dev is installed in Cygwin setup | 08:39 |
| az0re | I get: "./kernel/yosys.h:81:12: fatal error: tcl.h: No such file or directory" | 08:39 |
| az0re | Despite tcl.h existing in /usr/include/ | 08:41 |
| az0re | I wonder if the build config is missing some that include directory somehow? | 08:41 |
| daveshah | Is there any reason you need to use Cygwin and not msys2 itself? | 08:43 |
| whitequark | daveshah: i'm wondering if DFFEs can be legalized back in nextpnr | 08:44 |
| whitequark | to avoid having dffe_min_ce | 08:44 |
| daveshah | The problem is that if you want any kind of efficiency you need to re-pack the LUTs | 08:44 |
| daveshah | dffe_min_ce unmaps them before LUT mapping which is even more efficient | 08:44 |
| whitequark | yup | 08:44 |
| daveshah | I don't want to do LUT transforms in nextpnr yet | 08:45 |
| whitequark | it feels that maybe abc9 should be a part of nextpn... ahhh | 08:45 |
| whitequark | (not *literally* abc9) | 08:45 |
| daveshah | I have plans for a library that is a bit like that | 08:45 |
| daveshah | for retiming, physical resynthesis etc | 08:45 |
| whitequark | that sounds awesome | 08:45 |
| daveshah | but it could be a year off, don't get your hopes up | 08:45 |
| daveshah | I think by the time you start doing retiming it becomes needed | 08:45 |
| whitequark | yup, i understand that | 08:45 |
| whitequark | it does not sound like something that can be done in a few months, anyhow | 08:46 |
| daveshah | The first challenge is just designing a netlist structure that is efficient for these kind of transformations, without being restrictive as abc's | 08:46 |
| ZirconiumX | I mean, for what it is, ABC is quite efficient | 08:47 |
| ZirconiumX | Just, lacking a lot of important metadata it seems | 08:47 |
| daveshah | Yes, although I want first-class whitebox support | 08:47 |
| daveshah | it may be that AIGs aren't a bad way of representing the contents of boxes | 08:47 |
| daveshah | but it's finding efficient ways of tracking things like attributes and source tags that's half the problem | 08:48 |
| whitequark | what are the reasons to prefer AIGs or LUTs for whitebox contents? | 08:48 |
| daveshah | Imagine a DSP whitebox | 08:48 |
| whitequark | oh, point. | 08:48 |
| daveshah | If you represent the whole whitebox as one LUT that is quite big | 08:48 |
| daveshah | You could use a graph of LUTs, but at that point an AIG is probably just as good | 08:49 |
| ZirconiumX | From what I was reading on how FRAIG works, ABC has a library of precomputed optimal AIG for up to 20-inputs | 08:49 |
| ZirconiumX | Which is a mildly terrifying thought, but | 08:49 |
| az0re | daveshah: Not *need*, I guess, but I prefer it if I must use Windows. Anyway I just want to test something. | 08:50 |
| daveshah | az0re: I don't know if anyone compiles Yosys in Cygwin often, but msys2 should be a better trodden path | 08:51 |
| az0re | I see now, though, that there is an explicit cygwin config | 08:51 |
| az0re | What exactly is msys2, anyway? | 08:51 |
| * az0re is not a Windows user | 08:52 | |
| daveshah | As far as I know, msys2 is more of a gnu-style build environment in Windows than a build and runtime environment like Cygwin | 08:53 |
| daveshah | I haven't done much Windows stuff for a few years either | 08:53 |
| daveshah | so might not be quite correct here | 08:53 |
| whitequark | cygwin provides a POSIX environment to the compiler, the build system, and the application. msys2 provides a POSIX environment to just the compiler and build system | 08:53 |
| whitequark | i.e. cygwin builds produce cygwin-dependent binaries that think they run on a POSIX platform. msys2 builds produce native Windows binaries | 08:54 |
| az0re | I see, thanks. And how do I compile Yosys with MSVC? | 08:54 |
| az0re | Is it supported at all? I recall seeing `#if defined(__MSVC)` or similar in the code base | 08:56 |
| daveshah | I think using https://github.com/YosysHQ/yosys/blob/master/misc/create_vcxsrc.sh to create a project is the official way | 08:56 |
| tpb | Title: yosys/create_vcxsrc.sh at master · YosysHQ/yosys · GitHub (at github.com) | 08:56 |
| daveshah | not sure if there are other options | 08:56 |
| az0re | Aha | 08:58 |
| az0re | Thanks | 08:58 |
| az0re | So it requires Visual Studio and not just the build tools | 08:58 |
| daveshah | I think so | 08:59 |
| daveshah | never tried myself | 08:59 |
| az0re | I see | 09:04 |
| az0re | Thanks for the tips | 09:04 |
| ZirconiumX | That should probably be added to CI | 09:04 |
| daveshah | Yes, it would need someone to set up AppVeyor or similar | 09:05 |
| daveshah | this could probably also be set up to push Windows nightlies somewhere | 09:05 |
| *** vidbina_ has joined #yosys | 09:07 | |
| az0re | BTW it's building fine now in cygwin with the `cygwin` config. | 09:16 |
| ZirconiumX | If I want to write a function that returns a character (as part of a string), should it return an 8-bit-wide value? | 09:20 |
| az0re | Yes | 09:22 |
| az0re | see `kernel/rtlil.h`: IdString is basically an index to a char* | 09:22 |
| az0re | Also char* and std::string are common to see in the code base, but never wchar_t* or std::wstring | 09:24 |
| ZirconiumX | quartus_rename.v:111: ERROR: syntax error, unexpected $undefined | 09:32 |
| ZirconiumX | Well this is a terrible error | 09:32 |
| daveshah | Personally that's usually been from when a UTF-8 char has crept into the wrong place | 09:33 |
| daveshah | or generally something else totally unexpected | 09:33 |
| ZirconiumX | https://gist.github.com/ZirconiumX/7efc74cd568d3db85923a54fe5a433e0 | 09:34 |
| tpb | Title: string.v · GitHub (at gist.github.com) | 09:34 |
| ZirconiumX | daveshah: ^ | 09:35 |
| ZirconiumX | (I need this because Quartus takes RAM init as a hexadecimal string) | 09:38 |
| daveshah | You use double quotes even for single characters in Verilog | 09:38 |
| ZirconiumX | Oh, right, okay | 09:39 |
| twnqx | and now to understand what the fpga actually does after the changes, correct it do useful and adopt the controller code \o/ | 09:55 |
| *** elGamal has quit IRC | 10:44 | |
| *** elGamal has joined #yosys | 10:46 | |
| *** Vinalon has quit IRC | 11:02 | |
| Sarayan | Ok, I have a RTLIL::SigSpec, and I want to make a new SigSpec that extract a bit of it, can I do that? | 11:30 |
| mwk | a single bit? | 11:31 |
| mwk | just spec[i] | 11:31 |
| mwk | I mean, that gets you a SigBit, but that's perfectly assignable to a SigSpec | 11:32 |
| Sarayan | cool, thanks | 11:32 |
| Sarayan | and a bit range while I'm at it? | 11:32 |
| mwk | spec.extract(offset, length) | 11:33 |
| mwk | this gives you a new SigSpec | 11:33 |
| Sarayan | excellent, thanks | 11:34 |
| whitequark | ZirconiumX: have you seen how strings work in verilog? it's so cursed | 11:38 |
| whitequark | a n-character string is just a (n+1)*8 bit constant literal | 11:38 |
| ZirconiumX | I have, yes | 11:39 |
| ZirconiumX | And I need to manipulate strings in verilog to initialise LUTRAM, whitequark | 11:39 |
| ZirconiumX | Because Altera fucking hate me I think. | 11:39 |
| whitequark | right | 11:40 |
| ZirconiumX | So after getting quite annoyed trying to do it myself, I'm going to see what Quartus does and then copy them | 11:41 |
| Sarayan | wq: You mean like in C? ;-) | 11:42 |
| mwk | Sarayan: it's nothing like C... | 11:42 |
| whitequark | it's very slightly like C? | 11:43 |
| Sarayan | yeah, it's bits and not bytes | 11:43 |
| whitequark | the difference is that verilog doesn't have bytes or pointer decay | 11:43 |
| Sarayan | yeah, verilog is decay | 11:44 |
| mwk | I mean, for one, C has types | 11:44 |
| mwk | it's not a high standard, C types, but it is one that Verilog fails to meet | 11:44 |
| Sarayan | what's the difference between $logic_not and $not? | 11:44 |
| mwk | $not is per bit, ie. ~signal | 11:45 |
| whitequark | Sarayan: have you looked at cxxrtl.h yet? | 11:45 |
| mwk | $logic_not is ~signal | 11:45 |
| mwk | err | 11:45 |
| mwk | $logic_not is !signal | 11:45 |
| whitequark | it has C++ implementations of many cells, which may be helpful | 11:45 |
| mwk | ie. it's 1 if all the signal bits are 0 | 11:45 |
| Sarayan | wq: No, I only use it | 11:45 |
| Sarayan | nwk: Ah I see, thanks | 11:45 |
| Sarayan | verilog has ! ? | 11:45 |
| mwk | ... how do people keep making that typo | 11:45 |
| mwk | yes, it does | 11:46 |
| Sarayan | if (!rstn) | 11:46 |
| Sarayan | cnt <= 0; | 11:46 |
| Sarayan | I guess that's a logic-not, whatever the width of rstn | 11:46 |
| mwk | yes | 11:46 |
| Sarayan | ok, good | 11:46 |
| mwk | it's equivalent to $not for single-bit signals, of course | 11:46 |
| Sarayan | yeah | 11:47 |
| Sarayan | which is why I wasn't seeing the difference | 11:47 |
| Sarayan | if my example had been n:1, It's have guessed I think :-) | 11:47 |
| Sarayan | I like the idea of integrating slang given I don't know verilog or rtlil :-) | 11:47 |
| Sarayan | funniest thing is it's kinda going somewhere | 11:48 |
| *** fengling has quit IRC | 12:44 | |
| *** vidbina_ has quit IRC | 14:03 | |
| *** jfcaron has joined #yosys | 14:06 | |
| ZirconiumX | daveshah: Does the Xilinx firmware.hex still count primes? | 14:10 |
| ZirconiumX | Or is it just counting up? | 14:10 |
| *** emeb has joined #yosys | 14:23 | |
| Sarayan | In verilog, can you have expression statements that are not assign? | 14:27 |
| ZirconiumX | "expression statements"? | 14:28 |
| Sarayan | well, that a laguage grammar term, but that all expressions that are use in place of a statement | 14:29 |
| Sarayan | e.g. in C you can write 'x++;' which is an expression turned into a statement | 14:29 |
| Sarayan | you can even write 'x;' but that does nothing | 14:29 |
| whitequark | do you mean within processes? | 14:30 |
| Sarayan | and subroutine calls are expressions in C | 14:30 |
| Sarayan | yeah | 14:30 |
| whitequark | i think you can have at least a=b, a<=b, fn(a) | 14:30 |
| whitequark | actually i'm not sure if "a=b" is an expression in verilog | 14:31 |
| whitequark | i thought it was only a statement? | 14:31 |
| daveshah | SystemVerilog has ++ | 14:31 |
| daveshah | I think it is only valid inside always blocks or a few other places like that | 14:31 |
| daveshah | I don't know if it is a statement or expression though | 14:31 |
| *** hexagon5un has quit IRC | 14:32 | |
| Sarayan | I think slang has it as expression | 14:32 |
| Sarayan | so I should expect more than just <= | 14:32 |
| Sarayan | oh, it has calls as expressions too, so yeah | 14:33 |
| Sarayan | also, in rtlil, where is assign hiding? | 14:33 |
| daveshah | module->connections_ | 14:33 |
| Sarayan | even the conditional ones? | 14:34 |
| whitequark | those are in processes | 14:34 |
| Sarayan | RTLIL::Process doesn't have much of an interface | 14:35 |
| Sarayan | looks like you're supposed to hit RTLIL::Module::processes directly | 14:40 |
| whitequark | daveshah: i suspect your SNES thing might be suffering from #1944; can you check at -O2 or even -O0? | 14:46 |
| daveshah | What difference should I expect to see? | 14:47 |
| whitequark | you had corrupted memory, right? | 14:48 |
| daveshah | No, that was just a typo on my part | 14:48 |
| whitequark | ahhh ok | 14:48 |
| daveshah | after fixing that it all appears to work fine | 14:48 |
| whitequark | sweet | 14:48 |
| whitequark | how many fps? :D | 14:48 |
| daveshah | Not far off 1fps | 14:48 |
| whitequark | hm, that's not that bad | 14:49 |
| whitequark | daveshah: so here's one theory i'd be interested to test but so far have been unable to | 14:49 |
| daveshah | no, I miscounted, in the proper working one it is about 0.2fps | 14:49 |
| daveshah | 12fpm | 14:50 |
| whitequark | the theory is that cxxrtl simulation can get faster by exploiting the nature of input verilog, specifically, by translating processes to if/elif statements and just never computing results it doesn't need | 14:51 |
| whitequark | rather than throwing them aay | 14:51 |
| whitequark | the problem is that flatten chokes on processes | 14:51 |
| whitequark | and on non-flattened designs it makes no difference | 14:51 |
| daveshah | In this case, that wouldn't help as ghdl doesn't create processes afaik | 14:51 |
| whitequark | oh | 14:51 |
| daveshah | I think it only creates DFFs and I don't think there's any way to change that | 14:51 |
| whitequark | ok, i see | 14:52 |
| whitequark | if you see any inefficiencies in the generated c++ i'm all ears | 14:52 |
| whitequark | (that can be fixed) | 14:52 |
| daveshah | Something I would like is reading memory init from a file, but that depends on the $meminit cell | 14:52 |
| daveshah | *$memfileinit | 14:53 |
| daveshah | or whatever the file variant would be called | 14:53 |
| whitequark | will happily add this if you add the cell | 14:53 |
| whitequark | it would be also interesting to have some way to say "the contents of this memory is a placeholder called X" | 14:54 |
| daveshah | Yeah, I'll think about that | 14:55 |
| whitequark | sweet :) | 14:55 |
| daveshah | It would be nice to easily do those kind of changes post-PnR in a cleaner way than icebram etc | 14:55 |
| whitequark | yes, exactly what's that for | 14:55 |
| whitequark | and in cxxrtl i can just call a user function | 14:55 |
| mwk | ... have been thinking the same thing for a while | 14:57 |
| mwk | something like passing "relocation" attributes along with the blockrams / lutrams / lut roms | 14:58 |
| mwk | "insert file abc.bin bits 1234-1337 here" | 14:58 |
| mwk | probably with some crazy permutation / bit slicing support | 14:58 |
| mwk | to support all the crazy shit that happens to memories as they get lowered | 14:59 |
| *** Vinalon has joined #yosys | 15:13 | |
| *** npe has joined #yosys | 15:22 | |
| *** citypw has quit IRC | 15:39 | |
| ZirconiumX | mwk: ironically that would probably be what I need | 15:50 |
| *** brasilino has joined #yosys | 15:52 | |
| *** npe has quit IRC | 15:53 | |
| *** FFY00 has quit IRC | 16:03 | |
| whitequark | daveshah: oh btw you can just write the entire memory at startup | 16:04 |
| daveshah | Oh, that seems like a good option for now | 16:04 |
| *** FFY00 has joined #yosys | 16:04 | |
| whitequark | I should add an overload for that case | 16:05 |
| whitequark | or maybe just poke into `top.p_memory.data` directly | 16:06 |
| *** jakobwenzel has quit IRC | 16:06 | |
| whitequark | that actually seems like the most reasonable solution for your case | 16:06 |
| whitequark | oh, `top.p_memory[index]` should work just as well | 16:07 |
| whitequark | I forgot I added that | 16:07 |
| Sarayan | there's an easy direct access to memory? | 16:19 |
| Sarayan | I've had to implement cpu write to fill it from c++ for now :-) | 16:26 |
| *** stroboko1p has quit IRC | 16:27 | |
| whitequark | syre | 16:28 |
| whitequark | *sure | 16:28 |
| whitequark | you can do `top.p_memory[0] = value<32> {123u};` | 16:29 |
| *** jfcaron has quit IRC | 16:33 | |
| *** futarisIRCcloud has quit IRC | 16:34 | |
| whitequark | daveshah: https://github.com/YosysHQ/yosys/pull/1947 | 16:48 |
| tpb | Title: cxxrtl: minor documentation and usability improvements by whitequark · Pull Request #1947 · YosysHQ/yosys · GitHub (at github.com) | 16:48 |
| whitequark | this removes const from ROMs so you can update them | 16:48 |
| ZirconiumX | Is there a way to see what memory_bram picks as init value for a memory? | 17:03 |
| *** twnqx has quit IRC | 17:03 | |
| *** twnqx has joined #yosys | 17:04 | |
| whitequark | which cell or which value? | 17:16 |
| ZirconiumX | Value | 17:17 |
| ZirconiumX | I kinda added a hack for it | 17:17 |
| ZirconiumX | So I can see if the LUTRAM values make sense | 17:23 |
| *** dys has quit IRC | 17:28 | |
| ZirconiumX | Y'know, if memory_bram knows it's emitting a ROM (which it can tell by there being zero write ports), and it can tell that an initialiser is a constant value (which it can through initparam) it makes next to no sense for it to be emitting zero-initialised ROMs | 17:33 |
| ZirconiumX | Instead of constant drivers | 17:34 |
| twnqx | these weird errors creep me out. i switch two values in an emulated ROM, and suddenly my design doesn't fit any more. | 17:46 |
| ZirconiumX | twnqx: "emulated ROM"? | 17:47 |
| ZirconiumX | The case statements? | 17:47 |
| twnqx | a case statement on a 3 bit address range, yes | 17:47 |
| ZirconiumX | And how many other variables do you use in that case statement? | 17:48 |
| twnqx | noen | 17:48 |
| twnqx | none | 17:48 |
| ZirconiumX | To be fair, consider that ABC - the synthesis engine in Yosys - is heuristic, and subtle changes can cascade into major differences | 17:49 |
| twnqx | however, i know something else is broken, i just can't find it yet | 17:49 |
| twnqx | because one address is never reached, even though it comes from a counter. | 17:49 |
| Sarayan | counter reset issue, or it's full range? | 17:49 |
| twnqx | the reset comes from the ROM, my bet is on insufficient sync (too much logic, not enough regs) | 17:50 |
| twnqx | hm, nearly any change too the "ROM" makes it not fit | 17:52 |
| twnqx | and the reset is synchronized even | 17:55 |
| twnqx | what does yosys consider a "dead case" for removal? if i have a decode of 2'b0?, 2'10, 2'b11, is there a dead case? | 18:04 |
| Vinalon | Speaking of how 'simplifying' logic can sometimes lead to larger and slower designs, does the ABC algorithm have any sort of 'seed' value that you can manually change? | 18:04 |
| twnqx | hm... what does "number of cells" in yosys output mean? | 18:11 |
| twnqx | if yosys claims 384 cells are needed in an lp384, nextpnr might not be right with 82% utilization... | 18:12 |
| *** jfcaron has joined #yosys | 18:12 | |
| daveshah | That's total cells of all varieties, some of those will pack together | 18:12 |
| Vinalon | the timing analysis lists the actual utilization once the design is packed under "Device utilisation:" | 18:14 |
| twnqx | well, my deisgn is unplaceable | 18:14 |
| Vinalon | it still might show up; I have a design that's showing "ICESTORM_LC: 6755/ 5280 127%" right now :P | 18:14 |
| ZirconiumX | twnqx: You can fit a LUT4 and a DFF together in an LC, but Yosys counts these as separate. | 18:15 |
| twnqx | both variants are at 82%, one is mapable, one is not :/ | 18:16 |
| twnqx | and in the mapable, one step is not reached | 18:16 |
| twnqx | aaand now it is, ok | 18:18 |
| twnqx | and now it's not again | 18:19 |
| twnqx | wow | 18:19 |
| twnqx | i really must be bad at this | 18:20 |
| Vinalon | as someone who is also still learning about digital design, the tooling can seem sort of opaque sometimes - don't worry if it doesn't feel intuitive | 18:26 |
| Vinalon | also, I don't think the lp384 has any RAM resources; maybe that complicates memories a little bit? | 18:26 |
| whitequark | as someone who maintains a HDL, it is frankly not much easier for me to figure out where the heck the resources went | 18:27 |
| twnqx | i have no real memories - just a few counters, buffers, shift registers | 18:27 |
| whitequark | twnqx: you're not bad at it. the tools are. i even wrote a pass that should somewhat solve this problem, though it's not yet in a state where it'd help you | 18:27 |
| twnqx | whitequark: the version that compiles changes behavior between different runs. that means i somewhere made a mistake, assuming the tooling isn't broken | 18:28 |
| twnqx | differenr runs = different compile runs | 18:29 |
| whitequark | twnqx: philosophically, if the tools don't help you make deterministic designs, they are, in some ways, broken... | 18:29 |
| whitequark | but more concretely | 18:29 |
| whitequark | is it a fully synchronous design? no generated clocks? only one `posedge x`? | 18:29 |
| whitequark | *only one `x` for every `posedge x` you use? | 18:29 |
| whitequark | are the external inputs resynchronized to the clock? | 18:30 |
| twnqx | the parts with two @posedge X are the only ones working reliably (SPI interface), and there are no other inputs, just clock and outputs | 18:30 |
| whitequark | is the difference in behavor something you observe when using SPI, or is SPI totally unused? | 18:31 |
| lambda | hmm, `opt_muxtree` isn't turning (a ? x : (b ? x : (c ? x : (d ? x : y)))) (four 80-bit muxes) into (a || b || c || d ? x : y) (one 80-bit mux and a cheap or-reduce) - isn't that what it's supposed to do though? | 18:32 |
| ZirconiumX | lambda: no, it's not | 18:33 |
| twnqx | actually, thank you for this pointer... i might be having an issue with an asynchronous reset, though i wonder how i would handle a "load register with value froom shiftregister on CS going high, set to 0 on something internally" without "@(posegde X or posedge reset)" | 18:34 |
| ZirconiumX | lambda: "This pass analyzes the control signals for the multiplexer trees in the design and identifies inputs that can never be active. It then removes this dead branches from the multiplexer trees." | 18:34 |
| lambda | ZirconiumX: oh, right, I misread the manual. is there a pass that should do this then? | 18:34 |
| whitequark | twnqx: is the SPI clock much slower than the FPGA clock? | 18:35 |
| twnqx | uhhhh and THAT asynchronous signal is not buffered | 18:35 |
| twnqx | simple as that, that's the nondeterministic part | 18:35 |
| twnqx | (the reset) | 18:35 |
| ZirconiumX | lambda: at present, I don't think so, but whitequark has/had opt_match that I *think* would have detected this | 18:35 |
| whitequark | ZirconiumX: actually you just gave me a great idea | 18:36 |
| ZirconiumX | *proc_match | 18:36 |
| lambda | well, let's hope ABC takes care of it during synthesis | 18:36 |
| twnqx | thanks again whitequark! | 18:36 |
| whitequark | ZirconiumX: the pass is called proc_match, but what if... it was called opt_match? | 18:36 |
| ZirconiumX | <obnoxious Shakespeare quote about "what's in a rose"> | 18:37 |
| whitequark | ZirconiumX: i had the most problems with the part where it translated processes to muxes. what if i just ditch that, and instead make it optimize match order of bits in processes alone? | 18:37 |
| ZirconiumX | I mean, I saw it as an optimisation pass | 18:37 |
| ZirconiumX | But sure | 18:37 |
| whitequark | it was combined optimization plus codegen pass | 18:37 |
| whitequark | but I think I can extract just the optimization part into a much much smaller pass | 18:38 |
| whitequark | in fact, I now see I can break it up into at least three different passes | 18:38 |
| ZirconiumX | You're welcome? | 18:38 |
| ZirconiumX | ^^; | 18:38 |
| whitequark | ZirconiumX: thank you. your typo was incredibly helpful actually | 18:38 |
| twnqx | and that one extra flip flop doesn't fit any more *cries* | 18:39 |
| ZirconiumX | whitequark: I suppose sometimes it just takes that tiny thing to make things click | 18:40 |
| lambda | twnqx: just stick an external 74xx flip-flop on the board :) | 18:42 |
| twnqx | :P | 18:42 |
| twnqx | too bad lattice doesn't make larger LP devices in the QFN casings | 18:42 |
| twnqx | LP1K in QFN32 or so would be nice | 18:43 |
| ZirconiumX | Now for another whitequark hug of Twitter notifications (I don't mind, it's just funny) | 18:45 |
| * twnqx reduces camera trigger length to ~10µs and reduces the 6 bit counter to 1 bit | 18:46 | |
| twnqx | design fits. | 18:46 |
| twnqx | noidea if camera still works, though... | 18:46 |
| lambda | twnqx: oh, high speed cameras? (sorry, your nick doesn't ring any bells here) | 18:48 |
| twnqx | no, not really, but external trigger | 18:48 |
| twnqx | theoratically 160fps tops | 18:49 |
| lambda | ah, neat | 18:49 |
| twnqx | sadly the jetson nano connected to it can only process 20fps :P | 18:49 |
| twnqx | also global shutter to not cause issues with PWM dimmed LED lighting... and the fpga controlls all of that (LED sequence, PWM dimming, camera trigger) | 18:51 |
| lambda | I was wondering what the precise shutter control was about, that makes sense | 18:52 |
| ZirconiumX | twnqx: You're doing all of that in an LP384, and I'm eating up a HX8K just to generate chess moves | 18:53 |
| twnqx | heh, it's just a bunch of counters and a shiftregister that can load some paramaters | 18:53 |
| ZirconiumX | I, uh, use quite a lot more than that | 18:54 |
| twnqx | back in university i did image processing on a... virtex 2 i think, that was also a bit more | 18:54 |
| lambda | good news: synth_ice40 manages to figure out those mux chains and uses the same amount of LUTs as with only one mux in the RTLIL | 18:54 |
| twnqx | my size problems really started when i needed a third 24bit brightness set and a one-of-three mux... | 18:55 |
| *** Vinalon has quit IRC | 19:06 | |
| *** Vinalon has joined #yosys | 19:20 | |
| twnqx | *sigh* now nextpnr fails with 78% device utilization | 19:44 |
| twnqx | daveshah: following your suggestion of -dffe_min_ce_use 8 causes "Warning: Wire top.spislave.cmd has an unprocessed 'init' attribute." (unlike e.g. 4, which keeps the design unplaceable) - is that critical? | 19:48 |
| *** ayazar has joined #yosys | 19:48 | |
| *** adjtm has quit IRC | 20:19 | |
| ZirconiumX | twnqx: Yes; I treat a similar situation in synth_intel_alm as a hard error | 20:25 |
| ZirconiumX | It means Yosys was unable to implement a flop in logic | 20:25 |
| ZirconiumX | Or, well, emulate specific flop semantics | 20:26 |
| mwk | it means some register initial value was ignored due to being unimplementable | 20:26 |
| mwk | it could either be due to a FF type not supported in hardware (say some targets cannot support a ff with async set and initial value of 0), or due to an initial value attached to something where it doesn't make much sense in the first place | 20:27 |
| mwk | are you using FFs with async set/reset? | 20:27 |
| daveshah | It sounds more like a bug in dffe_min_ce_use | 20:28 |
| *** katharina has joined #yosys | 21:24 | |
| twnqx | well, in my particular case i'll just don't care... i am trying to init it to 0 anyway | 21:41 |
| twnqx | mwk: and yes, one bit of this has an async reset | 21:42 |
| mwk | reset or set? | 21:43 |
| twnqx | reset | 21:43 |
| mwk | that should work | 21:44 |
| twnqx | it throws no warning in yosys until i go to -dffe_min_ce_use 8, but with less than that nextpnt can't route it | 21:44 |
| twnqx | and i am really a bit stumped as i am now below 80% utilization in nextpnr | 21:45 |
| daveshah | Place, or route? | 21:46 |
| twnqx | "ERROR: Unable to find legal placement for all cells, design is probably at utilisation limit." | 21:47 |
| twnqx | so, place | 21:47 |
| daveshah | Can you try with --placer sa as a nextpnr argument? | 21:48 |
| daveshah | Sometimes I think SA does slightly better at designs on the margins of placement | 21:49 |
| twnqx | that works.... | 21:49 |
| twnqx | that even works without any --dffe_min_ce_use | 21:50 |
| daveshah | Oh, that's interesting, I think there is definitely room for improvement in HeAP there then | 21:50 |
| daveshah | I'll add that to my TODO list | 21:50 |
| *** adjtm has joined #yosys | 21:51 | |
| *** jfcaron has quit IRC | 22:03 | |
| *** ayazar has quit IRC | 22:34 | |
| *** twnqx has quit IRC | 22:51 | |
| *** X-Scale` has joined #yosys | 23:03 | |
| *** X-Scale has quit IRC | 23:04 | |
| *** X-Scale` is now known as X-Scale | 23:04 | |
| *** adjtm has quit IRC | 23:13 | |
| *** futarisIRCcloud has joined #yosys | 23:18 | |
| *** adjtm has joined #yosys | 23:27 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!