Thursday, 2019-07-18

*** tpb has joined #symbiflow00:00
*** Bertl_oO is now known as Bertl_zZ03:26
*** citypw has joined #symbiflow03:45
*** citypw has quit IRC04:16
*** citypw has joined #symbiflow04:32
*** Miyu has joined #symbiflow07:13
*** citypw has quit IRC07:26
*** celadon has quit IRC08:39
*** celadon has joined #symbiflow08:39
*** citypw has joined #symbiflow08:48
*** lopsided98 has quit IRC09:50
*** lopsided98 has joined #symbiflow09:51
*** Bertl_zZ is now known as Bertl10:33
*** celadon has quit IRC14:05
*** celadon has joined #symbiflow14:12
*** proteusguy has joined #symbiflow14:26
sf-slack2<butta> @litghost When sourcing the top_bit.v.tcl script from the ff_ce_sr_9_fdre test I get the following Vivado error: ERROR: [Vivado 12-2285] Cannot set LOC property of instance '$abc$5866$auto$$5896.fpga_mux_2CLBLL_L_X12Y116_SLICE_X17Y116_MU| XF8'... Shape is trying to block loc SLICE_X17Y116.A6LUT, however cell CLBLL_L_X12Y116_SLICE_X17Y116_ALUT/LUT6 is already placed at this location15:18
sf-slack2Resolution: When using BEL constraints, ensure the BEL constraints are defined before the LOC constraints to avoid conflicts at a given site.15:18
sf-slack2<butta> Am I doing something wrong here or does this test not work when loading back into Vivado?15:18
sf-slack2<butta> I loaded the top_bit.v as an RTL source, synthesized the design, and then sourced the tcl script15:19
*** Bertl is now known as Bertl_oO15:29
litghostButta: I don't know if we have tested fasm2v in that case.  There are some ordering dependecies that aren't immediately obvious15:44
litghostThat being said, why are you trying to use fasm2v in this particular case?  It isn't a very interesting design15:45
sf-slack2<butta> @litghost I don't care about that particular design.  You just mentioned a week or two ago that everything in ff_ce_sr worked so I picked one randomly.  I have yet to get any case to work.  Is there a specific case you know works?15:50
*** citypw has quit IRC16:06
litghostbutta: fasm2v does generate valid verilog for the ff_ce_sr tests, which is used to perform logical validation pre- and post-place-and-route16:08
litghostbutta: I know that murax_basys_vivado_fasm works at HEAD, which does run the verilog and tcl through Vivado16:09
sf-slack2<butta> @litghost Okay thanks,  I'll try that one16:10
*** acomodi has quit IRC16:22
*** proteusguy has quit IRC16:33
*** proteusguy has joined #symbiflow16:48
*** proteusguy has quit IRC17:07
*** Miyu has quit IRC17:07
sf-slack2<butta> @litghost is murax_basys under tests/9-soc/murax not the test you are talking about?17:43
sf-slack2<butta> I'm on master HEAD and that one also failed when I loaded the tcl in Vivado17:43
sf-slack2<butta> Does the Vivado version matter?17:43
litghostOnly 2017.2 is supported17:44
*** litghost has quit IRC17:53
*** bubble_buster has quit IRC17:53
*** litghost has joined #symbiflow17:53
*** bubble_buster has joined #symbiflow17:53
*** daveshah has quit IRC17:55
*** daveshah has joined #symbiflow17:57
sf-slack2<butta> I'm installing 2017.2 now, but I don't quite understand why this would be a version issue18:14
sf-slack2<butta> @litghost murax_basys works for you when loading back in vivado?18:14
litghostbutta: Yes.  The reason we use 2017.2 is related for some LOC issue, you may be hitting it18:15
tpbTitle: prjxray/ at b339940b2b4ff3d28ff9ba7d9ffa1d9002c157fa · SymbiFlow/prjxray · GitHub (at
litghostbutta: Looks like something changes after 2017.2 that prevents LUT6_2 from being used with a MUXF8, which is weird because as far as we can tell no such limitation exists in hardware18:16
litghostbutta: And fasm2v currently writes all LUT's as LUT6_2, so that would explain what you are seeing18:17
litghostbutta: For additional data:
tpbTitle: MUXF8 vivado compatibility · Issue #14 · SymbiFlow/prjxray · GitHub (at
*** proteusguy has joined #symbiflow18:19
sf-slack2<butta> @litghost Okay that's a strange issue but it definitely explains what we are seeing18:19
sf-slack2<butta> Will try everything again with 2017.2 once it installs18:19
litghostbutta: Ya, sorry for the confusion.  In prjxray we assert that 2017.2 is being used, but didn't add a similiar assertion in symbiflow-arch-defs18:19
*** proteusguy has quit IRC18:33
*** Miyu has joined #symbiflow19:50
sf-slack2<butta> @litghost Does symbiflow-arch-defs have to be built with Vivado 2017.2 for this to work?20:09
sf-slack2<butta> @litghost I just ran murax_basys on 2017.2 and had the same issue20:09
litghostWhat commit are you on?20:10
sf-slack2<butta> master HEAD20:10
sf-slack2<butta> c198d7b1b99ca5f66d129d1a743da539d26770b420:11
sf-slack2<butta> @litghost this is the error I get for murax_basys in 2017.2 ERROR: [Vivado 12-2285] Cannot set LOC property of instance 'CLBLM_L_X10Y110_SLICE_X12Y110_RAM64X1S_C',  for bel C6LUT Conflicting nets for SLICE_X12Y1| 10.C6LUT.WA4 Two net names are: murax.system_uartCtrl.streamFifo_2.ram.1.0.0.DPRA[3] and murax.system_uartCtrl.streamFifo_2.ram.1.0.0.WA[3] Resolution: When using BEL constraints, ensure the BEL constraints20:12
sf-slack2are defined before the LOC constraints to avoid conflicts at a given site.20:12
litghostbutta: Have you modified the yosys BRAM/LUT-RAM configs?20:21
litghostbutta: I ask because I'm fairly suprised to see a RAM64X1S20:22
litghostbutta: My yosys synthesis out is:20:23
litghost=== toplevel ===20:23
litghost   Number of wires:               554020:23
litghost   Number of wire bits:          1508820:23
litghost   Number of public wires:        259920:23
litghost   Number of public wire bits:   1138120:23
litghost   Number of memories:               020:23
litghost   Number of memory bits:            020:23
litghost   Number of processes:              020:23
litghost   Number of cells:               458720:23
litghost     $lut                         160320:23
litghost     CARRY4_VPR                     5620:23
sf-slack2<butta> We've edited it in other places but not in this directory20:24
sf-slack2<butta> This directory I directly cloned and built with no changes20:24
litghostbutta: symbiflow calls out to yosys, which if you've set the YOSYS env var may be outside of the conda version20:25
litghostbutta: If your version of yosys provides a path for RAM64X1S, then that is currently untested20:25
sf-slack2<butta> @litghost Oh okay that might be what's happening20:26
sf-slack2<butta> @litghost Looking at the CMake files for generating the murax_basys eblif it makes the call directly to build/env/conda/bin/yosys in this directory20:29
litghostbutta: Check your synth results and see if you see something akin to what I pasted20:30
sf-slack2<butta> @litghost it is different from what you sent20:33
sf-slack2<butta> @litghost is there an environment variable that tells yosys where to look for the share folder?20:33
litghostbutta: Sort of?  Yosys looks relative it itself20:34
litghostbutta: If the yosys from conda is being invoked, it should be using the files in the conda share folder20:34
litghostbutta: There are exceptions, but it isn't relevant to this case20:34
sf-slack2<butta> @litghost Okay the file relative to the version of yosys it's calling is unmodified20:35
litghostbutta: Anyways, please file an issue, and attach your synthesis log20:37
litghostbutta: Also attach the bitstream that is failing20:37
sf-slack2<butta> @litghost Okay.  Could you send me a toplevel_bit.v and toplevel_bit.v.tcl in the meantime so I can test that it works with my version of Vivado?20:38
litghostbutta: I'll attach mine to the issue20:39
sf-slack2<butta> @litghost GitHub issues doesn't let me upload the bitstream20:46
litghostbutta: Zip it first?20:47
sf-slack2<butta> @litghost Ok posted20:51
sf-slack2<butta> @litghost the zip with the rr_graph is too large to upload to GitHub21:19
sf-slack2<butta> What should I do instead?21:20
litghostbutta: Try a split:
tpbTitle: How to create, split, join and extract zip archives in Linux (at
*** Miyu has quit IRC22:19
hackerfooThis was useful in #prjmistral:
tpbTitle: CRC RevEng: arbitrary-precision CRC calculator and algorithm finder (at
hackerfooProbably a good tool to know about.23:19

Generated by 2.13.1 by Marius Gedminas - find it at!