| *** tpb has joined #yosys | 00:00 | |
| *** emeb_mac has joined #yosys | 00:24 | |
| *** Degi has quit IRC | 00:29 | |
| *** Degi has joined #yosys | 00:30 | |
| *** X-Scale` has joined #yosys | 00:57 | |
| *** X-Scale has quit IRC | 00:58 | |
| *** X-Scale` is now known as X-Scale | 00:58 | |
| *** emeb has quit IRC | 01:22 | |
| *** citypw has joined #yosys | 02:54 | |
| *** whitequark has joined #yosys | 03:06 | |
| *** npe has quit IRC | 03:07 | |
| *** Stary has quit IRC | 03:20 | |
| *** Stary has joined #yosys | 03:23 | |
| *** N2TOH_US has quit IRC | 03:32 | |
| *** N2TOH_US has joined #yosys | 03:33 | |
| *** npe has joined #yosys | 03:52 | |
| *** smarter_ has joined #yosys | 04:34 | |
| *** vup2 has joined #yosys | 04:34 | |
| *** daniellimws has joined #yosys | 04:37 | |
| *** vup has quit IRC | 04:40 | |
| *** m_hackerfoo has quit IRC | 04:40 | |
| *** anuejn has quit IRC | 04:40 | |
| *** grazfather has quit IRC | 04:40 | |
| *** m_hackerfoo has joined #yosys | 04:47 | |
| *** npe has quit IRC | 06:22 | |
| *** emeb_mac has quit IRC | 06:31 | |
| *** anuejn_ has joined #yosys | 07:03 | |
| *** dys has joined #yosys | 07:20 | |
| Sarayan | How can I have yosys tell me the exact compiler invocaitons on make? | 07:38 |
|---|---|---|
| Sarayan | V=1 doesn't do a thing and neither VERBOSE=1 | 07:39 |
| *** vidbina_ has joined #yosys | 07:39 | |
| whitequark | Sarayan: make PRETTY= | 07:40 |
| Sarayan | thanks :-) | 07:41 |
| sensille | is there a preferred way to get warnings from yosys/nextpnr? it's rather noisy | 08:02 |
| daveshah | -q | 08:03 |
| whitequark | have i mentioned the cxxrtl backend here yet? it's a backend i'm working on that emits C++ simulating ~arbitrary RTLIL netlists https://github.com/YosysHQ/yosys/pull/1562 | 08:05 |
| tpb | Title: write_cxxrtl: new backend by whitequark · Pull Request #1562 · YosysHQ/yosys · GitHub (at github.com) | 08:05 |
| whitequark | if any of you have use case for it, i'd be quite curious to hear | 08:05 |
| daveshah | I plan to try it for some mixed language sim fairly soon | 08:06 |
| sensille | daveshah: nice, thanks. to you normally aim for zero warnings? | 08:06 |
| daveshah | Yes | 08:06 |
| daveshah | For designs not doing anything particularly odd, zero warnings should be achievable with nextpnr and Yosys | 08:06 |
| sensille | my fear would be that the design changes be yosys-specific | 08:07 |
| daveshah | What warnings are you talking about? | 08:08 |
| whitequark | daveshah: nice! | 08:08 |
| sensille | like "Replacing memory ... with list of registers." | 08:08 |
| sensille | or "Resizing cell port ... from 5 bits to 8 bits." | 08:08 |
| daveshah | The resizing cell port one sounds like it would be good practice to fix | 08:08 |
| sensille | "Yosys has only limited support for tri-state logic at the moment." | 08:09 |
| daveshah | The replacing memory with list of registers is probably one that can be ignored (in the worst case it is a QoR issue, if you intended a memory to be used) | 08:09 |
| whitequark | you can mark the memory with (* ram_block *) if you intend a BRAM to be always used | 08:09 |
| daveshah | Does the frontend look at this? | 08:10 |
| daveshah | "Replacing memory ... with list of registers." means $memrd/$memwr and then $mem will never be created | 08:10 |
| whitequark | oh | 08:10 |
| whitequark | I have to fix that sometime | 08:10 |
| whitequark | I totally forgot that the Verilog frontend does that *too* for some reason | 08:10 |
| daveshah | It's for patterns that don't even make sense as $memrd/$memwr | 08:12 |
| daveshah | I think mostly things that involve continuous/async writes | 08:12 |
| whitequark | ah I see | 08:12 |
| daveshah | Usually, it is when the concept is an array rather than a memory anyway | 08:12 |
| whitequark | hm, $memwr does have a \CLK_ENABLE port | 08:12 |
| daveshah | I have a feeling from discussions with Claire in the past that there are a few other cases that need to be mem2reg'd in the frontend | 08:13 |
| daveshah | but I can't remember any details, just that there was a bug around this at one point | 08:14 |
| whitequark | yes, that's my impression too | 08:14 |
| sensille | it might be nice to see the utilization summary from nextpnr even with -q | 08:14 |
| whitequark | i also understand that the Verilog frontend in Yosys is perhaps one step above a proof of concept | 08:14 |
| daveshah | Yes, I think it was always intended to be rewritten but never was | 08:15 |
| daveshah | There are various talks of a new SV frontend based on one of the new parsers but I don't know if anything is actually happening | 08:15 |
| daveshah | ime, parsing is easy, elaborating is hard | 08:15 |
| whitequark | yup | 08:15 |
| whitequark | I feel like Yosys would be better off completely ditching the Verilog frontend and using some external project focusing on that specifically | 08:16 |
| whitequark | not only would this result in a much better frontend, but also it would reduce the intertwinedness of the Verilog frontend and optimization passe | 08:17 |
| daveshah | Yeah, ghdlsynth has shown this can be done | 08:17 |
| whitequark | and connect_rpc shows this can be done even if your frontend isn't in C++ :) | 08:18 |
| *** jakobwenzel has joined #yosys | 08:20 | |
| whitequark | daveshah: oh btw, any idea if transparent ports with RE can be supported by yosys reaonably easily? | 08:22 |
| whitequark | I feel like we discussed this before | 08:22 |
| daveshah | I'm tempted to automatically reply no for anything memory-related in yosys... | 08:22 |
| whitequark | oh yeah, they can't be, because the way it handles transparency groups at the moment is flawed | 08:23 |
| whitequark | blech | 08:23 |
| daveshah | I can't remember, I think it gets a bit complicated across clocks | 08:23 |
| daveshah | Yes | 08:23 |
| Sarayan | wq: I'm working today on seeing if I can integrate slang | 08:23 |
| whitequark | slang? | 08:24 |
| whitequark | oh the SV thing | 08:24 |
| daveshah | How much elaboration does it do? | 08:24 |
| Sarayan | Good question, it's on the way to integrate llvm, which I find, err, interesting :-) | 08:26 |
| Sarayan | (it's optional, so not an issue) | 08:26 |
| whitequark | llvm would not help you elaborate SV | 08:27 |
| Sarayan | Can you do sim-related code generation without having done elaboration first? | 08:29 |
| whitequark | no | 08:29 |
| Sarayan | Features | 08:29 |
| Sarayan | Fully parse, analyze, and elaborate all SystemVerilog features - see this page for current status. | 08:29 |
| whitequark | that sounds quite good | 08:29 |
| Sarayan | yeah | 08:29 |
| whitequark | perhaps too good? it took how many years for synopsys to implement all of SV? | 08:29 |
| Sarayan | no idea | 08:30 |
| Sarayan | it will be better than what's currently in there in any case | 08:30 |
| whitequark | indeed | 08:30 |
| Sarayan | Status page: https://sv-lang.com/language-support.html | 08:32 |
| tpb | Title: Language Support | slang C++ docs (at sv-lang.com) | 08:32 |
| Sarayan | there's a lot of red, but there's also a lot of green | 08:33 |
| *** daniellimws has left #yosys | 08:33 | |
| Sarayan | I'm not capable of seeing what's significant in there | 08:34 |
| whitequark | seems reasonable to me | 08:34 |
| whitequark | SVA seems to be largely missing | 08:34 |
| Sarayan | I don't even know what sva means :-) | 08:35 |
| whitequark | systemverilog assertions | 08:35 |
| whitequark | formal verification features, one of the most directly useful parts of systemverilog | 08:35 |
| daveshah | I think the big problem with anything like slang is the netlist generation side | 08:35 |
| daveshah | Which I can't see much of atm, but may be missing | 08:35 |
| daveshah | Certainly with adding synthesis to ghdl that has looked to have been fairly complicated | 08:36 |
| *** jryans has quit IRC | 08:39 | |
| *** promach3 has quit IRC | 08:39 | |
| *** fevv8[m] has quit IRC | 08:39 | |
| *** rjo has quit IRC | 08:39 | |
| *** emily has quit IRC | 08:39 | |
| Sarayan | hmmm, annoying caveat, slang really requires c++17 | 08:44 |
| *** oldtopman has joined #yosys | 08:44 | |
| sensille | hm. -defer does not help with default parameters set to invalid values for the design | 08:50 |
| *** Vinalon has quit IRC | 08:51 | |
| *** rjo has joined #yosys | 08:52 | |
| sensille | the "Resizing cell port" warning is also from a difference in default parameters | 08:54 |
| daveshah | In what context are you using -defer? | 08:54 |
| daveshah | This is exactly what it is intended for | 08:54 |
| sensille | you recommended it to me a few days ago | 08:55 |
| sensille | i initially set all default parameters to 0, which led to errors | 08:55 |
| daveshah | So you are using read_verilog -defer and you still get a warning based on the default parameters? | 08:55 |
| sensille | yosys -defer -p "synth_ecp5 -json $(TARGET).json" $(SRC) | 08:56 |
| sensille | oh, it's an option to read_verilog | 08:57 |
| sensille | i'm afraid i have to understand more of yosys | 08:57 |
| daveshah | It's an unfortunate consequence of getopt that -defer is accepted (it is parsed as -d -e fer) | 09:02 |
| sensille | i was shortly wondering about that | 09:03 |
| sensille | so yosys -p "verilog_defaults -add -defer" -p "synth_ecp5 -json $(TARGET).json" $(SRC)? | 09:04 |
| sensille | probably not, still complains | 09:04 |
| *** futarisIRCcloud has quit IRC | 09:05 | |
| sensille | doing that on the command line works, though | 09:06 |
| *** jryans has joined #yosys | 09:31 | |
| *** promach3 has joined #yosys | 09:31 | |
| *** fevv8[m] has joined #yosys | 09:31 | |
| *** emily has joined #yosys | 09:31 | |
| *** jakobwenzel has quit IRC | 09:55 | |
| sensille | i have no idea where the read_verilog comes from on my current command line | 10:00 |
| ZirconiumX | sensille: if you specify a .v file for Yosys it'll invoke read_verilog on it | 10:02 |
| sensille | ok, then the next question is why verilog_defaults doesn't work on that | 10:03 |
| daveshah | Because -p runs after command line frontends | 10:04 |
| daveshah | I think -f "verilog -defer" should use read_verilog -defer for command line files | 10:04 |
| *** jakobwenzel has joined #yosys | 10:06 | |
| sensille | with this i get less warnings, but an error "Module ... is not part of the design" | 10:07 |
| sensille | so it probably replaces more than just the read_verilog | 10:07 |
| daveshah | When using defer, you need to pass -top to synth_ecp5 | 10:09 |
| *** vidbina_ has quit IRC | 10:11 | |
| sensille | finally :) most warnings are gone, and now i can see that the "Resizing cell size" warnings are my own fault | 10:13 |
| *** vidbina_ has joined #yosys | 11:13 | |
| *** lambda has quit IRC | 11:41 | |
| *** lambda has joined #yosys | 11:44 | |
| *** lambda has quit IRC | 11:45 | |
| *** lambda has joined #yosys | 11:47 | |
| Sarayan | ok, slang compiles in a yosys tree, now for the fun part, plugging it in | 11:58 |
| *** vup2 is now known as vup | 12:23 | |
| *** vidbina_ has quit IRC | 12:41 | |
| *** vidbina_ has joined #yosys | 12:51 | |
| *** jfcaron has joined #yosys | 13:05 | |
| *** vidbina_ has quit IRC | 13:15 | |
| *** vidbina_ has joined #yosys | 13:45 | |
| *** sorear has quit IRC | 13:50 | |
| Sarayan | So, sv is parsed into... something | 13:51 |
| *** sorear has joined #yosys | 13:52 | |
| Sarayan | now to see how to introduce that somthing to yosys | 13:52 |
| whitequark | that was fast | 13:53 |
| Sarayan | :-) | 13:53 |
| Sarayan | it's rather minimal for now, as in I don't parse options (but that will be trivial, I just want to make the rest work first) | 13:54 |
| Sarayan | ok, terminology, elaboration, that's something that happens before or after the ast? | 13:57 |
| ZirconiumX | elaboration is turning a generic module into a concrete instance, AIUI | 13:57 |
| Sarayan | e.g. if I use whatever elaboration support is in slang, do I hook at the ast level or, i guess, at the rtlil level? | 13:58 |
| ZirconiumX | Yosys would take in concrete RTLIL, I think. | 13:58 |
| whitequark | ideally at rtlil level | 13:58 |
| ZirconiumX | So I think you'd want to elaborate before feeding into Yosys, right? | 13:59 |
| Sarayan | ZX: I'm into yosys in the first place | 13:59 |
| whitequark | rtlil is a relatively clean and well documented boundary, using it saves you a lot of trouble extending ast to suit slang's needs | 13:59 |
| whitequark | by using rtlil at the interface you leave both slang and yosys doing what they do best | 13:59 |
| Sarayan | ok, makes sense | 13:59 |
| Sarayan | also, are you supposed to be able to have multiple files in a read_* command? | 14:02 |
| Sarayan | if yes, how do that jive with the frontend execute interface, if no how do you input a design that is in three files? | 14:03 |
| ZirconiumX | Sarayan: I think order matters a fair bit in that respect | 14:04 |
| ZirconiumX | Either you can do what e.g. read_verilog -defer does, which resolves modules later, or you can require the user to input in topological order | 14:04 |
| Sarayan | hmmm ok | 14:05 |
| Sarayan | gonna try for topo order for now, once everything else works it gets easier to refine that kind of questions | 14:05 |
| *** Vinalon has joined #yosys | 14:31 | |
| *** vidbina_ has quit IRC | 14:32 | |
| *** Cerpin has quit IRC | 14:38 | |
| whitequark | does anyone here have strong opinions on the way cxxrtl should be emitting blackbox cells that are replaced with C++ models? | 14:52 |
| whitequark | i'm primarily deciding between making it a property of the *module* (therefore necessitating creation of blackbox modules) or a property of the *cell* | 14:52 |
| whitequark | i.e. if it is a property of the cell, then any undefined cell can be marked so that it turns into a C++ blackbox | 14:53 |
| whitequark | if it is a property of the module, something somewhere in the design flow has to create the blackbox modules | 14:53 |
| *** miek has joined #yosys | 14:55 | |
| *** emeb has joined #yosys | 15:01 | |
| ZirconiumX | It seems to me like it should be a property of the module, whitequark | 15:04 |
| ZirconiumX | Even though it requires more effort, I'd prefer it goes "hey, this module isn't defined" sooner in the event of a problem than have to wade through, what, linker errors? | 15:05 |
| whitequark | that was what I thought at first, but here is an issue with it: parametric blackboxes | 15:07 |
| whitequark | the thing is that I can't really generate a C++ class parameterized by port widths, at least not easily and possibly not at all | 15:12 |
| Sarayan | ok ,cat is gone, I can work on the code again | 15:40 |
| qu1j0t3 | rm /bin/cat | 15:41 |
| Sarayan | qu1j0t3: more like spontaneous relocation | 15:44 |
| Sarayan | does somebody have a non-entirely-trivial systemverilog example that works with yosys? | 15:50 |
| *** dys has quit IRC | 15:54 | |
| Sarayan | ah, found something | 16:01 |
| *** npe has joined #yosys | 16:04 | |
| *** az0re has quit IRC | 16:08 | |
| *** jakobwenzel has quit IRC | 16:12 | |
| Sarayan | what is the attribute ID::cells_not_processed ? I don't find it in the yosys manual | 16:30 |
| *** vidbina_ has joined #yosys | 16:37 | |
| *** Cerpin has joined #yosys | 16:57 | |
| *** vidbina_ has quit IRC | 17:03 | |
| *** citypw has quit IRC | 17:07 | |
| *** az0re has joined #yosys | 17:25 | |
| *** vidbina_ has joined #yosys | 17:25 | |
| *** futarisIRCcloud has joined #yosys | 17:31 | |
| *** npe has quit IRC | 18:13 | |
| *** az0re has quit IRC | 18:21 | |
| *** npe has joined #yosys | 18:47 | |
| *** futarisIRCcloud has quit IRC | 19:41 | |
| *** dh73 has joined #yosys | 19:48 | |
| *** dh73 has joined #yosys | 19:49 | |
| *** FFY00 has quit IRC | 20:10 | |
| *** FFY00 has joined #yosys | 20:11 | |
| *** smarter_ is now known as smarter | 20:17 | |
| *** Cerpin has quit IRC | 21:23 | |
| *** Cerpin has joined #yosys | 21:23 | |
| *** jfcaron has quit IRC | 22:13 | |
| *** dh73 has quit IRC | 22:58 | |
| *** emeb has quit IRC | 23:35 | |
| *** emeb_mac has joined #yosys | 23:58 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!