| *** tpb has joined #symbiflow | 00:00 | |
| *** galv[m] has quit IRC | 00:35 | |
| *** xobs has quit IRC | 00:35 | |
| *** mrhat2010[m] has quit IRC | 00:35 | |
| *** galv[m] has joined #symbiflow | 00:45 | |
| *** xobs has joined #symbiflow | 01:11 | |
| *** mrhat2010[m] has joined #symbiflow | 01:11 | |
| duck2 | i poked around with sax parsing | 01:22 |
|---|---|---|
| duck2 | it's not possible to do right away due to the edge->switch->node dependency | 01:26 |
| litghost | duck2: How so? | 01:34 |
| duck2 | but it's possible to first incrementally read into a "raw rr graph" struct, then use the struct to build graph. this is very much like flatbuffers so i'm hesitant to do it, but i think at the worst case i'll have made a tool to convert large rr graphs to flatbuffers? | 01:34 |
| litghost | duck2: Can you create an issue on https://github.com/SymbiFlow/vtr-verilog-to-routing and explain your finding with SAX? | 01:35 |
| tpb | Title: GitHub - SymbiFlow/vtr-verilog-to-routing: SymbiFlow WIP changes for Verilog to Routing -- Open Source CAD Flow for FPGA Research (at github.com) | 01:35 |
| litghost | duck2: Because I'm not following why the edge->switch->node issue would be a problem | 01:36 |
| litghost | duck2: I think it is safe to assume that edge's will appear after switches and nodes, and you could always do some kind of deferal on the off change that isn't true | 01:36 |
| duck2 | litghost: by "right away" i mean just stuffing data into device_ctx as it comes | 01:36 |
| litghost | duck2: I think we can just assert that edges must come after nodes and switches, does that solve what you are thinking about? | 01:37 |
| duck2 | i think it does. if nodes, switches and edges appear in this order, the reader won't have to cache much data | 01:38 |
| litghost | duck2: The XML writer for VPR always writes switches before nodes and nodes before edges | 01:39 |
| litghost | duck2: And you could always have a dual path in the parser, seen switch+node -> insert edge immediately, not either switch/node -> put edges in a vector and then insert the edges into the nodes. | 01:40 |
| litghost | duck2: Maybe file an issue with the upstream project and ask if it is safe to assume the order of tags | 01:40 |
| duck2 | what would be a "maximum" size of a rr_graph.xml? | 01:56 |
| litghost | duck2: billions of edges? | 01:57 |
| litghost | duck2: Like really really big | 01:57 |
| duck2 | i'm asking this to know if the "raw graph" struct can be a problem. whereas eliminating the struct would save up some more memory, having it would be very helpful because both the current reader and your flatbuffers reader assume a "reference structure" in memory | 02:01 |
| duck2 | i'm afraid if i rewrite the reader fns for reading in a single pass(for instance, process_seg_id() looks up segments for every node after everything is loaded), i might create a rather buggy version | 02:02 |
| duck2 | so this is another side | 02:02 |
| litghost | I think keeping two copies is undesirable. How much do you think you would need to keep aside? | 02:37 |
| duck2 | i plan to translate the whole file to something like the flatbuffers schema. i think it will occupy ~1/3 of the xml file size in memory. maybe a far estimate? | 02:53 |
| litghost | Okay | 02:53 |
| duck2 | (just realized xc7's rr_graph.xml gzips to 52mb) | 02:54 |
| *** citypw has joined #symbiflow | 03:17 | |
| litghost | FYI, the flatbuffer version of the xc7 graph was ~150 MB uncompressed | 03:35 |
| *** citypw has quit IRC | 04:05 | |
| *** citypw has joined #symbiflow | 04:18 | |
| *** Bertl is now known as bertl_zZ | 04:51 | |
| *** bertl_zZ is now known as Bertl_zZ | 04:51 | |
| *** OmniMancer has joined #symbiflow | 05:47 | |
| sf-slack1 | <mkurc> Update on tile grid split: I'm still struggling to make the PicoSoC work. I've just discovered that for the PicoSoC I'm getting duplicated statements in `fasm` file. This is very wrong. | 08:58 |
| *** citypw has quit IRC | 09:25 | |
| *** citypw has joined #symbiflow | 09:38 | |
| *** citypw has quit IRC | 09:45 | |
| sf-slack1 | <mkurc> I've also discovered that `fasm` files generated even without my modifications also contain some statement duplicates. Is it an intended behavior ? | 10:04 |
| sf-slack1 | <tmichalak> @mkurc: what happens at the next stage? what does fasm2frames say about this input? I would expect it to fail if such input was considered an error. | 10:12 |
| sf-slack1 | <mkurc> The fasm2frames passes correctly. It does not consider this an error. Therefore I'm curious whether the fasm file can have duplicated statements. | 10:18 |
| sf-slack1 | <tmichalak> Then I guess the duplicate entry is simply ignored. The question to ask here then is whether the entry that turned out to be a duplicate should be in fact a different feature, i.e. the prefix identifier might be incorrect | 10:29 |
| sf-slack1 | <tmichalak> The xc7frames2bit tool is pretty much ready (https://github.com/SymbiFlow/prjxray/pull/705) and I was wondering what would be the best next step | 11:40 |
| tpb | Title: Implement the xc7frames2bit tool by tmichalak · Pull Request #705 · SymbiFlow/prjxray · GitHub (at github.com) | 11:40 |
| sf-slack1 | <tmichalak> In https://github.com/SymbiFlow/symbiflow-arch-defs/issues/418 one of the tasks says: "Modify harness generation to output all bits outside of ROI and add them to "required_features" in the design.json" maybe I could take care of that? | 11:41 |
| tpb | Title: Remove use of design.bit (ROI bitstream harness) · Issue #418 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 11:41 |
| *** Bertl_zZ is now known as Bertl | 13:36 | |
| sf-slack1 | <acomodi> slicem and modes fix update: with this commit I have been able to add the test on the `Differing modes` issue. https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/29/commits/8dfae8f4a387e3792dab427784a0a12f8aa4bf94 | 14:16 |
| tpb | Title: Differing modes between lib_nets fix by acomodi · Pull Request #29 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com) | 14:16 |
| sf-slack1 | <acomodi> I have tested that, without the slicem fix the regression test fails, while, by using the fixed VPR version the issue is correctly solved | 14:17 |
| sf-slack1 | <acomodi> The only thing is that I have been able to isolate the `SLICEM` pb_type and it is more than 2000 lines long. I could try to further reduce it to have something more comprehensible, but I think this is a good starting point | 14:18 |
| litghost | mkurc: Duplicated FASM statements are expected and allowed. | 15:02 |
| sf-slack1 | <mkurc> @litghost Ok, thanks | 15:03 |
| litghost | tmichalak: Sure | 15:07 |
| litghost | acomodi: First thing I would try is to simplify the FF tree, for example try getting rid of the 5FF's | 15:08 |
| litghost | acomodi: Might also see if you can safely remove the F8MUX and if yes, the F7MUX's | 15:09 |
| sf-slack1 | <acomodi> litghost: All right | 15:12 |
| sf-slack1 | <mkurc> @litghost: I am still fighting with implementation of the PicoSoC using the split grid. It is not working on the hardware. Neither does the Murax. However, simpler designs do work fine (eg. UART taken from the PicoSoC which continuously sends content of an initialized BRAM). | 15:14 |
| litghost | mkurc: Interesting. Are you using the slower clock speed harness? | 15:15 |
| sf-slack1 | <mkurc> I am running out of ideas what can be wrong. I am pretty sure that I've ruled out incorrect connection definitions. | 15:15 |
| sf-slack1 | <mkurc> I tried slowing the PicoSoC down to 12.5 MHz. I can try slowing down even further. | 15:15 |
| sf-slack1 | <mkurc> I am using the same harness and the clock division is implemented on logic (toggling FFs) | 15:16 |
| litghost | mkurc: Interesting. I'm actively working on the FASM to Verilog converter. It still needs testing and BRAM support, but that will enable use to check the picosoc bitstream in simulation. I'm aiming to have BRAM support this week. In order for the FASM to Verilog converter to work, I do need to fix https://github.com/SymbiFlow/prjxray/pull/727 to work on K7 and Z7. | 15:17 |
| tpb | Title: Solve remaining bits in the ROI by litghost · Pull Request #727 · SymbiFlow/prjxray · GitHub (at github.com) | 15:17 |
| sf-slack1 | <mkurc> Having FASM to verilog would be great | 15:18 |
| sf-slack1 | <mkurc> @litghost: Actually, I have a question whether I am doing the connection definition correctly. | 15:26 |
| sf-slack1 | <mkurc> Here is what I did: I split the CLB (with sites SLICE_X0 and SLICE_X1) to CLB_SLICE_X0 (with one site SLICE_X0) and CLB_SLICE_X1 (with one site SLICE_X1). | 15:26 |
| sf-slack1 | <mkurc> For each new tile type I left only pips related to its site and removed the others. So the pips are split among new tile types. | 15:27 |
| sf-slack1 | <mkurc> But I left all tile wires so they can serve as a pass-trhough connection when reaching from eg. INT_L through CLB_SLICE_X0 to CLB_SLICE_X1. | 15:27 |
| sf-slack1 | <mkurc> And the problem is that the CLB_SLICE_X1 now contains the same wires as CLB_SLICE_X0. But wires related to SLICE_X0 in CLB_SLICE_X1 are not connected to any site within it. | 15:27 |
| sf-slack1 | <mkurc> Can it cause any problems ? | 15:27 |
| litghost | mkurc: Depends. Have you pushed your latest PR? | 15:28 |
| sf-slack1 | <mkurc> I need to check, but I think yes | 15:29 |
| sf-slack1 | <mkurc> Yep, its there: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/435 | 15:30 |
| tpb | Title: WIP - Xilinx Series 7 split CLB tiles into two tiles types (SLICEL / SLICEM) by mkurc-ant · Pull Request #435 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 15:30 |
| sf-slack1 | <mkurc> I think I will prepare some drawings which show the situation. | 15:31 |
| *** OmniMancer has quit IRC | 15:33 | |
| litghost | mkurc: How are you testing the new tileconn.json? | 15:34 |
| sf-slack1 | <mkurc> By feeding it through `prxray_` scripts. | 15:35 |
| sf-slack1 | <mkurc> And using it to do the P&R. | 15:35 |
| sf-slack1 | <mkurc> Also I've made a few crude utility scripts that allows me to render a section of the FPGA grid with connections to a SVG file. | 15:36 |
| litghost | mkurc: That's not testing. You should write a test that ensures that the nodes from your tileconn.json are the same nodes as before. | 15:40 |
| litghost | mkurc: tileconn.json as a file format is a tricky thing, small changes can have big effects. You need to ensure formally the the nodes from both tileconn.json are the same. | 15:41 |
| sf-slack1 | <mkurc> You mean in the final routing graph ? | 15:41 |
| litghost | mkurc: Sort of. You need to be sure that all sink instances connect to the same source instances. When tileconn.json is first formed, this is done be comparing that all nodes (groups of wires) remain the same. | 15:43 |
| litghost | mkurc: You can't do the check that simply, because you have split the wires. | 15:43 |
| litghost | mkurc: But you can verify that every sink is connected to the correct sources | 15:43 |
| sf-slack1 | <mkurc> Mhm | 15:44 |
| mithro | https://usercontent.irccloud-cdn.com/file/hKnWwcSO/image.png | 15:57 |
| sf-slack1 | <mkurc> Tile grid split illustration: https://pasteboard.co/I6a5iCL.png | 16:02 |
| tpb | Title: Pasteboard - Uploaded Image (at pasteboard.co) | 16:02 |
| litghost | mithro: ? | 16:05 |
| mithro | Diagram comparing Xilinx Slices to Intel ALMs I found in a paper I was reading earlier | 16:06 |
| litghost | Ah | 16:12 |
| mithro | elms: https://docs.google.com/document/d/1Pd_ygB0PvSq_gPEYIm8sJEF-mYY2nk3kLsazLVL21uw/edit | 16:48 |
| tpb | Title: VtR Python API Design Doc - Google Docs (at docs.google.com) | 16:48 |
| elms | mithro: this is the doc used when developing lib/rr_graph graph.py and channel.py? | 16:53 |
| mithro | elms: No, this is a doc to try and unify symbiflow and prga and provide an overall Python API for vtr xml generation | 16:54 |
| elms | prga? | 16:55 |
| mithro | https://prga.readthedocs.io/en/latest/ | 16:55 |
| tpb | Title: Welcome to the documentation of Princeton Reconfigurable Gate Array! Princeton Reconfigurable Gate Array 0.1 alpha documentation (at prga.readthedocs.io) | 16:55 |
| elms | For anyone with thoughts on including hardware testing in our CI please discuss here: https://github.com/SymbiFlow/ideas/issues/25 | 16:57 |
| tpb | Title: Testing on hardware · Issue #25 · SymbiFlow/ideas · GitHub (at github.com) | 16:57 |
| mithro | litghost: Should I be regenerating the database with your new ROI changes? | 17:01 |
| litghost | mithro: Not yet, need to get https://github.com/SymbiFlow/prjxray/pull/727 merges | 17:01 |
| tpb | Title: Solve remaining bits in the ROI by litghost · Pull Request #727 · SymbiFlow/prjxray · GitHub (at github.com) | 17:01 |
| mithro | litghost: Well, there is new ppips files already, right? | 17:01 |
| litghost | mithro: Those are of limited value without https://github.com/SymbiFlow/prjxray/pull/727 | 17:02 |
| tpb | Title: Solve remaining bits in the ROI by litghost · Pull Request #727 · SymbiFlow/prjxray · GitHub (at github.com) | 17:02 |
| mithro | litghost: Just incase you didn't see -> https://github.com/YosysHQ/yosys/commit/8c0740bcf7a1149ac11332f7e7fd9c8f78f0a0b5 | 20:11 |
| tpb | Title: Merge pull request #885 from YosysHQ/clifford/fix873 · YosysHQ/yosys@8c0740b · GitHub (at github.com) | 20:11 |
| mithro | litghost: Linked from https://github.com/YosysHQ/yosys/issues/873 | 20:11 |
| tpb | Title: Regression when initial-ising reg used on negedge clock · Issue #873 · YosysHQ/yosys · GitHub (at github.com) | 20:11 |
| litghost | Ya, I saw that | 20:11 |
| litghost | Opps | 20:11 |
| litghost | Makes sense when you see the fix | 20:12 |
| mithro | litghost: Guess there should probably be some type of testing for it? | 20:12 |
| litghost | mithro: On the yosys side or our side? | 20:12 |
| litghost | mithro: FYI, we don't support negative clocks yet, so we can't test for it yet | 20:13 |
| mithro | litghost: Probably on the yosys side? | 20:13 |
| litghost | mkurc: In doing the fasm 2 verilog I may have located a bug in the way we emit the routing graph. Can you check for the following condition: | 20:26 |
| litghost | FAN_ALT[0-7] and BYP_ALT[0-7] that is being routed to both FAN[0-7]/BYP[0-7] and FAN_BOUNCE[0-7]/BYP_BOUNCE[0-7] | 20:26 |
| litghost | mkurc: I think the FAN_ALT and BYP_ALT output pips may be mutially exclusive, but no bit indicates this behavior | 20:26 |
| litghost | mkurc: If my theory is true, then the routing graph could enable an invalid configuration | 20:26 |
| litghost | mkurc: Never mind, the routing implementation is correct, must be a bug in fasm 2 verilog | 21:10 |
| *** lopsided98_ has quit IRC | 22:24 | |
| litghost | mkurc: I've tested https://github.com/SymbiFlow/symbiflow-arch-defs/pull/473 on some designs out of both Vivado and VPR. It seems to be working, with differing routing. I haven't added the TCL statements to apply the existing routing | 23:41 |
| tpb | Title: WIP: Initial 7-series FASM to verilog conversion by litghost · Pull Request #473 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 23:41 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
