12-29-2017 04:36 PM
12-29-2017 05:24 PM
@rtfinch Many times when I see this, it is solved with cleaning up your PATH environment variable.
Try reducing it to the minimum, perhaps try setting it explicitly on a shell and starting vivado in the command line to see if it works better.
01-03-2018 01:58 AM
01-30-2018 01:45 PM
02-01-2018 02:01 PM
FYI, the issue has been resolved. Turns out that Vivado 2017.3 crashed when our SRAM code was wrongly modeled, hence got mapped to distributed RAM instead of blockRAM. Because the size as huge, I think the tool somehow ran out of memory.
I was able to isolate this issue because when running using Vivado 2016.2, the tool didn't crash but showed me a warning which gave me the clue to finding the culprit. Perhaps Xilinx could still investigate the discrepancy between how 2016.2 vs 2017.3 handles this scenario.
02-01-2018 10:42 PM
Good to hear that you were able to figure out the root cause for this issue.
If you can share the module or sample RAM code which is inferred as distributed RAM rather than BRAM, this will help us to further investigate this issue.If you can share the testcase please let me know, I will send you ezmove link where you can share the files with Xilinx.