| *** tpb has joined #symbiflow | 00:00 | |
| *** Bertl_oO is now known as Bertl_zZ | 03:26 | |
| *** citypw has joined #symbiflow | 03:45 | |
| *** citypw has quit IRC | 04:16 | |
| *** citypw has joined #symbiflow | 04:32 | |
| *** Miyu has joined #symbiflow | 07:13 | |
| *** citypw has quit IRC | 07:26 | |
| *** celadon has quit IRC | 08:39 | |
| *** celadon has joined #symbiflow | 08:39 | |
| *** citypw has joined #symbiflow | 08:48 | |
| *** lopsided98 has quit IRC | 09:50 | |
| *** lopsided98 has joined #symbiflow | 09:51 | |
| *** Bertl_zZ is now known as Bertl | 10:33 | |
| *** celadon has quit IRC | 14:05 | |
| *** celadon has joined #symbiflow | 14:12 | |
| *** proteusguy has joined #symbiflow | 14: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$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 | 15:18 |
|---|---|---|
| sf-slack2 | Resolution: 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 script | 15:19 |
| *** Bertl is now known as Bertl_oO | 15:29 | |
| litghost | Butta: I don't know if we have tested fasm2v in that case. There are some ordering dependecies that aren't immediately obvious | 15:44 |
| litghost | That being said, why are you trying to use fasm2v in this particular case? It isn't a very interesting design | 15: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 IRC | 16:06 | |
| 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 | 16:08 |
| litghost | butta: I know that murax_basys_vivado_fasm works at HEAD, which does run the verilog and tcl through Vivado | 16:09 |
| sf-slack2 | <butta> @litghost Okay thanks, I'll try that one | 16:10 |
| *** acomodi has quit IRC | 16:22 | |
| *** proteusguy has quit IRC | 16:33 | |
| *** proteusguy has joined #symbiflow | 16:48 | |
| *** proteusguy has quit IRC | 17:07 | |
| *** Miyu has quit IRC | 17: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 Vivado | 17:43 |
| sf-slack2 | <butta> Does the Vivado version matter? | 17:43 |
| litghost | Only 2017.2 is supported | 17:44 |
| *** litghost has quit IRC | 17:53 | |
| *** bubble_buster has quit IRC | 17:53 | |
| *** litghost has joined #symbiflow | 17:53 | |
| *** bubble_buster has joined #symbiflow | 17:53 | |
| *** daveshah has quit IRC | 17:55 | |
| *** daveshah has joined #symbiflow | 17:57 | |
| sf-slack2 | <butta> I'm installing 2017.2 now, but I don't quite understand why this would be a version issue | 18:14 |
| sf-slack2 | <butta> @litghost murax_basys works for you when loading back in vivado? | 18:14 |
| litghost | butta: Yes. The reason we use 2017.2 is related for some LOC issue, you may be hitting it | 18:15 |
| litghost | https://github.com/SymbiFlow/prjxray/blob/b339940b2b4ff3d28ff9ba7d9ffa1d9002c157fa/minitests/clb-muxf8/README.md#L7 | 18:15 |
| tpb | Title: prjxray/README.md at b339940b2b4ff3d28ff9ba7d9ffa1d9002c157fa · SymbiFlow/prjxray · GitHub (at github.com) | 18:15 |
| 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 | 18:16 |
| litghost | butta: And fasm2v currently writes all LUT's as LUT6_2, so that would explain what you are seeing | 18:17 |
| litghost | butta: For additional data: https://github.com/SymbiFlow/prjxray/issues/14 | 18:17 |
| tpb | Title: MUXF8 vivado compatibility · Issue #14 · SymbiFlow/prjxray · GitHub (at github.com) | 18:18 |
| *** proteusguy has joined #symbiflow | 18:19 | |
| sf-slack2 | <butta> @litghost Okay that's a strange issue but it definitely explains what we are seeing | 18:19 |
| sf-slack2 | <butta> Will try everything again with 2017.2 once it installs | 18:19 |
| 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 | 18:19 |
| *** proteusguy has quit IRC | 18:33 | |
| *** Miyu has joined #symbiflow | 19: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 issue | 20:09 |
| litghost | What commit are you on? | 20:10 |
| sf-slack2 | <butta> master HEAD | 20:10 |
| sf-slack2 | <butta> c198d7b1b99ca5f66d129d1a743da539d26770b4 | 20: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 constraints | 20:12 |
| sf-slack2 | are defined before the LOC constraints to avoid conflicts at a given site. | 20:12 |
| litghost | butta: Have you modified the yosys BRAM/LUT-RAM configs? | 20:21 |
| litghost | butta: I ask because I'm fairly suprised to see a RAM64X1S | 20:22 |
| litghost | butta: My yosys synthesis out is: | 20:23 |
| litghost | === toplevel === | 20:23 |
| litghost | Number of wires: 5540 | 20:23 |
| litghost | Number of wire bits: 15088 | 20:23 |
| litghost | Number of public wires: 2599 | 20:23 |
| litghost | Number of public wire bits: 11381 | 20:23 |
| litghost | Number of memories: 0 | 20:23 |
| litghost | Number of memory bits: 0 | 20:23 |
| litghost | Number of processes: 0 | 20:23 |
| litghost | Number of cells: 4587 | 20:23 |
| litghost | $lut 1603 | 20:23 |
| litghost | CARRY4_VPR 56 | 20:23 |
| sf-slack2 | <butta> We've edited it in other places but not in this directory | 20:24 |
| sf-slack2 | <butta> This directory I directly cloned and built with no changes | 20:24 |
| litghost | butta: symbiflow calls out to yosys, which if you've set the YOSYS env var may be outside of the conda version | 20:25 |
| litghost | butta: If your version of yosys provides a path for RAM64X1S, then that is currently untested | 20:25 |
| sf-slack2 | <butta> @litghost Oh okay that might be what's happening | 20: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 directory | 20:29 |
| litghost | butta: Check your synth results and see if you see something akin to what I pasted | 20:30 |
| sf-slack2 | <butta> @litghost it is different from what you sent | 20:33 |
| sf-slack2 | <butta> @litghost is there an environment variable that tells yosys where to look for the share folder? | 20:33 |
| litghost | butta: Sort of? Yosys looks relative it itself | 20:34 |
| litghost | butta: If the yosys from conda is being invoked, it should be using the files in the conda share folder | 20:34 |
| litghost | butta: There are exceptions, but it isn't relevant to this case | 20:34 |
| sf-slack2 | <butta> @litghost Okay the file relative to the version of yosys it's calling is unmodified | 20:35 |
| litghost | butta: Anyways, please file an issue, and attach your synthesis log | 20:37 |
| litghost | butta: Also attach the bitstream that is failing | 20: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 |
| litghost | butta: I'll attach mine to the issue | 20:39 |
| sf-slack2 | <butta> @litghost GitHub issues doesn't let me upload the bitstream | 20:46 |
| litghost | butta: Zip it first? | 20:47 |
| sf-slack2 | <butta> @litghost Ok posted | 20:51 |
| sf-slack2 | <butta> @litghost the zip with the rr_graph is too large to upload to GitHub | 21:19 |
| sf-slack2 | <butta> What should I do instead? | 21:20 |
| litghost | butta: Try a split: http://linuxg.net/how-to-create-split-join-and-extract-zip-archives-in-linux/ | 21:20 |
| tpb | Title: How to create, split, join and extract zip archives in Linux LinuxG.net (at linuxg.net) | 21:20 |
| *** Miyu has quit IRC | 22:19 | |
| hackerfoo | This was useful in #prjmistral: http://reveng.sourceforge.net/ | 23:19 |
| tpb | Title: CRC RevEng: arbitrary-precision CRC calculator and algorithm finder (at reveng.sourceforge.net) | 23:19 |
| hackerfoo | Probably a good tool to know about. | 23:19 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!