Aloha! Good work on the investigation of problems. The speed grade snafu is a good example why firmware mechanisms really should check that the image is for its device type.
> On 18 Aug 2018, at 02:03, Pavel Shatov <meisterpa...@yandex.ru> wrote: > ... > Now speaking of the particular timing errors, they are in the ChaCha inside > of the CSPRNG. This is consistent with the fact that when running both > unit-tests.py and parallel-signatures.py STM32 locks up in hal_get_random() > waiting for CSPRNG valid status bit to go high. I tried to hardwire the > CSPRNG valid bit to always read 1 and both tests started doing some work and > then failing with HAL_ERROR_CSPRNG_BROKEN, which again makes sense. > > From the timing report I suspect that the problem with ChaCha is that there > are combinatorial adders in chacha_qr.v module. The first obvious thing that > comes to mind is adding registers after them, but maybe I'm wrong, so I'd > leave that to Joachim, because he clearly has a better understanding of how > ChaCha works. To explain further, the ChaCha quarterround contains multiple 64-bit chained adders. The Artix-7 architecture is able to perform 64-bit additions in almost 200 MHz. But double additions, and the slower speed grade causes this to take too many ns to meet timing. I’ll update ChaCha to cut the path and adjust the control FSM to match the two cycle/qr operation accordingly. This should be done by Tuesday afternoon. > Regarding the Makefile, I tried to double-check it for other possible > anomalies. I've discovered two things: > > 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. > > 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. > > > -- > With best regards, > Pavel Shatov > _______________________________________________ > Tech mailing list > Tech@cryptech.is > https://lists.cryptech.is/listinfo/tech _______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech
