<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$blifparse.cc:492:parse_blif$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 location
<sf-slack2>
Resolution: When using BEL constraints, ensure the BEL constraints are defined before the LOC constraints to avoid conflicts at a given site.
<sf-slack2>
<butta> Am I doing something wrong here or does this test not work when loading back into Vivado?
<sf-slack2>
<butta> I loaded the top_bit.v as an RTL source, synthesized the design, and then sourced the tcl script
Bertl is now known as Bertl_oO
<litghost>
Butta: I don't know if we have tested fasm2v in that case. There are some ordering dependecies that aren't immediately obvious
<litghost>
That being said, why are you trying to use fasm2v in this particular case? It isn't a very interesting design
<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?
citypw has quit [Ping timeout: 246 seconds]
<litghost>
butta: fasm2v does generate valid verilog for the ff_ce_sr tests, which is used to perform logical validation pre- and post-place-and-route
<litghost>
butta: I know that murax_basys_vivado_fasm works at HEAD, which does run the verilog and tcl through Vivado
<sf-slack2>
<butta> @litghost Okay thanks, I'll try that one
acomodi has quit [Quit: Connection closed for inactivity]
proteusguy has quit [Ping timeout: 246 seconds]
proteusguy has joined #symbiflow
proteusguy has quit [Ping timeout: 264 seconds]
Miyu has quit [Ping timeout: 272 seconds]
<sf-slack2>
<butta> @litghost is murax_basys under tests/9-soc/murax not the test you are talking about?
<sf-slack2>
<butta> I'm on master HEAD and that one also failed when I loaded the tcl in Vivado
<sf-slack2>
<butta> Does the Vivado version matter?
<litghost>
Only 2017.2 is supported
bubble_buster has quit [Ping timeout: 257 seconds]
litghost has quit [Ping timeout: 257 seconds]
litghost has joined #symbiflow
bubble_buster has joined #symbiflow
daveshah has quit [Ping timeout: 257 seconds]
daveshah has joined #symbiflow
<sf-slack2>
<butta> I'm installing 2017.2 now, but I don't quite understand why this would be a version issue
<sf-slack2>
<butta> @litghost murax_basys works for you when loading back in vivado?
<litghost>
butta: Yes. The reason we use 2017.2 is related for some LOC issue, you may be hitting it
<litghost>
butta: 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 hardware
<litghost>
butta: And fasm2v currently writes all LUT's as LUT6_2, so that would explain what you are seeing
<sf-slack2>
<butta> @litghost Okay that's a strange issue but it definitely explains what we are seeing
<sf-slack2>
<butta> Will try everything again with 2017.2 once it installs
<litghost>
butta: 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-defs
proteusguy has quit [Ping timeout: 272 seconds]
Miyu has joined #symbiflow
<sf-slack2>
<butta> @litghost Does symbiflow-arch-defs have to be built with Vivado 2017.2 for this to work?
<sf-slack2>
<butta> @litghost I just ran murax_basys on 2017.2 and had the same issue
<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 constraints
<sf-slack2>
are defined before the LOC constraints to avoid conflicts at a given site.
<litghost>
butta: Have you modified the yosys BRAM/LUT-RAM configs?
<litghost>
butta: I ask because I'm fairly suprised to see a RAM64X1S
<litghost>
butta: My yosys synthesis out is:
<litghost>
Number of wires: 5540
<litghost>
Number of public wires: 2599
<litghost>
Number of wire bits: 15088
<litghost>
=== toplevel ===
<litghost>
Number of memories: 0
<litghost>
Number of public wire bits: 11381
<litghost>
Number of memory bits: 0
<litghost>
Number of processes: 0
<litghost>
Number of cells: 4587
<litghost>
$lut 1603
<litghost>
CARRY4_VPR 56
<sf-slack2>
<butta> We've edited it in other places but not in this directory
<sf-slack2>
<butta> This directory I directly cloned and built with no changes
<litghost>
butta: symbiflow calls out to yosys, which if you've set the YOSYS env var may be outside of the conda version
<litghost>
butta: If your version of yosys provides a path for RAM64X1S, then that is currently untested
<sf-slack2>
<butta> @litghost Oh okay that might be what's happening
<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 directory
<litghost>
butta: Check your synth results and see if you see something akin to what I pasted
<sf-slack2>
<butta> @litghost it is different from what you sent
<sf-slack2>
<butta> @litghost is there an environment variable that tells yosys where to look for the share folder?
<litghost>
butta: Sort of? Yosys looks relative it itself
<litghost>
butta: If the yosys from conda is being invoked, it should be using the files in the conda share folder
<litghost>
butta: There are exceptions, but it isn't relevant to this case
<sf-slack2>
<butta> @litghost Okay the file relative to the version of yosys it's calling is unmodified
<litghost>
butta: Anyways, please file an issue, and attach your synthesis log
<litghost>
butta: Also attach the bitstream that is failing
<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?
<litghost>
butta: I'll attach mine to the issue
<sf-slack2>
<butta> @litghost GitHub issues doesn't let me upload the bitstream
<litghost>
butta: Zip it first?
<sf-slack2>
<butta> @litghost Ok posted
<sf-slack2>
<butta> @litghost the zip with the rr_graph is too large to upload to GitHub