Yosys sensitivity to input changes

acomodi commented 3 years ago

This issue is to keep track of the issue reported here: https://github.com/SymbiFlow/symbiflow-arch-defs/issues/1776.

Problem statement

The auto-generated designs, such as litex, present some small variations in the memory initialization of the BRAMs. This causes a small perturbation in the initial conditions of a test, which lead to major changes in the output results.

This problem might not be only related to the BRAM initialization, but to any small changes that are applied to a specific design, but for the sake of this issue description, we will keep the small BRAM initialization changes as the triggering factor for this issue.

This issue covers the sensitivity of the synthesis step which produces two very different eblifs given a small change in the memory initialization values.

Synthesis

The mem.init changes make yosys produce two completely different output eblifs. There are some tests that need to be performed in order to asses whether the two different eblifs represent the same circuit, and it is just a matter of ordering.

run post_synthesis simulations
apply sorting to the output blifs

The expected output of the synthesis step would be to have only a small number of lines affected, relative to the BRAM initializations.

Steps to reproduce

Get the latest version of symbiflow-arch-defs (https://github.com/SymbiFlow/symbiflow-arch-defs/commit/991c74f0e1d579f143878b22d72ab65235f3c18c at the moment of writing)

Run one of the litex tests as follows:

cd symbiflow-arch-defs
make env
cd build
make minilitex_arty_bit

Save all the run results somewhere
Go to the minilitex_arty build directory and delete the arty_soc directory.
```
cd build/xc/xc7/tests/soc/litex/mini && rm -r arty_soc
```
Re-run the minilitex test, which will trigger a new litex-design generation:
```
make minilitex_arty_eblif
```
Compare the newly generated eblif with the ones saved from the previous run.

acomodi commented 3 years ago

To temporary work-around the litex differences between different builds, a patch might be applied to litex, as this line in the bios source code produce the small changes in the mem init file:

litghost commented 3 years ago

To temporary work-around the litex differences between different builds, a patch might be applied to litex, as this line in the bios source code produce the small changes in the mem init file:

Could we propose a PR for LiteX to #ifdef out that line so we get reproducible builds? They have other #define's for adding and removing stuff from the BIOS header.

acomodi commented 3 years ago

@litghost Sure, opened PR here: https://github.com/enjoy-digital/litex/pull/702

mithro commented 3 years ago

@acomodi Can we split this bug into two seperate things?

[ ] (a) Synthesis issue -- Why does a small change in BRAM contents cause anything other than a small change in the output eblif's BRAM init?
[ ] (b) Packing issue -- Why do two eblifs which should have almost identical content end up at very different packing results?

It could turn out that due to (a) the assumption that in (b) the two eblifs are actually "almost identical" is incorrect.

f4pga / f4pga-arch-defs