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. _______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech
