| *** tpb has joined #symbiflow | 00:00 | |
| *** celadon has quit IRC | 01:09 | |
| *** celadon has joined #symbiflow | 01:10 | |
| *** Bertl_oO is now known as Bertl_zZ | 01:48 | |
| *** citypw has joined #symbiflow | 02:02 | |
| *** Degi has quit IRC | 02:03 | |
| *** Degi has joined #symbiflow | 02:04 | |
| *** heath is now known as h | 02:52 | |
| *** h is now known as heath | 02:52 | |
| *** proteus-guy has quit IRC | 05:04 | |
| *** OmniMancer1 has joined #symbiflow | 05:25 | |
| *** OmniMancer has quit IRC | 05:27 | |
| *** OmniMancer has joined #symbiflow | 05:33 | |
| *** OmniMancer1 has quit IRC | 05:35 | |
| *** citypw has quit IRC | 05:35 | |
| *** citypw has joined #symbiflow | 05:49 | |
| *** az0re has quit IRC | 05:50 | |
| *** rvalles has quit IRC | 05:50 | |
| *** rvalles has joined #symbiflow | 06:08 | |
| *** az0re has joined #symbiflow | 06:21 | |
| *** OmniMancer has quit IRC | 06:32 | |
| *** OmniMancer has joined #symbiflow | 06:35 | |
| *** Bertl_zZ is now known as Bertl | 08:01 | |
| *** clay_1 has joined #symbiflow | 08:45 | |
| lambda | litghost: I'm using an xc7a35t, which seems to have two CMT_TOP_L_UPPER_T PLLs in the bottom right, and three CMT_TOP_R_UPPER_T PLLs along the left side of the chip | 09:39 |
|---|---|---|
| lambda | (at least that's what the Vivado device view suggests) | 09:40 |
| lambda | mithro: I can try vpr. the design is open source at https://gitlab.com/YARM-project/soc/, but it's VHDL - but I expect just dumping it to a verilog netlist with yosys should work? | 09:43 |
| sf-slack | <mithro> This content can't be displayed. | 09:43 |
| tpb | Title: Sign in · GitLab (at gitlab.com) | 09:43 |
| *** az0re has quit IRC | 09:45 | |
| *** proteus-guy has joined #symbiflow | 10:06 | |
| *** kraiskil has joined #symbiflow | 10:19 | |
| *** kraiskil has quit IRC | 10:42 | |
| *** clay_1 has quit IRC | 10:52 | |
| *** CMP1 has joined #symbiflow | 11:03 | |
| CMP1 | Hey everyone. I would like some help regarding the term of Slice. As I can see typically a Tile has two of them. In the case of CLB there are sliceL and sliceM slices. But what about DSPs and BRAMs? | 11:13 |
| CMP1 | are their tiles considered to have slices ? | 11:14 |
| sf-slack | <acomodi> SLICE is a `Site` within only the CLB tiles | 11:14 |
| sf-slack | <acomodi> Tiles can have sites | 11:15 |
| CMP1 | So CLBs, BRaMs and DSPs have two sites each | 11:15 |
| CMP1 | actually thats falso BRAms have more sites | 11:15 |
| sf-slack | <acomodi> Each tile can have its own specific set of sites, it doesn't need to be 2 | 11:16 |
| CMP1 | and also the interconnect box inside CLBs are a site as well, right ? | 11:16 |
| CMP1 | I see, so every "box" inside a tile is a site | 11:17 |
| sf-slack | <acomodi> For the 7series the CLB has 2 sites, which are the two Slices you mentioned | 11:17 |
| CMP1 | oh so the fake pip box they have is not considered a site ? | 11:17 |
| sf-slack | <acomodi> Exactly, that's not a site | 11:17 |
| CMP1 | so slices are called only the CLB sites ? | 11:18 |
| CMP1 | I mean that used to be my earlier understanding but then I saw the title of ug479 beeing `7 Series DSP48E1 Slice` | 11:20 |
| CMP1 | and that started to make me believe that more tiles have divisions called slices or something | 11:20 |
| sf-slack | <eddy.gta17> Does project icestorm support system verilog? I am trying to synthesise the ibex core for the ice40. Yosys gives errors on the .sv file and the .v file that was converted using sv2v. I read this is due to the parser in yosys. Is there a workaround? | 11:22 |
| sf-slack | <acomodi> CMP1: so, to answer your questions, you can see in the device view on Vivado, that when you select a tile it opens the `Tile properties`, when you navigate within that tile you can select the sites, which will open the `Site properties` . The naming is a convention. CLB have two SLICE sites, DSP have two DSP48E1 sites, BRAMs have 2 RAMB18E1 and 1 RAMB36E1 sites and so on | 11:26 |
| sf-slack | <acomodi> @eddy.gta17 I am not sure whether the synthesis pass for the ice40 will pass, but here there are ibex core .v files that has been translated from .sv and can be correctly synthesized for the artix7 | 11:28 |
| sf-slack | <acomodi> https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc/xc7/tests/soc/ibex | 11:28 |
| tpb | Title: symbiflow-arch-defs/xc/xc7/tests/soc/ibex at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 11:28 |
| CMP1 | I see, now things are more clear. In my uneducated view the term slice seems redundant and can cause only confusion since siteL and site | 11:28 |
| CMP1 | siteM would work to describe everything, right ? | 11:29 |
| sf-slack | <acomodi> CMP1: what do you mena by describe everything? | 11:30 |
| CMP1 | I mean by removing the term slice we would still be able to address every unit with the term site | 11:30 |
| sf-slack | <eddy.gta17> @acomodi I will try the .v files in the Symbiflow repo. Are they the same as the lowRISC or any keywords changed? | 11:31 |
| *** _whitelogger has quit IRC | 11:36 | |
| *** _whitelogger has joined #symbiflow | 11:38 | |
| sf-slack | <acomodi> @eddy.gta17 They are the same. Only difference is in the absence of the clock gating part. | 11:39 |
| sf-slack | <acomodi> CMP1: I believe I am not completely following. What do you mean by unit, and from where would you remove the term slice? | 11:42 |
| sf-slack | <acomodi> CMP1: one more thing is that, if you see in the documentation something like `DSP SLICE` it should actually refer not to the sites, but the DSP tile itself. | 11:42 |
| CMP1 | I meant that since all slices are sties but not all sites slices, by introducing different types of sites (like siteL, siteM) we wouldnt need the term slice. | 11:44 |
| CMP1 | Hmm but the title was `7 Series DSP48E1 Slice` and as you said erlier, DSP48E1 is a site of a DSP tile | 11:45 |
| sf-slack | <acomodi> But the fact is that with `siteL` and `siteM` there would be a lot of confusion. The term `SLICE` within the CLB clearly eliminates any doubts. CLBs are formed by sites named `SLICEs` | 11:46 |
| sf-slack | <acomodi> As I said `7 Series DSP48E1 Slice` refers to the DSP "Tile". In this case the term Slice has nothing to do with the CLB Slices | 11:47 |
| CMP1 | I agree with that but it seems the term slice is not only used there--> hence the confusion | 11:47 |
| CMP1 | But at least i think I have them clear in my head now. Thank you very much ! | 11:48 |
| sf-slack | <acomodi> No problem ;) | 11:49 |
| CMP1 | :D | 11:52 |
| *** kraiskil has joined #symbiflow | 11:52 | |
| CMP1 | Hmm what about the relationship between configuration packets and configuration frames ? Configuration packets contain a number of configuration frames depending on their type ? | 12:28 |
| *** CMP1 has quit IRC | 12:47 | |
| *** CMP1 has joined #symbiflow | 12:48 | |
| sf-slack | <tmichalak> configuration packages consist of header and payload, Type 1 Configuration packets have a register address field so you can write a configuration frames' address to the FAR register followed by a Type 2 configuration packet writes to the FDRI register with all the words within that configuration frame | 13:02 |
| CMP1 | So for a type one packet, the header will idicate that it is type 1 and the payload will be one configuration frame's address ? | 13:06 |
| *** kraiskil has quit IRC | 13:08 | |
| sf-slack | <tmichalak> It's a little bit more complex, please refer to the configuration user guide (https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf) starting at page 104 | 13:10 |
| sf-slack | <tmichalak> In brief the configuration frame address has to be written to the FAR (Frame Address Register) register and the configuration words to the FDRI (Frame Data Register Input) register) | 13:12 |
| sf-slack | <tmichalak> And to do this you need a combination of Type1 and Type2 packets | 13:12 |
| CMP1 | In the way I understand it from the ug, type 2 will only be used if the word count supported by type 1 is not sufficient | 13:13 |
| CMP1 | but I don't understand what this word count depends on | 13:14 |
| sf-slack | <tmichalak> Yes, so you can configure a number of frames using the Type1 packets only | 13:15 |
| CMP1 | does it try to write all the configuration frames at once ? so for small designs a type1 only is sufficient but for bigger ones you need type 2 as well ? | 13:15 |
| litghost | lambda: Both CMT_TOP_L_UPPER_T and CMT_TOP_R_UPPER_T have tilegrid base addresses, so both should work. I expect that the the problem is in how nextpnr-xilinx is emitting the FASM, not in the database | 13:21 |
| sf-slack | <tmichalak> CMP1: It doesn't really depend on the design size. You can write 20 configuration frames with 10 Type1 writes (20 * 101 < 2048) or just with one Type2 | 13:22 |
| lambda | litghost: oh, nice! I'll look into that then if daveshah isn't already on it | 13:22 |
| -_whitenotifier-3- [prjtrellis] minecraft2048 opened issue #131: I think multiplier inference is working in prjtrellis and yosys master - https://git.io/JvHwk | 13:23 | |
| sf-slack | <tmichalak> CMP1: Since Type1 one can write 2048 words at once | 13:23 |
| CMP1 | tmichalak but wont this normally happen automatically by vivado ? | 13:23 |
| daveshah | lambda: feel free to have a go, I think something probably just needs renaming | 13:24 |
| daveshah | Most likely an L and R swapped in the output or similar | 13:24 |
| lambda | alright, will do | 13:24 |
| sf-slack | <tmichalak> CMP1: Depends on you bootgen setting, if you have PER_FRAME_CRC enabled then no | 13:25 |
| CMP1 | oh I think I understand now why you said that the design size doesnt matter. No matter how big or small the device is, all frames will be read (even the empty ones) so the number of words that have to be read are FPGA device specific ? | 13:25 |
| *** tcal has quit IRC | 13:26 | |
| sf-slack | <tmichalak> CMP1: Yes, it's more FPGA family dependent, but for Series7 it's always 101 words | 13:27 |
| CMP1 | oh yes, but I didnt mean that, I meant the number of 101 32-bit words that need to be read in total | 13:28 |
| sf-slack | <tmichalak> The number of words in a frame is constant for Series7 it's 101 32-bit words | 13:29 |
| CMP1 | and how about the number of frames in a device, isnt that device constant depending on how bi it is or something like that ? | 13:30 |
| CMP1 | big * | 13:30 |
| sf-slack | <tmichalak> frame addressing is described in SymbiFlow's documentation and also in the Configuration Guide, the number of frames really depends on the size of the FPGA | 13:34 |
| CMP1 | Nice, and in every configuration all frames are read regardless if they are empty or not, right ? | 13:35 |
| sf-slack | <tmichalak> right | 13:37 |
| CMP1 | great, thanks :) | 13:38 |
| *** epony has quit IRC | 13:52 | |
| *** Bertl is now known as Bertl_oO | 13:56 | |
| *** epony has joined #symbiflow | 14:19 | |
| *** tcal has joined #symbiflow | 15:01 | |
| *** citypw has quit IRC | 15:21 | |
| *** OmniMancer has quit IRC | 15:21 | |
| CMP1 | Has CFG_CLB been found in any bit stream up to now ? | 15:32 |
| *** proteus-guy has quit IRC | 15:46 | |
| *** az0re has joined #symbiflow | 15:59 | |
| *** proteus-guy has joined #symbiflow | 15:59 | |
| *** kraiskil has joined #symbiflow | 16:02 | |
| *** kraiskil has quit IRC | 16:02 | |
| *** kraiskil has joined #symbiflow | 16:03 | |
| *** kraiskil has joined #symbiflow | 16:04 | |
| *** kraiskil has quit IRC | 16:33 | |
| *** kraiskil has joined #symbiflow | 16:36 | |
| *** CMP1 has quit IRC | 17:24 | |
| lambda | daveshah litghost: fasm2frames.py is saying `Segment DB CMT_TOP_R_LOWER_B, key CMT_TOP_R_LOWER_B.MMCM_CLK_FREQ_BB_NS0.MMCM_CLK_FREQ_BB_REBUF0_NS not found from line 'CMT_TOP_R_LOWER_B_X8Y61.MMCM_CLK_FREQ_BB_NS0.MMCM_CLK_FREQ_BB_REBUF0_NS'`. | 17:33 |
| lambda | I'm assuming that's a pip connecting MMCM_CLK_FREQ_BB_REBUF0_NS and MMCM_CLK_FREQ_BB_NS0 in a CMT_TOP_R_LOWER_B - but I see that exact pip ("CMT_TOP_R_LOWER_B.MMCM_CLK_FREQ_BB_REBUF0_NS<<->>MMCM_CLK_FREQ_BB_NS0") in tile_type_CMT_TOP_R_LOWER_B.json. | 17:33 |
| litghost | That's a MMCM pip? | 17:35 |
| litghost | We do *not* have fuzzing for the MMCM part of the CMT interconnect | 17:35 |
| litghost | Not sure why nextpnr is going down there though | 17:35 |
| lambda | ohh, so this might not be directly related to enabling more PLLs in nextpnr, but rather to the fact that litedram now gets through PNR - it of course uses PHASERs and such, maybe those just aren't supported enough yet | 17:36 |
| litghost | I don't think LiteDRAM used PHASERs? And yes, PHASERs are not currently supported | 17:37 |
| lambda | I also get two errors from PIPs in CMT_TOP_R_UPPER_B_X8Y31, which looks to be a PHASER | 17:37 |
| daveshah | It seems like nextpnr is just using pips that it shouldn't | 17:38 |
| daveshah | Is this the same netlist as before, I can have a look tomorrow | 17:38 |
| daveshah | I think I've seen this phaser pip issue before | 17:38 |
| lambda | daveshah: I'll retry with the old netlist real quick, should be the same though yes | 17:39 |
| litghost | lambda: It is worth noting that I expect the fuzzers written for the PLL will work with the MMCM with a "s/PLL/MMCM/", but it hasn't been tried yet | 17:40 |
| lambda | daveshah: sorry for the wait, here's a set of netlist, constraints and FASM that fails: https://misc.xiretza.xyz/repro/badpips.tar.gz | 18:46 |
| daveshah | Thanks | 18:46 |
| *** TheHolyC_ has joined #symbiflow | 19:45 | |
| *** TheHolyC has quit IRC | 19:45 | |
| *** az0re has quit IRC | 19:45 | |
| *** Vonter has quit IRC | 19:46 | |
| *** Vonter has joined #symbiflow | 19:47 | |
| *** az0re has joined #symbiflow | 20:39 | |
| *** kraiskil has quit IRC | 22:09 | |
| FFY00 | mithro, do you have any questions about https://github.com/enjoy-digital/litex/issues/443? do you still not agree with my comments? | 23:31 |
| tpb | Title: Add a release · Issue #443 · enjoy-digital/litex · GitHub (at github.com) | 23:31 |
| sf-slack | <mithro> This content can't be displayed. | 23:31 |
| FFY00 | I just want to make sure everyone is fine with the change | 23:31 |
| FFY00 | > <mithro> This content can't be displayed. | 23:32 |
| FFY00 | sorry, irc | 23:32 |
| mithro | FFY00: The discussion around weather releases are good or bad for software reliability is a long one | 23:32 |
| FFY00 | okay | 23:33 |
| mithro | FFY00: The discussion around if it is good to getting stuff from your distro or directly is also a long one | 23:34 |
| mithro | semver is also pretty much impossible to comply with in a language like Python | 23:35 |
| FFY00 | that point doesn't really apply to archlinux (which is the distro I use, and I package for) | 23:35 |
| FFY00 | semver is not impossible, it just probably requires a different development approach than you guys have | 23:35 |
| FFY00 | I imagine | 23:36 |
| FFY00 | and that's fine, that's why I only asked for it to be considerate | 23:36 |
| mithro | FFY00: It is currently pretty much possible to really define what "backwards compatible manner" and "API" actually covers in Python | 23:36 |
| FFY00 | *considered | 23:36 |
| FFY00 | that's right, if you have a moving target | 23:37 |
| FFY00 | and, as I said, I understand and it's fine | 23:37 |
| mithro | In compiled statically typed languages you can at least define it as it should continue to compile | 23:37 |
| FFY00 | but it is very possible to follow semver in python | 23:37 |
| FFY00 | mithro, you have type hint in python | 23:38 |
| FFY00 | and you can run type checks | 23:38 |
| sf-slack | <mithro> This content can't be displayed. | 23:38 |
| FFY00 | I use that heavily on my projects | 23:38 |
| FFY00 | > <mithro> This content can't be displayed. | 23:38 |
| FFY00 | again ;) | 23:38 |
| mithro | Hrm... What is the slackbridge doing :-/ | 23:39 |
| FFY00 | but type hints in python is fairly recent | 23:39 |
| FFY00 | although, from my experience it works pretty well | 23:39 |
| FFY00 | nevertheless, no doubt it is harder to follow semver in python than typed or compiled languages | 23:40 |
| FFY00 | but we probably shouldn't be arguing about that, unless you want to spend some time | 23:41 |
| mithro | I do think semver works really work for C libraries used as part of a server / desktop environment | 23:41 |
| FFY00 | if you want an example of one of my projects that does take advantage of type hints: https://github.com/libratbag/ratbag-emu | 23:41 |
| tpb | Title: GitHub - libratbag/ratbag-emu: HID emulation stack (at github.com) | 23:41 |
| FFY00 | the thing is that in python you should still keep track of breaking changes | 23:42 |
| mithro | FFY00: Yeah, we are slowly moving towards using more type hints | 23:42 |
| mithro | FFY00: But it is pretty easy to make breaking changes in Python without knowing it | 23:43 |
| mithro | FFY00: "If you want it to work, you should put a test on it" :-) | 23:43 |
| FFY00 | but semver probably is too aggressive (at least for your development environment) as it would probably require a major version bump every release | 23:43 |
| FFY00 | mithro, exactly | 23:43 |
| FFY00 | if a certain part of your code does not have tests, it as good as broken | 23:44 |
| FFY00 | because changes are it will eventually break | 23:44 |
| FFY00 | *chances | 23:45 |
| mithro | There was a quote I found the other day which went something like "Everyone has a testing environment, some people are just lucky enough for it to be seperate from their production environment" | 23:45 |
| FFY00 | yeah | 23:46 |
| mithro | FFY00: Github doesn't seem to correctly detect your license -- https://github.com/libratbag/ratbag-emu/blob/master/LICENSE | 23:46 |
| tpb | Title: ratbag-emu/LICENSE at master · libratbag/ratbag-emu · GitHub (at github.com) | 23:46 |
| mithro | FFY00: With low test coverage and dynamic language like python you want your users to try and run with your changes ASAP so they can report bugs / breaking issues as quickly as they can so you can fix them before they affect a lot of people | 23:47 |
| FFY00 | I don't think it correctly detect any license with a custom copyrighted field? | 23:47 |
| mithro | Works fine here -> https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/COPYING | 23:47 |
| *** FFY00 has quit IRC | 23:47 | |
| tpb | Title: symbiflow-arch-defs/COPYING at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 23:47 |
| *** FFY00 has joined #symbiflow | 23:48 | |
| mithro | Works fine here -> https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/COPYING | 23:50 |
| tpb | Title: symbiflow-arch-defs/COPYING at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 23:50 |
| FFY00 | eh, it's just github being broken | 23:51 |
| FFY00 | someday I remember it is closed source | 23:51 |
| FFY00 | *somedays | 23:51 |
| FFY00 | circling back to litex, just having releases would be a great improvement in my book | 23:53 |
| FFY00 | semver would be a great plus but I totally understand why it might not make sense for you | 23:54 |
| FFY00 | :) | 23:54 |
| mithro | FFY00: my goal is to improve the test suite and get us publishing any time the test suite is green | 23:54 |
| FFY00 | I still think that's not a great idea | 23:55 |
| FFY00 | releases should be manual in my opinion | 23:55 |
| FFY00 | but if you do that make sure you also check for coverage | 23:55 |
| mithro | FFY00: Why? What do you think should be done that isn't done automatically | 23:55 |
| mithro | FFY00: This conversation should probably be in #litex too rather than here | 23:56 |
| FFY00 | I mean, the release itself could be automated | 23:56 |
| mithro | FFY00: The License detection code is open source -> https://help.github.com/en/github/creating-cloning-and-archiving-repositories/licensing-a-repository#detecting-a-license | 23:56 |
| tpb | Title: Licensing a repository - GitHub Help (at help.github.com) | 23:56 |
| FFY00 | I just think it should be arbitrarily chosen | 23:56 |
| FFY00 | and with each release a quick summary of the changes and the api changes | 23:57 |
| FFY00 | ^ that would be a plus | 23:57 |
| FFY00 | yes, let's go to litex, sorry | 23:57 |
| mithro | FFY00: https://github.com/licensee/licensee | 23:58 |
| tpb | Title: GitHub - licensee/licensee: A Ruby Gem to detect under what license a project is distributed. (at github.com) | 23:58 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!