| *** tpb has joined #symbiflow | 00:00 | |
| *** Bertl_oO is now known as Bertl_zZ | 01:54 | |
| *** citypw has joined #symbiflow | 02:35 | |
| *** citypw has quit IRC | 02:55 | |
| *** citypw has joined #symbiflow | 02:58 | |
| *** citypw has quit IRC | 04:23 | |
| *** citypw has joined #symbiflow | 04:24 | |
| *** Miyu has joined #symbiflow | 05:49 | |
| *** tweakoz has joined #symbiflow | 05:52 | |
| *** tweakoz has quit IRC | 06:57 | |
| *** Bertl_zZ is now known as Bertl | 08:56 | |
| *** futarisIRCcloud has quit IRC | 09: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 bits | 09:24 |
|---|---|---|
| *** Bertl is now known as Bertl_oO | 10:32 | |
| *** proteusguy has joined #symbiflow | 10:55 | |
| *** Maya-sama has joined #symbiflow | 11:01 | |
| *** Miyu has quit IRC | 11:05 | |
| *** celadon_ has quit IRC | 11:38 | |
| *** celadon has joined #symbiflow | 11:38 | |
| *** Maya-sama is now known as Miyu | 11:40 | |
| *** Miyu has quit IRC | 12:03 | |
| *** Miyu has joined #symbiflow | 12:04 | |
| hackerfoo | ZirconiumX is starting work on documenting the Cyclone V bitsteam: https://github.com/ZirconiumX/mistral | 14:22 |
| tpb | Title: GitHub - ZirconiumX/mistral (at github.com) | 14:22 |
| *** citypw has quit IRC | 16: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 #symbiflow | 16:41 | |
| *** proteusguy has quit IRC | 16:57 | |
| *** tweakoz has quit IRC | 17:23 | |
| *** tweakoz has joined #symbiflow | 17:23 | |
| *** tweakoz has quit IRC | 17:24 | |
| *** tweakoz has joined #symbiflow | 17:24 | |
| *** tweakoz has joined #symbiflow | 17:25 | |
| *** tweakoz has quit IRC | 17:25 | |
| *** tweakoz has joined #symbiflow | 17:26 | |
| *** tweakoz has joined #symbiflow | 17:27 | |
| *** tweakoz has quit IRC | 17:27 | |
| *** tweakoz has joined #symbiflow | 17:27 | |
| *** tweakoz has quit IRC | 17:28 | |
| *** tweakoz has joined #symbiflow | 17:28 | |
| *** tweakoz has joined #symbiflow | 17:29 | |
| *** tweakoz has quit IRC | 17:29 | |
| sf-slack2 | <butta> @litghost I can't get that branch to build | 18:54 |
| sf-slack2 | <butta> I get this error | 18: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 2 | 18:54 |
| sf-slack2 | <butta> Does this require a different version of conda from symbiflow-arch-defs master? | 18:55 |
| litghost | Butta: I've been seeing conda flag issues, and haven't been able to determine what is happening | 18:57 |
| 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:58 |
| litghost | I haven't been able to pin down what is causing the flag change to date | 18:59 |
| sf-slack2 | <butta> Is there a quick change I can make just to get it to build for now? | 19:00 |
| litghost | butta: Did you start with a clean build folder? | 19:02 |
| 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 | 19:03 |
| sf-slack2 | <butta> @litghost yeah I started with a clean build folder | 19:06 |
| 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:07 |
| sf-slack2 | <butta> @litghost The CMakeOutput.log? | 19:22 |
| litghost | Everything from a clean build to the error | 19:24 |
| *** Miyu has quit IRC | 19:34 | |
| sf-slack2 | <butta> @litghost Okay I posted the issue. | 19:38 |
| litghost | butta: Try cleaning the build directory, and run "make all_conda" before any other targets | 19:45 |
| mithro | litghost: That log output is really weird... | 19:46 |
| litghost | mithro: Agreed, I'm try to find where the "weirdness" comes from | 19:46 |
| mithro | hackerfoo: I thought that was already in upstream Yosys... | 19:47 |
| sf-slack2 | <butta> @litghost it says there's no make target for all_conda | 19:47 |
| litghost | butta: Err, did you run CMake in the directory? | 19:49 |
| litghost | butta: E.g. "cd build && cmake .. && make all_conda" | 19:50 |
| hackerfoo | mithro: The repo doesn't contain much, but there is ongoing discussion in #prjmistral, so there is at least some interest now. | 19:50 |
| hackerfoo | And there's this, but I'm not sure how to read it: https://gist.github.com/ZirconiumX/1c75bb187b72702aaf8be20f4b8b619e | 19:52 |
| tpb | Title: observations.txt ยท GitHub (at gist.github.com) | 19:52 |
| hackerfoo | Also discussion in ##openfpga | 19:53 |
| 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:54 |
| litghost | butta: e.g. "git diff master", and make sure you don't have inadvert CMake changes | 19:55 |
| sf-slack2 | <butta> @litghost Not sure what happened but I cloned that branch again and it seems to be working now | 20: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 prjxray_create_edges.py with a RecursionError. | 21:51 |
| 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:51 |
| 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:51 |
| 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:51 |
| 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:51 |
| sf-slack2 | <butta> Any clue how to fix this? Or is this a limitation of the connection box branch? | 21:52 |
| 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:54 |
| litghost | butta: FYI, expanding the ROI like that will cause problems with clock routing | 21:54 |
| litghost | butta: Does that ROI change cause the ROI to extend past CMT X0Y2? | 21:55 |
| litghost | butta: If so, then anything placed in CMT X0Y1 will not be able to use dedicate clock routing | 21:55 |
| litghost | butta: This may explain your earlier reported routing congestion | 21: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 |
| 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:57 |
| litghost | butta: Never mind, I had it right on the first go | 21:59 |
| litghost | butta: Expanding the ROI Y max to 103 causes the ROI to span CMT X0Y1 and X0Y2 | 22:00 |
| 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 | 22:00 |
| 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 | 22:01 |
| litghost | butta: Work is on going to enable VPR to place/route clock resource, that is not currently supported | 22:02 |
| litghost | *but it is not currently supported | 22:02 |
| sf-slack2 | <butta> @litghost We need 20 brams in our roi which is why we expanded the region like this | 22:03 |
| 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 | 22: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 |
| litghost | butta: No | 22:05 |
| sf-slack2 | <butta> @litghost Okay, thanks | 22:05 |
| 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 | 22:06 |
| sf-slack2 | <butta> @litghost Makes sense | 22:07 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!