| *** tpb has joined #symbiflow | 00:00 | |
| *** OmniMancer has joined #symbiflow | 01:37 | |
| *** Degi has quit IRC | 02:01 | |
| *** Degi_ has joined #symbiflow | 02:01 | |
| *** Degi_ is now known as Degi | 02:01 | |
| *** ramin_r348 has joined #symbiflow | 02:06 | |
| ramin_r348 | Hi All, I am a PhD student, working on FPGA architectures (Designing LE, DSPs, Routing) targeting ML applications. I was wondering to find a task here which I can handle and help the SymbiFlow. Also, I want to submit a GSoC application, as well. Could you please help me and tell me about the architectural works here? I have a few published works | 02:21 |
|---|---|---|
| ramin_r348 | about LE/DSPs. I hope to be helpful. | 02:21 |
| ramin_r348 | Thanks | 02:21 |
| *** citypw has joined #symbiflow | 02:40 | |
| *** citypw has quit IRC | 03:32 | |
| *** citypw has joined #symbiflow | 03:34 | |
| *** citypw has quit IRC | 03:36 | |
| *** citypw has joined #symbiflow | 03:37 | |
| *** citypw has joined #symbiflow | 04:30 | |
| *** citypw_ has joined #symbiflow | 04:33 | |
| *** sth0R__ has joined #symbiflow | 04:33 | |
| *** citypw has quit IRC | 04:34 | |
| *** sth0R__ has quit IRC | 04:34 | |
| *** citypw has joined #symbiflow | 04:38 | |
| *** _whitelogger has quit IRC | 05:21 | |
| *** _whitelogger has joined #symbiflow | 05:23 | |
| *** _whitelogger has quit IRC | 06:39 | |
| *** _whitelogger has joined #symbiflow | 06:41 | |
| *** ramin_r348 has quit IRC | 06:57 | |
| *** Bertl_oO is now known as Bertl_zZ | 07:23 | |
| *** _whitelogger has quit IRC | 07:45 | |
| *** _whitelogger has joined #symbiflow | 07:47 | |
| *** tcal has quit IRC | 08:26 | |
| *** clay_1 has joined #symbiflow | 10:39 | |
| *** clay_1 has quit IRC | 10:54 | |
| *** kraiskil has joined #symbiflow | 11:19 | |
| *** zeen has joined #symbiflow | 11:52 | |
| *** CMP1 has joined #symbiflow | 11:58 | |
| CMP1 | Hello, I have moved into reading about PIPs and comparing it to what I can visually see in vivado. So far I have understood that to create a wire, you have to define the connection between two `pip junctions` from what is shown in vivado. | 12:02 |
| CMP1 | If my understanding regarding that is correct, I am getting confused by the `<tile_type>.<destination_wire>.<source_wire>.` format | 12:03 |
| CMP1 | shouldnt it be a destination/source pip junction instead ? since in each such line one wire/connection is defined | 12:04 |
| daveshah | In reality, pip junctions are just a wire that has pips on it | 12:09 |
| CMP1 | so what is actually a pip, from its name I understand its a point, so to define a wire you need two pips, is that right ? | 12:10 |
| daveshah | A pip is a programmable connection between wires | 12:11 |
| daveshah | Wires are not defined by pips, it is more the other way round | 12:11 |
| daveshah | wires can also be connected to site pins, or other wires (a set of permanently-connected is called a node) as well as pips | 12:11 |
| daveshah | * a set of permanently-connected wires | 12:14 |
| CMP1 | so, nodes are always active ? | 12:15 |
| daveshah | A node is a set of wires - wires are always contained within a single tile, nodes contain connected wires across tiles | 12:16 |
| daveshah | For example, the node INT_L_X32Y217/SL1BEG2 that covers two wires contains the wires INT_L_X32Y216/SL1END2 and INT_L_X32Y217/SL1BEG2 - these two wires are permanently connected (physically just a single bit of metal) | 12:17 |
| CMP1 | hmm | 12:21 |
| CMP1 | I am a bit confused | 12:21 |
| CMP1 | pips are only connections inside a swithchbox | 12:22 |
| CMP1 | while nodes are outside | 12:22 |
| CMP1 | and the outside is wires | 12:22 |
| CMP1 | is that correct ? | 12:22 |
| daveshah | The key difference is that pips can (with a few exceptions) be turned on or off, and generally have bitstream bits associated with them. Pips connect two wires. | 12:24 |
| daveshah | Wires are local to a tile | 12:24 |
| daveshah | Nodes represent the fact that multiple wires (possibly in different tiles) are permanently connected together | 12:25 |
| CMP1 | that permenently, is always there or will happen after the programming ? | 12:25 |
| daveshah | In practice all of the wires in the node are physically a single piece of metal | 12:26 |
| daveshah | the reason the node is split into different wires is purely a software thing | 12:27 |
| daveshah | there is no way for the different wires in a node to not be connected together | 12:27 |
| CMP1 | probably that is confusing me because in vivado as a node they mean a single wire | 12:28 |
| CMP1 | but lets get back to the basics to see if I have at least understood pips | 12:28 |
| daveshah | Yes, in practice a node is multiple wires | 12:29 |
| CMP1 | CLBLL_L_A6.CLBLL_IMUX5 this means a pip will get activated to connect the wire clbll_L_A6 with the wire IMUX5, right ? | 12:29 |
| daveshah | Yes, pips are almost always directional so this means that CLBLL_L_A6 is driven by CLBLL_IMUX5 | 12:30 |
| CMP1 | great | 12:30 |
| daveshah | If you want to see all the wires in a node, you can do it with Tcl, run `get_wires -of_objects [get_nodes $node]` | 12:30 |
| CMP1 | is there a way to highlight the results of that in the view | 12:35 |
| CMP1 | ? | 12:35 |
| daveshah | No, normally you could use show_objects but that doesn't work for wires | 12:36 |
| CMP1 | I see | 12:36 |
| *** citypw has quit IRC | 12:36 | |
| daveshah | Vivado somewhat hides the existence of wires | 12:36 |
| daveshah | the GUI is mostly based on nodes | 12:36 |
| daveshah | the only place where it shows wires separate from their nodes is "pip junctions" | 12:37 |
| CMP1 | you mean if you look at the junction name ? because graphicaly a junction is just a circle | 12:38 |
| daveshah | Yes, the junction name is actually a wire | 12:38 |
| daveshah | If you look at a node in Vivado, the section of each node in a specific tile is effectively a wire too | 12:38 |
| CMP1 | great so graphically every wire i see outside of switchboxes are wires | 12:40 |
| CMP1 | (but if I look at its name it will give me the node name that it contaits it) | 12:40 |
| CMP1 | and to see the actual wire name i will have to see at the name of its associated pip junction | 12:41 |
| CMP1 | also how do pips connect the wires together ? | 12:47 |
| *** citypw has joined #symbiflow | 12:51 | |
| daveshah | Pips boil down to one or two transistors controlled by some bitstream bits (and in some cases a decoder on some of those bits) | 12:55 |
| daveshah | often that is followed by a buffer | 12:55 |
| CMP1 | I see, so abstractly I can imagine them like a select switch controlled by the bitstream values ? | 12:57 |
| daveshah | Yeah | 12:58 |
| CMP1 | thank you for the clarifications ! | 12:59 |
| *** Bertl_zZ is now known as Bertl | 13:15 | |
| *** OmniMancer has quit IRC | 14:05 | |
| CMP1 | is both `hint` and `always` indicating a fake pip that is always active ? | 14:05 |
| *** citypw has quit IRC | 14:57 | |
| *** citypw has joined #symbiflow | 14:57 | |
| daveshah | always is a fake pip that is always active | 14:59 |
| daveshah | hint is for route throughs, etc, that are not conventional pips but are not always enabled either | 14:59 |
| daveshah | For example a hint pip from LUT input to output routes through the LUT by setting the LUT value accordingly | 15:00 |
| CMP1 | Doesnt a roit through depend on the LUT init values ? | 15:01 |
| CMP1 | oh I think I get it. The hint means that depending on the logic in the lut, this connection may happen ? | 15:02 |
| CMP1 | So all "CLBLL_L.CLBLL_L_D.CLBLL_L_D1 hintCLBLL_L.CLBLL_L_D.CLBLL_L_D2 hintCLBLL_L.CLBLL_L_D.CLBLL_L_D3 hintCLBLL_L.CLBLL_L_D.CLBLL_L_D4 hintCLBLL_L.CLBLL_L_D.CLBLL_L_D5 hintCLBLL_L.CLBLL_L_D.CLBLL_L_D6 hint" | 15:04 |
| CMP1 | show that any of the inputs of LUT D can by forwarded to output CLBLL_L_D | 15:04 |
| CMP1 | correct ? | 15:04 |
| FFY00 | daveshah, do you have any particular reason why you don't want meson? | 15:32 |
| daveshah | FFY00: the support burden of changing | 15:33 |
| FFY00 | but changing now | 15:33 |
| daveshah | CMP1: yes, that's correct, any of those inputs could be routed through each setting a different LUT value | 15:33 |
| FFY00 | not in the future, right? | 15:33 |
| daveshah | At any time | 15:34 |
| CMP1 | daveshah thanks | 15:34 |
| FFY00 | so, as you can probably see looking at the code, it is incredibly simple | 15:34 |
| FFY00 | I almost just have definitions | 15:35 |
| daveshah | Yes, but that doesn't mean it won't cause problems | 15:35 |
| FFY00 | which kinds of problems? | 15:35 |
| daveshah | Well, all the usual build system problems | 15:35 |
| FFY00 | I have been using in production for several projects and never had any major issues | 15:35 |
| FFY00 | only some really minor bugs | 15:36 |
| FFY00 | and that was in a project with 600+ line build script | 15:36 |
| FFY00 | not the case of trellis | 15:37 |
| daveshah | The reality is that anything in Trellis is something that I need to be able to support | 15:37 |
| FFY00 | but meson can be updated with pip | 15:37 |
| FFY00 | so, that would solve the issues there | 15:37 |
| FFY00 | daveshah, right, but I am offering to help | 15:37 |
| FFY00 | and to help you become conformable with it | 15:38 |
| daveshah | Yes, but I've had people offer to help with things like this before and disappear. No personal offence but I'm very wary of accepting stuff like this | 15:38 |
| FFY00 | I am offering to provide support until you don't need me anymore | 15:38 |
| daveshah | Particularly when I'll inevitably be on the receiving end of complaints when stuff breaks for people | 15:38 |
| FFY00 | well, right | 15:39 |
| FFY00 | you would need to believe in me :) | 15:39 |
| FFY00 | all I can say is that I am willing to commit | 15:39 |
| FFY00 | would you please at least consider doing a test run? | 15:40 |
| FFY00 | like I mentioned | 15:40 |
| FFY00 | keep both build systems for now, if any issues arise with meson, just remove it | 15:40 |
| daveshah | No, because once people half start using it then it's even more of a problem | 15:40 |
| FFY00 | so, you really really want to keep cmake? | 15:42 |
| daveshah | No, but at the current state of Trellis it's the best option | 15:42 |
| FFY00 | because a lot of things are broken | 15:42 |
| FFY00 | and my biggest issue is that it can break systems | 15:42 |
| daveshah | They don't seem to be affecting people on the whole | 15:42 |
| daveshah | No one has reported Trellis breaking their system to me before now | 15:43 |
| FFY00 | or maybe people are not reporting it to you | 15:43 |
| FFY00 | ah | 15:43 |
| FFY00 | the thing about breaking systems is that most people wont really is trellis fault | 15:43 |
| FFY00 | *wont realize | 15:44 |
| FFY00 | daveshah, is there anything I can day to convince you to trust me? that I will provide support? | 15:45 |
| daveshah | No, there isn't | 15:45 |
| FFY00 | I am packaging this for archlinux so I am already committed there | 15:45 |
| daveshah | But I am effectively _contractually_ commited to supporting Trellis for people | 15:47 |
| daveshah | I simply can't take something on that I don't know how much trouble it will cause | 15:48 |
| *** proteus-like has joined #symbiflow | 15:49 | |
| FFY00 | and what about you personally looking into meson and spending time time learning it | 15:52 |
| FFY00 | and experimenting | 15:52 |
| FFY00 | and once you are comfortable, bringing it to trellis? | 15:52 |
| *** proteus-dude has quit IRC | 15:52 | |
| daveshah | I just don't have the time right now | 15:53 |
| FFY00 | I would say that the time invested there is much less than the time you will spend fixing cmake | 15:53 |
| FFY00 | right, I am not saying it needs to be right now | 15:53 |
| daveshah | I doubt that in practice | 15:53 |
| FFY00 | I have had experience with both cmake and meson, as well with interacting with a lot of upstreams (because packaging) and I can tell you from my experience it is definitely true | 15:54 |
| FFY00 | but you could always have a different experience | 15:55 |
| FFY00 | is there anything in the project I could help with for you to be able to take time off to experiment with meson? | 15:56 |
| daveshah | To be honest I am not spending any significant time on Trellis itself atm | 15:58 |
| daveshah | All my time is on generic nextpnr stuff (mostly routing), nextpnr-xilinx and some currently non-OSS projects | 15:58 |
| FFY00 | okay | 15:58 |
| daveshah | I don't know anything I could point you at in particular | 15:58 |
| FFY00 | anything I can help with there? | 15:58 |
| FFY00 | okay | 15:59 |
| daveshah | You could take a peek at nextpnr issues but I don't know if that will significantly reduce my burden | 15:59 |
| daveshah | A lot of what I am working on is pretty much "single thread" atm | 16:00 |
| FFY00 | ack | 16:03 |
| FFY00 | just some final comment | 16:04 |
| daveshah | If you are really keen on meson, then your best bet at getting it merged will be to make sure that it actually works properly for Windows and OS X | 16:05 |
| daveshah | and a good couple of common linux distros | 16:05 |
| FFY00 | if you are contractually committed to support it, you could still keep cmake for that purpose | 16:05 |
| FFY00 | while we test meson | 16:05 |
| FFY00 | okay, right | 16:05 |
| daveshah | (Windows = mingw and cygwin ideally) | 16:06 |
| FFY00 | okay | 16:06 |
| daveshah | Yes, in the short term. But long term I'd want to avoid that | 16:06 |
| daveshah | I can't guarantee a merge immediately even with those tests but it would make me happier about it | 16:06 |
| FFY00 | yes, optimally you would in time get comfortable enough with meson to replace cmake entirely | 16:07 |
| FFY00 | also, nextpnr also suffers from the same issues in the build system, I assume your position is the same there, right? | 16:07 |
| FFY00 | daveshah, ack | 16:07 |
| daveshah | nextpnr is much more complicated so that's not changing | 16:07 |
| FFY00 | complicated in what way? | 16:08 |
| daveshah | Many more configurations, some non public forks that also rely on sub cmake files, some cmake based dependencies | 16:09 |
| daveshah | The testing burden would simply be too high | 16:10 |
| FFY00 | meson can generate cmake dependencies | 16:10 |
| FFY00 | but sure | 16:10 |
| FFY00 | just keep in mind, if you want this to actually be adopted, the build system will need to work properly | 16:13 |
| *** citypw has quit IRC | 16:30 | |
| *** _whitelogger has quit IRC | 16:48 | |
| *** _whitelogger has joined #symbiflow | 16:50 | |
| *** CMP1 has quit IRC | 16:58 | |
| *** adjtm has quit IRC | 17:31 | |
| *** adjtm has joined #symbiflow | 17:45 | |
| *** kraiskil has quit IRC | 18:03 | |
| mithro | FFY00: At the moment most of the SymbiFlow related tools are all cmake based -- having everything use the same system, even if it is less than idea is important | 18:33 |
| *** kraiskil has joined #symbiflow | 19:04 | |
| Degi | At summer of code, is "infrastructure" the right tag for a PCIe interface? | 19:06 |
| Degi | Okay I've submitted it (since it can be changed later) | 19:20 |
| FFY00 | mithro, meson can identify cmake dependencies | 19:26 |
| FFY00 | is there any other issue? | 19:27 |
| *** kraiskil has quit IRC | 19:58 | |
| *** OmniMancer has joined #symbiflow | 20:18 | |
| *** QDX45 has joined #symbiflow | 21:23 | |
| *** tcal has joined #symbiflow | 21:39 | |
| *** tcal has quit IRC | 22:01 | |
| *** tcal has joined #symbiflow | 22:03 | |
| *** Renga has joined #symbiflow | 22:08 | |
| *** OmniMancer has quit IRC | 22:20 | |
| *** OmniMancer has joined #symbiflow | 22:21 | |
| *** Renga has quit IRC | 22:23 | |
| *** lambda has quit IRC | 22:23 | |
| *** titanbiscuit has quit IRC | 22:46 | |
| *** titanbiscuit has joined #symbiflow | 22:47 | |
| *** lambda has joined #symbiflow | 22:56 | |
| *** wavedrom has joined #symbiflow | 23:16 | |
| *** wavedrom has joined #symbiflow | 23:17 | |
| mithro | Degi: I'll take a look at it shortly | 23:40 |
| *** tcal has quit IRC | 23:52 | |
| mithro | FFY00: For consistency reasons should be cmake *or* meson -- converting everything from cmake to meson is a big task | 23:54 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!