Update environment.yml to use vtr-optimized (vtr compiled with PGO)

[HackerFoo]

No description provided.

[HackerFoo]

@mithro Could you help me figure out why Conda fails? make env works on my workstation.

[HackerFoo]

My theory is that the condarc file in the package causes this, because vtr-gui also fails: https://github.com/HackerFoo/symbiflow-arch-defs/tree/test-ci

GitHub

HackerFoo/symbiflow-arch-defs

FOSS architecture definitions of FPGA hardware useful for doing PnR device generation. - HackerFoo/symbiflow-arch-defs

[HackerFoo]

I think I know what's happening. Some dependencies are coming from conda-forge, so that needs to be included in environment.yml.

[acomodi]

The fact that there are some conda-forge dependencies is a hint that there is something wrong with the vtr-optmized package. Looking at the package description in litex-hub-conda, I see that there is a condarc file which should be deleted from there: https://github.com/litex-hub/litex-conda-eda/blob/master/pnr/vtr-optimized/condarc.

The problem is that conda-forge generates this kinds of issues and leads to instability, and we should not use it at all.

GitHub

litex-hub/litex-conda-eda

Conda recipes for FPGA EDA tools for simulation, synthesis, place and route and bitstream generation. - litex-hub/litex-conda-eda

[HackerFoo]

Unfortunately, there is no other good way to get python-constraint. I can't use pip: conda/conda-build#548

[HackerFoo]

I have created a package for python-constraint to avoid depending on conda-forge: hdl/conda-eda#61

[acomodi]

LGTM, let's wait for CI

[litghost]

LGTM, merge if green

[litghost]

I'm not seeing an improvement in overall runtime. This is likely because most of the time is spent during the lookahead computation. @HackerFoo have you explored/tested PGO improvements on the lookahead computation stuff?

[HackerFoo]

I have not. It might be worth trying a separate PGO build optimized for lookup computation, but it's probably not worth the ~10% performance gain, and I suspect that lookup is mostly memory bound, so it will probably have less effect.

I think the most effective way to improve lookup time is by balancing the parallel workload better, and shortening the tail.