01:17 <sf-slack4> <arvindsrinivasan> So how does the conda package version avoid this issue Lofy

01:18 <sf-slack4> <arvindsrinivasan> Cause I’m curious now if I can diff the ilang files for using the specific versions that the examples use by default and see the source of teh error

05:44 <_whitenotifier-5> [symbiflow-arch-defs] the-centry opened issue #2056: Packing problem - https://git.io/JtblZ

17:28 <sf-slack4> <arvindsrinivasan> > ERROR: Module `FDRE' is used with parameters but is not parametric! @lofty, where did you actually see this error btw?

17:28 <sf-slack4> <arvindsrinivasan> Its not in the ilang file is it?

18:22 <lambda> I missed that discussion yesterday, but it seems to be about https://github.com/SymbiFlow/symbiflow-examples/issues/120, which I reported a while ago

18:23 <litghost> Ya, it seems to be the same issue

18:36 <_whitenotifier-5> [symbiflow-arch-defs] andrewb1999 opened issue #2058: Trade-off pnr time and performance - https://git.io/JtNIg

18:49 <sf-slack4> <arvindsrinivasan> Yea its the same issue

18:50 <sf-slack4> <timo.callahan> Symbiflow-LiteX questions: I got a SymbiFlow build working for a LiteX-based project I'm working on, using simply --toolchain=symbiflow. Arty A735T board. I first tried at 80MHz since I saw that on a Zephyr webpage; the bitstream kind of worked (I got the lightchaser and LiteX prompt) but there were memory errors reported (address and data), and the firmware hung at `Liftoff!`. I then tried building at

18:50 <sf-slack4> 100MHz, and it all worked perfectly! I remember a long time ago (months!) building LiteX at 50MHz, which was too slow for the memory, but then I thought it worked at 60MHz. So are the errors I'm seeing at 80MHz unexpected?

18:53 <sf-slack4> <timo.callahan> This is the webpage that recommended an 80MHz clk: https://docs.zephyrproject.org/latest/boards/riscv/litex_vexriscv/doc/index.html : `cd litex/litex/boards/targets && ./arty.py --toolchain symbiflow --cpu-type vexriscv --sys-clk-freq 80e6 --build`, which again, didn't work for me due to memory errors reported from LiteX BIOS.

18:53 <tpb> Title: LiteX VexRiscv Zephyr Project Documentation (at docs.zephyrproject.org)

18:53 <litghost> What's the timing report say at 80 MHz and 100 MHz?

18:54 <litghost> If the timing report shows slack violations at both speeds, the fact that it appears to work at 100 MHz might just be luck

18:54 <litghost> It is also possible that the solution at 100 MHz has less of a slack violation than the design at 80 MHz, which means that it has a high change of working

18:55 <litghost> Another thing to try is multiple seeds into VPR

18:56 <litghost> It is possible that 9/10 designs close timing at 80 MHz, but you got unlucky, and 5/10 designs close timing at 100 MHz, and you happened to get luck reversed

18:56 <sf-slack4> <timo.callahan> Hmm yeah, there are some pretty large negative slacks reported at 100MHz.

18:56 <litghost> Then I expect that it isn't really working at 100 MHz, you are just getting luck

18:56 <sf-slack4> <timo.callahan> Yep

18:57 <litghost> One thing to double check is run the design through the Vivado timing analysis as a sanity check and see if the VPR slack analysis was wrong

18:57 <litghost> We've had some bugs in the timing model that resulted in invalid timing analysis in both directions

18:57 <litghost> But it is believed that the remaining errors are small

18:59 <sf-slack4> <timo.callahan> I see some paths involving the PLL that have data required time of 0.479, not the usual 10.0+delta. xilinxasyncresetsyncronizer? Is that false path?

19:01 <litghost> Possible? I don't have enough information from that statement, but it is possible

19:01 <andrewb1999> timo.callahan: I remember someone mentioning there were issues with the liteDRAM core itself. In the past I have tried the liteDRAM core on Vivado and it only worked properly at 100 MHz.

19:02 <litghost> andrewb1999: We've tested it successfully at 60 and 80 MHz

19:02 <litghost> I believe

19:08 <andrewb1999> litghost: Ah ok maybe it is fixed since when I was testing it.

19:09 <tcal> litghost: andrewb1999: thanks for the info! If I figure out any more I'll post it.

20:07 <sf-slack4> <pgielda> @lambda you are using https://github.com/YosysHQ/yosys repo and conda packages were built from https://github.com/symbiflow/yosys repo...

20:08 <sf-slack4> <pgielda> those repos are not interchangable

20:08 <lambda> pgielda: correct, I believe I also tested it with the vendored version though

20:08 <sf-slack4> <pgielda> what is vendored version?

20:09 <lambda> the symbiflow fork

20:09 <sf-slack4> <pgielda> this is what interests me -- it would be an issue

20:09 <sf-slack4> <pgielda> if it failed against symbiflow/yosys

20:09 <sf-slack4> <pgielda> its kinda expected to fail with YosysHQ/yosys

20:12 <lambda> alright, I hope I can go back to nextpnr soon to avoid all this, the fpga-interchange frontend seems to be making huge progress :)

20:37 <sf-slack4> <arvindsrinivasan> @pgielda I can reproduce that issue with the symbiflow fork as well, it only works with the conda packaged versions

22:58 <sf-slack4> <pgielda> @arvindsrinivasan, I've talked to @kgugala and he wrote to me that he plans to try to reproduce this issue and see whats going on. If you have some additional info -- just paste it to this issue that @lambda opened: https://github.com/SymbiFlow/symbiflow-examples/issues/120

22:58 <sf-slack4> <pgielda> And lets track progress there.