09:16 <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 bits

14:13 <hackerfoo> ZirconiumX is starting work on documenting the Cyclone V bitsteam: https://github.com/ZirconiumX/mistral

14:13 <tpb> Title: GitHub - ZirconiumX/mistral (at github.com)

16:14 <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.

18:45 <sf-slack2> <butta> @litghost I can't get that branch to build

18:45 <sf-slack2> <butta> I get this error

18:45 <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 2

18:46 <sf-slack2> <butta> Does this require a different version of conda from symbiflow-arch-defs master?

18:48 <litghost> Butta: I've been seeing conda flag issues, and haven't been able to determine what is happening

18:49 <litghost> In 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-reinstall

18:50 <litghost> I haven't been able to pin down what is causing the flag change to date

18:51 <sf-slack2> <butta> Is there a quick change I can make just to get it to build for now?

18:53 <litghost> butta: Did you start with a clean build folder?

18:54 <litghost> butta: 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 change

18:57 <sf-slack2> <butta> @litghost yeah I started with a clean build folder

18:58 <litghost> butta: 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 is

19:13 <sf-slack2> <butta> @litghost The CMakeOutput.log?

19:15 <litghost> Everything from a clean build to the error

19:29 <sf-slack2> <butta> @litghost Okay I posted the issue.

19:36 <litghost> butta: Try cleaning the build directory, and run "make all_conda" before any other targets

19:37 <mithro> litghost: That log output is really weird...

19:37 <litghost> mithro: Agreed, I'm try to find where the "weirdness" comes from

19:38 <mithro> hackerfoo: I thought that was already in upstream Yosys...

19:38 <sf-slack2> <butta> @litghost it says there's no make target for all_conda

19:40 <litghost> butta: Err, did you run CMake in the directory?

19:41 <litghost> butta: E.g. "cd build && cmake .. && make all_conda"

19:41 <hackerfoo> mithro: The repo doesn't contain much, but there is ongoing discussion in #prjmistral, so there is at least some interest now.

19:43 <hackerfoo> And there's this, but I'm not sure how to read it: https://gist.github.com/ZirconiumX/1c75bb187b72702aaf8be20f4b8b619e

19:43 <tpb> Title: observations.txt · GitHub (at gist.github.com)

19:44 <hackerfoo> Also discussion in ##openfpga

19:45 <litghost> butta: 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:46 <litghost> butta: e.g. "git diff master", and make sure you don't have inadvert CMake changes

19:51 <sf-slack2> <butta> @litghost Not sure what happened but I cloned that branch again and it seems to be working now

21:42 <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 prjxray_create_edges.py with a RecursionError.

21:42 <sf-slack2> <butta> Traceback (most recent call last): File "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/xc7/utils/prjxray_create_edges.py", line 1845, in <module> main() File "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/xc7/utils/prjxray_create_edges.py", line 1828, in main annotate_pin_feeds(conn) File "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/xc7/utils/prjxray_create_edges.py",

21:42 <sf-slack2> line 1521, in annotate_pin_feeds tracks=list(), File "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/xc7/utils/prjxray_create_edges.py", line 1428, in walk_and_mark_segment pin_graph_node_pkey, tracks File "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/xc7/utils/prjxray_create_edges.py", line 1428, in walk_and_mark_segment pin_graph_node_pkey, tracks File

21:42 <sf-slack2> "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/xc7/utils/prjxray_create_edges.py", 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/prjxray_create_edges.py", line 1356, in walk_and_mark_segment graph_node_type = NodeType(cur.fetchone()[0]) File

21:42 <sf-slack2> "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/build/env/conda/lib/python3.7/enum.py", line 310, in __call__ return cls.__new__(cls, value) File "/scratch/safe/SymbiFlow/symbiflow-arch-defs.litghostfresh/build/env/conda/lib/python3.7/enum.py", line 530, in __new__ if type(value) is cls: RecursionError: maximum recursion depth exceeded while calling a Python object

21:43 <sf-slack2> <butta> Any clue how to fix this? Or is this a limitation of the connection box branch?

21:45 <litghost> butta: 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 that

21:45 <litghost> butta: FYI, expanding the ROI like that will cause problems with clock routing

21:46 <litghost> butta: Does that ROI change cause the ROI to extend past CMT X0Y2?

21:46 <litghost> butta: If so, then anything placed in CMT X0Y1 will not be able to use dedicate clock routing

21:47 <litghost> butta: This may explain your earlier reported routing congestion

21:47 <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:48 <litghost> butta: It looks like you are just trying to ensure that BRAM_L_X6Y50 is in the ROI, which is part of CMT X0Y2

21:50 <litghost> butta: Never mind, I had it right on the first go

21:51 <litghost> butta: Expanding the ROI Y max to 103 causes the ROI to span CMT X0Y1 and X0Y2

21:52 <litghost> butta: Because the ROI brings the clock in via the CMT X0Y2 clock network, anything in CMT X0Y1 will not have access to dedicate clock resources

21:52 <litghost> butta: Until clock resources are place/routable by VPR (which they are currently not), anything in CMT X0Y1 will lack access to the dedicate clock network

21:53 <litghost> butta: Work is on going to enable VPR to place/route clock resource, that is not currently supported

21:53 <litghost> *but it is not currently supported

21:54 <sf-slack2> <butta> @litghost We need 20 brams in our roi which is why we expanded the region like this

21:55 <litghost> butta: 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 limitation

21:55 <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?

21:56 <litghost> butta: No

21:56 <sf-slack2> <butta> @litghost Okay, thanks

21:57 <litghost> butta: I want to be clear, this is something that is actively being worked on, but until that work is complete, this limitation will continue

21:58 <sf-slack2> <butta> @litghost Makes sense