Maciej Kurc

IMO we should treat the Symbiflow backend and a "pure" VPR backend as separate. The reason is that Symbiflow architectures that use VPR rely on dedicated helper scripts that are...

@WhiteNinjaZ Hmm, weird. How are you building your designs? Using installed toolchain? Have you tested the MMCM test design(s) built using CMake? Those are under `xc/xc7/tests/mmcm`. The `MMCM` parameters have...

@WhiteNinjaZ To debug this you may run the "diff FASM" test. This will use SymbiFlow to generate a bitstream, then disassemble it and convert back to netlist via `fasm2bels` followed...

@WhiteNinjaZ Plase take look at the `MMCM` tests which are in `symbiflow-arch-defs`: https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc/xc7/tests/mmcm. You can add you test alongside them. This will allow you to run the diff FASM test....

@nelsobe From what I remember when working on MMCM and PLL there are no bits that relate one-to-one to the COMPENSATION parameter. The only influence of the parameter on bitstream...

@nelsobe I'd say that making a default value for a parameter is not a big deal on its own. Testing the MMCM behavior in multiple scenarios may require a little...

Vendor tool tests (Vivado) fails on the PLL test with: ``` ERROR: [DRC PLCR-1] Placement Constraints Check for Clock Region(s): Design Check found an error in Clock Region X0Y0. This...

The `BUFHCE` route-through was fixed in `fasm2bels` some time ago. I've rebased this PR.

:/ Looks like there are some conflicting bits in the `prjxray-db` related to routing around `PLL`: ``` prjxray.fasm_assembler.FasmInconsistentBits: FASM line "CMT_TOP_R_UPPER_T_X8Y44.CMT_TOP_R_UPPER_T_PLLE2_CLKIN1.CMT_TOP_R_UPPER_T_CLKIN1" wanted to clear bit (4194461, 74, 0) but was...

@acomodi Thanks, I've just done that. I was under impression that we used the most recent one on master.