Wednesday, 2019-02-27

*** tpb has joined #symbiflow00:00
mithroHow does someone connect to the slack?01:07
*** citypw has joined #symbiflow03:38
*** proteusguy has quit IRC04:30
*** proteusguy has joined #symbiflow04:50
*** OmniMancer has joined #symbiflow05:44
*** _whitelogger has quit IRC06:22
*** _whitelogger has joined #symbiflow06:25
*** OmniMancer has quit IRC07:12
*** OmniMancer has joined #symbiflow07:13
*** citypw has quit IRC07:21
*** citypw has joined #symbiflow07:33
*** AnishGG has joined #symbiflow08:41
*** AnishGG has quit IRC08:42
*** AnishGG has joined #symbiflow09:32
*** citypw has quit IRC10:09
sf-slack<acomodi> 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 and register11: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 issue11:24
sf-slack<acomodi> Anyways, I believe that picosoc is probably hard to route within the ROI11:25
*** proteusguy has quit IRC11:29
sf-slack<acomodi> This is the current routing state:
tpbTitle: ---- ------ ------- ------- ------- ------- ----------------- -------- Iter - (at
sf-slack<acomodi> For picosoc11:55
*** proteusguy has joined #symbiflow12:03
sf-slack<acomodi> Picosoc got to the end of routing, now there is another issue (the very last one I suppose):
tpbTitle: Traceback (most recent call last): File "/home/build/acomodi/symbiflow-arch-d - (at
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:
*** OmniMancer has quit IRC13:47
sf-slack<kgugala> @acomodi your error looks like there is something missing in the database14:07
sf-slack<acomodi> Yes indeed I have filed an issue here:
tpbTitle: BRAM SDP_WRITE_WIDTH_36 not found when building bram_sdp_test · Issue #677 · SymbiFlow/prjxray · GitHub (at
sf-slack<acomodi> And for the brk hard blocks issue my first guess would be that routing went beyond the ROI14:19
*** citypw has joined #symbiflow14:44
litghostAh, the sdp_write_width is a new bit.  Rerun the Bram fuzzers until a new db is pushed14:56
litghostmkurc: Okay, let's add back the WCLK parameter and call the yosys side good to go14:57
litghostAs for the bike, that may be a ppip, I'll take a look15:00
litghostacomodi: BRKH_INT_X5Y99 is indeed outside of the ROI15:11
sf-slack<acomodi> Yes, it is just between clk region X0Y1 and X0Y215:11
litghostacomodi: Chances are it just wants a bounce15:12
litghostacomodi: 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 look15:13
litghostacomodi: Did you rerun fuzzer 025?15:14
litghostTo 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 iterations15:16
sf-slack<acomodi> BTW I am also adding an option to enable round_robin_packing15:17
litghostacomodi: Try using setting VPR_NUM_WORKERS=6415:17
litghostacomodi: It's an enviroment variable15:17
litghostChange 64 to a better #15:17
litghostacomodi: Also make sure you are running the release build15:18
sf-slack<acomodi> litghost: Ok. What you mean by release build?15:19
litghostacomodi: Run "grep BUILD CMakeCache.txt" in the vtr build dir15:20
sf-slack<acomodi> litghost: All clear, thanks15:21
litghostacomodi: I think with that latest change, picosoc is correctly placed and routed, plus or minus timing issues15:23
litghostacomodi: One think to examine is rosource utilization between yosys+vpr and vivado15:24
litghostacomodi: Also are you using the DRAM progmem.v or the BRAM progmem.v?15:24
litghostacomodi: If we are still using the DRAM progmem.v that could explain why the routing is so hard15:25
sf-slack<acomodi> litghost: yes, and make sure about that the segfault issue is completely solved15:25
sf-slack<acomodi> litghost: so I have been using the latest master15:25
sf-slack<mkurc> @litghost: Hi there, Right now the picosoc program is stored in DRAM15:25
sf-slack<mkurc> @litghost: But as far as I remember Yosys did infer one BRAM for som other RAM memory in the design15: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 guess15: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 counts15:28
sf-slack<mkurc> @litghost: If it is a priority I can make the picosoc use BRAM(s) starting from tomorrow morning.15:29
litghostmkurc: 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 good15:33
sf-slack<mkurc> @litghost: Ok, I'll look into it too.15:34
sf-slack<acomodi> litghost, @mkurc: this is the utilization
tpbTitle: === basys3_demo === Number of wires: 16140 Number of wire - (at
litghost64 DRAM's seems like a low number.  That should pack into 32 SLICEM's15: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 memory15: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#917:07
*** citypw has quit IRC17:31
elmsIt'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
elmsI guess the downside is build time increase.17:45
elmsmithro: litghost: do you know when conda packages are rebuilt (eg vtr)?17:51
litghostelms: Agreed.  conda packages are rebuilt when you bump the conda-packages repo17:53
litghostelms: For co-dev, I use the env var override for local development17:54
elmslitghost: how do you easily set that?17:54
litghostexport VPR=<path to vpr binary>17:54
litghostsame as pre-cmake system17:55
litghostI generally have both YOSYS and VPR always set17:55
elmsdoes that work for genfasm?17:55
litghostall binaries from conda can be overridden using the env var17:56
elmscool I thought I tried that but maybe I switched terminals17:56
litghostI have it set in my bashrc17:56
litghostAnyone have experience with 7-series tristate output and tristate feedback?17:56
*** lopsided98_ is now known as lopsided9820: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 now21:14

Generated by 2.13.1 by Marius Gedminas - find it at!