| *** tpb has joined #symbiflow | 00:00 | |
| mithro | How does someone connect to the slack? | 01:07 |
|---|---|---|
| *** citypw has joined #symbiflow | 03:38 | |
| *** proteusguy has quit IRC | 04:30 | |
| *** proteusguy has joined #symbiflow | 04:50 | |
| *** OmniMancer has joined #symbiflow | 05:44 | |
| *** _whitelogger has quit IRC | 06:22 | |
| *** _whitelogger has joined #symbiflow | 06:25 | |
| *** OmniMancer has quit IRC | 07:12 | |
| *** OmniMancer has joined #symbiflow | 07:13 | |
| *** citypw has quit IRC | 07:21 | |
| *** citypw has joined #symbiflow | 07:33 | |
| *** AnishGG has joined #symbiflow | 08:41 | |
| *** AnishGG has quit IRC | 08:42 | |
| *** AnishGG has joined #symbiflow | 09:32 | |
| *** citypw has quit IRC | 10:09 | |
| sf-slack | <acomodi> https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/9/commits/b61da9718d1f1034b19270d2eefd9f51e05df0ea: with this commit I have separated the chain and non-chain atom prepacking. There is duplicated code which maybe should be avoided, but for now Murax is built and picosoc is taking ages for the routing process (currently it is at the 7th iteration) | 11:20 |
| sf-slack | <kgugala> @mithro just go to symbiflow.slack.com and register | 11:21 |
| sf-slack | <kgugala> @acomodi does this fix the segfault issue? | 11:22 |
| sf-slack | <acomodi> @kgugala I couldn't actually replicate the segfault issue, I have tried to build the `chain_packing` test with non-multiple blocks and it didn't encounter any segfault issue | 11:24 |
| sf-slack | <acomodi> Anyways, I believe that picosoc is probably hard to route within the ROI | 11:25 |
| *** proteusguy has quit IRC | 11:29 | |
| sf-slack | <acomodi> This is the current routing state: https://pastebin.com/ws9CKc5z | 11:55 |
| tpb | Title: ---- ------ ------- ------- ------- ------- ----------------- -------- Iter - Pastebin.com (at pastebin.com) | 11:55 |
| sf-slack | <acomodi> For picosoc | 11:55 |
| *** proteusguy has joined #symbiflow | 12:03 | |
| sf-slack | <acomodi> Picosoc got to the end of routing, now there is another issue (the very last one I suppose): https://pastebin.com/jyUj8GJe | 12:11 |
| tpb | Title: Traceback (most recent call last): File "/home/build/acomodi/symbiflow-arch-d - Pastebin.com (at pastebin.com) | 12:11 |
| sf-slack | <mkurc> @litghost: I checked the possibility to have DRAMs with explicit clock inversion (by instantiating DRAM and DRAM_1 for inversion). It turns out that not all of DRAM primitives have a "_1" counterparts. But all of them has a "IS_WCLK_INVERTED" parameter. Here is a synthesis log, I tried to instantiate all combinations, these are the ones that succeeded: https://pastebin.com/raw/1LATrh9i | 12:38 |
| *** OmniMancer has quit IRC | 13:47 | |
| sf-slack | <kgugala> @acomodi your error looks like there is something missing in the database | 14:07 |
| sf-slack | <acomodi> Yes indeed I have filed an issue here: https://github.com/SymbiFlow/prjxray/issues/677 | 14:18 |
| tpb | Title: BRAM SDP_WRITE_WIDTH_36 not found when building bram_sdp_test · Issue #677 · SymbiFlow/prjxray · GitHub (at github.com) | 14:18 |
| sf-slack | <acomodi> And for the brk hard blocks issue my first guess would be that routing went beyond the ROI | 14:19 |
| *** citypw has joined #symbiflow | 14:44 | |
| litghost | Ah, the sdp_write_width is a new bit. Rerun the Bram fuzzers until a new db is pushed | 14:56 |
| litghost | mkurc: Okay, let's add back the WCLK parameter and call the yosys side good to go | 14:57 |
| litghost | As for the bike, that may be a ppip, I'll take a look | 15:00 |
| litghost | Brk | 15:00 |
| litghost | acomodi: BRKH_INT_X5Y99 is indeed outside of the ROI | 15:11 |
| sf-slack | <acomodi> Yes, it is just between clk region X0Y1 and X0Y2 | 15:11 |
| litghost | acomodi: Chances are it just wants a bounce | 15:12 |
| litghost | acomodi: Have you visualized the output with fasm2pips? | 15:12 |
| sf-slack | <acomodi> Not yet, I have another run which is about to finish soon and I'll give it a look | 15:13 |
| litghost | acomodi: Did you rerun fuzzer 025? | 15:14 |
| litghost | To pick up the SDP bit/ | 15:14 |
| sf-slack | <acomodi> litghost: No, unfortunately I have started the run before your suggestion, I am also about to start another one with the SDP as soon as the fuzzer completes. It will take a while to route picosoc (~1 hour) for the routing takes 18 iterations | 15:16 |
| sf-slack | <acomodi> BTW I am also adding an option to enable round_robin_packing | 15:17 |
| litghost | acomodi: Try using setting VPR_NUM_WORKERS=64 | 15:17 |
| litghost | acomodi: It's an enviroment variable | 15:17 |
| litghost | Change 64 to a better # | 15:17 |
| litghost | acomodi: Also make sure you are running the release build | 15:18 |
| sf-slack | <acomodi> litghost: Ok. What you mean by release build? | 15:19 |
| litghost | acomodi: Run "grep BUILD CMakeCache.txt" in the vtr build dir | 15:20 |
| sf-slack | <acomodi> litghost: All clear, thanks | 15:21 |
| litghost | acomodi: I think with that latest change, picosoc is correctly placed and routed, plus or minus timing issues | 15:23 |
| litghost | acomodi: One think to examine is rosource utilization between yosys+vpr and vivado | 15:24 |
| litghost | acomodi: Also are you using the DRAM progmem.v or the BRAM progmem.v? | 15:24 |
| litghost | acomodi: If we are still using the DRAM progmem.v that could explain why the routing is so hard | 15:25 |
| sf-slack | <acomodi> litghost: yes, and make sure about that the segfault issue is completely solved | 15:25 |
| sf-slack | <acomodi> litghost: so I have been using the latest master | 15:25 |
| sf-slack | <mkurc> @litghost: Hi there, Right now the picosoc program is stored in DRAM | 15:25 |
| sf-slack | <mkurc> @litghost: But as far as I remember Yosys did infer one BRAM for som other RAM memory in the design | 15:26 |
| sf-slack | <acomodi> @litghost, @mkurc: Ok, than it perfectly makes sense, there is a lot of logic used to store the progmem, probably it is better to move it to BRAMs I guess | 15:27 |
| sf-slack | <mkurc> @acomodi You can examine what resources are used via Yosys. Run the Yosys manually (in interactive mode), import the .eblif file and issue the "stat" command. You should get a list of primitives with counts | 15:28 |
| sf-slack | <mkurc> @litghost: If it is a priority I can make the picosoc use BRAM(s) starting from tomorrow morning. | 15:29 |
| litghost | mkurc: Probably a good plan. FYI after reverting the DRAM IS_WCLK_INVERTED change, I think we might be ready to cleanup and push the yosys changes upstream. I did a diff after merging from master, and it looked pretty good | 15:33 |
| sf-slack | <mkurc> @litghost: Ok, I'll look into it too. | 15:34 |
| sf-slack | <acomodi> litghost, @mkurc: this is the utilization https://pastebin.com/9EdhGE1R | 15:53 |
| tpb | Title: === basys3_demo === Number of wires: 16140 Number of wire - Pastebin.com (at pastebin.com) | 15:53 |
| litghost | 64 DRAM's seems like a low number. That should pack into 32 SLICEM's | 15:54 |
| sf-slack | <mkurc> Yes... Maybe the Yosys did actually infer the BRAM and packed the program into it. There is one BRAM there. | 15:55 |
| sf-slack | <mkurc> Currently there are 759 32-bit words in the program memory | 15:57 |
| sf-slack | <acomodi> `round_robin_packing` is now optional and can be set with a flag, I will add the option to the `xc7 arch-defs` | 16:35 |
| sf-slack | <acomodi> litghost: segfault should be now handled with latest commit on PR#9 | 17:07 |
| *** citypw has quit IRC | 17:31 | |
| elms | It's pretty clunky to work on a change that requires changes vtr and arch-defs. Makes me think a submodule make be better than conda if we foresee a lot more co-development. | 17:44 |
| elms | I guess the downside is build time increase. | 17:45 |
| elms | mithro: litghost: do you know when conda packages are rebuilt (eg vtr)? | 17:51 |
| litghost | elms: Agreed. conda packages are rebuilt when you bump the conda-packages repo | 17:53 |
| litghost | elms: For co-dev, I use the env var override for local development | 17:54 |
| elms | litghost: how do you easily set that? | 17:54 |
| litghost | export VPR=<path to vpr binary> | 17:54 |
| litghost | same as pre-cmake system | 17:55 |
| litghost | I generally have both YOSYS and VPR always set | 17:55 |
| elms | does that work for genfasm? | 17:55 |
| litghost | yep | 17:55 |
| litghost | all binaries from conda can be overridden using the env var | 17:56 |
| elms | cool I thought I tried that but maybe I switched terminals | 17:56 |
| litghost | I have it set in my bashrc | 17:56 |
| litghost | Anyone have experience with 7-series tristate output and tristate feedback? | 17:56 |
| *** lopsided98_ is now known as lopsided98 | 20:45 | |
| sf-slack | <acomodi> litghost: Travis CI build has passed with PR#9 of VTR, tomorrow I'll try to solve the brk issue, but I guess it is good to go now | 21:14 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!