Friday, 2019-07-12

*** tpb has joined #symbiflow00:00
*** Bertl_oO is now known as Bertl_zZ01:54
*** citypw has joined #symbiflow02:35
*** citypw has quit IRC02:55
*** citypw has joined #symbiflow02:58
*** citypw has quit IRC04:23
*** citypw has joined #symbiflow04:24
*** Miyu has joined #symbiflow05:49
*** tweakoz has joined #symbiflow05:52
*** tweakoz has quit IRC06:57
*** Bertl_zZ is now known as Bertl08:56
*** futarisIRCcloud has quit IRC09:03
sf-slack2<acomodi> Turns out my supposition was wrong, the IN_FIFO and OUT_FIFO are not used at all by Arty litex and they are relative to the column next to the one with the missing bits09:24
*** Bertl is now known as Bertl_oO10:32
*** proteusguy has joined #symbiflow10:55
*** Maya-sama has joined #symbiflow11:01
*** Miyu has quit IRC11:05
*** celadon_ has quit IRC11:38
*** celadon has joined #symbiflow11:38
*** Maya-sama is now known as Miyu11:40
*** Miyu has quit IRC12:03
*** Miyu has joined #symbiflow12:04
hackerfooZirconiumX is starting work on documenting the Cyclone V bitsteam:
tpbTitle: GitHub - ZirconiumX/mistral (at
*** citypw has quit IRC16:06
sf-slack2<mkurc> This day I investigated an alternative solution than segmatch for fuzzing. The method I proposed allowed me to solve all bits for IDELAY which couldn't be solved by the segmatch.16:23
*** tweakoz has joined #symbiflow16:41
*** proteusguy has quit IRC16:57
*** tweakoz has quit IRC17:23
*** tweakoz has joined #symbiflow17:23
*** tweakoz has quit IRC17:24
*** tweakoz has joined #symbiflow17:24
*** tweakoz has joined #symbiflow17:25
*** tweakoz has quit IRC17:25
*** tweakoz has joined #symbiflow17:26
*** tweakoz has joined #symbiflow17:27
*** tweakoz has quit IRC17:27
*** tweakoz has joined #symbiflow17:27
*** tweakoz has quit IRC17:28
*** tweakoz has joined #symbiflow17:28
*** tweakoz has joined #symbiflow17:29
*** tweakoz has quit IRC17:29
sf-slack2<butta> @litghost I can't get that branch to build18:54
sf-slack2<butta> I get this error18:54
sf-slack2<butta> usage: conda [-h] [-V] command ... conda: error: unrecognized arguments: --force-reinstall CMakeFiles/conda_yosys.dir/build.make:60: recipe for target 'env/conda/bin/yosys' failed make[3]: *** [env/conda/bin/yosys] Error 218:54
sf-slack2<butta> Does this require a different version of conda from symbiflow-arch-defs master?18:55
litghostButta: I've been seeing conda flag issues, and haven't been able to determine what is happening18:57
litghostIn theory we have fixed the conda version to avoid flag issues, but for some reason some times we get a version of conda that accepts --force and sometimes it accepts --force-reinstall18:58
litghostI haven't been able to pin down what is causing the flag change to date18:59
sf-slack2<butta> Is there a quick change I can make just to get it to build for now?19:00
litghostbutta: Did you start with a clean build folder?19:02
litghostbutta: Travis CI and Kokoro are both starting with clean build folders, are seem to be working, so it is possible something remotely changed with conda that caused the change19:03
sf-slack2<butta> @litghost yeah I started with a clean build folder19:06
litghostbutta: Please file an issue with the log of your run, I'll compare it against travis CI's successfully run.  This issue started in the last couple weeks, and it is not clear what the cause is19:07
sf-slack2<butta> @litghost The CMakeOutput.log?19:22
litghostEverything from a clean build to the error19:24
*** Miyu has quit IRC19:34
sf-slack2<butta> @litghost Okay I posted the issue.19:38
litghostbutta: Try cleaning the build directory, and run "make all_conda" before any other targets19:45
mithrolitghost: That log output is really weird...19:46
litghostmithro: Agreed, I'm try to find where the "weirdness" comes from19:46
mithrohackerfoo: I thought that was already in upstream Yosys...19:47
sf-slack2<butta> @litghost it says there's no make target for all_conda19:47
litghostbutta: Err, did you run CMake in the directory?19:49
litghostbutta: E.g. "cd build && cmake .. && make all_conda"19:50
hackerfoomithro: The repo doesn't contain much, but there is ongoing discussion in #prjmistral, so there is at least some interest now.19:50
hackerfooAnd there's this, but I'm not sure how to read it:
tpbTitle: observations.txt ยท GitHub (at
hackerfooAlso discussion in ##openfpga19:53
litghostbutta: Something very strange in your log is the lack of "[  0%] Built target file_env_conda_bin_conda".  Can you diff your branch and make sure you haven't made an accidental revert to the cmake system?19:54
litghostbutta: e.g. "git diff master", and make sure you don't have inadvert CMake changes19:55
sf-slack2<butta> @litghost Not sure what happened but I cloned that branch again and it seems to be working now20:00
sf-slack2<butta> @litghost Was able to build the rr_graph with the connection box branch.  However, we need more brams for our tests than can be provided by the typical ROI.  With the master of symbiflow-arch-defs, increasing the ROI size is as simple as changing the design.json roi y max to 103.  But when I do the same with the connection box branch, building the architecture fails in with a RecursionError.21:51
sf-slack2<butta> Traceback (most recent call last):   File "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/xc7/utils/", line 1845, in <module>     main()   File "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/xc7/utils/", line 1828, in main     annotate_pin_feeds(conn)   File "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/xc7/utils/",21:51
sf-slack2line 1521, in annotate_pin_feeds     tracks=list(),   File "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/xc7/utils/", line 1428, in walk_and_mark_segment     pin_graph_node_pkey, tracks   File "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/xc7/utils/", line 1428, in walk_and_mark_segment     pin_graph_node_pkey, tracks   File21:51
sf-slack2"/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/xc7/utils/", line 1428, in walk_and_mark_segment     pin_graph_node_pkey, tracks   [Previous line repeated 990 more times]   File "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/xc7/utils/", line 1356, in walk_and_mark_segment     graph_node_type = NodeType(cur.fetchone()[0])   File21:51
sf-slack2"/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/build/env/conda/lib/python3.7/", line 310, in __call__     return cls.__new__(cls, value)   File "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/build/env/conda/lib/python3.7/", line 530, in __new__     if type(value) is cls: RecursionError: maximum recursion depth exceeded while calling a Python object21:51
sf-slack2<butta> Any clue how to fix this?  Or is this a limitation of the connection box branch?21:52
litghostbutta: I haven't seen that issue arise.  It is certainly a bug in the code, as I don't believe the routing graph has a loop, which is what would be required for that code to behave like that21:54
litghostbutta: FYI, expanding the ROI like that will cause problems with clock routing21:54
litghostbutta: Does that ROI change cause the ROI to extend past CMT X0Y2?21:55
litghostbutta: If so, then anything placed in CMT X0Y1 will not be able to use dedicate clock routing21:55
litghostbutta: This may explain your earlier reported routing congestion21:56
sf-slack2<butta> @litghost Cause clock routing problems in what way?  We are moving the synth_tiles to PBlock partition pins that are generated by Vivado.  Are the clock resources just not there for CMT X0Y1 or is it just an issue with the prjxray ROI synth_tile locations?21:56
litghostbutta: It looks like you are just trying to ensure that BRAM_L_X6Y50 is in the ROI, which is part of CMT X0Y221:57
litghostbutta: Never mind, I had it right on the first go21:59
litghostbutta: Expanding the ROI Y max to 103 causes the ROI to span CMT X0Y1 and X0Y222:00
litghostbutta: Because the ROI brings the clock in via the CMT X0Y2 clock network, anything in CMT X0Y1 will not have access to dedicate clock resources22:00
litghostbutta: Until clock resources are place/routable by VPR (which they are currently not), anything in CMT X0Y1 will lack access to the dedicate clock network22:01
litghostbutta: Work is on going to enable VPR to place/route clock resource, that is not currently supported22:02
litghost*but it is not currently supported22:02
sf-slack2<butta> @litghost We need 20 brams in our roi which is why we expanded the region like this22:03
litghostbutta: I understand your requirement, but it doesn't change the fact that only one CMT can currently use dedicated clock resources.  This is a known limitation22:04
sf-slack2<butta> @litghost Okay that might be explaining some of what we're seeing.  Is there any way to get around this so we can have access to the 20 brams?22:04
litghostbutta: No22:05
sf-slack2<butta> @litghost Okay, thanks22:05
litghostbutta: I want to be clear, this is something that is actively being worked on, but until that work is complete, this limitation will continue22:06
sf-slack2<butta> @litghost Makes sense22:07

Generated by 2.13.1 by Marius Gedminas - find it at!