| *** tpb has joined #symbiflow | 00:00 | |
| *** adjtm has quit IRC | 00:02 | |
| *** adjtm has joined #symbiflow | 00:02 | |
| *** lopsided98 has quit IRC | 01:41 | |
| *** lopsided98 has joined #symbiflow | 01:42 | |
| *** citypw_ has joined #symbiflow | 02:29 | |
| *** bit0fun has joined #symbiflow | 03:11 | |
| *** proteus-guy has quit IRC | 03:40 | |
| *** _whitelogger has quit IRC | 05:21 | |
| *** _whitelogger has joined #symbiflow | 05:23 | |
| *** titanbiscuit has quit IRC | 05:34 | |
| *** titanbiscuit has joined #symbiflow | 05:37 | |
| *** proteus-guy has joined #symbiflow | 06:11 | |
| *** Bertl_oO is now known as Bertl_zZ | 07:30 | |
| *** allenlorenz has quit IRC | 08:20 | |
| sf-slack | <acomodi> hackerfoo: nice, did it improve in runtime or QoR? | 08:28 |
|---|---|---|
| hackerfoo | Both. I'm still tuning it: https://docs.google.com/document/d/1kxi4xXHTZyVaQO8HNpIHmEw6Pz9jvfzzMNvMRGD6BtE/edit?usp=sharing | 08:30 |
| tpb | Title: Speeding up Placement - Google Docs (at docs.google.com) | 08:30 |
| *** OmniMancer has joined #symbiflow | 08:50 | |
| *** proteus-guy has quit IRC | 10:29 | |
| -_whitenotifier-3- [symbiflow-arch-defs] acomodi opened issue #1359: Issue with clock net names in SDC - https://git.io/JvaLY | 10:48 | |
| *** Vonter has quit IRC | 10:54 | |
| *** clay_1 has joined #symbiflow | 10:54 | |
| clay_1 | Hello ! | 10:54 |
| *** luaraneda has quit IRC | 10:56 | |
| *** promach3 has quit IRC | 10:56 | |
| *** nrossi has quit IRC | 10:56 | |
| *** hzeller[m] has quit IRC | 10:56 | |
| *** xobs has quit IRC | 10:57 | |
| *** bunnie[m] has quit IRC | 10:57 | |
| *** abeljj[m] has quit IRC | 10:57 | |
| *** lromor[m] has quit IRC | 10:57 | |
| *** Vonter has joined #symbiflow | 11:05 | |
| *** Vonter_ has joined #symbiflow | 11:11 | |
| *** Vonter has quit IRC | 11:11 | |
| *** xobs has joined #symbiflow | 11:21 | |
| *** allenlorenz has joined #symbiflow | 11:21 | |
| ZirconiumX | Hello | 11:42 |
| *** luaraneda has joined #symbiflow | 11:53 | |
| *** abeljj[m] has joined #symbiflow | 11:53 | |
| *** promach3 has joined #symbiflow | 11:53 | |
| *** bunnie[m] has joined #symbiflow | 11:53 | |
| *** nrossi has joined #symbiflow | 11:53 | |
| *** lromor[m] has joined #symbiflow | 11:53 | |
| *** hzeller[m] has joined #symbiflow | 11:53 | |
| *** Jihad has joined #symbiflow | 12:12 | |
| ZirconiumX | clay_1: ^ | 12:23 |
| clay_1 | how is it going ? ZirconiumX | 12:38 |
| ZirconiumX | Not too bad, thank you, clay_1 | 12:40 |
| clay_1 | I hope the not too bad will turn into good soon ^^ | 12:41 |
| *** killruana has quit IRC | 12:43 | |
| ZirconiumX | Well, personal things suggest that's unlikely to be the case, but that's besides the point | 12:43 |
| clay_1 | Oh, there always hope though | 12:44 |
| ZirconiumX | I've got a couple of things in mind to work on Yosys, but I think you mentioned you wanted to work on nextpnr? | 12:44 |
| clay_1 | No, I am interested in project Xray | 12:45 |
| clay_1 | I needed help in understanding what they have documented about the bitstream because I dont really get it | 12:46 |
| clay_1 | looking at previous conversation here, hackerfoo I saw that he stated the following " think it's very confusing from the outside. The output of Project X-Ray and symbiflow-arch-defs is mostly data that can be used by other tools, such as VPR and Yosys. So users will never really see them in the end" | 12:47 |
| clay_1 | so maybe thats why I dont get it ? | 12:47 |
| ZirconiumX | Maybe if you explain what you're looking for someone can help | 12:47 |
| clay_1 | Thats a good idea ZirconiumX:) | 12:54 |
| clay_1 | In a paper with the title Extract LUT Logics from a Downloaded Bitstream Data in FPGA | 12:55 |
| clay_1 | the authors expalin how the lut values are documented on a vivado created bitstream | 12:55 |
| clay_1 | I have not found any similar form of information in project xray | 12:56 |
| clay_1 | what I am currently interested in is how interconnect is represented on a bitstream | 12:56 |
| ZirconiumX | So, the term for an interconnect here is a PIP, for a "Programmable Interconnect Point" | 13:15 |
| ZirconiumX | https://github.com/SymbiFlow/prjxray/tree/master/fuzzers | 13:15 |
| tpb | Title: prjxray/fuzzers at master · SymbiFlow/prjxray · GitHub (at github.com) | 13:15 |
| ZirconiumX | If you look at the fuzzers you can see a bunch of them that begin with "pip-" | 13:15 |
| ZirconiumX | These are in charge of fuzzing interconnects | 13:15 |
| clay_1 | but it does it have them documented ? For example, if I set some given bits to a specific value it will connect a specific lut output to a specific registrer | 13:18 |
| clay_1 | ? | 13:18 |
| ZirconiumX | That's..a different problem entirely | 13:21 |
| OmniMancer | Lut output to register within one CLB is usually a mux and not considered interconnect | 13:21 |
| clay_1 | OmniMancer do s pip would be lut to lut connection? If yes does it matter if the two luts are in the same clb or not ? | 13:23 |
| ZirconiumX | Pips would be LUT to LUT | 13:23 |
| ZirconiumX | Or rather, CLB to CLB | 13:24 |
| OmniMancer | I do not know much about the xilinx specifics in architecture, but there are usually inputs and outputs of the CLB, and then pips that let you connect the outputs to some set of things, including inter tile interconnect wires, and then pips that let you connect various wires as sources to the inputs | 13:24 |
| clay_1 | i see so every connection inside a clb is not considered a pip | 13:28 |
| ZirconiumX | PIPs are external interconnects | 13:29 |
| ZirconiumX | Internal interconnect generally behaves very differently and thus is treated as such | 13:30 |
| clay_1 | how we call the internal ones then ? | 13:30 |
| ZirconiumX | Muxes, generally | 13:33 |
| OmniMancer | The intra CLB config usually has very limited settings | 13:33 |
| OmniMancer | Wherase the inter CLB switchboxes are usually quite wide in what connections they allow | 13:34 |
| clay_1 | i see, thank you ! | 13:34 |
| *** clay_1 has quit IRC | 13:39 | |
| *** clay_1 has joined #symbiflow | 13:40 | |
| *** Bertl_zZ is now known as Bertl | 14:06 | |
| *** OmniMancer has quit IRC | 14:28 | |
| clay_1 | https://symbiflow.readthedocs.io/projects/prjxray/en/latest/architecture/glossary.html#term-bitstream | 14:47 |
| tpb | Title: Glossary Project X-Ray 0.0-3049-g418063af documentation (at symbiflow.readthedocs.io) | 14:47 |
| clay_1 | in the frame entry here, it states "The 50th payload word is an EEC" | 14:48 |
| clay_1 | what is EEC ? is it a typo for ECC ? | 14:48 |
| ZirconiumX | Possibly. | 14:55 |
| clay_1 | (y) | 15:04 |
| *** Jihad has quit IRC | 15:07 | |
| ZirconiumX | clay_1: going back to earlier, a PIP is generally like a programmable on/off switch between two wires. This means that a single wire can connect to a lot of other wires, forming a one to many relationship along the wires | 15:13 |
| ZirconiumX | However inside a CLB you have muxes instead, and these are always connected, but only connect to a single target. | 15:14 |
| ZirconiumX | Thus we consider them to be separate to PIPs | 15:14 |
| clay_1 | so the muxes are always there | 15:14 |
| ZirconiumX | Yes, they're part of the CLB itself | 15:14 |
| clay_1 | hmm I see | 15:15 |
| clay_1 | probably thats why I have such a routing in this example ? | 15:16 |
| clay_1 | Uploaded file: https://uploads.kiwiirc.com/files/5dca37716b4935fd4130d8315f52d605/routing.png | 15:17 |
| clay_1 | I mean If i havent forced anything, the lut content would be stored on the lowest register but since I asked for a different one it had to make that feedback looking thing | 15:20 |
| *** VitiminV has joined #symbiflow | 15:59 | |
| litghost | clay_1: There are 2/3 types of "features" that are documented. The first is pips, which are used to connect the routing fabric together. PIPs generally generate features that look like <tile>.<dest>.<src>. The other type of feature is site configuration features. Site feature are generated <tile>.<site index>.<feature> | 16:16 |
| litghost | In your example, you'd see some LUT features for the LUT INIT parameter, a feature for the B FF in MUX, and that's about it | 16:16 |
| litghost | FYI, for an Vivado design that prjxray fully understands, you can run bit2fasm to convert the bitstream from the binary format into individual FASM features | 16:17 |
| clay_1 | in case i had more luts and ffs would i know what is connected to what ? | 16:18 |
| litghost | prjxray can be thought of the exercise on how to convert bitstreams from binary to some text format and back, along with timing information and graph | 16:18 |
| clay_1 | thanks, i will the bit2fasm | 16:18 |
| litghost | So once sites are configured (e.g. SLICE_L), PIPs are used to configure the generate interconnect to connect sites to each other | 16:18 |
| clay_1 | so in my screenshot, a pip is used to create that conection between the clb output and input ? | 16:20 |
| litghost | Yes, some out and you'll see them | 16:24 |
| litghost | zoom out/8 | 16:24 |
| *** VitiminV has quit IRC | 16:25 | |
| clay_1 | yes I have seen them | 16:26 |
| clay_1 | but if I havent done tha, it would connect to the botom register, in that case no PIP would be used, right ? because it would be handled by the site configuration features ? | 16:27 |
| litghost | clay_1: Sorry, can you rephrase. I don't understand your question. | 16:33 |
| clay_1 | sure. in the picture I attached, the use of this register for storing has been forced. If I havent done that, the tool would pick the bottom one. If it picked that it would get the d value straight from the lut without making that loop | 16:35 |
| clay_1 | so I assume that no pip will be used for that | 16:36 |
| clay_1 | but the information for that connectio will be included in what you called "site configuration features" | 16:36 |
| *** shivam_potdar has joined #symbiflow | 16:45 | |
| *** shivam_potdar has quit IRC | 16:49 | |
| litghost | clay_1: You are correct that if the FF was in the A FF position, the interconnect based loopback would not be required | 16:51 |
| litghost | clay_1: In both the A FF and B FF position, there would be site configuration features to configure the FF in MUX to select the O6 -> FF path | 16:52 |
| clay_1 | but would that also mean that no pip would be set ? | 16:52 |
| litghost | clay_1: In the B FF position there are additional features to configure the interconnect to loop from the SLICE_M A output back to the SLICE_M BX input | 16:54 |
| litghost | clay_1: In the A FF position, no additional PIP's would be required | 16:55 |
| clay_1 | and this is needed because the internal interconnect is so to say fixed, right ? | 16:56 |
| clay_1 | because it is expected to store Alut to Aff | 16:56 |
| *** citypw_ has quit IRC | 17:40 | |
| *** clay_1 has quit IRC | 17:44 | |
| *** Vonter_ has quit IRC | 17:59 | |
| *** Vonter has joined #symbiflow | 18:29 | |
| *** kgugala has quit IRC | 18:52 | |
| *** proteusguy has quit IRC | 19:03 | |
| *** kgugala has joined #symbiflow | 19:11 | |
| -_whitenotifier-3- [prjtrellis] gojimmypi opened issue #122: PyTrellis.cpp crashes c++: internal compiler error: Killed (program cc1plus) - Out of memory - https://git.io/Jva81 | 20:36 | |
| *** blackhat has joined #symbiflow | 20:45 | |
| *** blackhat has left #symbiflow | 20:50 | |
| *** Vonter has quit IRC | 21:55 | |
| *** Vonter has joined #symbiflow | 22:01 | |
| *** Vonter_ has joined #symbiflow | 23:12 | |
| *** Vonter has quit IRC | 23:13 | |
| *** Vonter_ has joined #symbiflow | 23:19 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
