01:15 <duck2> i poked around with sax parsing

01:19 <duck2> it's not possible to do right away due to the edge->switch->node dependency

01:26 <litghost> duck2: How so?

01:26 <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:28 <litghost> duck2: Can you create an issue on https://github.com/SymbiFlow/vtr-verilog-to-routing and explain your finding with SAX?

01:28 <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:28 <litghost> duck2: Because I'm not following why the edge->switch->node issue would be a problem

01:29 <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:29 <duck2> litghost: by "right away" i mean just stuffing data into device_ctx as it comes

01:29 <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:31 <duck2> i think it does. if nodes, switches and edges appear in this order, the reader won't have to cache much data

01:31 <litghost> duck2: The XML writer for VPR always writes switches before nodes and nodes before edges

01:32 <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:33 <litghost> duck2: Maybe file an issue with the upstream project and ask if it is safe to assume the order of tags

01:48 <duck2> what would be a "maximum" size of a rr_graph.xml?

01:50 <litghost> duck2: billions of edges?

01:50 <litghost> duck2: Like really really big

01:53 <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

01:54 <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

01:54 <duck2> so this is another side

02:29 <litghost> I think keeping two copies is undesirable. How much do you think you would need to keep aside?

02:45 <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:46 <litghost> Okay

02:46 <duck2> (just realized xc7's rr_graph.xml gzips to 52mb)

03:28 <litghost> FYI, the flatbuffer version of the xc7 graph was ~150 MB uncompressed

08:51 <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.

09:56 <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:05 <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:10 <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:21 <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

11:32 <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:32 <tpb> Title: Implement the xc7frames2bit tool by tmichalak · Pull Request #705 · SymbiFlow/prjxray · GitHub (at github.com)

11:33 <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:33 <tpb> Title: Remove use of design.bit (ROI bitstream harness) · Issue #418 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

14:08 <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:08 <tpb> Title: Differing modes between lib_nets fix by acomodi · Pull Request #29 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)

14:09 <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:11 <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:54 <litghost> mkurc: Duplicated FASM statements are expected and allowed.

14:56 <sf-slack1> <mkurc> @litghost Ok, thanks

14:59 <litghost> tmichalak: Sure

15:01 <litghost> acomodi: First thing I would try is to simplify the FF tree, for example try getting rid of the 5FF's

15:01 <litghost> acomodi: Might also see if you can safely remove the F8MUX and if yes, the F7MUX's

15:05 <sf-slack1> <acomodi> litghost: All right

15:06 <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:07 <litghost> mkurc: Interesting. Are you using the slower clock speed harness?

15:07 <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:08 <sf-slack1> <mkurc> I tried slowing the PicoSoC down to 12.5 MHz. I can try slowing down even further.

15:08 <sf-slack1> <mkurc> I am using the same harness and the clock division is implemented on logic (toggling FFs)

15:09 <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:09 <tpb> Title: Solve remaining bits in the ROI by litghost · Pull Request #727 · SymbiFlow/prjxray · GitHub (at github.com)

15:11 <sf-slack1> <mkurc> Having FASM to verilog would be great

15:19 <sf-slack1> <mkurc> @litghost: Actually, I have a question whether I am doing the connection definition correctly.

15:19 <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:19 <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:19 <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:19 <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:19 <sf-slack1> <mkurc> Can it cause any problems ?

15:21 <litghost> mkurc: Depends. Have you pushed your latest PR?

15:21 <sf-slack1> <mkurc> I need to check, but I think yes

15:22 <sf-slack1> <mkurc> Yep, its there: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/435

15:22 <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:23 <sf-slack1> <mkurc> I think I will prepare some drawings which show the situation.

15:26 <litghost> mkurc: How are you testing the new tileconn.json?

15:27 <sf-slack1> <mkurc> By feeding it through `prxray_` scripts.

15:27 <sf-slack1> <mkurc> And using it to do the P&R.

15:28 <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:33 <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:33 <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:33 <sf-slack1> <mkurc> You mean in the final routing graph ?

15:35 <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:36 <litghost> mkurc: You can't do the check that simply, because you have split the wires.

15:36 <litghost> mkurc: But you can verify that every sink is connected to the correct sources

15:36 <sf-slack1> <mkurc> Mhm

15:49 <mithro> https://usercontent.irccloud-cdn.com/file/hKnWwcSO/image.png

15:54 <sf-slack1> <mkurc> Tile grid split illustration: https://pasteboard.co/I6a5iCL.png

15:54 <tpb> Title: Pasteboard - Uploaded Image (at pasteboard.co)

15:58 <litghost> mithro: ?

15:58 <mithro> Diagram comparing Xilinx Slices to Intel ALMs I found in a paper I was reading earlier

16:04 <litghost> Ah

16:40 <mithro> elms: https://docs.google.com/document/d/1Pd_ygB0PvSq_gPEYIm8sJEF-mYY2nk3kLsazLVL21uw/edit

16:40 <tpb> Title: VtR Python API Design Doc - Google Docs (at docs.google.com)

16:45 <elms> mithro: this is the doc used when developing lib/rr_graph graph.py and channel.py?

16:46 <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:47 <elms> prga?

16:48 <mithro> https://prga.readthedocs.io/en/latest/

16:48 <tpb> Title: Welcome to the documentation of Princeton Reconfigurable Gate Array! Princeton Reconfigurable Gate Array 0.1 alpha documentation (at prga.readthedocs.io)

16:49 <elms> For anyone with thoughts on including hardware testing in our CI please discuss here: https://github.com/SymbiFlow/ideas/issues/25

16:49 <tpb> Title: Testing on hardware · Issue #25 · SymbiFlow/ideas · GitHub (at github.com)

16:53 <mithro> litghost: Should I be regenerating the database with your new ROI changes?

16:53 <litghost> mithro: Not yet, need to get https://github.com/SymbiFlow/prjxray/pull/727 merges

16:53 <tpb> Title: Solve remaining bits in the ROI by litghost · Pull Request #727 · SymbiFlow/prjxray · GitHub (at github.com)

16:54 <mithro> litghost: Well, there is new ppips files already, right?

16:54 <litghost> mithro: Those are of limited value without https://github.com/SymbiFlow/prjxray/pull/727

16:54 <tpb> Title: Solve remaining bits in the ROI by litghost · Pull Request #727 · SymbiFlow/prjxray · GitHub (at github.com)

20:03 <mithro> litghost: Just incase you didn't see -> https://github.com/YosysHQ/yosys/commit/8c0740bcf7a1149ac11332f7e7fd9c8f78f0a0b5

20:03 <tpb> Title: Merge pull request #885 from YosysHQ/clifford/fix873 · YosysHQ/yosys@8c0740b · GitHub (at github.com)

20:04 <mithro> litghost: Linked from https://github.com/YosysHQ/yosys/issues/873

20:04 <tpb> Title: Regression when initial-ising reg used on negedge clock · Issue #873 · YosysHQ/yosys · GitHub (at github.com)

20:04 <litghost> Ya, I saw that

20:04 <litghost> Opps

20:04 <litghost> Makes sense when you see the fix

20:04 <mithro> litghost: Guess there should probably be some type of testing for it?

20:05 <litghost> mithro: On the yosys side or our side?

20:05 <litghost> mithro: FYI, we don't support negative clocks yet, so we can't test for it yet

20:06 <mithro> litghost: Probably on the yosys side?

20:18 <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:18 <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:18 <litghost> mkurc: I think the FAN_ALT and BYP_ALT output pips may be mutially exclusive, but no bit indicates this behavior

20:19 <litghost> mkurc: If my theory is true, then the routing graph could enable an invalid configuration

21:03 <litghost> mkurc: Never mind, the routing implementation is correct, must be a bug in fasm 2 verilog

23:34 <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:34 <tpb> Title: WIP: Initial 7-series FASM to verilog conversion by litghost · Pull Request #473 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)