Friday, 2019-03-22

*** tpb has joined #symbiflow00:00
*** kraiskil has quit IRC00:23
*** kraiskil has joined #symbiflow00:41
*** somlo has quit IRC01:25
*** somlo has joined #symbiflow01:28
*** kraiskil has quit IRC01:41
*** Bertl_oO is now known as Bertl_zZ02:26
*** OmniMancer has joined #symbiflow03:37
*** citypw has joined #symbiflow03:38
*** sorear has quit IRC04:39
*** litghost has quit IRC04:40
*** ovf has quit IRC04:40
*** litghost has joined #symbiflow04:40
*** sorear has joined #symbiflow04:42
*** ovf has joined #symbiflow04:44
*** _whitelogger has quit IRC05:22
*** _whitelogger has joined #symbiflow05:25
*** tmichalak has quit IRC05:41
*** tmichalak has joined #symbiflow06:55
*** Sarthak has joined #symbiflow07:40
*** Sarthak has quit IRC07:41
*** Sarthak has joined #symbiflow07:58
*** kraiskil has joined #symbiflow08:32
*** Sarthak has quit IRC08:35
sf-slack1<acomodi> upstream VTR merge update: murax is working on HW after merge (without round robin option)09:12
*** citypw has quit IRC09:13
sf-slack1<mkurc> @acomodi I've stumbled on a similar issue as you did with routing the PicoSoC. The routing was taking a huge number of iterations and the number of overused connections were varying between 1 and 5. Don't remember which commit it was though...09:18
sf-slack1<acomodi> @mkurc: I think it could be after the first merge done by @litghost. I will investigate, even though, given that Round Robin is the issue, it will not be pushed upstream as it was a workaround before the tile split.09:23
sf-slack1<tmichalak> Hi everyone, a small update on the effort to remove the use of design.bit (  With the database that has the HCLK_CMT and CLK_HROW bits and the design.json generated with the small change that adds the bits outside of ROI to the required_features, I was able to generate a working counter bitstream from the frames with xc7frames2bit. So no harness bitstream09:27
sf-slack1is needed anymore.09:27
tpbTitle: Remove use of design.bit (ROI bitstream harness) · Issue #418 · SymbiFlow/symbiflow-arch-defs · GitHub (at
sf-slack1<acomodi> That's great!09:29
*** Bertl_zZ is now known as Bertl09:38
*** kraiskil has quit IRC10:25
*** kraiskil has joined #symbiflow10:46
*** kraiskil has quit IRC11:10
*** kc8apf_ has joined #symbiflow12:14
*** ants` has joined #symbiflow12:20
*** kc8apf has quit IRC12:22
*** galv[m] has quit IRC12:22
*** nats` has quit IRC12:22
*** kc8apf_ is now known as kc8apf12:22
*** galv[m] has joined #symbiflow12:29
sf-slack1<tmichalak> In parallel to adding the BRAM36 support to VTR I am looking at the stabilization of the CI fuzzer runs. Since it was mostly Vivado that failed I modifed the script to be more verbose when a fuzzer fails and print out last 50 lines of the vivado.log. The build seems to be more stable, but not stable enough.13:25
sf-slack1<tmichalak> The sad thing is that reappeared13:25
tpbTitle: INT FAN_ALT[0-9].GFAN0 solutions are still unstable · Issue #567 · SymbiFlow/prjxray · GitHub (at
sf-slack1<tmichalak> @acomodi: you worked on a fix for this right? Can we improve your fix somehow?13:27
sf-slack1<tmichalak> @mithro: btw, since I already mentioned the fuzzer stabilization, if I wanted to work on I would need some of my questions that I asked in the ticket answered13:30
tpbTitle: Test output on CI cleanup needed · Issue #713 · SymbiFlow/prjxray · GitHub (at
sf-slack1<acomodi> @tmichalak: well, there is one option that could increase the success probabilities and it would be to increase the number of specimens, but as always it does not assure a 100% success.13:33
sf-slack1<tmichalak> @acomodi: well, increase the number of specimen is not really the solution I would like to go with13:36
sf-slack1<acomodi> @tmichalak: another thing that could be done is to have a fuzzer to get GFAN only related bits, and than FAN_ALT, that will depend on the GFAN fuzzer will not add the bits related to GFAN13:38
sf-slack1<tmichalak> I will rerun the CI with the small stabilization changes I made a couple of times and see what is the success rate13:39
sf-slack1<acomodi> I think that right now GFAN related bits are computed in the `056-rem` fuzzer, if I'm not wrong13:40
sf-slack1<tmichalak> @acomodi: this sounds much better, I guess we might have to do this eventually13:42
sf-slack1<tmichalak> @acomodi: you are right about the `056-rem` fuzzer and GFAN bits13:43
sf-slack1<acomodi> Maybe it is worth extracting the GFAN in another fuzzer and add it to the dependencies of the FAN_ALT one13:47
*** lethalbit has quit IRC13:58
*** lethalbit has joined #symbiflow13:58
litghosttmichalak: I think a dedicated GFAN fuzzer is a good idea.  Increases sample count has not stabilized it.  One advantage of using a dedicated fuzzer is you can limit the solution size to 2 bits (e.g. "-c 2"), which I believe all the GFAN bits fall within.  This is not generally true for all INT pips, but might15:13
litghostbe true for the GFAN bits.15:14
*** Bertl is now known as Bertl_oO15:18
sf-slack1<mkurc> Good time of day. I've created a test design that can be scaled in size for testing of VPR operation.
tpbTitle: Scalable test design by mkurc-ant · Pull Request #490 · SymbiFlow/symbiflow-arch-defs · GitHub (at
sf-slack1<mkurc> I wrote initial conclusions of testing in the PR's comment.15:21
sf-slack1<acomodi> Hi everyone. Here there is a PR that changes the cmake build system to allow the creation of different devices/boards/parts for the same architecture:
tpbTitle: WIP: Add arty support by acomodi · Pull Request #462 · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** ants` is now known as nats`15:30
sf-slack1<acomodi> Here I have started a doc used to think about the major VPR patches that have to be isolated and upstreamed:
tpbTitle: Google Docs - create and edit documents online, for free. (at
*** futarisIRCcloud has quit IRC15:37
litghostmkurc: Thanks, it's good to have something we can test with.  It makes a good regression test too.  I've found another case that breaks too.  I suspect this may be caused by the MUX vs SHORT issue on the channel merges.  I'll test if that helps in my case15:40
sf-slack1<mkurc> I used the design also to test on the split grid based on SLICEs and observed that it fails for less complex designs than for the CLB based grid.15:42
*** kraiskil has joined #symbiflow15:58
sf-slack1<acomodi> litghost, mithro: I have merged Arty doesn't currently compile as a new harness is needed and placed in this directory `third_party/prjxray-db/artix7/harness/arty-a7/uart/`16:07
tpbTitle: Sign in to GitHub · GitHub (at
litghostacomodi: I assume prjxray can generate the arty harness right now?16:08
sf-slack1<acomodi> yes indeed16:08
litghostacomodi: Because you've tested the ROI, can you make a PR on with the harness?16:09
tpbTitle: GitHub - SymbiFlow/prjxray-db: Project X-Ray Database: XC7 Series (at
sf-slack1<acomodi> litghost: all right16:10
sf-slack1<acomodi> litghost, mithro: done, PR opened to add working arty harness (UART and one LED are correctly working)16:30
litghostacomodi: Where are we with the testing with ?  I believe you said the router was getting stuck?  Still true?16:32
tpbTitle: VTR: upstream merge by acomodi · Pull Request #30 · SymbiFlow/vtr-verilog-to-routing · GitHub (at
sf-slack1<acomodi> litghost: yes, it stucks only with round robin option enabled16:33
sf-slack1<acomodi> I am still investigating why this happens, but I couldn't find the source of the issue yet16:33
*** dhiraj24 has joined #symbiflow16:53
dhiraj24I am interested in project for gsoc. I am Third year undergraduate student doing Bachelor of engineering in Electronics and Telecommunication in India and have good grasp over python.I have been contributing to opensource a lot.Please see my github profile and also in summers 2018 i had participated in an opensource contest where i built this project https16:57
tpbTitle: Add a Verilog / SystemVerilog support to Sphinx · Issue #11 · SymbiFlow/ideas · GitHub (at
dhiraj24The link for sphinix document is not opening and please provide me a little advise over the above project.I had seen the approach given in the issue but basically i am confused as which of your repos will be used by  doxygen-verilog .16:59
litghostsymbiflow-arch-defs I believe is teh one we are targetting.  mithro should pop in later and can answer more questions17:00
tpbTitle: GitHub - SymbiFlow/symbiflow-arch-defs: FOSS architecture definitions of FPGA hardware useful for doing PnR device generation. (at
dhiraj24Alright so doxygen-verilog  will use symbiflow-arch-defs to generate Doxygen output from the Verilog and i have to use either breathe or exhale to read it and output it to sphinx.17:04
dhiraj24Am i right ?17:04
litghostThat sounds correct.  What we are intending for the architecture documentation process is to write some verilog, generate a schematic diagram in SVG from it, and then build sphnix documentation including both17:05
litghostmithro: Want to add to that explaination?17:05
dhiraj24write some verilog ? can i get an example ? is verilog code not present in
tpbTitle: GitHub - SymbiFlow/symbiflow-arch-defs: FOSS architecture definitions of FPGA hardware useful for doing PnR device generation. (at
*** kraiskil has quit IRC17:13
dhiraj24Asking again sorry for it. [22:30] <dhiraj24> write some verilog ? can i get an example ? is verilog code not present in
tpbTitle: GitHub - SymbiFlow/symbiflow-arch-defs: FOSS architecture definitions of FPGA hardware useful for doing PnR device generation. (at
litghostPlease wait for @mithro to answer your question17:16
dhiraj24alright, i will wait meanwhile should i add comments on the issue tracker for this project on github17:19
litghostFeel free17:19
dhiraj24okay thanks, i will wait.17:19
*** kraiskil has joined #symbiflow17:29
dhiraj24i guess he is not online17:41
litghostmkurc: I've filed to track what is going with the designs failing on hardware17:48
tpbTitle: [XC7] Some designs fail on hardware · Issue #491 · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** kraiskil has quit IRC17:56
*** OmniMancer has quit IRC18:02
dhiraj24@litghost can i tell me do i need to solve some issues in order to get selected for GSOC or should i directly work on proposal18:18
mithrodhiraj24: Hi! I think for GSoC adding Verilog support to Sphinx would be a better project18:31
dhiraj24hello sir, alright but need some clarification18:32
dhiraj24i had commented on
tpbTitle: Add a Verilog / SystemVerilog support to Sphinx · Issue #11 · SymbiFlow/ideas · GitHub (at
*** acomodi has quit IRC18:37
mithrodhiraj24: I've yet to get through my email this morning, so probably haven't seen your question18:46
dhiraj24alright sir, in India there is 12:30 am and tomorrow is my college. can i know as when you will guide me for that ?18:49
mithrodhiraj24: I have replied to your comment18:55
dhiraj24Okay sir, i had commented again there please check.19:06
dhiraj24Also sir, should i directly start with my proposal and show the implementation of it ? or before that any contribution is necessary ? Meanwhile please check the updated comment on
tpbTitle: Add a Verilog / SystemVerilog support to Sphinx · Issue #11 · SymbiFlow/ideas · GitHub (at
litghostacomodi/mkurc: Looks like round robin packing might be causing other issues19:45
tpbTitle: [XC7] Some designs fail on hardware · Issue #491 · SymbiFlow/symbiflow-arch-defs · GitHub (at
sf-slack1<acomodi> litghost: well, given that round robin is not going to be needed anymore with the clb tile being splitted we could disable it for good, right?19:55
litghostacomodi: Sure.  Hopefully if mkurc tests with round robin disabled the tile split starts working as expect, then that is the path forward + equivilent tils19:56
sf-slack1<acomodi> litghost: my question though is: why would the SLICEM be set to DRAMs mode instead of LUTs?19:57
litghostacomodi: Because the round robin packer is doing what it is supposed to, alturnate modes on packing19:57
*** dhiraj24 has quit IRC20:02
sf-slack1<acomodi> litghost: All right. What is still needed to merge and start using @mkurc work on splitting tiles? (Provided that we test that there is no regression wrt the current status)20:02
*** acomodi has joined #symbiflow20:21
*** kraiskil has joined #symbiflow21:06
litghostacomodi: I believe there were regressions with it.  See his comment on
tpbTitle: Scalable test design by mkurc-ant · Pull Request #490 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostacomodi: To be fair, that PR fails on both pre- and post- split21:51
litghostbut the post-split seems worse21:51
litghostIf round robin packing explains the failure, then maybe we are ready to merge the split.  I would like the tile split to have the unified tile names (e.g. just SLICEL/SLICEM), but unclear how much more work is left for that21:52
*** kraiskil has quit IRC21:52
mithrolitghost: Running a db rebuild now22:35
litghostmithro: Thanks22:35
mithrolitghost: What is going on here ->22:40
mithro CLK_HROW_BOT_R ?22:42
tpbTitle: Diff to HTML by rtfpessoa (at
mithroLooks like you renamed some stuff?22:42
litghostmithro: Which are you asking about?22:45
litghostmithro: Segbits for CLK_HROW?22:45
mithrolitghost: Yeah22:46
litghostmithro: Couple things happened.  Turns out the offset and word count was too small to include all the bits in the interconnect, so the offset was lowered, which resulted in all bits getting rebased22:49
litghostmithro: the other thing that happened is that we enabled fuzzing of the entire clk hrow interconnect switch box, which resulted in a bunch of new features22:51
tpbTitle: Comparing SymbiFlow:master...mithro:master · SymbiFlow/prjxray-db · GitHub (at
mithrolitghost: How does that look?23:01
litghostmithro: Looks great23:02
mithrolitghost: Pushed23:04
litghostmithro: Please merge
tpbTitle: arty-a7: add UART harness by acomodi · Pull Request #6 · SymbiFlow/prjxray-db · GitHub (at
litghostmithro: acomodi has tested it, and there is now first class arty support in arch-defs23:05
mithrolitghost: I don't quite understand this harness?23:15
litghosthow so?23:15
litghostI believe it is one button, one LED and a UARt23:16
litghostmithro: How so?23:24
mithrolitghost: Hold on a sec23:24
tpbTitle: gist:c41d7443dab3e6b33df17c9704c0cc57 · GitHub (at
litghostmithro: And?23:35
mithroShouldn't we just add the UART to the ARTY-A7-SWBUT harness? Both the Zybo and Basys SWBUT harness have the UART available... -- then with that change, I'm not sure what the point of the Arty-A7-UART harness is?23:36
tpbTitle: roi_harness: Add ARTY-A7-UART configuration by acomodi · Pull Request #724 · SymbiFlow/prjxray · GitHub (at
mithrolitghost: BTW Have you landed the short switch change?23:39
litghostmithro: Not yet, I've been focused on a large refactor in the fasm2verilog work.  Hopefully with a little more effort that will be ready to merge.23:40
litghostmithro: I don't believe we have evidence that the MUX vs SHORT has been causing a problem.  There does appear to be an issue with the round robin packing interacting with the DRAM bits.23:41
litghostmithro: To be clear I do want to land the PR23:41
mithrolitghost: without the short change vpr might end up trying to use the same wire for two signals?23:41
litghostmithro: But we don't have evidence that has actually happened23:41
litghostmithro: In fact I specifically added logic to the fasm2verilog code to look for such a problem23:42
litghostmithro: And did not see it23:42
mithrolitghost: Oh, I guess the Xilinx parts really only have point-to-point wires... would be more a problem with the long wires which I don't think you are importing at the moment?23:53
litghostmithro: No I do believe that the MUX vs SHORT is a bug, and should be fixed.  I just don't have evidence it is a problem this very minute.23:54
*** futarisIRCcloud has joined #symbiflow23:58
mithrolitghost: I've committed a replacement for that pull request23:59

Generated by 2.13.1 by Marius Gedminas - find it at!