[Cryptech Tech] Getting sync FMC to work

[Rob Austein]

On Fri, 17 Aug 2018 20:03:12 -0400, Pavel Shatov wrote:
> 
> I believe I've finally figured out why the new sync FMC bitstream
> doesn't work. First of all, there's an error in the Makefile, namely
> in core/platform/alpha/build/Makefile on line 15. Part should be
> "xc7a200tfbg484-1", not "xc7a200tfbg484-3". That last digit is the
> speed grade rating which roughly indicates the maximum switching speed
> of the internal configurable logic block. Our boards are populated
> with the slower -1 devices, while in the Makefile the target device is
> -3.

Whoops!  Thanks.

> 1) Multi-threading was not enabled in xilinx.mk, while both map and
> place-and-route tools support multi-threading. From my experience it
> does speed up implementation, not that it cuts run-time in half, of
> course, but still. I've pushed xilinx.mk with multi-threading enabled
> (the corresponding switch is -mt, see commit message). I don't know
> the configuration of the machine where we build packages though, so if
> it only has two cores and we don't want to cripple it, then please
> discard the change.

I think it's reasonable to assume that a machine being used for
synthesis has more than one core.  As it happens, the build VM I use
to generate the public packages has only one core configured, but the
underlying hardware has cores coming out of its ears, so that's just
dumb mis-configuration to be fixed.

If this becomes a serious issue, we can make this a separate makefile
parameter to make it easier to configure.

> 2) SmartGuide was enabled. SmartGuide is a technology that is meant to
> be enabled late in the design phase when you are only doing small
> changes. It claims to speed up the implementation by reusing the
> previous implementation result as a reference and trying to keep as
> much of the placement and routing as possible and only touching nets
> that have changed. From my experience it doesn't work very well,
> moreover when the changes are substantial (eg. different configuration
> of the core selector) it only makes things worse, because it's easier
> to do everything from scratch than to convert one design into
> another. I'm also afraid SmartGuide can prevent us from having
> reproducible builds. Suppose that one clones our sources and starts
> building. His tools will work from scratch and build a bitstream. Now
> if we build a package and don't do 'make clean' beforehand the tools
> will work in that "guided" mode and may build a different
> bitstream. Both bitstreams will function correctly, but they may be
> different. Not a very good situation, I guess. Xilinx tools are
> already a blackbox, and SmartGuide is a blockbox inside of a
> blackbox. I believe that the fewer blackboxes the better, so I'd
> suggest disabling SmartGuide altogether.

This makes sense to me.